= Discussions = * '''[http://asteasolutions.net/videos/2009-01-27%20General%20Discussion.mpg (2009-01-27) General Discussion]''' In this video are explained our goals, what we strive to achieve, our challenges and how we shall proceed in order to create a product with high quality. It is recommended everyone to be familiar with this discussion. * [http://asteasolutions.net/videos/2009-01-20%20Design%20Discussion.mpg (2009-01-20) Design Discussion] Detailed log of the discussion is included below. {{{ Topics: = pro_lib = - designed to help people! If they are not helping, either something should be fixed or people do not understand how to use it. * attibute - self responsible. * do not care about initializing order. * good practices: * defaulty constructors. * avoid final properties. * push updates - instead of updating things manually, provide these things the ability to auto-update. * avoid trying to use unconventionally the pro_lib since this is error prone. * Property improper use cases: * accessing an AutoProperty WILL NOT invoke its compute() method! * resource properties: * create method should depend on NOTHING => it is invoked once and will not update things. * setup methods are designed to keep things synchronized for people. @Setup may be put to split setup things in different methods, so that they are updated in groups. * destroy methods are not working. * List properties. = core_modularity = * extensions are now sortable by comparator. = base_visual = == layout == == menus == * this is a new module to split the layout and menus from the main.view things. = base_skins = * provides things to simplify things that are registered for a single skin => currently a map with (id, value) entries. = global things = * few people have a global vision about things. * people should get a better overall idea. * supercool model. * not only implement a great library but find a task to actually use it and also do that task. * this will improve the library. * things that are error prone will appear. * the "not my task/class" problem (people tend to do only things that are tracked and planned): * the code is owned by everyone! * fix things that need to fixed in order to implement you things, otherwise the next revision of the task will fail. * if the things are complicated to be fixed, ask the others, make discussions about it. }}} * AsteaCon 2008 * [http://asteasolutions.net/videos/2008-12-10%20Weekly%20Meeting%20(Part%201).mpg 2008-11-19 1st Day Discussions (Part 1)] * [http://asteasolutions.net/videos/2008-12-10%20Weekly%20Meeting%20(Part%202).mpg 2008-11-19 1st Day Discussions (Part 2)] * [http://asteasolutions.net/~parlev/AsteaCon2008/2008-11-20/ 2008-11-20 2nd Day Discussions] * [http://asteasolutions.net/~parlev/AsteaCon2008/2008-11-21/ 2008-11-21 3rd Day Discussions] During the three days of discussions at Sheraton Hotel between Astea Team and some of our oversea partners detailed information about all aspects of the project was given. * Branding discussions with Robert Abbott from ''Shift Global'' * [http://asteasolutions.net/videos/2009-01-30%20Milo%27s%20Project%20Overview.mpg (2009-01-30) Milo's Project Overview] Project overview of Sophie 2.0 by the team leader which aims to introduce the product to Robert Abbott from Shift Global. * [http://asteasolutions.net/videos/2009-01-30%20Robert%27s%20Branding%20Discussion.mpg (2009-01-30) Robert's Branding Discussion] Discussion between Robert Abbott and Astea Team on which they discussed Sophie 2.0 logo drafts and basic visual wireframes of the future product. * [http://asteasolutions.net/videos/2009-01-31%20Robert%27s%20UI%20Discussion.mpg (2009-01-31) Robert's UI DIscussions] Discussion about Sophie 2.0 user interface and some internal aspects of the project. * [http://asteasolutions.net/videos/2009-01-31%20Sophie2%20Website%20Discussion.mpg (2009-01-31) Sophie2 Website Discussion] Discussion between Astea team and Robert Abbott about the vision and functionality of Sophie 2 website. * [http://asteasolutions.net/videos/2009-02-03%20Milo%27s%20Refactoring%20Discussion.mpg (2009-02-03) Milo's Refactoring Discussion] Milo gives details about the modules that he refactored, and explains his vision about improvement of the code quality. * [http://asteasolutions.net/videos/2009-02-17-Design%20Discussion%20(Part%201).mpg (2009-02-17) Discussion about core.mvc] * common concept of mvc * model * view * controller * interactions among them * past attempts at integrating mvc in sophie2 * R1 * dark ages * pure MVC form * parallel model, view, controller hierarchies * R2 * ProLib * customized form of MVC pattern * nonparaller model, view, controlelr hierarchies * examples of bad code/design * R3 * model - same as R2 * view * view shouldn't modify the model directly, it should fire an event * controller * only single class * a set of operation * enum of operations * each operation has two methods * defineFilter * define what kind of events this operation processes * handleEvent * returns boolean * gets the actual event * try to process it, return wheter the event was processed * sortkey of each operation * event description * OO approach (Swing/AWT) * grouping of similar events * decomposing into class hierarchy * EventR3 * contextData * source - (component, etc.) * context - (a parent view for instance) * tip - (a corresponding model / bad design) * cause - other event (EventR3, Swing event etc.) * target / event specific data * eventId * Ids enum * @EventParams * Place enum * params * enum InputEventR3 * enum InputModifier * CTRL down, SHIFT down.. etc. * ModifierSet * immutable set of InputModifier fields * example: * @EventParams(ModifierSet.class) * [http://asteasolutions.net/videos/2009-02-17-Design%20Discussion%20(Part%202).mpg (2009-02-17) Discussion about base.visual] {{{ G0gOv pR0d\/cT10nZ pR0uDLy pR3s3nTs: ================ PART 2 ================ * base.visual [interaction] * app structure / doc structure correspondence for visuals * interaction is put in skins * sample of what you usually put in a skin * sample of how you add interaction maps in a skin * interaction maps "string language" * skins are meant to be written to/read from human readable string configuration files * brief skin explanation * (input -> user events) map [continued in PART 3]... }}} * [http://asteasolutions.net/videos/2009-02-17-Design%20Discussion%20(Part%203).mpg (2009-02-17) Discussion about base.skins, base.visual (continued), base.model.text] {{{ G0gOv pR0d\/cT10nZ pR0uDLy pR3s3nTs: ================ PART 3 ================ * base.skins * brief skins content description * brief value lookup scheme in skin hierarchy * each skin is consisted of SkinParts * @SkinPartDef * SkinPropId * @SkinElementId ...[continued from PART 2] * userEvents * events/operations/interaction maps relation * SwingEventAdapter * base.model.text * brief overview * HotText * list of HotUnit * HotPos * HotTextLayout * HotTextPane * HotStyleDef * HotStyle * sample use cases and solutions }}} * [http://asteasolutions.net/videos/2009-02-18%20Milo%27s%20Persistence%20Discussion.mpg (2009-02-18) Discussion about base.persistence] * base.persistence * overall description * current format structure * different formats * different entities * resourses * immutables * Pro* * Storage * like XML DOM * used as an internal data format * attributes * children tags * PersistFormat * S - source type * T - destination type * converts between two types * general saving/loading overheads * SharedSaver * saves in Storage * T - Page, Frame... * single saver for each type * save scenario * traverse everything and save it * SharedLoader * multiple loaders for different instances of each type * load scenario * create "blank" objects for each loaded entity * fill in dependencies between objects * savers/loaders and extensions/extension points * @Persist * save this as something * could list multiple @Persist for same field for different target formats * content to be persisted/not persisted * saving/loading immutables * saving/loading Pro* * [http://asteasolutions.net/videos/2009-02-19%20Modularity%20Discussion%20(Part%201).mpg (2009-02-19) Discussion about core.modularity, part 1] * core.modularity * modularization * modules * different understanding of modules, depending on context * classes, packages, source files, .jars, eclipse projects, maven projects, plugins, components * comparison * dependencies between modules * cyclic dependencies * target could be acyclic graph * sample scenario of registering a TetrisFrame * sample solution * works but could be better * uml notations * module * extension * extension point * TetrisFrame scenario adapter to these concepts * scenes examples * core.modularity module * content * SophieModule * SophieExtension * SophieExtensionPoint * comparison with OSGI * convention for such concept * hides OSGI complexity * FakeModule registry * can run in a fake environment * provides a simulation of what happens when app is deployed in an OSGI container * TrueModule registry * content * SophieModule * doStart(), doStop() - shouldn't have to be overriden * defineExtensions(), defineExtensionPoints() - should be overriden * SophieExtension * sortKeys (not present still, will be in the future) * SophieExtensionPoint * ProList of extensions, so it's tracked and easy to use * communication class/interface between extensions and extension points * extension which provides an Integer doesn't work with extension point which requires Number, should be exactly the same * matching extensions with extension points * currently each provided extension maps to each possible extension points which accepts it * Felix, Maven * terminology * pom.xml * module naming convention * accessibility of packages * embedding external modules * embedding vs depending * can have classes with the same name in different modules * example leading to runtime error * creating a module * use proto.project * remove .svn entries * fix pom.xml of module * fix pom.xml of parent module * documented in the wiki (continued in PART 2...) * [http://asteasolutions.net/videos/2009-02-19%20Modularity%20Discussion%20(Part%202).mpg (2009-02-19) Discussion about core.modularity, part 2] ...(continued from PART 1) * the future * list of modules (for displaying in UI for instance) * mechanism of accessing resourses in the modules * platform structure * current structure (in Eclipse) * planned final structure * [http://asteasolutions.net/videos/2009-02-19%20Visual%20Discussion.mpg (2009-02-19) Discussion about base.visual and some brief notes about base.scenes] * base.visual * VisualElement * parent * title * tooltip * VisualElement hierarchy * BaseVisualElement * getSkinValue() * computePropElement() * computeListProp() * findParent() * VisualProvider * SimpleVisualProvider * AutoVisualProvider * @VisualDef * could be used for multiple needs * @Related * tells the AutoVisualProvided which classes to scan for extensions to register * palette tracking current book example * short AutoProperty discussion * base.scenes * short description * starting and stopping needed modules * not enough time... ---- = Weekly Meetings = ITERATION_03 * [http://asteasolutions.net/~boyan/sprint03_week1/ 1st Weekly Meeting] * [http://asteasolutions.net/~parlev/sprint03_week2/ 2nd Weekly Meeting] * [http://asteasolutions.net/~boyan/sprint03_week3/ 3rd Weekly Meeting] ITERATION_04 * [http://asteasolutions.net/videos/2009-01-27%20Weekly%20Meeting.mpg (2009-01-27) 3rd Weekly Meeting] * [http://asteasolutions.net/videos/2009-02-03%20Weekly%20Meeting.mpg (2009-02-03) 4th Weekly Meeting] * [http://asteasolutions.net/videos/2009-02-08%20Sprint%20Closing.mpg (2009-02-08) Sprint Closing] ITERATION_05 * [http://asteasolutions.net/videos/2009-02-10%20Sprint%20Opening.mpg (2009-02-10) 3rd Sprint Opening] * [http://asteasolutions.net/videos/2009-02-17%20Weekly%20Meeting.mpg (2009-02-17 Weekly Meeting] * [http://asteasolutions.net/videos/2009-20-02%20MiniSprint%20Closing%20(Part%201).mpg (2009-02-20) Mini Sprint Closing, part 1] * [http://asteasolutions.net/videos/2009-20-02%20MiniSprint%20Closing%20(Part%202).mpg (2009-02-20) Mini Sprint Closing, part 2]