Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Welcome, Guest. Please login or register.
November 25, 2017, 12:33:25 AM
Home Help Search Login Register
News: Please DM @puremvc on Twitter to gain forum access. Spambots are why we can't have nice things.
  Show Posts
Pages: 1 ... 186 187 [188]
2806  Announcements and General Discussion / Public Demos, Tools and Applications / Re: Flash Develop 3 Project Template on: June 28, 2007, 07:03:40 PM
That's awesome! Flash Develop looks pretty cool and it's just the sort of place this middleware could come in handy to automate project setup.

BTW, they could redistribute the PureMVC.swc with their package if need be for your template dohicky to work, they just need to attribute the source somewhere so that people who are using it can get back to the support site to figure out how to use it Smiley
2807  Announcements and General Discussion / Getting Started / Architecture 101 Course - Interested in testing? on: June 28, 2007, 01:10:11 PM
Hello All,

I'm currently working on a PureMVC Architecture 101 Course, and will soon be looking for interested participants in the process of testing and evaluating the overall courseware structure and effectiveness.

I've delivered extemporaneous multi-day training on Cairngorm, and I've been teaching Flex as an Adobe/Macromedia Certified Instructor since 1.5, and have had a lot of time to observe and think about courseware content, layout and delivery.

I've also felt that the thing that is missing after teaching a week of F2RCA ( http://www.adobe.com/support/training/instructor_led_curriculum/flex2_rca.html ) and F2DC ( http://www.adobe.com/support/training/instructor_led_curriculum/flex2_data_com.html ) or F2BDA ( http://www.adobe.com/support/training/instructor_led_curriculum/flex2_dashboard.html ) is Architecture.

Students come out of these classes, very well aquainted what Flex can do, and ready to build, but without a lot of direction in terms of architecture. I usually point people to the best design pattern books and sites that I know and offer to help with architecture if they need it.

But I think they'd be better served to have their top folks on the project sit through at least a 2 or 3 day structured architecture course in addition to the more development focused courses.

Recently while pondering next steps with PureMVC, I realized that courseware was the best way to proceed. I feel we need simpler examples, and a bunch of 'Hello World's are great for bitesized granularity, but won't really give you the big picture unless they fall within some ordered context.

Fortunately, Implementation Idioms had already layed out a logical way of unfolding the PureMVC design, but was entirely narrative.

With Architecture 101 the overall structure is similar, except there is much less narrative and much more hands on. Units cover the major actors in the applications you will write. There is some preamble to frame the Unit, but quickly it moves to the Labs, each of which has several learning points to be taken away and we set about absorbing them in the Steps for the Lab.

The courseware has a Lab project which you are modifying and a Solution project that you can refer to if you get stuck, though the Student Manual summarizes changes clearly and often.

If this sounds to you like a good way to learn PureMVC, and you'd like to get a first look at it when it is ready for testing, email me at cliff at puremvc dot org.

For businesses, FutureScale will also be offering PureMVC Architecture 101 as onsite instructor-led training in addition to the already available Adobe Flex training.
2808  Announcements and General Discussion / General Discussion / Re: Abstract Classes on: June 28, 2007, 12:00:34 PM
Michael,

A good and logical question. There is only one problem with that; the framework doesn't know your Facade name or package.

The issue (for those just tuning in) is we often want our Mediators and Proxies to have a local reference to the Singleton instance of our concrete Facade. (See for instance pages 20 and 29 of Implementation Idioms: http://puremvc.org/docs/praxis/PureMVC_Best_Practices-1.0.swf)

This keeps us from having to call ApplicationFacade.getInstance() everytime our Mediator or Proxy needs to talk to the concrete Facade.

It would be nice if the Mediator or Proxy had this from birth, so to speak.

So the idiom is to create AbstractMediator and AbstractProxy classes for our application that extend the PureMVC implementations and that fetch and cache a reference to our concrete Facade in its constructor. Then we have all our Mediators and Proxies extend these abstracts rather than the framework classes.

It's also a helpful place to imbue our Mediator or Proxy instance with any other inheritable features we'd like all Mediators or Proxies to have.

Although we don't have to create an AbstractMediator or AbstractProxy, it's one of those things that makes sense at implementation time. And it can't be put into the framework because only in our application will we know the package and name of our custom concrete Facade class.

As with EJB and plenty of other technologies, sometimes this is the sort of thing is best relegated to middleware. (Code generation and notification traffic analysis tools are on the drawing boards, but I'm busy creating PureMVC Architecture 101 Courseware at the moment).

But again, it isn't necessary to create AbstractMediator and AbstractProxy classes, its just a logical implementation time decision that is easy to do and provides a lot of benefit in terms of fewer calls to get the Singleton at runtime.
2809  Announcements and General Discussion / Getting Started / Re: Looks good on: June 21, 2007, 08:52:39 AM
Stephan,

I have been researching screencasting tools, and found one I think will do the job.

A series of screencasts are in order I think. Setting up a project, both with and without Flex Builder. Debugging in Flex Builder.

And of course more and simpler hello worlds. All on the way.
2810  Announcements and General Discussion / Architecture / Re: Application package structure on: June 21, 2007, 07:46:13 AM
Dale,

You got it. Inserting your [app domain] between the app name and the MVC branches is definitely the right place in the package structure to make that break.

The original post sidestepped the whole issue of the slicing of your app into discrete functional areas. It really focused on the factors leading to the sole decision of how to make the split when you come to the tiers, ie: MVC (model, view and controller) or BMVCV (business, model, view, controller, vo).

The further question the reader was left with, (the one you answered perfectly) was:

When we slice the app into functional areas to manage the inevitable explosion of classes as an app becomes less trivial, do we make that split before the MVC (or BMVCV, or whatever) branching or after it, replicated inside each of the branches.

Clearly making that branch immediately after application name will lead to a more sensible and manageable package structure.

However if you found that you created a thousand branches at that 'com.myco.myapp.subsystem' level, it would be prudent to create some grouping for them putting them at a level one deeper like:

com.myco.myapp.subsysgroup.subsystem.model.*
com.myco.myapp.subsysgroup.subsystem.view.*
com.myco.myapp.subsysgroup.subsystem.controller.*

But the point, folks is let the major application domain related branches come *before* the pacakge structure branches made for the sake of MVC framework affinity.

Thanks for bringing this up, Dale. It adds a valuable dimension to the thread.
2811  Announcements and General Discussion / Architecture / Application package structure on: June 20, 2007, 07:00:26 PM
This is a brief post regarding recommended package structure for PureMVC-based applications.

First, if you look at the pacakage structure of the CodePeek application, you see:

com.futurescale.codepeek.*
com.futurescale.codepeek.model.*
com.futurescale.codepeek.view.*
com.futurescale.codepeek.controller.*

If you have a look at the package structure in the CafeTownsend demo, you see:

com.gurufaction.codepeek.*
com.futurescale.codepeek.business.*
com.futurescale.codepeek.controller.*
com.futurescale.codepeek.model.*
com.futurescale.codepeek.view.*
com.futurescale.codepeek.vo.*

The CafeTownsend demo was ported by Michael Ramirez and he did so with an eye toward Cairngorm developers and architects evaluating or migrating to PureMVC. So its package structure is influenced by Cairngorm. ARP has a similar format.

One thing I don't like so much about either package structure is that it makes you 'think' every time you look at it. It has crossed some visual threshold were we have to consider the 5 or so options, and consider what we're looking for and arrive at the conclusion as to which folder to open.

True, vo's may be shuttled around the three tiers and therefore logically stand 'outside' it also adds an extra package branch. The business delegate may do work for the controller or the model, and therefore would logically stand on its own island as well.

The reason I use the more simplistic 'model, view and controller', is that the original intent was to help separate code into three discrete 'piles'. This overcomes 90% of the problems we have with muddy responsibility placement in our apps. You still stand at the same crossroads, it only takes less time to pick a path.

So like everything, it's a compromise. More logical separations, which is good if there is an explosive number of classes that could be subdivided, or more minimal packaging, which is faster to traverse and means fewer regular occurrences of staring at your package structure wondering where something is, if only for seconds longer at a time.

2812  Announcements and General Discussion / Getting Started / Best Practices document Released on: June 20, 2007, 03:41:13 PM
From the project architect, PureMVC Implementation Idioms and Best Practices is 35 pages of essential architectural advice for implementing an RIA based on the PureMVC framework.

PureMVC.org -> Docs -> Best Practices
Pages: 1 ... 186 187 [188]