Ralph Goers wrote:
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.
I can't share this thought.
IMO the sitemap hasn't been built for web applications. It's about matching URIs with pipelines. Sure, many people want to use this beautiful concept of pipelines in their web _applications_ too and so actions were born. But following this concept, complicated sitemap constructs were necessary in order to add application logic.
I believe that Flowscript solved this by decoupling URI-matching from the controller:
<map:match pattern="myPage"> <map:call function="myFunc"/> </map:match>
This clearly calls the controller and doesn't require you to define at this point all possiblities that are possible if you want to access the URI "myPage". After this Flowscript is responsible and you decide _there_ which pipeline you want to "send" to the client. No complicated, hard to understand nestings or redirects are necessary!
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).
I think this is over-simplified. Maybe you've to send the long version of your mail ;-)
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 would say you can implement all usecases by using the sitemap only or by using a sitemap+flowscript combination. But don't forget that the sitemap wasn't built to write web applications.
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!
IMO it's fine what you did!
-- Reinhard
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
