John, I started to write a really long response but though better of it. The bottom line here, is that what you are doing is not "wrong". It is probably exactly how I would implement your site. However, pardon me for saying so, your site is fairly simple. As the system grows larger you will find that your flowscript is turning into a full-blown application, which is exactly what I feel it shouldn't be.
The whole point of MVC, at least in my view, is to create an easily extensible and maintainable system. Creating Flowscript applications doesn't do either. To answer your question, "Surely the controller has to be aware of the business layer's public methods/interface to actually perform anything useful?", the answer is, no it does not. Trying to explain this is what made my first draft really, really long, but the short answer is that Cocoon's support of Inversion of Control (i.e. configuring things in Cocoon.xconf and the sitemap) allows one to create all kinds of things through configuration that are manipulated in the sitemap in a generic manner. For example, what if I wanted to turn your vocabulary site into one for spelling or history, etc.? I can't imagine that the sitemaps would need to be very different. With the design I would use a slightly different URL could cause the sitemap to automatically choose different business objects - with no code changes involved. I'd just define the new business object in Cocoon.xconf and add a sitemap entry to handle the url (if that is even needed). To answer your question, "isn't the sitemap doing exactly what flowscript does?" No. The sitemap can only pass Strings. Actions can only provide information to the sitemap. Therefore, actions are clearly part of the model while the sitemap remains the controller. Flowscript can do both so it can mix the model and the view. I don't know that you have mixed anything up. You simply have a different problem to solve and a different approach. -----Original Message----- From: John Shea [mailto:[EMAIL PROTECTED] Sent: Sunday, May 02, 2004 10:20 PM To: [EMAIL PROTECTED] Subject: Re: JXT or XSP? Hi everyone, sorry for my irreverent newbie questions. I'll hopefully be forgiven by the "no question is a stupid question" defense. Doesn't the user often determine whether business objects are instantiated or not? Cannot flowscript be my interface between the user and my business methods? What is the difference between instantiating them in an action and in the flowscript? I don't mean programmatically - I mean in the separation of concerns. something has to act as the controller - why cant it be Flow? I have just created my first cocoon web app and it is a Language Vocab Testing Program, I have a POJ business layer which has all my methods to get the next word - checks to see if the word has already been tested, and it calls my POJ Access Layer - which at the moment does JDBC calls. My Flowscript starts the test by calling biz.start(), gets the number of questions, and gets the next word biz.getNextWord() looping with sendPageAndWait until the test finishes. The controller depends on user input, when to start the test, to get the next word, when the test is over, so why should not these be in the flowscript? The biz objects have to be in some sort of user "context" - and the state management provided by flow provides that context. If i jump between sitemap/actions and flowscript to call my biz methods - how does that help the "separation of concerns"? Is not the pipeline doing all the matching and the calling of actions acting as the controller, and therefore doing exactly what flow is doing? I assume that i have mixed something up along the way - so is there a more complicated example somewhere which shows the preferred way to integrate the different components of cocoon and provide the clear separation of layers? With explanation of "why" it is done this way? help me obi wan, help me! Cheers and thanks, John. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
