cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Los Morales" <morales...@hotmail.com>
Subject RE: new to cocoon question
Date Thu, 11 Mar 2004 20:13:17 GMT
>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 ;-)


Hmm, again being a cocoon newbie, I thought XSPs with cocoon were like JSPs 
when used with struts.  Hence they are more for "presentation"--or in the 
sense "view"--rather than the controller/model aspect in struts actions.  If 
so, I don't think XSPs are appropriate for handling controller-like logic.  
Correct me if I'm wrong about the whole XSP thing.

>
>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

I skimmed through this and still can't quite see how this type of 
control/logic flow fits in the perspective of 1) take requests, 2) grab info 
from form, 3) call appropriate java business logic and process any related 
information, 4) forward to page with processed information.  My first 
problem with cocoon control logic is that it seems to rely on a 
JavaScript-like language.   Can this type of scripting language invoke Java 
business logic directly?  Personally I would like the controller to be in 
Java since it will have to invoke java-based logic regardless.  Secondly, 
seems to me this control flow mechanism is really just a forwarding system 
based on the state of the system.  No controller-like functionality here. If 
this is the case, then cocoon control flow is just like declaring 
global/local action forwards in the struts-config.


Another question that I have regarding the previous post was that cocoon 
actions could not call the business layer directly?  I thought that these 
actions were able to do that.  For example, suppose a form gets submitted by 
a user.  Cocoon picks this up and forwards it to a particular cocoon action. 
  This action grabs the form parameters via woody, calls a service defined 
by the business tier (passing any required parameters supplied in the form), 
processes any result returned by this service, and packages the final result 
via a Map to be returned to the user.   Now my question is, can this 
particular scenario be done with a cocoon action?  Or can it be done by 
something else in the cocoon framework, e.g. the XSP-way?  This is what I'm 
really concerned right now since this is what Struts basically does (and 
does real well).  I do not mind if there are intermediate transformations 
needed by the cocoon framework but I would like to get a sense if cocoon can 
actually handle a situation like the scenario just described.  If so, how 
would you do this exactly in cocoon.

>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.
>


Thus far after doing some researching, cocoon really is just an excellent 
and flexible presentation framework.   It might be one of the best in terms 
of handling the "V" in the MVC paradigm, but the "C" seems to have less 
focus.  Struts, on the other hand, seems to focus on the "C" aspect really 
well but the "V" is limited to JSPs (although integration with JSF is 
another story).  Although I have not used cocoon yet, I would like to 
understand exactly what I'm getting into (coming from a Struts background) 
before actually spending a lot of time with cocoon.

Any suggestions would be appreciated.  Thanks again!

-los





>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
>

_________________________________________________________________
Get a FREE online computer virus scan from McAfee when you click here. 
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963


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


Mime
View raw message