cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Derek Hohls" <dho...@csir.co.za>
Subject RE: new to cocoon question
Date Thu, 11 Mar 2004 19:30:47 GMT
You say:

"I really don't see anywhere else in the cocoon framework 
where there is an explicit class that handles requests, calls services
from 
the business layer and returns a response.  Everything else in cocoon
seems 
to be all transformations of some sort."

One place where this can be is inside an XSP - this can handle requests,
call and store data in external objects (e.g. beans) and return a
response.
If needs be, XSPs can also used as XSP "actions" and hence the results 
they return can be taken up in the sitemap.  Saying that Cocoon is just
about "transformations" would be like saying that Struts is just about
the
struts-config file ;-)

The other area where logic flow can be handled is in, well, the flow
pages, usually scripted.  Suggested reading is:
http://cocoon.apache.org/2.1/userdocs/flow/index.html

The Cocoon philisophy has always been about "separation of concerns":
in the beginning the focus of those concerns was very much on moving
the presentation layer out of the application logic flow and enabling
effective use and reuse of output data; in more recent times the focus
has been more on adding capabilities moving "back" towards the logic
handling.

HTH


>>> moraleslos@hotmail.com 03/11/04 8:38 PM >>>
Well, in essence, struts actions do return a "forward".  However, the 
page/action to forward to is agnostic in practice, i.e. the actual page
or 
action to forward next is defined separately in a config file called 
struts-config.xml (I think this is similar to the sitemap).  So really
the 
configuration where struts  does its forwarding is outside of the action

classes.

In theory, the struts actions are extensions of the controller (or
model, 
depending on how you interpret it) in the MVC paradigm.  They can
represent 
the actual business logic, but in practice they are used as 
delegates--calling business objects to do the work.  Hence struts
actions 
are like a service layer for the front-end, interacting with the
business 
layer.   Looking at cocoon actions, they return a Map containing
information 
used for display purposes.  This can be done in struts actions by
explicitly 
putting the information into the request (usually encapsulated as a
bean) 
that can be easily manipulated with struts or jstl tags.

Therefore my understanding thus far about cocoon when comparing it to
struts 
is that the cocoon actions are "similar" to struts actions.  Do you use 
cocoon actions more often then the *traditional* pipeline for doing MVC 
applications?  I really don't see anywhere else in the cocoon framework 
where there is an explicit class that handles requests, calls services
from 
the business layer and returns a response.  Everything else in cocoon
seems 
to be all transformations of some sort.

Also, struts has a neat thing with declaring forms.  There is the 
traditional way of creating POJOs via ActionForms and there is the 
declarative way defined in the struts-config called DynaForms.  In
cocoon, I 
see something called "woody" and "xforms".  I have no clue how these
forms 
are used within the cocoon framework, particular with cocoon actions. 
In 
struts, the form used for submission is explicitly passed to the action 
handling the form.  In cocoon actions, I don't see any woody form being 
passed in...

Any more suggestions would be appreciated!  Thanks!

-los


>From: Ralph Goers <Ralph.Goers@digitalinsight.com>
>Reply-To: users@cocoon.apache.org
>To: "'users@cocoon.apache.org'" <users@cocoon.apache.org>
>Subject: RE: new to cocoon question
>Date: Thu, 11 Mar 2004 09:11:31 -0800
>
>Pardon my ignorance on Struts as I haven't used it extensively either,
but
>my recollection is that Struts invokes Actions which then return a
forward 
>-
>in essence telling the controller what to do next based upon what the
>business logic for the action did.  This, in essence and IMO, makes the
>Action more knowledgeable than it should be.
>
>Cocoon's notion of an action is somewhat different, although it can be
>subverted to behave very similarly to a Struts action.  Typically
actions 
>in
>Cocoon simply return information in a Map object.  The pipeline is
>configured to operate upon that data in any manner it sees fit.  Thus,
the
>action is in the business of simply returning information rather than 
>acting
>as a director.
>
>Ralph
>
>  -----Original Message-----
>From: 	Derek Hohls [mailto:dhohls@csir.co.za]
>Sent:	Thursday, March 11, 2004 8:57 AM
>To:	users@cocoon.apache.org
>Subject:	Re: new to cocoon question
>
>Interesting question - in brief, actions are primarily used *inside*
>pipelines to act as logic "switches" between different choices; or to
>allow easy handling of case failures. I am not sure how this
corresponds
>to what Struts does - I actually would like to find out more about
>Struts
>as there a number of developers I know that use it, to whom I'd like to
>relate a little better - if there is any reading you can point me
>towards
>to grasp that framework's approaches, I'd be happy to share any
>comparisons I find (as this is something I want to do anyway...)
>
>Derek
>
>D Hohls
>Environmental Systems Developer
>CSIR Environmentek
>PO Box 17001
>Kwa-Zulu Natal
>South Africa
>4013
>www.csir.co.za
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>For additional commands, e-mail: users-help@cocoon.apache.org
>

_________________________________________________________________
Frustrated with dial-up? Lightning-fast Internet access for as low as 
$29.95/month. http://click.atdmt.com/AVE/go/onm00200360ave/direct/01/


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
MailScanner thanks transtec Computers for their support.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message