|
Over 10 years of community discussion and knowledge are maintained here as a read-only archive. New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC
|
|
 |
|
106
|
PureMVC Manifold / Client Side / Lets talk about the Client Side
|
on: March 13, 2008, 06:36:41
|
The AS3 reference implementation was necessarily designed with client side concerns in mind. At the time of this writing, all of the current documentation for the framework is written from this perspective. Specifically, the documentation examples are in AS3 and Flex. However if you are working on one of the other ports that support Client Side development, you should not have a problem understanding these documents as they are written with you in mind as well. The hope is that as we get some of the other Ports off the ground with demos and utilities, we can create versions of these docs for your Ports so that so much mental mapping is not required of future newcomers. Currently the Ports that support client-side development are AS2, AS3, C#, and Java. - Client side desktop or browser platforms include: Flex, Flash, AIR, Silverlight, JavaFX
- Client side mobile platforms include: FlashLite, Flash, Windows Mobile, J2ME
Currently, for those looking for guidance in developing for these platforms, you are advised, (even if you don't know AS3, Flex, Flash or AIR) to: - Read the primary documentation found in the Docs menu on the PureMVC.org home page, in the order presented.
- Examine some of the demos, beginning with the Employee Admin Flex demo.
- Frequent the forums for the Port that you are working with.
- Aquaint yourself with the Project Owner for the port you are working with.
- If the Port is new, there may not be much documentation or demos. Offer to do a demo or utility. You learn, and it will help the Port and its community get off the ground.
- Post questions often. It points out where the documentation is thin, and the answers provoked serve other readers well.
- It is amazing the power of the human race to learn and progress. It is entirely possible that complete balance in the universe can be achieved if you answer as many questions as you ask.
-=Cliff> |
|
|
|
|
107
|
PureMVC Manifold / Port Authority / Branches, Versions and Tags
|
on: March 13, 2008, 05:16:58
|
Hello all, Lets start with framework version numbers. VersionsUp until now, PureMVC has taken an extremely simplistic approach to version numbering; one minor rev for every change. That's because there have only been 8 changes to the project from the 1.0 version, over a year ago. Because the public was never given access to the source code until it was very stable and the with no further feature aspirations, this versioning approach made sense. In fact the compiled SWC file for Flex didn't even have a version number on it. The shame! So, now, with all the ports, demos and utilities being open to the public we have to have a codified scheme for versioning. After a bit bashing on this getting everything in the repositories where, here is the news on versioning going forward: Ports- Each Port will begin at 0.1 when it begins and rev upward by one minor number (.1) each time there is new functionality: (0.1 to 0.2)
- If there are only bug fixes, these will be micro (.01) increments: (0.8 to 0.8.1)
- If the fixes on the micro number is not yet stable, the number will be odd (0.4.5, 0.9.3)
- When the fixes on the micro number become stable, the number will be even (0.8.2, 1.0.2)
- When the functionality set for a Port is stable and is ready for general use, its major number will be incremented: (0.9 to 1.0).
NOTE: New functionality sets for the framework will be determined for all Ports and carried out across the board. The name of the game is to push all Ports toward a stable state with an appropriate scope. Extension of the framework happens by utilities, not expanding the framework codebase itself. Demos and UtilitiesThe same rules apply but we don't expect so many changes to happen there. Usually the Demo or Utility should work to begin with, and most changes will be updates to make it work with the latest version of the framework when it changes. Therefore Demo and Utility versions will start at 1.0. Branches and TagsDue to its hive-like nature branches will rarely happen in the Manifold project. Since it is not a monolithic codebase with an ever growing feature set, it just shouldn't be necessary. Each revision for release will be tagged. Developers at large are warned to beware of what is on the trunk check out working code from the most recent tag. This can be found on the Downloads page of every project. - Tags for Ports are just the number: (tags/1.0.1)
- Tags for Demos and Utilities are in the format: (MyDemo_1_2)
PROJECT OWNERS NOTE: I will be doing the tagging, so whenever you have a revision needing to be tagged, please let me know. There is a lot of updating to do when a tag is made, not just to the repository but the archive, source view, api docs, live demos, wiki, etc. I am working to automate much of this but for now will handle everything by hand to ensure uniformity. -=Cliff> |
|
|
|
|
108
|
PureMVC Manifold / MultiCore Version / Debugging the MultiCore PureMVC Universe
|
on: March 12, 2008, 06:51:32
|
When you find yourself with several full-fledged applications all running in the same VM, the debugger is going to be your best friend. And since MultiCore implements Multitons instead of Singletons, the only difference is that the Facade now stores a map of IFacade instances instead of one. Same for the other actors. That means anywhere you can get a reference to any facade, you can inspect everything registered in every Core. (In the debugger, that is) See the attached debugger output from the MultiCore Modularity demo. Note that a facade reference has been opened (doesn't matter which one), and you can see hilighted: In Yellow: All three Controller instances (CoolWidget, SuperWidget and Modularity) In Green: All three Facade instances In Red: All three Model instances In Blue: All three View instances with the Mediators for the SuperWidget displayed, and SuperWidgetMediator selected You can get this view by doing: In Flex Builder's Debugger, in the Variables view menu, set Flex->Show Inaccessable Member Variables, and Show Static Variables.
Then set a breakpoint in any Mediator, Command, or Proxy of the Modularity Demo and run it.
Inspect this.facade and you have a handle the entire holographic PureMVC universe.
-=Cliff> |
|
|
|
|
109
|
PureMVC Manifold / MultiCore Version / Facade becomes available in initializeNotifier NOT constructor
|
on: March 11, 2008, 01:47:43
|
Milos pointed out here: http://forums.puremvc.org/index.php?topic=311.msg1212#msg1212...that you can't talk to the facade inside the constructors of your Notifier subclasses (Mediator, Proxy, SimpleCommand) now, you must do any facade access in the initializeNotifier method. This is mentioned in the ASDoc for MultiCore and is shown in the demo, but is worth pointing out explicitly and will be elaborated on soon. The pattern of having an initializeSomething method that is called from the framework class constructor and used to initialize the subclass is in keeping with other classes in the system: - Model.initializeModel
- View.initializeView
- Controller.initializeController
- Facade.initializeFacade
- Facade.initializeModel
- Facade.initializeView
- Facade.initializeController
- MacroCommand.initializeMacroCommand
- and now:
- Notifier.initializeNotifier
It keeps the constructor clean, which helps make easily Notifiers easily subclassed. For instance if you prepare and call a service from your MyProxy constructor then a subclass of MyProxy cannot do the required call to super to pass its name and data object up to the Proxy superclass without executing the unwanted code in the MyProxy constructor. -=Cliff> |
|
|
|
|
|
|
Show Posts
