Hi all... Be warned I ramble on a lot here!!!
I'm designing a web app to handle company logistics for a friend and I'm basing it on Turbine 2.x ( I know a good thing when I see one). This is sort of an experiment for me becuase it'll be my first turbine-based web app and also the first app I would have completely designed myself (Domain designer, App architect, developer and template designer all rolled into one big mess ;) ). I've read up lot on oop design, best practices, avoiding coupling, the use of design patterns to allow flexibility... Basically I want to create a well designed app following best practice oop principles that is modularised, can be easily extended, promotes reuse, handles complexity well and scales well. (i.e. I want design paradise .. ;) ) At the moment, the experimental app is only a very small scale but I'd like it to be able to scale well should it need to. For the moment, I don't want it to be distributed and no EJB's either, I'm trying out a web-centric approach first off, and if need be will use load-balancing to provide scale-up. After this web-centric app is out, I plan to re-design with distribution in mind with or without EJB's (maybe using Jini services and Java Spaces....I'll cross that bridge when I come to it...) and compare it too the previous approach. I've come up with a preliminary design but I'm a bit confused about the whole thing... I'd really appreciate any input here (pros and cons), because I'm having doubts about wether it's overkill or not or wether basic Turbine without my extentions would do the job nicely. Basically my system, involves turbine 2.x at the core, using it's services, but in order to handle application complexity, I decided to introduce extra infrastructure (I've been quite influenced by what I've been reading). Here goes... Didaxe Example: <begin-example> 1. We have a template for Course Management with three buttons (Create, Update,Cancel)! 2. On clicking the Create button, causes a doCreate() method to be executed in the Turbine Course Action to be executed. 3. In this method, the appropriate EventFactory for the current Module is provided by the Module Manager Service (A Turbine Service) which generates a CourseEvent object setting it's action index to 1 (just as an example, it corresponds to Create_Course) 4. The StateMachine (Also a Turbine service) is then called passing in the Event object, the RunData and Context object. 5. The StateMachine (SM) then looks up the event handler for this event, and delegates to it. (Actually it first searches for the handler in the Turbine Pool Service and if it doesn't find it instantiates a new one and sticks it in the pool. Then it calls the handlers init()- (there will be no efect on this if it has already been instantiated), doStart(), execute() and doEnd() methods). 6. I've now come up with two possibilities ( actually I can think of a few more): A.) The eventhandler follows the Mediator pattern in combination with the Command pattern. It uses the Event object's getAction() method (which defines what type of action has been called in this case Create_Course) and the FlowMapping object for the event (which defines where flow should go to if successfull or not and is graciously donated by the FlowManagerService ) to create the appropriate Command objects (passing in RunData, Context ). Then it executes the Command objects execute(data, context) method for all the Command objects defined in the FlowMapping object for this handler which causes the appropriate domain/peer object to do it's stuff, populates the context using pull tools. Depending on the result of the Commands it set's the next template...This way I could have the possibility of introducing an Undo ability for the web app. B.) The handler does everything itself according to what action the event is (getAction()) to perform whatever is necesary,passing in RunData, Context to update the Domain, handle business logic, using pull tools to populate the context accordingly and set the next Template. In either case, any 'State' change in the application is set using the StateMachine (this holds a record of the application state during run-time). When the handler has finished the SM uses the ModelNotifier to take care of notifying any registered listeners for this event (This could perhaps just queue the notifications and they will be executed at intervals by the Turbine Scheduler service.) 7. State for the app has been changed (or not), listeners have been notified , the context has now been populated , the next Template has been set and control can now be returned to theTurbine action doXXX() method and back into normal Turbine control.... </end of example> Those of you who have had a look at the Java Petshop, will notice that I've taken a few ideas from there and also a few ideas from various articles I've read...It is probably immediately obvious that I've not got a good deal of experience and finally... My doubts....is all of this necessary... Why don't I just handle business logic in the action doXXX() methods directly like scarab does... I'm using a Flow Mapping system to be able to define where to go next depending upon the results of the handling of a particular event, thus not hardcoding the flow directly in the code. Is this so important or could I get away with hard-coding...? By using this event handling system am I just adding extra objects into the system, just postponing something that could have easily been done a few method calls before or is it a good way to provide flexibility into the system. I look at what I've come up with and I keep finding parallels within Turbine current design that makes me think that I'm just designing for design's sake with no real idea of what I need to do... Does an app need a StateMachine to encapsulate application state during run time or can that be left implicitly within the Domain models state as reflected in the DB? ( I think I've got what is known as 'analysis paralysis' or is it 'design paralysis'.. ;) ) Please feel free to crititcise at will! I'd just like a few brief comments about wether I'm going off on a tangent or not. I'd love to hear a few opinions, criticisms and hopefully decide for myself what would be the best thing to do...or what the heck should I perhaps just try it (i.e. go ahead and implement it ) and then see... Yours truly, Saimon Moore P.S. A bit brain numb ;) I was up quite early this morning and I'm riding a caffeine high...that probably explains all of the above...) _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
