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 Fri, 12 Mar 2004 06:25:39 GMT
In reply to:  (some previous detail omitted)

>>> moraleslos@hotmail.com 2004/03/11 10:13:17 PM >>>

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

Well, I guess it depends on how you define your terms - I am not too
hung up on MVC, and I am not sure that bending the universe to fit
into that "view" (for want of a better term!) is necessarily a Good
Thing.
That being said, XSP was primarily designed to be able be generate
data,
where the generation procedure depends on some logic.  The logic can
be encapsulated into reusable logic sheets (really, fragments of Java
code)
or embedded into the source XSP.  I would not use them for viewing
data
per se.  So no, I would not compare them to JSP in Struts (bearing in
mind
that it is a *long* time since I have used JSP; looking back now it
seems a 
very clunky mishmash approach...) - but you are right that XSP are not
for
doing overall application "control"  - that is the role of the sitemap
and/or
control flow.

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

What can I say?  its there, as I said, in conjunction with the
sitemap...

>My first  problem with cocoon control logic is that it seems to rely
on a 
>JavaScript-like language.   

Not sure why this is a problem per se? 

>Can this type of scripting language invoke Java 
>business logic directly?  

Yes.

>Personally I would like the controller to be in 
>Java since it will have to invoke java-based logic regardless.  

Well, a language is just a language - heck, you could write your
entire
webapp in pure java and stop messing around with all these higher level

abstractions that "hide" the Real Code, if you are that way inclined!

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

Hmm, as I said right at the start I am not familiar with Struts and
cannot compare
aspects directly - what additional "controller-like functionality" do
you need that cannot
be embedded in customized Java actions (that you could write) and
called from
Cocoon?  Analogies can be helpful, but can also limit to your view to
existing
paradigms...

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

AFAIK, yes - but you will have to ask more experienced heads than mine
about this one!

> Any suggestions would be appreciated.  Thanks again!

Keep reading and asking - maybe browse the mail archives and ask
more specific questions in particular threads.  People will probably
say
"it can be done" but are unlikely to want to write code for you unless

they can see you are attempting something first yourself... 

Derek





>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 


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