Re: Commons Chain Cookbook: Why have Struts Actions?

[Craig McClanahan]

On Fri, 17 Dec 2004 10:58:44 -, Pilgrim, Peter
<[EMAIL PROTECTED]> wrote:
> [snip]
> Can a ``Context'' ever be too big? I mean, everytime a
> web user hits a submit then a naive implementation would
> create a big context object with a request, response,
> errors, etc. What if an naive Struts 1.3+ developer did this
> in his or her `FooCommandAction' for every web request

I think of "too big" as primarily a performance related constraint,
rather than a constraint on understandability.  Given that, the
potential peformance impacts can be dealt with (for a large number of
cases) by using lazy instantiation.

Just as an example, in JSF there is API to return you a Map of the
request parameters for a particular request
(FacesContext.getExternalContext().getRequestParameterMap()).  However
(in the JSF RI at least) this instance will *not* be created until the
first time it is requested -- and, after the first time for a
particular request, it will be cached.

The important issue is that the *framework* should not be a "naive"
implementation, in your termnology.

Craig

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Commons Chain Cookbook: Why have Struts Actions?

[Alan Mehio]

Very nice example and analysis from Peter Pilgrim


> -Original Message-
> From: Pilgrim, Peter [mailto:[EMAIL PROTECTED]
> Sent: 17 December 2004 10:59
> To: 'Struts Developers List'
> Subject: RE: Commons Chain Cookbook: Why have Struts Actions?
> 
> 
> 
> 
> > -Original Message-
> > From: BaTien Duong [mailto:[EMAIL PROTECTED]
> ====
> > 
> > 
> > Ted Husted wrote:
> > 
> > >On Wed, 15 Dec 2004 17:22:15 +, Pilgrim, Peter wrote:
> > >  
> > >
> > >> I was thinking in truth, only providing access to the ``catalog''
> > >> and ``command'' not necessarily changing the execution model. But
> > >> if that is the case, could a Struts ``Action'' as it appears in
> > >> 1.2.6 actually be a commons chain `Command' type? If it is, then,
> > >> it opens the doors for the ``chaining action'' conundrum all again.
> > >>  
> > >>
> > >>
> > >
> > >It's my own feeling that there should be a clean break 
> > between the presentation layer (Struts) that collects and 
> > display values, and the business logic layer (e.g. Chain) 
> > that should do everything else. 
> > >
> > >I started a new project this week based on Context, Command, 
> > and (as of five minutes ago) Spring. The paradigm is that the 
> > presentation layer collects whatever values are needed and 
> > puts them into a Context. A controller component executes the 
> > associated Command (or Chain) and returns the outcome in the 
> > Context. Both the Context and Command are extended so that 
> > they can handle all the business processing: Input and Output 
> > Validation, Execution, Error and Exception Handling, and 
> > Message Resolution. 
> > >
> > >For input, the Context has convenience properties for 
> > Locale, User, Role, and for output, there are properties for 
> > Output, Errors, Messages, and Fault (Exception). I expect 
> > there to be more, but I'm only adding what I need when I need it. 
> > >
> > >When the Context returns, it can be examined by the 
> > presentation layer, which can then display the output, 
> > messages, or errors.
> 
> When I reread this note, it occurred to me that this is
> similar to the way Expresso Controllers are implemented,
> except the ``Context'' is split into ``ControllerRequest''
> and ``ControllerResponse''. The design was inspired by the 
> Java Servlet API specification `ServletRequest', 
> `ServletResponse'.
> 
> So I'd agree with this `bigger' all-seeing-context design
> in principle. I'd factor out some interfaces for Struts
> web environment so that people in theory could re-sig
> the implementation. 
> 
> Can a ``Context'' ever be too big? I mean, everytime a
> web user hits a submit then a naive implementation would
> create a big context object with a request, response,
> errors, etc. What if an naive Struts 1.3+ developer did this
> in his or her `FooCommandAction' for every web request
> 
> class FooCommandAction {
>   public Context createKiddieOnContext() {
>   ...
>   
>   PhotoImage image = new PhotoImage( 2048, 2048 ); // 
> 4Mega Pixel 
>   grabPhotoFromPersistence( "mallorca0001.jpg", image )
>   context.put( "myPhoto", image );
>   ...
>   return context;
>   }
> 
> }
> 
> > >
> > >  
> > >
> > This is great Ted. What it means is that each individual backend 
> > software component catalog can determine finer grain of authorization 
> > and the amount of supplied information. The web layer will 
> > take care of 
> > the first pass and assemble the supplied fragments. Please 
> > let all the 
> > mortals know when it is available.
> > 
> 
> This is C#, so I think he'd have to port it to Java first.
> 
> > Thanks
> > 
> > BaTien
> > DBGROUPS
> > 
> > >It's all in C# now, since I'm working in .NET, but I'd like 
> > to port it back to Java 1.5 and maybe PHP 5. 
> > >
> > >-Ted.
> > >
> > >
> > >
> > >-
> > >To unsubscribe, e-mail: [EMAIL PROTECTED]
> > >For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> --
> Peter Pilgrim
> Operations/IT - Credit Suisse First Bost

Re: Commons Chain Cookbook: Why have Struts Actions?

[Dakota Jack]

I would be very interested in this.  

Jack


On Fri, 17 Dec 2004 08:53:32 -0500, Ted Husted <[EMAIL PROTECTED]> wrote:
> On Thu, 16 Dec 2004 11:04:05 -0700, BaTien Duong wrote:
> > This is great Ted. What it means is that each individual backend
> > software component catalog can determine finer grain of
> > authorization and the amount of supplied information. The web layer
> > will take care of the first pass and assemble the supplied
> > fragments. Please let all the mortals know when it is available.
> 
> If anyone were interested, I could start making snapshots of the Visual 
> Studio project available.
> 
> As mentioned, it's all in C# now.
> 
> Of course, this will all work for Mono too, which can run under an Apache 
> server, for Linux and MacIntosh, as well as Windows.
> 
> -Ted.
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


-- 
"You can lead a horse to water but you cannot make it float on its back."

~Dakota Jack~

"You can't wake a person who is pretending to be asleep."

~Native Proverb~

"Each man is good in His sight. It is not necessary for eagles to be crows."

~Hunkesni (Sitting Bull), Hunkpapa Sioux~

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Commons Chain Cookbook: Why have Struts Actions?

[Ted Husted]

On Thu, 16 Dec 2004 11:04:05 -0700, BaTien Duong wrote:
> This is great Ted. What it means is that each individual backend
> software component catalog can determine finer grain of
> authorization and the amount of supplied information. The web layer
> will take care of the first pass and assemble the supplied
> fragments. Please let all the mortals know when it is available.

If anyone were interested, I could start making snapshots of the Visual Studio 
project available.

As mentioned, it's all in C# now.

Of course, this will all work for Mono too, which can run under an Apache 
server, for Linux and MacIntosh, as well as Windows.

-Ted.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Commons Chain Cookbook: Why have Struts Actions?

[Ted Husted]

>From my viewpoint, it's important to distinguish between the StrutsContext and 
>the application's context.

Right now, the Commons Chain package implies a different approach, where a 
WebContext might be passed up to the application layer under the Context 
interface. In my own work, I like to allow the application layer to have its 
own speciality Contexts, that are easy to populate from another Context, or 
from other members.

In my own work, I'm in the process of building on a request-response business 
layer framework based on Commons Chain. It has its own POO (plain old object) 
Context that can be used with any presentation layer, including a testing 
environment or command line program.

The idea is that the Action (or code-behind or backing bean) collects whatever 
values are needed for a request (or Command) and submits a Context to the 
business layer.

All of the processing takes place in the Command (or Chain of Commands), 
including authorization, validation, and message resolution.

What's left for the presentation tier is to decide what page to display, and 
then emit the markup that puts pixel to screen.

As to the all-seeing Web context, all of those objects already exist. The 
StrutsContext does not create them, but simply provides a facade.

-Ted.

On Fri, 17 Dec 2004 10:58:44 +, Pilgrim, Peter wrote:
> When I reread this note, it occurred to me that this is
> similar to the way Expresso Controllers are implemented,
> except the ``Context'' is split into ``ControllerRequest''
> and ``ControllerResponse''. The design was inspired by the
> Java Servlet API specification `ServletRequest',
> `ServletResponse'.
>
> So I'd agree with this `bigger' all-seeing-context design
> in principle. I'd factor out some interfaces for Struts
> web environment so that people in theory could re-sig
> the implementation.
>
> Can a ``Context'' ever be too big? I mean, everytime a
> web user hits a submit then a naive implementation would
> create a big context object with a request, response,
> errors, etc. What if an naive Struts 1.3+ developer did this in his
> or her `FooCommandAction' for every web request
>
> class FooCommandAction {
>    public Context createKiddieOnContext() {
>    ...
>   
>    PhotoImage image = new PhotoImage( 2048, 2048 ); //
> 4Mega Pixel grabPhotoFromPersistence(
> "mallorca0001.jpg", image ) context.put( "myPhoto",
> image ); ... return context;    
>  }




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Commons Chain Cookbook: Why have Struts Actions?

[Dakota Jack]

+1

On Fri, 17 Dec 2004 10:58:44 -, Pilgrim, Peter
<[EMAIL PROTECTED]> wrote:
> 
> So I'd agree with this `bigger' all-seeing-context design
> in principle. I'd factor out some interfaces for Struts
> web environment so that people in theory could re-sig
> the implementation.


Jack



-- 
"You can lead a horse to water but you cannot make it float on its back."

~Dakota Jack~

"You can't wake a person who is pretending to be asleep."

~Native Proverb~

"Each man is good in His sight. It is not necessary for eagles to be crows."

~Hunkesni (Sitting Bull), Hunkpapa Sioux~

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Commons Chain Cookbook: Why have Struts Actions?

[Pilgrim, Peter]

> -Original Message-
> From: BaTien Duong [mailto:[EMAIL PROTECTED]
====
> 
> 
> Ted Husted wrote:
> 
> >On Wed, 15 Dec 2004 17:22:15 +, Pilgrim, Peter wrote:
> >  
> >
> >> I was thinking in truth, only providing access to the ``catalog''
> >> and ``command'' not necessarily changing the execution model. But
> >> if that is the case, could a Struts ``Action'' as it appears in
> >> 1.2.6 actually be a commons chain `Command' type? If it is, then,
> >> it opens the doors for the ``chaining action'' conundrum all again.
> >>  
> >>
> >>
> >
> >It's my own feeling that there should be a clean break 
> between the presentation layer (Struts) that collects and 
> display values, and the business logic layer (e.g. Chain) 
> that should do everything else. 
> >
> >I started a new project this week based on Context, Command, 
> and (as of five minutes ago) Spring. The paradigm is that the 
> presentation layer collects whatever values are needed and 
> puts them into a Context. A controller component executes the 
> associated Command (or Chain) and returns the outcome in the 
> Context. Both the Context and Command are extended so that 
> they can handle all the business processing: Input and Output 
> Validation, Execution, Error and Exception Handling, and 
> Message Resolution. 
> >
> >For input, the Context has convenience properties for 
> Locale, User, Role, and for output, there are properties for 
> Output, Errors, Messages, and Fault (Exception). I expect 
> there to be more, but I'm only adding what I need when I need it. 
> >
> >When the Context returns, it can be examined by the 
> presentation layer, which can then display the output, 
> messages, or errors.

When I reread this note, it occurred to me that this is
similar to the way Expresso Controllers are implemented,
except the ``Context'' is split into ``ControllerRequest''
and ``ControllerResponse''. The design was inspired by the 
Java Servlet API specification `ServletRequest', 
`ServletResponse'.

So I'd agree with this `bigger' all-seeing-context design
in principle. I'd factor out some interfaces for Struts
web environment so that people in theory could re-sig
the implementation. 

Can a ``Context'' ever be too big? I mean, everytime a
web user hits a submit then a naive implementation would
create a big context object with a request, response,
errors, etc. What if an naive Struts 1.3+ developer did this
in his or her `FooCommandAction' for every web request

class FooCommandAction {
public Context createKiddieOnContext() {
...

PhotoImage image = new PhotoImage( 2048, 2048 ); // 4Mega Pixel 
grabPhotoFromPersistence( "mallorca0001.jpg", image )
context.put( "myPhoto", image );
...
return context;
}

}

> >
> >  
> >
> This is great Ted. What it means is that each individual backend 
> software component catalog can determine finer grain of authorization 
> and the amount of supplied information. The web layer will 
> take care of 
> the first pass and assemble the supplied fragments. Please 
> let all the 
> mortals know when it is available.
> 

This is C#, so I think he'd have to port it to Java first.

> Thanks
> 
> BaTien
> DBGROUPS
> 
> >It's all in C# now, since I'm working in .NET, but I'd like 
> to port it back to Java 1.5 and maybe PHP 5. 
> >
> >-Ted.
> >
> >
> >
> >-
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]


--
Peter Pilgrim
Operations/IT - Credit Suisse First Boston, 
10 South Colonnade, London E14 4QJ, United Kingdom
Tel: +44-(0)207-883-4497

==
This message is for the sole use of the intended recipient. If you received
this message in error please delete it and notify us. If this message was
misdirected, CSFB does not waive any confidentiality or privilege. CSFB
retains and monitors electronic communications sent through its network.
Instructions transmitted over this system are not binding on CSFB until they
are confirmed by us. Message transmission is not guaranteed to be secure.
==


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Commons Chain Cookbook: Why have Struts Actions?

[BaTien Duong]

Ted Husted wrote:
On Wed, 15 Dec 2004 17:22:15 +, Pilgrim, Peter wrote:
 

I was thinking in truth, only providing access to the ``catalog''
and ``command'' not necessarily changing the execution model. But
if that is the case, could a Struts ``Action'' as it appears in
1.2.6 actually be a commons chain `Command' type? If it is, then,
it opens the doors for the ``chaining action'' conundrum all again.
 
   

It's my own feeling that there should be a clean break between the presentation layer (Struts) that collects and display values, and the business logic layer (e.g. Chain) that should do everything else. 

I started a new project this week based on Context, Command, and (as of five minutes ago) Spring. The paradigm is that the presentation layer collects whatever values are needed and puts them into a Context. A controller component executes the associated Command (or Chain) and returns the outcome in the Context. Both the Context and Command are extended so that they can handle all the business processing: Input and Output Validation, Execution, Error and Exception Handling, and Message Resolution. 

For input, the Context has convenience properties for Locale, User, Role, and for output, there are properties for Output, Errors, Messages, and Fault (Exception). I expect there to be more, but I'm only adding what I need when I need it. 

When the Context returns, it can be examined by the presentation layer, which 
can then display the output, messages, or errors.
 

This is great Ted. What it means is that each individual backend 
software component catalog can determine finer grain of authorization 
and the amount of supplied information. The web layer will take care of 
the first pass and assemble the supplied fragments. Please let all the 
mortals know when it is available.

Thanks
BaTien
DBGROUPS
It's all in C# now, since I'm working in .NET, but I'd like to port it back to Java 1.5 and maybe PHP 5. 

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
.
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Commons Chain Cookbook: Why have Struts Actions?

[Vic]

Joe Germuska wrote:
Actually, this solves the 'chaining action' conundrum, because your 
command can actually point to a chain, where you compose a series of 
logical steps which execute, but which do not each require an 
additional pass through the rest of the RequestProcessor chain.

Or just have 2 catalogs: One for system/request processor. One for 
applicatoin/users.
.V

--
RiA-SoA w/JDNC  forums
blog 
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Commons Chain Cookbook: Why have Struts Actions?

[Joe Germuska]

Yes I also thought of this idea of a map of custom properties.
Yeah, as I had mentioned in earlier discussion, it's been a pet 
feature request from someone on my team, and it makes possible the 
ChainAction when you need two config params; the alternative would be 
an ActionMapping which implements a two-property interface so that 
people could use ChainAction with their own custom subclasses of 
ActionConfig... and soon it's tangled mess.

 > Presumably in the model you describe, Struts would treat the presence
 of "command" as an alternative form to "type" or "forward" -- that is
 one of three substantially different execution models.
I was thinking in truth, only providing access to the ``catalog'' and
``command'' not necessarily changing the execution model.
But if that is the case, could a Struts ``Action'' as it appears in 1.2.6
actually be a commons chain `Command' type? If it is, then,
it opens the doors for the ``chaining action'' conundrum all again.
 
 
Maybe the ``set-property'' attributes can evolve over time.
If it turns out that lots of developers are writing the same
XML code over, then at some point we can migrate it to
proper attributes. We 'd have ease their deployment.
Yes, I think that's a good general model...
 > Presumably in the model you describe, Struts would treat the presence
 of "command" as an alternative form to "type" or "forward" -- that is
 one of three substantially different execution models.
I was thinking in truth, only providing access to the ``catalog'' and
``command'' not necessarily changing the execution model.
But if that is the case, could a Struts ``Action'' as it appears in 1.2.6
actually be a commons chain `Command' type? If it is, then,
it opens the doors for the ``chaining action'' conundrum all again.
Actually, this solves the 'chaining action' conundrum, because your 
command can actually point to a chain, where you compose a series of 
logical steps which execute, but which do not each require an 
additional pass through the rest of the RequestProcessor chain.

The "alternate execution model" is really as simple as adding two 
bean properties to ActionConfig and one more command in the base 
request processing chain.  As it is now, the chain commands which 
deal with an action mapping which has a defined "forward" or "type" 
are happy to sit back and do nothing when those aren't defined.  So 
one more command which tests the value of "command" and if its 
defined, looks up the command and executes it.  As with the others, 
it would simply do nothing if it saw an ActionMapping with an 
undefined value for command.

Because it turns out that the ActionMapping is involved in several 
other steps in the process (form population and validation, most 
importantly), it would probably always make sense to keep the 
 config element, not least because so many people are 
familiar with it, and as you note, vendors are making tools that are 
familiar with it too...

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

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Commons Chain Cookbook: Why have Struts Actions?

[Ted Husted]

On Wed, 15 Dec 2004 17:22:15 +, Pilgrim, Peter wrote:
> I was thinking in truth, only providing access to the ``catalog''
> and ``command'' not necessarily changing the execution model. But
> if that is the case, could a Struts ``Action'' as it appears in
> 1.2.6 actually be a commons chain `Command' type? If it is, then,
> it opens the doors for the ``chaining action'' conundrum all again.
>  

It's my own feeling that there should be a clean break between the presentation 
layer (Struts) that collects and display values, and the business logic layer 
(e.g. Chain) that should do everything else.

I started a new project this week based on Context, Command, and (as of five 
minutes ago) Spring. The paradigm is that the presentation layer collects 
whatever values are needed and puts them into a Context. A controller component 
executes the associated Command (or Chain) and returns the outcome in the 
Context. Both the Context and Command are extended so that they can handle all 
the business processing: Input and Output Validation, Execution, Error and 
Exception Handling, and Message Resolution.

For input, the Context has convenience properties for Locale, User, Role, and 
for output, there are properties for Output, Errors, Messages, and Fault 
(Exception). I expect there to be more, but I'm only adding what I need when I 
need it.

When the Context returns, it can be examined by the presentation layer, which 
can then display the output, messages, or errors.

It's all in C# now, since I'm working in .NET, but I'd like to port it back to 
Java 1.5 and maybe PHP 5.

-Ted.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Commons Chain Cookbook: Why have Struts Actions?

[Pilgrim, Peter]

> -Original Message-
> From: Joe Germuska [mailto:[EMAIL PROTECTED]
====
> 
> Peter:
> 
> If you haven't seen it, this is effectively what the ChainAction 
> does, or at least what it will be doing soon.
>  
>name="LocaleChangeForm"
>  
> type="org.apache.commons.chain.mailreader.struts.CommandAction
> SubclassingChainAction"
>   >
> 
> 
>
>  
>  
> 
> I've got the code written to support arbitrary properties (the new 
> 'key' attribute in set-property), but just ran out of time to write a 
> mini Struts App to demonstrate that it actually works.  The current 
> ChainAction (in struts-chain) only looks for the command in the 
> "default" catalog, because it predates some of the refinement of 
> catalog management in commons-chain.  That limitation was one of the 
> motivations for adding this arbitrary map of properties to 
> ActionConfig.

Yes I also thought of this idea of a map of custom properties.

> 
> I agree that your XML config proposal is nicely concise, but I think 
> we should get some more people using Chain commands in place of 
> actions before making more specific changes to configuration syntax. 

Some period of experimentation, trial and error, discussion is required
before any permanent decision is built into the syntax / API.

> Presumably in the model you describe, Struts would treat the presence 
> of "command" as an alternative form to "type" or "forward" -- that is 
> one of three substantially different execution models.

I was thinking in truth, only providing access to the ``catalog'' and 
``command'' not necessarily changing the execution model. 
But if that is the case, could a Struts ``Action'' as it appears in 1.2.6
actually be a commons chain `Command' type? If it is, then,
it opens the doors for the ``chaining action'' conundrum all again.
 

 
 

Maybe the ``set-property'' attributes can evolve over time.
If it turns out that lots of developers are writing the same
XML code over, then at some point we can migrate it to
proper attributes. We 'd have ease their deployment.

My approach would be beneficial to tool vendors, because it
is easier to parse the XML for `catalog="fooCatalog"' and
`value="fooCommand"' than to analyse the mapping properties
of an ActionConfig.

> It would be possible to skip the action-mapping completely and look 
> up a chain command based on the path, since command names can be any 
> string -- but then we'd have to re-invent all the config which is 
> currently wrapped up in the ActionConfig.
> 

Yes I think that would be possible, removing the ActionMapping 
depedence. I suppose you could also refactor that code into a 
composable request processor / chain implementation. 

I am sure you'ill agree there is going to be more way to slice a 
big cheese in half! It's is going to be, therefore, a lot more 
difficult for tool vendors to say what is the best practice 
for future Struts project. I am worried that there is already 
XML Configuration Hell tidal wave, -- no. strike that --, 
more like flooding in the coast line.

> Joe
> 
> 
> At 10:34 AM + 12/15/04, Pilgrim, Peter wrote:
> >Hello
> >
> >I have read the Commons Chain Cookbook.
> >http://jakarta.apache.org/commons/chain/cookbook.html
> >
> >Regarding the receipe, "Call a Command from Struts", it 
> seems to me that
> >Struts
> >could support the Command more directly in the ActionMapping.
> >
> >Instead of relying on convention, shared database key, or action form
> >name we could expand the ActionMapping schema directly.
> >
> >
> > 
> >  > name="LocaleChangeForm"
> > 
> type="org.apache.commons.chain.mailreader.struts.CommandAction"
> >+
> >+catalog="fooCatalog"
> >+command="fooCommand"
> >+
> > >
> > 
> > 
> > 
> >
> >
> >Obviously the extra attributes are just java.lang.String, and the
> >actual `CommandAction' will have to retrieve them from
> >`ActionConfig' object, and then use them to execute the action.
> >
> >"catalog=fooCatalog" is the name of the catalog in application scope.
> >You could default this attribute to just "catalog" as in the
> >cookbook example or the default value from `ChaingListener'
> >"command=fooCommand" picks a chain from that catalog, which 
> is looked up.
> >
> >I just pointed that out, because "parameter" may already be used in
> >the button or javascript controlled method ``DispatchAction''s
> >derivatives. Also some workshops have a policy document that an
> >``ActionForm'' must be named `FooBar*Form', and the ``Action''
> >must be named `FooBar*Action' etc etc
> >
> >Over to you.
> >
====


--
Peter Pilgrim
Operations/IT - Credit Suisse First Boston, 
10 South Colonnade, London E14 4QJ, United Kingdom
Tel: +44-(0)207-883-4497

==
This message is for the sole use of the intende

Re: Commons Chain Cookbook: Why have Struts Actions?

[Joe Germuska]

At 7:38 AM -0600 12/15/04, Joe Germuska wrote:
I've got the code written to support arbitrary properties (the new 
'key' attribute in set-property), but just ran out of time to write 
a mini Struts App to demonstrate that it actually works.
OK, I felt lame writing the above since I've been sitting on the code 
for a week or so, so I went ahead and wrote a very simple app which 
uses the config and spits out the values in the action, so I'm going 
to go ahead and commit the changes.

Technically, the DTD should be extended to permit "key" as an 
attribute of "set-property" -- and then that means that probably a 
new struts-config_1_3.dtd should be created, etc.  Should I just go 
ahead and do that?  That would also imply that I should:

1) add it as a registration in ActionServlet
2) update the examples to use the new doctype
3) publish it at the URL used in the doctype
Am I forgetting anything?
Also to come: documenting this feature somewhere other than in 
JavaDoc and the DTD.

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

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Commons Chain Cookbook: Why have Struts Actions?

[Joe Germuska]

Peter:
If you haven't seen it, this is effectively what the ChainAction 
does, or at least what it will be doing soon.


name="LocaleChangeForm"

type="org.apache.commons.chain.mailreader.struts.CommandActionSubclassingChainAction"
>
   
   
  


I've got the code written to support arbitrary properties (the new 
'key' attribute in set-property), but just ran out of time to write a 
mini Struts App to demonstrate that it actually works.  The current 
ChainAction (in struts-chain) only looks for the command in the 
"default" catalog, because it predates some of the refinement of 
catalog management in commons-chain.  That limitation was one of the 
motivations for adding this arbitrary map of properties to 
ActionConfig.

I agree that your XML config proposal is nicely concise, but I think 
we should get some more people using Chain commands in place of 
actions before making more specific changes to configuration syntax. 
Presumably in the model you describe, Struts would treat the presence 
of "command" as an alternative form to "type" or "forward" -- that is 
one of three substantially different execution models.

It would be possible to skip the action-mapping completely and look 
up a chain command based on the path, since command names can be any 
string -- but then we'd have to re-invent all the config which is 
currently wrapped up in the ActionConfig.

Joe
At 10:34 AM + 12/15/04, Pilgrim, Peter wrote:
Hello
I have read the Commons Chain Cookbook.
http://jakarta.apache.org/commons/chain/cookbook.html
Regarding the receipe, "Call a Command from Struts", it seems to me that
Struts
could support the Command more directly in the ActionMapping.
Instead of relying on convention, shared database key, or action form
name we could expand the ActionMapping schema directly.





Obviously the extra attributes are just java.lang.String, and the
actual `CommandAction' will have to retrieve them from
`ActionConfig' object, and then use them to execute the action.
"catalog=fooCatalog" is the name of the catalog in application scope.
You could default this attribute to just "catalog" as in the
cookbook example or the default value from `ChaingListener'
"command=fooCommand" picks a chain from that catalog, which is looked up.
I just pointed that out, because "parameter" may already be used in
the button or javascript controlled method ``DispatchAction''s
derivatives. Also some workshops have a policy document that an
``ActionForm'' must be named `FooBar*Form', and the ``Action''
must be named `FooBar*Action' etc etc
Over to you.
--
Peter Pilgrim
Operations/IT - Credit Suisse First Boston,
10 South Colonnade, London E14 4QJ, United Kingdom
Tel: +44-(0)207-883-4497
==
This message is for the sole use of the intended recipient. If you received
this message in error please delete it and notify us. If this message was
misdirected, CSFB does not waive any confidentiality or privilege. CSFB
retains and monitors electronic communications sent through its network.
Instructions transmitted over this system are not binding on CSFB until they
are confirmed by us. Message transmission is not guaranteed to be secure.
==
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Commons Chain Cookbook: Why have Struts Actions?

[Ted Husted]

The nice thing about Struts is that we can always experiment with custom 
ActionMappings before adjusting the DTD.

I'm sure that once we integrate Chain with Struts, and people start using 
Commands in their own applications, there will be several proposals regarding 
ways to integrate Struts with a Chain-based application layer.

If you'd like to submit an article for using a custom ActionMapping in the way 
you described, I'm sure we'd love to post it.

-Ted.

On Wed, 15 Dec 2004 10:34:43 +, Pilgrim, Peter wrote:
> Hello
>
> I have read the Commons Chain Cookbook.
> http://jakarta.apache.org/commons/chain/cookbook.html
>
> Regarding the receipe, "Call a Command from Struts", it seems to me
> that Struts
> could support the Command more directly in the ActionMapping.
>
> Instead of relying on convention, shared database key, or action
> form name we could expand the ActionMapping schema directly.
>
>
> 
>  name="LocaleChangeForm"
> type="org.apache.commons.chain.mailreader.struts.CommandAction" +
> +                catalog="fooCatalog" +                command="fooCommand" + 
>>  name="success" path="/Welcome.do" />  
>
>
> Obviously the extra attributes are just java.lang.String, and the
> actual `CommandAction' will have to retrieve them from
> `ActionConfig' object, and then use them to execute the action.
>
> "catalog=fooCatalog" is the name of the catalog in application
> scope. You could default this attribute to just "catalog" as in the
> cookbook example or the default value from `ChaingListener'
> "command=fooCommand" picks a chain from that catalog, which is
> looked up.
>
> I just pointed that out, because "parameter" may already be used in
> the button or javascript controlled method ``DispatchAction''s
> derivatives. Also some workshops have a policy document that an
> ``ActionForm'' must be named `FooBar*Form', and the ``Action'' must
> be named `FooBar*Action' etc etc
>
> Over to you.
>
> --
> Peter Pilgrim
> Operations/IT - Credit Suisse First Boston,
> 10 South Colonnade, London E14 4QJ, United Kingdom
> Tel: +44-(0)207-883-4497
>
>
> ==
>  This message is for the sole use of the intended
> recipient. If you received this message in error please delete it
> and notify us. If this message was misdirected, CSFB does not waive
> any confidentiality or privilege. CSFB retains and monitors
> electronic communications sent through its network. Instructions
> transmitted over this system are not binding on CSFB until they are
> confirmed by us. Message transmission is not guaranteed to be
> secure.
> ==
> 
>
>
> 
> - To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]