You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Marco Mistroni <mm...@waersystems.com> on 2005/05/23 10:39:45 UTC

RE: sTRUTS 1.3 - chain flow / complex app

Hello all,

>It's interesting to have some more complex use cases to test the 
>chain model against...

I would offer my app as 'guinea pig' for complex cases :-)

Currently it's a small app that manage my own 'expenses' (I have a mysql
as backend and jboss 3.2.5/tomcat 5.5 as app server)to see
What do I spend an where (yeah, I m not that good with money :-)

I am updating my db almost automatically via quartz job, using struts as
user interface for manual insert of expenses and job scheduling..
I m using castor/hibernate as ORM frameworks, and spring & struts
I manage to port it from struts 1.1 to struts 1.3, and I was looking
into strutsws cos I want to have J2ME clients that communicates using
ksoap.

I am looking forward to add more complexity for 'testing' the chain.. 
If you have anything to suggest me, go ahead :-) ..

Does Shale use chain? Could you integrate chain in Shale?

Regards
	marco



---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Re: sTRUTS 1.3 - chain flow / complex app

Posted by Craig McClanahan <cr...@gmail.com>.
On 5/23/05, Joe Germuska <Jo...@germuska.com> wrote:
> Marco wrote:
> >Does Shale use chain? Could you integrate chain in Shale?
> 
> Shale does use chain, but to be honest, I don't know much more about
> it than that.
> 

Shale uses Commons Chain to configure it's application level
processing (i.e. the stuff that is performed in its "front controller"
filter).  Shale does not use Commons Chain for any detailed
per-request processing (although you can easily do so for your own
application's purposes, by having your action handler (the code that
processes a submit button event, sorta like an Action.execute() method
in Struts 1.x) look up an appropriate Chain, set up an appropriate
Context, and then fire off the chain.

For conversation management, Shale also includes Dialog -- a very
simple implementation of the same idea that Spring WebFlow fleshes out
in all its sophisticated glory.  This is quite useful for managing
state across a multiple-request dialog with the user.  This doesn't
use Commons Chain, because it supports transitions to one of several
next states, based on logical outcomes -- and the sequential flow
nature that Commons Chain provides does not really match that model.

Craig

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


RE: sTRUTS 1.3 - chain flow /again

Posted by Joe Germuska <Jo...@Germuska.com>.
At 9:23 AM +0100 5/25/05, Marco Mistroni wrote:
>Hello Joe & all,
>	I have one question regarding the chain..
>Am I correct to assume that The SelectInput command that comes after
>ValidateActionForm in chain-config.xml should be called in case
>validation fails?
>How does that happen? Javadoc says that
>/**
>  * <p>Validate the properties of the form bean for this request.  If
>there are
>  * any validation errors, execute the child commands in our chain;
>otherwise,
>  * proceed normally.</p>
>  *
>  * @version $Rev: 153658 $ $Date: 2005-02-13 14:26:03 -0500 (Sun, 13 Feb
>2005) $
>  */

I think that JavaDoc is misleading.  I had wanted to do some 
rearrangement to the chain around this issue, but have not yet.  (To 
be honest, I'm not really sure what "child commands in our chain" 
means!)

Here's how it works now: in the process action chain, the 
ValidateActionForm command does the validation and sets a flag in the 
context.  Then, each subsequent command in the chain inspects the 
value of this and controls its behavior accordingly.

This is kind of clumsy, and entangles the commands too much.  It 
would be better to "abort" the chain when the form is invalid, at 
least as soon as possible.  The problem is that commons-chain 1.0 
treats a "true" return from a lookup chain as a signal to end ALL 
chain processing, not just that chain which was looked up.  This has 
been addressed with a configurable property on LookupCommand in an as 
yet unreleased version of commons-chain.  With that, one can "abort" 
a sub-chain without interrupting the processing of the source chain.

There's still the awkward bit of having SelectInput separate from 
ValidateActionForm -- you have at least one class which needs to be 
invoked paying attention to this value in the context.  I've thought 
of a few possible chain design approaches, like a branching command 
or a conditional lookup command, but none have felt so compelling 
that I wanted to push them in yet.

>but as far as I could see, SelectInput is just another command that
>comes after ValidateActionForm... and, one thing that make me more
>confused, is that if ValidateActionForm fails, it should return true, so
>the next command (which is SelectInput) shouldn't get executed.......

That's not true -- as noted above, in commons-chain 1.0, no command 
in a chain may ever return true without cancelling all chain 
processing.  I found this counter-intuitive, as it seems do you -- 
and that's why I added the configuration property to LookupCommand.

I'd suggest checking out the code -- it should be pretty easy to 
actually trace through it and get a better handle on what happens in 
there.

Joe
-- 
Joe Germuska            
Joe@Germuska.com  
http://blog.germuska.com    
"Narrow minds are weapons made for mass destruction"  -The Ex

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


RE: sTRUTS 1.3 - chain flow /again

Posted by Marco Mistroni <mm...@waersystems.com>.
Hello Joe & all,
	I have one question regarding the chain.. 
Am I correct to assume that The SelectInput command that comes after
ValidateActionForm in chain-config.xml should be called in case
validation fails?
How does that happen? Javadoc says that 
/**
 * <p>Validate the properties of the form bean for this request.  If
there are
 * any validation errors, execute the child commands in our chain;
otherwise,
 * proceed normally.</p>
 *
 * @version $Rev: 153658 $ $Date: 2005-02-13 14:26:03 -0500 (Sun, 13 Feb
2005) $
 */


but as far as I could see, SelectInput is just another command that
comes after ValidateActionForm... and, one thing that make me more
confused, is that if ValidateActionForm fails, it should return true, so
the next command (which is SelectInput) shouldn't get executed.......

could you clarify me how and when the SelectInput gets called?

Thanx and regards
	marco


	

-----Original Message-----
From: Joe Germuska [mailto:Joe@Germuska.com] 
Sent: 23 May 2005 14:10
To: Marco Mistroni; 'Struts Users Mailing List'; 'Frank W. Zammetti'
Subject: RE: sTRUTS 1.3 - chain flow / complex app

Marco wrote:
>Does Shale use chain? Could you integrate chain in Shale?

Shale does use chain, but to be honest, I don't know much more about 
it than that.

>I am looking forward to add more complexity for 'testing' the chain..
>If you have anything to suggest me, go ahead :-) ..

Just keep doing what you're doing!  More than the complexity, it's 
just valuable to have people using it period.  I've been developing a 
new app on it for a few months now and everything seems to be going 
smoothly, but I'm sure I don't use every feature of Struts, so having 
more people use it to make any kind of webapp gives us more chances 
to flush out any quirks.

Joe


-- 
Joe Germuska            
Joe@Germuska.com  
http://blog.germuska.com    
"Narrow minds are weapons made for mass destruction"  -The Ex

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


RE: sTRUTS 1.3 - chain flow / complex app

Posted by Joe Germuska <Jo...@Germuska.com>.
Marco wrote:
>Does Shale use chain? Could you integrate chain in Shale?

Shale does use chain, but to be honest, I don't know much more about 
it than that.

>I am looking forward to add more complexity for 'testing' the chain..
>If you have anything to suggest me, go ahead :-) ..

Just keep doing what you're doing!  More than the complexity, it's 
just valuable to have people using it period.  I've been developing a 
new app on it for a few months now and everything seems to be going 
smoothly, but I'm sure I don't use every feature of Struts, so having 
more people use it to make any kind of webapp gives us more chances 
to flush out any quirks.

Joe


-- 
Joe Germuska            
Joe@Germuska.com  
http://blog.germuska.com    
"Narrow minds are weapons made for mass destruction"  -The Ex

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Dealing with many forms

Posted by Janek Ziniewicz <ja...@gmail.com>.
Hi, I am writing my first Struts application, and have some problems with
it.
 
Some part of my app, gets data from database, fills appropriate form,
displays it and, if user changed the form, writes data back to database.
 
Another functionality is: get whole webpage (including form)from database,
fill it with data and if user changes it, write changed data back to
database. It was done with Jsp and JavaScript. Writing ActionForm for each
form would be senseless because part of functionality of the app is that
any user can submit new forms.
 
And now the problem: Some devices do not deal with JavaScript well (some
palmtops, cellphones etc). And my app must run properly on them. So, is
there any way to do the task above without JavaScript?
--
Pozdrawiam, Janek Ziniewicz
gg:902858
irc.freenode.net: #gore, #dub

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org