I was aware of the points you have made, but is doesn't hurt to highlight these to the whole list (the more developers making use of mach-ii, the better it will become :-) )
Indeed. Release 1.0.8 is pretty solid now and we're using it in production already (with some high traffic apps coming online this month).
Sean Corfield has done a great job with his dev giude, and if you follow his outlines, you can't really go wrong.
Thanx. It's mostly based on the workflow that my team use to develop apps (designing the UI and the business model in parallel and then integrating them with Mach II in a loosely coupled manner).
I look forward to hearing Sean explain how macromedia is using mach-ii to develop online applications on their site at MXDU.
I'll mostly be talking and the pros & cons of Mach II itself and looking at some of the big apps we've built with it - rather than methodology. I'll probably write up something on methodology at a later date.
I'm really interested in an end-to-end methodology though, one that takes you through the design steps before you sit down and start to write your CF code. I need to be able to produce docs for developers, and I've been doing a fair bit of reading on UML and OO design methodologies.
We don't use a formal methodology but we make heavy use of UML within the engineering team to document requirements and model the applications, using TogetherSoft's CASE tool Control Center (now owned by Borland). We're lucky in that we have some really good OO software architects and designers on our team who are able to guide the other engineers so we haven't yet felt a need to be more formal.
Certainly, starting out by documenting Use Cases in a more formal manner is a big help for any project - identify your systems, your actors and your use cases and then write plain English scenarios (Ivar Jacobson's book "Object Oriented Software Engineering" is a great resource for learning about Use Cases - Jacobson formalized the concept in the telecom world and then he joined with Booch et al to integrate Use Cases into UML).
Then we look at the scenarios and perform a fairly standard first pass to identify our logical object model outline - nouns (and relationships) typically become classes; verbs typically become methods. Then we refine the logical model, looking at some of the more complex interactions using collaboration diagrams or sequence diagrams (using the latter if lifetimes of objects are key to the scenario), and build a physical object model (applying design patterns to refactor and flesh out the structure).
At that point we're ready to build CFCs.
That's for the business model.
For the UI, we have creative folks who evolve designs and Information Architects who work out the user interactions and flows and between them they build full graphic mockups as well as schematics (essentially wireframes). These then go through a standard web production phase to produce HTML mockups and cut up graphics. Then an engineer works with the design/production folks to create Mach II views.
By this time, we have enough information to have identified all the public events in the system and we can hook up the basic views and transitions using Mach II and then engineers continue to flesh out the integration of the business model into this, adding listeners, filters and private events as necessary to connect everything together.
Note that in a simple application, the modeling phase is much more straightforward (and most applications really are fairly simple).
Sean A Corfield -- http://www.corfield.org/blog/
"If you're not annoying somebody, you're not really alive." -- Margaret Atwood
--- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED]
MXDU2004 + Macromedia DevCon AsiaPac + Sydney, Australia http://www.mxdu.com/ + 24-25 February, 2004
