RE: ActionForwards, et al (was SuccessAction)
snip/ I guess I have to reiterate what others have said earlier today: how do you deal with handling or enforcing composition order? I.e. are you implicitly assuming/requiring that the various elements in the chain are orthogonal with respect to changes in the input/output stream or changes in state that other elements in the chain might have visibility into? Or do you assume that the composition order is part of the interface specification, document accordingly, and hope that your clients will read and follow the ordering specification? Steve Yep this is looking sexy. Yep ... lots of interesting room for playing around here. To say nothing of the fact that you can compose your own request processor pipeline to boot. Craig - 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: [OT] Re: ActionForwards, et al (was SuccessAction)
And to add another pedantic log to the fire... :) Quoted from dictionary.com because it's easier than looking it up in a real text: --- et al adv 1: used as an abbreviation of `et alii' (masc. plural) or `et aliae' (fem. plural) or `et alia' (neut. plural) when referring to a number of people [syn: et al., and others] 2: used as an abbreviation of `et alibi' when referring to other occurrences in a text [syn: et al., and elsewhere] I think the second one fits. I always fidget about the missing period personally, but I'm working through those issues. ;) -Paul Micael wrote: Sigh! I cannot stand bad grammar, so once again I must remind my nerd friends that et al strictly applies to people, and that an ActionForward, while dear to my heart, is just not a person. LOL! I hope you take this as interesting and new knowledge and not as a pain in the patoosh. Bye 'd bye! At 08:40 PM 8/12/2003 +0100, Peter A. Pilgrim wrote: David Graham wrote: --- PILGRIM, Peter, FM [EMAIL PROTECTED] wrote: -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] --//-- I chose my words carefully when I said ActionContext interface. I *think* we can all agree that if we added this it should be an interface :-). ---- Why would want the ActionContext to be an interface? Well, ServletContext is an interface and it makes sense for this to be an interface rather than an unnecessarily limiting base class. --//-- I presume that there would be default implementation , then. What I am getting at here, this default implementation could be extended by normal web application developers, say to add in security profile information. Non-trival web application, say framework developers like myself, would write implementation of the interface. In Expresso there are two contextes ( ControllerRequest and ControllerResponse) abstractions of the web servlet request and servlet response. We can write controller that run outside of the web app environment. I think this is where you are going with the ActionContext interface. If the interface was supposed to be environment free what would this interface be? -- Peter Pilgrim __ _ _ _ / //__ // ___// ___/ + Serverside Java / /___/ // /__ / /__ + Struts / // ___// ___// ___/ + Expresso Committer __/ // /__ / /__ / /__ + Independent Contractor /___/////// + Intrinsic Motivation On Line Resume || \\=== `` http://www.xenonsoft.demon.co.uk/no-it-striker.html '' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] LEGAL NOTICE This electronic mail transmission and any accompanying documents contain information belonging to the sender which may be confidential and legally privileged. This information is intended only for the use of the individual or entity to whom this electronic mail transmission was sent as indicated above. If you are not the intended recipient, any disclosure, copying, distribution, or action taken in reliance on the contents of the information contained in this transmission is strictly prohibited. If you have received this transmission in error, please delete the message. Thank you - 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: ActionForwards, et al (was SuccessAction)
--- PILGRIM, Peter, FM [EMAIL PROTECTED] wrote: -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] --//-- I chose my words carefully when I said ActionContext interface. I *think* we can all agree that if we added this it should be an interface :-). ---- Why would want the ActionContext to be an interface? Well, ServletContext is an interface and it makes sense for this to be an interface rather than an unnecessarily limiting base class. David -- Peter Pilgrim, Struts/J2EE Consultant, RBoS FM, Risk IT Tel: +44 (0)207-375-4923 *** This e-mail is intended only for the addressee named above. As this e-mail may contain confidential or privileged information, if you are not the named addressee, you are not authorised to retain, read, copy or disseminate this message or any part of it. The Royal Bank of Scotland plc is registered in Scotland No 90312 Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB Regulated by the Financial Services Authority Visit our website at http://www.rbs.co.uk/CBFM/ *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ActionForwards, et al (was SuccessAction)
David Graham wrote: --- PILGRIM, Peter, FM [EMAIL PROTECTED] wrote: -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] --//-- I chose my words carefully when I said ActionContext interface. I *think* we can all agree that if we added this it should be an interface :-). ---- Why would want the ActionContext to be an interface? Well, ServletContext is an interface and it makes sense for this to be an interface rather than an unnecessarily limiting base class. --//-- I presume that there would be default implementation , then. What I am getting at here, this default implementation could be extended by normal web application developers, say to add in security profile information. Non-trival web application, say framework developers like myself, would write implementation of the interface. In Expresso there are two contextes ( ControllerRequest and ControllerResponse) abstractions of the web servlet request and servlet response. We can write controller that run outside of the web app environment. I think this is where you are going with the ActionContext interface. If the interface was supposed to be environment free what would this interface be? -- Peter Pilgrim __ _ _ _ / //__ // ___// ___/ + Serverside Java / /___/ // /__ / /__ + Struts / // ___// ___// ___/ + Expresso Committer __/ // /__ / /__ / /__ + Independent Contractor /___/////// + Intrinsic Motivation On Line Resume || \\=== `` http://www.xenonsoft.demon.co.uk/no-it-striker.html '' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ActionForwards, et al (was SuccessAction)
On Tue, 12 Aug 2003, Joe Germuska wrote: Date: Tue, 12 Aug 2003 15:06:59 -0500 From: Joe Germuska [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: ActionForwards, et al (was SuccessAction) At 12:48 -0700 8/12/03, David Graham wrote: The main goal of an ActionContext being passed to Action.execute() methods would be to separate Actions from the Servlet API so that you could write Actions to respond to Porlets. It would also serve to stabalize the execute() method's interface and allow you to pass in more than the current 4 or 5 parameters. It seems that another gain of an ActionContext interface would be simplifying the steps in RequestProcessor towards an ability to chain arbitrary processors. However, would we need to do anything to compensate for losing some of the clarity of definitive signatures? My hunch is that you deal with that in the documentation, and leave it up to the user to chain things in a sane order, but maybe that's too risky? One of the potential problems in a Context-based environment is knowing which keys you are using to store and retrieve stuff -- obviously, the producer and consumer of a piece of data need to agree. It is also important that people looking at a Command should be able to determine what attributes will be used for what by this particular Command. The convention of exposing the keys that you're using seems quite helpful in this regard, for at least two reasons: * It's automatically configurable in case you want to reuse the Command implementation in a different way. * The fact that a fooKey property exists is automatically documentation that your Command is going to utilize a particular attribute for some purpose. Craig Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ActionForwards, et al (was SuccessAction)
PILGRIM, Peter, FM wrote:
Would this new ActionForward be created each time like it is now?
ActionForwards (or FowardConfigs) are instantiated when the Struts
Config is digested and stored in a Map. FindForward then returns the
instance directly from the Map. So they are already singleton instances
(or at least shared instances), like ActionMappings.
public ActionForward findForward(String name) {
ForwardConfig config = findForwardConfig(name);
if (config == null) {
config = getModuleConfig().findForwardConfig(name);
}
return ((ActionForward) config);
}
public ForwardConfig findForwardConfig(String name) {
return ((ForwardConfig) forwards.get(name));
}
protected HashMap forwards = new HashMap();
Or would it become a dynamic singleton?
The core idea is to expand ForwardConfig so that it can host a type
(or handler) property, like the ActionMappings. If the type were
specified, it would point to a View class. The View class would have
an extension method that would return a String. If the View class were
specified, the Controller would call that to obtain the path instead.
So, if specified, the View class gives ForwardConfig another bite at
the apple before passing back the String to use for the path.
A View class instance would be shared by all the ForwardConfigs, as an
Action class instance is shared by all the ActionConfigs.
The problem is not necessarily
interacting with the business tier, but making any such interaction
to a minimum. The probably means delegation, or caching, or something
else to add decoration. Ideally the Struts Action such grab all the
business logic for you and then store this information for you.
Ideally, yes, but then the Action needs to know every presentation
requirement of the View, which implies it has a deep knowledge of the
View's implementation. One View may need a select list, another View may
not, but they may both serve the same Action in different page flows.
Alternatively, the Action needs to serve the highest-common denominator
of all the decoration required by all the Views.
If we define a Context that can be passed around Struts, and perhaps the
business layer too, it would be easier for people to implement facades
and services that Actions and Views can share. (Though, it's not so hard
now.)
If an action forward requires special business requirements then
I can see both advantages and disadvantages.
The advantages is that such a new ActionForward could add
special attributes to the response that are not concerned
with the Action logic.
The disadvantages is that it is open to abuse. Bad programming
could introduce another layer of dispatching in the ActionForward
code. You would get mini-MVC nested inside another MVC, which
looks like Hierarchical MVC
This is why the extension method returns a String and not another
ActionForward. The intent here is to render the path, not to dispatch to
another component.
One viewpoint would be that the Action is not (or should not be)
dispatching to a path. It's dispatching to a logical view. It's already
the ForwardConfig's job to provide the path. Whether it is a static path
or a dynamic path doesn't affect the status quo.
And speaking of the status quo, we already have Composite View tools
like Tiles, which essential create a virtual path, and may have page
controller actions of their own.
Meanwhile, people are doing things like creating dynamic ActionForwards
in Actions (mainly to paste on request parameters) simply because they
have no place else to do it. IMHO, the Action should have as little to
do with web semantics as possible. An extension point on the
ForwardConfig gives people a place to dynamically control the path and
safely add web semantics without polluting the Action.
Also, as it stands, we have the Action rending a dynamic Response, if
needed. IMHO, this is another place where lack of a View extension point
pollutes the Action. To work around this, you can create an Action who's
only job is to create a Response and then chain to it. But a better
solution would be to have a View class render such a Response and leave
the Action class out of it.
So, the best practice would be that the Action class should never touch
the Response or the ActionForward path, that would be up to the View class.
-Ted.
--
Ted Husted,
Junit in Action - http://www.manning.com/massol/,
Struts in Action - http://husted.com/struts/book.html,
JSP Site Design - http://www.amazon.com/exec/obidos/ISBN=1861005512.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: ActionForwards, et al (was SuccessAction)
Craig R. McClanahan wrote: In addition, commons-chain provides a couple of layers of Context implementation (optional, compiled only if you have the corresponding APIs) for web applications: Actually optional compiling doesn't work, I believe in commons-chain but could be the contrib. I was 12:30 am for me when the checkin occured and I was just trying to get it compiled quickly. -Rob -- Robert Leland [EMAIL PROTECTED] -- Java, J2EE, Struts, Web Application Development 804 N. Kenmore Street +01-703-525-3580 Arlington VA 22201 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ActionForwards, et al (was SuccessAction)
On Tue, 12 Aug 2003, Byrne, Steven wrote: Date: Tue, 12 Aug 2003 21:07:42 -0400 From: Byrne, Steven [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: RE: ActionForwards, et al (was SuccessAction) snip/ I guess I have to reiterate what others have said earlier today: how do you deal with handling or enforcing composition order? I.e. are you implicitly assuming/requiring that the various elements in the chain are orthogonal with respect to changes in the input/output stream or changes in state that other elements in the chain might have visibility into? Or do you assume that the composition order is part of the interface specification, document accordingly, and hope that your clients will read and follow the ordering specification? If you're using an externally configured pipeline (as we are discussing here), you definitely rely on documentation rather than a monolithic process() method to describe the constraints on ordering. That is not as safe (although you can do things like provide optional plug-in points in between each standard command so that people do not normally need to tweak the standard pipeline). However, it also comes with a lot of power: * You can arbitrarily rearrange commands where the order really does not matter -- there are cases like that in the standard pipeline today, and people have sometimes subclassed RequestProcessor just to change the order for their own purposes. * You can weave together multiple chains (avoiding the problems we have today with everybody wanting to subclass the one-and-only RequestProcessor). * You can have custom chains per URL (or pattern) within a module, not just custom request processors per module. * You can omit commands for things that you don't use. For example, if you're not using container managed security, the processRoles() method is just a time waster. * You can create individual Command implementations that are fine grained and reusable in different application environments. I can imagine a library of such implementations to allow composition of pipelines like what Cocoon, or Stxx, or StrutsCX do - but allow you to build your commands in Java instead of XSLT if you want :-). * You can create Command implementations that invoke scripts in arbitrary languages, so you can incorporate logic written in a variety of scripting languages together. * You can create individual Command implementations that are unit testable, since they can clearly document their expectations for input state (in the Context) and the transformations that they intend to perform on that state. * You can solve the problems people have with action chaining today by firing off your own arbitrary chains of commands, instead of just a single Action. * You can even write a one-step pipeline that invokes a hard coded RequestProcessor-like pipeline that imposes the same ordering constraints that we have today :-). Steve Craig Yep this is looking sexy. Yep ... lots of interesting room for playing around here. To say nothing of the fact that you can compose your own request processor pipeline to boot. Craig - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] Re: ActionForwards, et al (was SuccessAction)
-Original Message- From: Micael [mailto:[EMAIL PROTECTED] Hi, Peter, Yah, there are some that don't like free knowledge or listening. So there was no way to not offend some people. I appreciate that. Why I don't know, and I don't need to know. But, I have a watch. LOL. Micael It would appear to me that your talent for English grammar is not being put to good use. Apparently you did waste your education at college. I dont know if you are idling away in the Struts developer mailing list or if you are now the new ``Mark'' out-of-topic, Friday guy in this list. ( One of the reason why I did not resubscribe to the struts-user list after my holiday, I got really tired of the OT/FRIDAY stuff, but I digress ) We, article writers, might need somebody to correct the grammar in works. I strongly suggest you get yourself a copy of open office so that you pass over out review copy. LOL Seriously I type way to fast for my mind. I hereby solemnly promise to take time to ruminate, ponder, and think imaginatively before I answer another Struts design email. Damn, that boy is so fresh. -- Peter Pilgrim, Struts/J2EE Consultant, RBoS FM, Risk IT Tel: +44 (0)207-375-4923 *** This e-mail is intended only for the addressee named above. As this e-mail may contain confidential or privileged information, if you are not the named addressee, you are not authorised to retain, read, copy or disseminate this message or any part of it. The Royal Bank of Scotland plc is registered in Scotland No 90312 Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB Regulated by the Financial Services Authority Visit our website at http://www.rbs.co.uk/CBFM/ *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ActionForwards, et al (was SuccessAction)
At 12:48 -0700 8/12/03, David Graham wrote: The main goal of an ActionContext being passed to Action.execute() methods would be to separate Actions from the Servlet API so that you could write Actions to respond to Porlets. It would also serve to stabalize the execute() method's interface and allow you to pass in more than the current 4 or 5 parameters. It seems that another gain of an ActionContext interface would be simplifying the steps in RequestProcessor towards an ability to chain arbitrary processors. However, would we need to do anything to compensate for losing some of the clarity of definitive signatures? My hunch is that you deal with that in the documentation, and leave it up to the user to chain things in a sane order, but maybe that's too risky? Joe -- -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com If nature worked that way, the universe would crash all the time. --Jaron Lanier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ActionForwards, et al (was SuccessAction)
On Tue, 12 Aug 2003, Ted Husted wrote: Date: Tue, 12 Aug 2003 15:33:31 -0400 From: Ted Husted [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: ActionForwards, et al (was SuccessAction) This threw me at first too. It works if you set the property to a nonexistent path. There's also a typo in the build file. Under the compile target, the lines should be excludename=org/apache/commons/chain/web/portlet/*.java unless=portlet.present/ excludename=org/apache/commons/chain/web/servlet/*.java unless=servlet.present/ Assuming Craig won't mind, I'll post these little fixes. =:0) +1 on you (or anyone who wants to) fixing this stuff. -Ted. Craig Robert Leland wrote: Actually optional compiling doesn't work, I believe in commons-chain but could be the contrib. I was 12:30 am for me when the checkin occured and I was just trying to get it compiled quickly. - 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: ActionForwards, et al (was SuccessAction)
-Original Message- From: David Graham [mailto:[EMAIL PROTECTED] --//-- I chose my words carefully when I said ActionContext interface. I *think* we can all agree that if we added this it should be an interface :-). ---- Why would want the ActionContext to be an interface? -- Peter Pilgrim, Struts/J2EE Consultant, RBoS FM, Risk IT Tel: +44 (0)207-375-4923 *** This e-mail is intended only for the addressee named above. As this e-mail may contain confidential or privileged information, if you are not the named addressee, you are not authorised to retain, read, copy or disseminate this message or any part of it. The Royal Bank of Scotland plc is registered in Scotland No 90312 Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB Regulated by the Financial Services Authority Visit our website at http://www.rbs.co.uk/CBFM/ *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ActionForwards, et al (was SuccessAction)
Could one instead use a stack for the chain Context and then derive your current context from the stack depth (or chain length) and/or contents? Actually (stream of conciousness beginning), might we even better register a listener that will automatically execute when a certain Context chain is created? For example, when you register a context listener, you say you want to execute whenever there is a Context chain assembled that has a certain combination of elements in a certain order. Of course, now that I think of it, none of this solves the problem of who goes first? Unless one enforces only one listener per unique combination. Then, of course, you would enforce the notion that you can only add a listener to the end of the chain and never somewhere in the middle. Perhaps even allowing a wildcard to say I want to be attached to any chain that begins with httpservletrequest and let the chain assembler do everything in the proper order. (I.E. the aforementioned would always go before something that wanted httpservletrequest AND httpservletresponse). Just my $.025 (those half cents add up) -Original Message- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 13, 2003 11:02 PM To: Struts Developers List Subject: RE: ActionForwards, et al (was SuccessAction) At 9:07 PM -0400 8/12/03, Byrne, Steven wrote: I guess I have to reiterate what others have said earlier today: how do you deal with handling or enforcing composition order? I.e. are you implicitly assuming/requiring that the various elements in the chain are orthogonal with respect to changes in the input/output stream or changes in state that other elements in the chain might have visibility into? Or do you assume that the composition order is part of the interface specification, document accordingly, and hope that your clients will read and follow the ordering specification? Ted H more or less suggested this, but I think the way to go is to give each command an opportunity to validate any contract pre-conditions, like expecting certain beans to be defined in the context. You could even just leave this up to the command author to do in the main execute method, but it might promote good practice if it were explicitly in the API. Joe -- -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com If nature worked that way, the universe would crash all the time. --Jaron Lanier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message and its contents (to include attachments) are the property of Kmart Corporation (Kmart) and may contain confidential and proprietary information. You are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on information contained herein is strictly prohibited. Unauthorized use of information contained herein may subject you to civil and criminal prosecution and penalties. If you are not the intended recipient, you should delete this message immediately. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ActionForwards, et al (was SuccessAction)
-Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: 11 August 2003 14:47 To: Struts Developers List Subject: Re: ActionForwards, et al (was SuccessAction) --- Ted Husted [EMAIL PROTECTED] wrote: David Graham wrote: What I think we're seeing here is that we've outgrown our ActionForward declarations and need some new ones. I'm fine with adding a SuccessAction but would really like to see us discuss future possibilities in this area. This may not be what you meant, but I've been thinking that ActionForward could use a class extension point, same as ActionMapping. The idea would be to give ActionForward a type property for a Java class. If the property is specified, instead of just taking the path as it stands, the Controller would call a prepare method on the class, passing it the ActionForward, ActionForm, HttpRequest, and HttpResponse. This may be a good time to add an ActionContext interface instead of passing all these individual pieces. This would also slightly remove the dependence on Servlet to allow us more flexibility when we look at the Portlet API. +1 Aggregate ActionForm,ActionMapping,HttpServletRequest,HttpServletResponse into one object. This is what I have done for Struts 1.0.2 old project in base action class and for this new one at Royal Bank of Scotland. -- Peter Pilgrim, Struts/J2EE Consultant, RBoS FM, Risk IT Tel: +44 (0)207-375-4923 *** This e-mail is intended only for the addressee named above. As this e-mail may contain confidential or privileged information, if you are not the named addressee, you are not authorised to retain, read, copy or disseminate this message or any part of it. The Royal Bank of Scotland plc is registered in Scotland No 90312 Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB Regulated by the Financial Services Authority Visit our website at http://www.rbs.co.uk/CBFM/ *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ActionForwards, et al (was SuccessAction)
On Tue, 12 Aug 2003, Mainguy, Mike wrote: Date: Tue, 12 Aug 2003 10:05:15 -0400 From: Mainguy, Mike [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: 'Struts Developers List' [EMAIL PROTECTED] Subject: RE: ActionForwards, et al (was SuccessAction) I think that is reasonable, but, if it is too generic, we would end up with no value. I.E. if all we can do it pull generic objects in and out and cast them to what they need to be, we end up unifying the interface for a bunch of differing technologies, but causing more work when using them by them selves. What would be really cool is if a commons/context framework where developed that was based on a Base that had prerolled subclasses that where overloaded to return the proper type for what you want (i.e. HttpServletRequest, Cookies[], Cookie, Beans, DynaBeans, Maps...) so if you are coding an action class, you can get a cookie out of the context by using context.getCookie(foo) instead of the more generic (but flexible) (Cookie)context.get(foo). I think an underlying interface would be ok, but, it seems a lot of functionality for these different contexts would end up being replicated anyway and perhaps we could unify it a bit by putting some core functionality in the Base Class (i.e. BeanUtils.copyProperties()...) What you described is pretty much exactly how the Context in commons-chain is implemented -- but with an extra twist. In order to keep users of the Context from always having to cast to some known implementation class, it supports attribute-property transparency. In other words, if your Context implementation class has a foo property that is a String, the following two calls are identical: String foo = ((MyContext) context).getFoo(); String foo = (String) context.getAttributes().get(foo); In addition, commons-chain provides a couple of layers of Context implementation (optional, compiled only if you have the corresponding APIs) for web applications: // The fundamental interface package org.apache.commons.chain; public interface Context; // Convenience base class that does the transparency trick package org.apache.commons.chain.impl; public class ContextBase implements Context; // Abstract base class for web tier Context implementations package org.apache.commons.chain.web; public abstract class WebContext extends ContextBase; // Concrete class for Servlet API package org.apache.commons.chain.web.servlet; public class ServletWebContext extends WebContext; // Concrete class for Portlet API package org.apache.commons.chain.web.portlet; public class PortletWebContext extends WebContext; The WebContext class adds things like the applicatonScope property that returns a Map of the application attributes, whereas ServletWebContext implements that based on ServletContext, and PortletWebContext implements that based on PortletContext. Now, someone who receives a Context can be as generic or specific as they want, and cast only if they want the type safe property accessors: Map map = (Map) context.getAttributes().get(applicationScope); Map map = ((WebContext) context).getAppicationScope(); Note that the latter call works in either a Servlet or a Portlet environment, because the difference is abstracted away. (JavaServer Faces does exactly this sort of thing in ExternalContext :-). And, all of this is a long-winded way of saying that a Context implementation without some sort of specific functionality isn't really needed. If what you want is a reusable container for named variables, we've already got a perfectly good API for that purpose, complete with very powerful abstractions and a variety of implementations: java.util.Map :-). Craig -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 12, 2003 9:47 AM To: Struts Developers List Subject: Re: ActionForwards, et al (was SuccessAction) David Graham wrote: No, I was thinking Actions would be passed an ActionContext in their execute() method similar to how Servlets know about a ServletContext. The ActionContext would contain the HttpServletRequest, form bean, etc. and would serve to keep the API stable while allowing flexibility in what the ActionContext actually contained. Perhaps it's time for a Commons Context foundation class. Tiles uses a Context, Velocity uses a Context, the Commons-Chain sandbox package uses a Context, Struts wants to use a Context, and I'm sure that there are others. Ideally, we might want to be able to pass a Context between Struts and the business layer as well as other packages like Tiles and Velocity. So it might be helpful if they could be implementations of the same underlying interface. Perhaps we could squeeze it into Resources, since, in practice, messages are definitely something you would be attaching to a Context. =:0) I just don't want Geir coming along in a few months and pointing out how many
Re: ActionForwards, et al (was SuccessAction)
David Graham wrote: No, I was thinking Actions would be passed an ActionContext in their execute() method similar to how Servlets know about a ServletContext. The ActionContext would contain the HttpServletRequest, form bean, etc. and would serve to keep the API stable while allowing flexibility in what the ActionContext actually contained. Perhaps it's time for a Commons Context foundation class. Tiles uses a Context, Velocity uses a Context, the Commons-Chain sandbox package uses a Context, Struts wants to use a Context, and I'm sure that there are others. Ideally, we might want to be able to pass a Context between Struts and the business layer as well as other packages like Tiles and Velocity. So it might be helpful if they could be implementations of the same underlying interface. Perhaps we could squeeze it into Resources, since, in practice, messages are definitely something you would be attaching to a Context. =:0) I just don't want Geir coming along in a few months and pointing out how many Context implementations we have in Jakarta now =:0) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ActionForwards, et al (was SuccessAction)
At 21:36 -0700 8/13/03, Craig R. McClanahan wrote: Ted H more or less suggested this, but I think the way to go is to give each command an opportunity to validate any contract pre-conditions, like expecting certain beans to be defined in the context. You could even just leave this up to the command author to do in the main execute method, but it might promote good practice if it were explicitly in the API. How would you suggest putting something like this into the API? Adding a method like verifyPreconditions() seems like it makes things harder instead of easier -- why not just let the execute() method throw an IllegalStateException (or something like that) if its preconditions are not met? I'm not sure I see why a verify... method makes things harder, except that it's an awkward method name. However, I can't think of any that I like much better, which I sometimes take as a sign that an idea isn't strong enough. But sometimes other folks on the list pick up on the bud of an idea and take it the next step. I don't think I feel strongly enough about this to make much of a case for it. IllegalStateException will handle this problem. Joe -- -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com If nature worked that way, the universe would crash all the time. --Jaron Lanier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ActionForwards, et al (was SuccessAction)
--- Ted Husted [EMAIL PROTECTED] wrote: David Graham wrote: What I think we're seeing here is that we've outgrown our ActionForward declarations and need some new ones. I'm fine with adding a SuccessAction but would really like to see us discuss future possibilities in this area. This may not be what you meant, but I've been thinking that ActionForward could use a class extension point, same as ActionMapping. The idea would be to give ActionForward a type property for a Java class. If the property is specified, instead of just taking the path as it stands, the Controller would call a prepare method on the class, passing it the ActionForward, ActionForm, HttpRequest, and HttpResponse. This may be a good time to add an ActionContext interface instead of passing all these individual pieces. This would also slightly remove the dependence on Servlet to allow us more flexibility when we look at the Portlet API. The prepare method would return a String that the Controller would use for the path. This allows the ActionForward to act as a Page Controller for the path. If the particular page referenced by the path needs any special chrome the Page Controller can set that up. Or, if the path needs to be adjusted for Locale or device (PDA, browser, et al), then the Page Controller could adjust the path before returning it. If it were a virtual page, like an dynamic image, merge file, or PDF, the Page class could also render the Response, rather than have the Action do it. Right now, the Action is doing double duty. It first acts as a Dispatcher that acquires business resources and selects the logical view. But, in real life, many pages often need special runtime resources of their own. So, the Action also serves as a Page Controller for the page it selects. Many of us consider that a mixing of concerns, and so we start to use some Actions as Dispatchers and others as Page Controllers. Tiles also fills this gap and is essentially a hybrid of a Compositive View and a Page Controller framework. I'm thinking that, architecturally, the ActionForward represents some resource available to the application, of any type, that can be reached by the application's protocol. In an http environment, it's the job of a Resource object to provide a URI that the Controller can use the reach the actual resource. (And, in another environment, perhaps the path would not be a URI.) The Action, in its purest form, represents a Dispatcher. It's the job of a Dispatcher to select which (logical) Resource will handle the response. When we talk about selecting between success, failure, or glockenspiel, we're talking about dispatching. But, in real life, we often can't just dispatch to a page. The page needs certain resources to render, often to fill UI controls like select lists. Ideally, I believe another class, specified by the ActionForward, should be responsible for setting up any chrome a particular page may need. It's the one that knows where the page is (via the path property), and so it's the one that should be privy to these details. What would start to happen here, I think, is that people will put into the new class the code that now encourages them to chain some Actions. By providing a separation of concern between choosing the Resource and preparing the context for the Resource, it becomes easier for people to Do The Right Thing. I've had similar composition problems and agree that a separation makes sense. Tiles Controllers can be used to setup page data but that doesn't always work (especially if you're not using Tiles :-) so I end up chaining actions. None of the action chaining is due to bus. logic as that's properly factored into a Service layer; it has to do purely with setting up page data. Tiles Controllers are one of the major reasons I use Tiles and I think it's appropriate to move that concept into the Struts core. David The gotcha is that, to do its job, the ActionForward type may also need to interact with the business layer. It doesn't seem right that the Page Controller should try to branch to another page, like an Action might, if there's an error. But the declarative exception handling might be able to step in here. -Ted. -- Ted Husted, Junit in Action - http://www.manning.com/massol/, Struts in Action - http://husted.com/struts/book.html, JSP Site Design - http://www.amazon.com/exec/obidos/ISBN=1861005512. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands,
[OT] Re: ActionForwards, et al (was SuccessAction)
Sigh! I cannot stand bad grammar, so once again I must remind my nerd friends that et al strictly applies to people, and that an ActionForward, while dear to my heart, is just not a person. LOL! I hope you take this as interesting and new knowledge and not as a pain in the patoosh. Bye 'd bye! At 08:40 PM 8/12/2003 +0100, Peter A. Pilgrim wrote: David Graham wrote: --- PILGRIM, Peter, FM [EMAIL PROTECTED] wrote: -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] --//-- I chose my words carefully when I said ActionContext interface. I *think* we can all agree that if we added this it should be an interface :-). ---- Why would want the ActionContext to be an interface? Well, ServletContext is an interface and it makes sense for this to be an interface rather than an unnecessarily limiting base class. --//-- I presume that there would be default implementation , then. What I am getting at here, this default implementation could be extended by normal web application developers, say to add in security profile information. Non-trival web application, say framework developers like myself, would write implementation of the interface. In Expresso there are two contextes ( ControllerRequest and ControllerResponse) abstractions of the web servlet request and servlet response. We can write controller that run outside of the web app environment. I think this is where you are going with the ActionContext interface. If the interface was supposed to be environment free what would this interface be? -- Peter Pilgrim __ _ _ _ / //__ // ___// ___/ + Serverside Java / /___/ // /__ / /__ + Struts / // ___// ___// ___/ + Expresso Committer __/ // /__ / /__ / /__ + Independent Contractor /___/////// + Intrinsic Motivation On Line Resume || \\=== `` http://www.xenonsoft.demon.co.uk/no-it-striker.html '' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] LEGAL NOTICE This electronic mail transmission and any accompanying documents contain information belonging to the sender which may be confidential and legally privileged. This information is intended only for the use of the individual or entity to whom this electronic mail transmission was sent as indicated above. If you are not the intended recipient, any disclosure, copying, distribution, or action taken in reliance on the contents of the information contained in this transmission is strictly prohibited. If you have received this transmission in error, please delete the message. Thank you - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ActionForwards, et al (was SuccessAction)
This conversation seems to be a by-product of looking at the Action classes as children of the servlet and consumers of messages instead of stand-alone entities. One intriguing way of dealing with this (IMHO) would be to consider elements as being able to Pull the required components out of some other area (Context?) (much like how the Turbine framework does). Instead of Chaining commands or passing a context to every execute(), you would make available a generic application infrastructure that you could pull your required components from. Really this is probably just a semantic difference as the implementation (in my mind) would probably be much the same, but, to me when you word it as something 'Pulling' something out of the Context it makes more sense (errr, I can visualize it better at least) than trying to guess what should be 'Passed' along. Comments? -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 12, 2003 5:37 PM To: Struts Developers List Subject: Re: ActionForwards, et al (was SuccessAction) Craig R. McClanahan wrote: One of the potential problems in a Context-based environment is knowing which keys you are using to store and retrieve stuff -- obviously, the producer and consumer of a piece of data need to agree. It is also important that people looking at a Command should be able to determine what attributes will be used for what by this particular Command. The convention of exposing the keys that you're using seems quite helpful in this regard, for at least two reasons: * It's automatically configurable in case you want to reuse the Command implementation in a different way. * The fact that a fooKey property exists is automatically documentation that your Command is going to utilize a particular attribute for some purpose. And a potential problem in any Strategy-based implementation is that you don't know which of the parameters are actually used by a particular instance. For example, every Action is passed the Response, but very few every actually use it. In a framework like Struts, we can be passing some type of ActionContext that would have JavaBean properties corresponding to the greatest-denominator signature. So, given the properties, we'd have the same level of documentation as we do now. In implementing a Strategy-based or Context-based business layer framework, something I'm starting to look at know is the idea of building validation into the Command processing. So just as we can validate ActionForms, you might also want to validate a Context for a particular Command, using the Command's Catalog name (to use the Chain classnames) as the key. Of course, here, I'm talking about that fabled business layer framework that would live below Struts but use the same architectural patterns =:0) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message and its contents (to include attachments) are the property of Kmart Corporation (Kmart) and may contain confidential and proprietary information. You are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on information contained herein is strictly prohibited. Unauthorized use of information contained herein may subject you to civil and criminal prosecution and penalties. If you are not the intended recipient, you should delete this message immediately. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ActionForwards, et al (was SuccessAction)
Just a little me-too here, but I think both Ted and David have good points. Ted's approach to adding a controller to the ActionForward is a relatively small change to the infrastructure that can offer a lot of gain. And I've been interested in seeing some kind of ActionContext class for quite a while now. Joe At 6:47 -0700 8/11/03, David Graham wrote: --- Ted Husted [EMAIL PROTECTED] wrote: David Graham wrote: What I think we're seeing here is that we've outgrown our ActionForward declarations and need some new ones. I'm fine with adding a SuccessAction but would really like to see us discuss future possibilities in this area. This may not be what you meant, but I've been thinking that ActionForward could use a class extension point, same as ActionMapping. The idea would be to give ActionForward a type property for a Java class. If the property is specified, instead of just taking the path as it stands, the Controller would call a prepare method on the class, passing it the ActionForward, ActionForm, HttpRequest, and HttpResponse. This may be a good time to add an ActionContext interface instead of passing all these individual pieces. This would also slightly remove the dependence on Servlet to allow us more flexibility when we look at the Portlet API. The prepare method would return a String that the Controller would use for the path. This allows the ActionForward to act as a Page Controller for the path. If the particular page referenced by the path needs any special chrome the Page Controller can set that up. Or, if the path needs to be adjusted for Locale or device (PDA, browser, et al), then the Page Controller could adjust the path before returning it. If it were a virtual page, like an dynamic image, merge file, or PDF, the Page class could also render the Response, rather than have the Action do it. Right now, the Action is doing double duty. It first acts as a Dispatcher that acquires business resources and selects the logical view. But, in real life, many pages often need special runtime resources of their own. So, the Action also serves as a Page Controller for the page it selects. Many of us consider that a mixing of concerns, and so we start to use some Actions as Dispatchers and others as Page Controllers. Tiles also fills this gap and is essentially a hybrid of a Compositive View and a Page Controller framework. I'm thinking that, architecturally, the ActionForward represents some resource available to the application, of any type, that can be reached by the application's protocol. In an http environment, it's the job of a Resource object to provide a URI that the Controller can use the reach the actual resource. (And, in another environment, perhaps the path would not be a URI.) The Action, in its purest form, represents a Dispatcher. It's the job of a Dispatcher to select which (logical) Resource will handle the response. When we talk about selecting between success, failure, or glockenspiel, we're talking about dispatching. But, in real life, we often can't just dispatch to a page. The page needs certain resources to render, often to fill UI controls like select lists. Ideally, I believe another class, specified by the ActionForward, should be responsible for setting up any chrome a particular page may need. It's the one that knows where the page is (via the path property), and so it's the one that should be privy to these details. What would start to happen here, I think, is that people will put into the new class the code that now encourages them to chain some Actions. By providing a separation of concern between choosing the Resource and preparing the context for the Resource, it becomes easier for people to Do The Right Thing. I've had similar composition problems and agree that a separation makes sense. Tiles Controllers can be used to setup page data but that doesn't always work (especially if you're not using Tiles :-) so I end up chaining actions. None of the action chaining is due to bus. logic as that's properly factored into a Service layer; it has to do purely with setting up page data. Tiles Controllers are one of the major reasons I use Tiles and I think it's appropriate to move that concept into the Struts core. David The gotcha is that, to do its job, the ActionForward type may also need to interact with the business layer. It doesn't seem right that the Page Controller should try to branch to another page, like an Action might, if there's an error. But the declarative exception handling might be able to step in here. -Ted. -- Ted Husted, Junit in Action - http://www.manning.com/massol/, Struts in Action - http://husted.com/struts/book.html, JSP Site Design - http://www.amazon.com/exec/obidos/ISBN=1861005512. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ActionForwards, et al (was SuccessAction)
On Wed, 13 Aug 2003, Peter A. Pilgrim wrote: Date: Wed, 13 Aug 2003 07:48:57 +0100 From: Peter A. Pilgrim [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: ActionForwards, et al (was SuccessAction) Craig R. McClanahan wrote: On Tue, 12 Aug 2003, Peter A. Pilgrim wrote: So we could have convenience methods such as StrutsWebContext scontext = (StrutsWebContext)context; // Where ``StrutsWebContext'' is a type of ``ServletWebContext'' ActionForm form = scontext.getActionForm(); ActionMapping mapping = scontext.getActionMapping(); If we're talking about a Struts2 world (where we're willing to reconsider the calling sequence of an Action anyway), wouldn't it be better to make StrutsWebContext just extend WebContext instead of ServletWebContext? That way we could have transparent support for servlets and portlets. So instead you would make convenience method from WebContext instead I see the `WebContext.getRequestScope()' returns a mutable map of attribute values. In other words they are derived from `ServletRequest.getAttributeNames()'. But looking at the current Struts 1.1 library would you for compatibility reason also supply the `HttpServletRequest' object to Struts users? HttpServletRequest = StrutsWebContext.getRequest(); // convenience method and like wise `HttpServletResponse' object? In the contrib/struts-chain sources, I actually do that because I was trying to avoid requiring any changes to the Action signature, so it is certainly feasible. You'll also note that I didn't try to create a StrutsWebContext at all -- just used WebContext with conventions on what attribute keys the standard Struts objects were passed under. Another import idea is that, if we wanted, we could also add other other convenience methods to the context without breaking the signature. My question above. And presumably we [as application developer] will be able to subclass the ServletWebContext and add application features like Single Sign-On / Security / personalisation etcetera. We will be able to configure Struts Module to use our custom `Context' instead of the Struts default context. Yep this is looking sexy. Yep ... lots of interesting room for playing around here. To say nothing of the fact that you can compose your own request processor pipeline to boot. Moving swiftly back to the original design reason. The [old] request processor is now effectively a `Chain' isn't it? ( ... I will now continue this note at work ) That's what I was trying to do in contrib/struts-chain. It doesn't contain all the standard functionality, and hasn't been tested at all, but it looks like the idea is feasible. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ActionForwards, et al (was SuccessAction)
On Wed, 13 Aug 2003, Sgarlata Matt wrote: In terms of making the infrastructure available to callers, it's pretty clear how passing a context object around makes the infrastructure available to anyone who needs it. Are there other options for how you'd make the infrastructure available without passing it? I haven't thought of any. Sorry if this was already said, but couldn't you use JNDI if you wanted to use a pull approach? I'm not sure if that's a good idea or not, but I thought I would throw it out there. Do you mean the JNDI naming context that the web contgainer provides for you? If so, it's got two serious problems: * It's read-only * It's application scoped so you wouldn't be able to store any per-request or per-session stuff there, without building some sort of data structures inside. Regarding context in general, what you normally want is essentially a HashMap with typesafe getters and setters for well-known things. You don't necessarily need the hierarchy support that something like JNDI would provide. Matt Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ActionForwards, et al (was SuccessAction)
Craig R. McClanahan wrote: On Tue, 12 Aug 2003, Peter A. Pilgrim wrote: So we could have convenience methods such as StrutsWebContext scontext = (StrutsWebContext)context; // Where ``StrutsWebContext'' is a type of ``ServletWebContext'' ActionForm form = scontext.getActionForm(); ActionMapping mapping = scontext.getActionMapping(); If we're talking about a Struts2 world (where we're willing to reconsider the calling sequence of an Action anyway), wouldn't it be better to make StrutsWebContext just extend WebContext instead of ServletWebContext? That way we could have transparent support for servlets and portlets. So instead you would make convenience method from WebContext instead I see the `WebContext.getRequestScope()' returns a mutable map of attribute values. In other words they are derived from `ServletRequest.getAttributeNames()'. But looking at the current Struts 1.1 library would you for compatibility reason also supply the `HttpServletRequest' object to Struts users? HttpServletRequest = StrutsWebContext.getRequest(); // convenience method and like wise `HttpServletResponse' object? Another import idea is that, if we wanted, we could also add other other convenience methods to the context without breaking the signature. My question above. And presumably we [as application developer] will be able to subclass the ServletWebContext and add application features like Single Sign-On / Security / personalisation etcetera. We will be able to configure Struts Module to use our custom `Context' instead of the Struts default context. Yep this is looking sexy. Yep ... lots of interesting room for playing around here. To say nothing of the fact that you can compose your own request processor pipeline to boot. Moving swiftly back to the original design reason. The [old] request processor is now effectively a `Chain' isn't it? ( ... I will now continue this note at work ) -- Peter Pilgrim __ _ _ _ / //__ // ___// ___/ + Serverside Java / /___/ // /__ / /__ + Struts / // ___// ___// ___/ + Expresso Committer __/ // /__ / /__ / /__ + Independent Contractor /___/////// + Intrinsic Motivation On Line Resume || \\=== `` http://www.xenonsoft.demon.co.uk/no-it-striker.html '' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ActionForwards, et al (was SuccessAction)
Comment at the bottom of this message... - Original Message - From: Craig R. McClanahan [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Tuesday, August 12, 2003 6:13 PM Subject: RE: ActionForwards, et al (was SuccessAction) On Tue, 12 Aug 2003, Mainguy, Mike wrote: Date: Tue, 12 Aug 2003 18:03:14 -0400 From: Mainguy, Mike [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: 'Struts Developers List' [EMAIL PROTECTED] Subject: RE: ActionForwards, et al (was SuccessAction) This conversation seems to be a by-product of looking at the Action classes as children of the servlet and consumers of messages instead of stand-alone entities. One intriguing way of dealing with this (IMHO) would be to consider elements as being able to Pull the required components out of some other area (Context?) (much like how the Turbine framework does). Instead of Chaining commands or passing a context to every execute(), you would make available a generic application infrastructure that you could pull your required components from. Really this is probably just a semantic difference as the implementation (in my mind) would probably be much the same, but, to me when you word it as something 'Pulling' something out of the Context it makes more sense (errr, I can visualize it better at least) than trying to guess what should be 'Passed' along. Comments? Doesn't pulling something from some application infrastructure imply that somebody else pushed it into that infrastructure? For example, if you expect to find the HttpServletRequest object in there, presumably the controller must have seeded that content. It's also perfectly reasonable for one Command in a Chain (in commons-sandbox/chain terms) to push something into the Context that another Command executed later will need. In terms of making the infrastructure available to callers, it's pretty clear how passing a context object around makes the infrastructure available to anyone who needs it. Are there other options for how you'd make the infrastructure available without passing it? I haven't thought of any. Sorry if this was already said, but couldn't you use JNDI if you wanted to use a pull approach? I'm not sure if that's a good idea or not, but I thought I would throw it out there. Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ActionForwards, et al (was SuccessAction)
the patch is here: http://issues.apache.org/bugzilla/show_bug.cgi?id=18002 This one needs to be in a 1.1 release. -TPP - This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, retention, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. Also, email is susceptible to data corruption, interception, tampering, unauthorized amendment and viruses. We only send and receive emails on the basis that we are not liable for any such corruption, interception, tampering, amendment or viruses or any consequence thereof. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ActionForwards, et al (was SuccessAction)
On Wed, 13 Aug 2003, Joe Germuska wrote: Date: Wed, 13 Aug 2003 22:01:30 -0500 From: Joe Germuska [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: RE: ActionForwards, et al (was SuccessAction) At 9:07 PM -0400 8/12/03, Byrne, Steven wrote: I guess I have to reiterate what others have said earlier today: how do you deal with handling or enforcing composition order? I.e. are you implicitly assuming/requiring that the various elements in the chain are orthogonal with respect to changes in the input/output stream or changes in state that other elements in the chain might have visibility into? Or do you assume that the composition order is part of the interface specification, document accordingly, and hope that your clients will read and follow the ordering specification? Ted H more or less suggested this, but I think the way to go is to give each command an opportunity to validate any contract pre-conditions, like expecting certain beans to be defined in the context. You could even just leave this up to the command author to do in the main execute method, but it might promote good practice if it were explicitly in the API. How would you suggest putting something like this into the API? Adding a method like verifyPreconditions() seems like it makes things harder instead of easier -- why not just let the execute() method throw an IllegalStateException (or something like that) if its preconditions are not met? Such a policy is easily unit testable as well. Joe Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ActionForwards, et al (was SuccessAction)
--- Peter A. Pilgrim [EMAIL PROTECTED] wrote: David Graham wrote: --- PILGRIM, Peter, FM [EMAIL PROTECTED] wrote: -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] --//-- I chose my words carefully when I said ActionContext interface. I *think* we can all agree that if we added this it should be an interface :-). ---- Why would want the ActionContext to be an interface? Well, ServletContext is an interface and it makes sense for this to be an interface rather than an unnecessarily limiting base class. --//-- I presume that there would be default implementation , then. What I am getting at here, this default implementation could be extended by normal web application developers, say to add in security profile information. Non-trival web application, say framework developers like myself, would write implementation of the interface. In Expresso there are two contextes ( ControllerRequest and ControllerResponse) abstractions of the web servlet request and servlet response. We can write controller that run outside of the web app environment. I think this is where you are going with the ActionContext interface. The main goal of an ActionContext being passed to Action.execute() methods would be to separate Actions from the Servlet API so that you could write Actions to respond to Porlets. It would also serve to stabalize the execute() method's interface and allow you to pass in more than the current 4 or 5 parameters. If the interface was supposed to be environment free what would this interface be? Not necessarily environment free but more environment neutral. For example, I have no interest in using Struts for Swing apps but do for web apps using Servlet and/or Portlet. David -- Peter Pilgrim __ _ _ _ / //__ // ___// ___/ + Serverside Java / /___/ // /__ / /__ + Struts / // ___// ___// ___/ + Expresso Committer __/ // /__ / /__ / /__ + Independent Contractor /___/////// + Intrinsic Motivation On Line Resume || \\=== `` http://www.xenonsoft.demon.co.uk/no-it-striker.html '' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ActionForwards, et al (was SuccessAction)
On Mon, 11 Aug 2003, Ted Husted wrote: Since, I'm lead to understand Craig finds http hard to say when he gives talks =:) Ah, you've heard me trip over that one? :-). I actually like web better than http for a different reason -- it doesn't presume the one true way protocol will be around forever. While talking about contexts and layers, there's actually room for a controller layer below the HTTP layer as well, on top of which you can build the web layer and then the app layer. The general pattern is also useful in business logic as well. That idea, and some of your earlier thoughts, were part of the inspiration for commons-chain -- which I've been noodling on for about six months but never had time to get finished and polished enough to post until this last weekend. -Ted. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ActionForwards, et al (was SuccessAction)
-Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] --//-- The idea would be to give ActionForward a type property for a Java class. If the property is specified, instead of just taking the path as it stands, the Controller would call a prepare method on the class, passing it the ActionForward, ActionForm, HttpRequest, and HttpResponse. The prepare method would return a String that the Controller would use for the path. This allows the ActionForward to act as a Page Controller for the path. If the particular page referenced by the path needs any special chrome the Page Controller can set that up. Or, if the path needs to be adjusted for Locale or device (PDA, browser, et al), then the Page Controller could adjust the path before returning it. If it were a virtual page, like an dynamic image, merge file, or PDF, the Page class could also render the Response, rather than have the Action do it. Right now, the Action is doing double duty. It first acts as a Dispatcher that acquires business resources and selects the logical view. But, in real life, many pages often need special runtime resources of their own. So, the Action also serves as a Page Controller for the page it selects. Many of us consider that a mixing of concerns, and so we start to use some Actions as Dispatchers and others as Page Controllers. Tiles also fills this gap and is essentially a hybrid of a Compositive View and a Page Controller framework. If an action forward requires special business requirements then I can see both advantages and disadvantages. The advantages is that such a new ActionForward could add special attributes to the response that are not concerned with the Action logic. The disadvantages is that it is open to abuse. Bad programming could introduce another layer of dispatching in the ActionForward code. You would get mini-MVC nested inside another MVC, which looks like Hierarchical MVC I'm thinking that, architecturally, the ActionForward represents some resource available to the application, of any type, that can be reached by the application's protocol. In an http environment, it's the job of a Resource object to provide a URI that the Controller can use the reach the actual resource. (And, in another environment, perhaps the path would not be a URI.) The Action, in its purest form, represents a Dispatcher. It's the job of a Dispatcher to select which (logical) Resource will handle the response. When we talk about selecting between success, failure, or glockenspiel, we're talking about dispatching. But, in real life, we often can't just dispatch to a page. The page needs certain resources to render, often to fill UI controls like select lists. Ideally, I believe another class, specified by the ActionForward, should be responsible for setting up any chrome a particular page may need. It's the one that knows where the page is (via the path property), and so it's the one that should be privy to these details. If you wanted to develop a skinnable web application for example personalisation this new ActionForward might be the way to go. What would start to happen here, I think, is that people will put into the new class the code that now encourages them to chain some Actions. By providing a separation of concern between choosing the Resource and preparing the context for the Resource, it becomes easier for people to Do The Right Thing. The gotcha is that, to do its job, the ActionForward type may also need to interact with the business layer. It doesn't seem right that the Page Controller should try to branch to another page, like an Action might, if there's an error. But the declarative exception handling might be able to step in here. Would this new ActionForward be created each time like it is now? Or would it become a dynamic singleton? The problem is not necessarily interacting with the business tier, but making any such interaction to a minimum. The probably means delegation, or caching, or something else to add decoration. Ideally the Struts Action such grab all the business logic for you and then store this information for you. If you are developing a new Action Forward, may be take advantage of this fact, and pass the business info to this new object at construction time. --//-- -- Peter Pilgrim, Struts/J2EE Consultant, RBoS FM, Risk IT Tel: +44 (0)207-375-4923 *** This e-mail is intended only for the addressee named above. As this e-mail may contain confidential or privileged information, if you are not the named addressee, you are not authorised to retain, read, copy or disseminate this message or any part of it. The Royal Bank of Scotland plc is registered in Scotland No 90312 Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB
Re: ActionForwards, et al (was SuccessAction)
Ted Husted wrote: Peter A. Pilgrim wrote: If the interface was supposed to be environment free what would this interface be? Have a look at the abstract WebContext in the Craig's new Chain of Responsibility package. http://jakarta.apache.org/builds/jakarta-commons/nightly/commons-chain/ So, the ActionContext interface *might* start with the WebContext members and then add some convenience methods for retrieving the ActionMapping and ActionForm. MyActionForm form = (MyActionForm) context.getActionForm(); The idea being that at runtime Struts could be passing around a ServletActionContext or a PortletActionContext, or a generic ActionContext (implemented with HashMaps) that you populated yourself as part of an automatic test. Right. So we could have convenience methods such as StrutsWebContext scontext = (StrutsWebContext)context; // Where ``StrutsWebContext'' is a type of ``ServletWebContext'' ActionForm form = scontext.getActionForm(); ActionMapping mapping = scontext.getActionMapping(); Another import idea is that, if we wanted, we could also add other other convenience methods to the context without breaking the signature. And presumably we [as application developer] will be able to subclass the ServletWebContext and add application features like Single Sign-On / Security / personalisation etcetera. We will be able to configure Struts Module to use our custom `Context' instead of the Struts default context. Yep this is looking sexy. -- Peter Pilgrim __ _ _ _ / //__ // ___// ___/ + Serverside Java / /___/ // /__ / /__ + Struts / // ___// ___// ___/ + Expresso Committer __/ // /__ / /__ / /__ + Independent Contractor /___/////// + Intrinsic Motivation On Line Resume || \\=== `` http://www.xenonsoft.demon.co.uk/no-it-striker.html '' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ActionForwards, et al (was SuccessAction)
Except JNDI wouldn't necessary give use the ability to have the context be dynamic (i.e. how do you pull an HttpServletRequest out of a JNDI context) hmmm, maybe you could do that -Original Message- From: Sgarlata Matt [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 13, 2003 7:11 PM To: Struts Developers List Subject: Re: ActionForwards, et al (was SuccessAction) Comment at the bottom of this message... - Original Message - From: Craig R. McClanahan [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Tuesday, August 12, 2003 6:13 PM Subject: RE: ActionForwards, et al (was SuccessAction) On Tue, 12 Aug 2003, Mainguy, Mike wrote: Date: Tue, 12 Aug 2003 18:03:14 -0400 From: Mainguy, Mike [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: 'Struts Developers List' [EMAIL PROTECTED] Subject: RE: ActionForwards, et al (was SuccessAction) This conversation seems to be a by-product of looking at the Action classes as children of the servlet and consumers of messages instead of stand-alone entities. One intriguing way of dealing with this (IMHO) would be to consider elements as being able to Pull the required components out of some other area (Context?) (much like how the Turbine framework does). Instead of Chaining commands or passing a context to every execute(), you would make available a generic application infrastructure that you could pull your required components from. Really this is probably just a semantic difference as the implementation (in my mind) would probably be much the same, but, to me when you word it as something 'Pulling' something out of the Context it makes more sense (errr, I can visualize it better at least) than trying to guess what should be 'Passed' along. Comments? Doesn't pulling something from some application infrastructure imply that somebody else pushed it into that infrastructure? For example, if you expect to find the HttpServletRequest object in there, presumably the controller must have seeded that content. It's also perfectly reasonable for one Command in a Chain (in commons-sandbox/chain terms) to push something into the Context that another Command executed later will need. In terms of making the infrastructure available to callers, it's pretty clear how passing a context object around makes the infrastructure available to anyone who needs it. Are there other options for how you'd make the infrastructure available without passing it? I haven't thought of any. Sorry if this was already said, but couldn't you use JNDI if you wanted to use a pull approach? I'm not sure if that's a good idea or not, but I thought I would throw it out there. Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message and its contents (to include attachments) are the property of Kmart Corporation (Kmart) and may contain confidential and proprietary information. You are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on information contained herein is strictly prohibited. Unauthorized use of information contained herein may subject you to civil and criminal prosecution and penalties. If you are not the intended recipient, you should delete this message immediately. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ActionForwards, et al (was SuccessAction)
At 9:07 PM -0400 8/12/03, Byrne, Steven wrote: I guess I have to reiterate what others have said earlier today: how do you deal with handling or enforcing composition order? I.e. are you implicitly assuming/requiring that the various elements in the chain are orthogonal with respect to changes in the input/output stream or changes in state that other elements in the chain might have visibility into? Or do you assume that the composition order is part of the interface specification, document accordingly, and hope that your clients will read and follow the ordering specification? Ted H more or less suggested this, but I think the way to go is to give each command an opportunity to validate any contract pre-conditions, like expecting certain beans to be defined in the context. You could even just leave this up to the command author to do in the main execute method, but it might promote good practice if it were explicitly in the API. Joe -- -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com If nature worked that way, the universe would crash all the time. --Jaron Lanier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ActionForwards, et al (was SuccessAction)
On Tue, 12 Aug 2003, Peter A. Pilgrim wrote: So we could have convenience methods such as StrutsWebContext scontext = (StrutsWebContext)context; // Where ``StrutsWebContext'' is a type of ``ServletWebContext'' ActionForm form = scontext.getActionForm(); ActionMapping mapping = scontext.getActionMapping(); If we're talking about a Struts2 world (where we're willing to reconsider the calling sequence of an Action anyway), wouldn't it be better to make StrutsWebContext just extend WebContext instead of ServletWebContext? That way we could have transparent support for servlets and portlets. Another import idea is that, if we wanted, we could also add other other convenience methods to the context without breaking the signature. And presumably we [as application developer] will be able to subclass the ServletWebContext and add application features like Single Sign-On / Security / personalisation etcetera. We will be able to configure Struts Module to use our custom `Context' instead of the Struts default context. Yep this is looking sexy. Yep ... lots of interesting room for playing around here. To say nothing of the fact that you can compose your own request processor pipeline to boot. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Re: ActionForwards, et al (was SuccessAction)
Micael wrote: Sigh! I cannot stand bad grammar, so once again I must remind my nerd +++ friends that et al strictly applies to people, and that an ~~~ ^ ^ ActionForward, while dear to my heart, is just not a person. LOL! I * ew%U(R** hope you take this as interesting and new knowledge and not as a pain in the patoosh. Bye 'd bye! ~~~ Time you had a watch -- PP - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Re: ActionForwards, et al (was SuccessAction)
Hi, Peter, Yah, there are some that don't like free knowledge or listening. So there was no way to not offend some people. I appreciate that. Why I don't know, and I don't need to know. But, I have a watch. LOL. Micael At 12:50 AM 8/13/2003 +0100, Peter A. Pilgrim wrote: Micael wrote: Sigh! I cannot stand bad grammar, so once again I must remind my nerd +++ friends that et al strictly applies to people, and that an ~~~ ^ ^ ActionForward, while dear to my heart, is just not a person. LOL! I * ew%U(R** hope you take this as interesting and new knowledge and not as a pain in the patoosh. Bye 'd bye! ~~~ Time you had a watch -- PP - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] LEGAL NOTICE This electronic mail transmission and any accompanying documents contain information belonging to the sender which may be confidential and legally privileged. This information is intended only for the use of the individual or entity to whom this electronic mail transmission was sent as indicated above. If you are not the intended recipient, any disclosure, copying, distribution, or action taken in reliance on the contents of the information contained in this transmission is strictly prohibited. If you have received this transmission in error, please delete the message. Thank you - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ActionForwards, et al (was SuccessAction)
Craig R. McClanahan wrote: One of the potential problems in a Context-based environment is knowing which keys you are using to store and retrieve stuff -- obviously, the producer and consumer of a piece of data need to agree. It is also important that people looking at a Command should be able to determine what attributes will be used for what by this particular Command. The convention of exposing the keys that you're using seems quite helpful in this regard, for at least two reasons: * It's automatically configurable in case you want to reuse the Command implementation in a different way. * The fact that a fooKey property exists is automatically documentation that your Command is going to utilize a particular attribute for some purpose. And a potential problem in any Strategy-based implementation is that you don't know which of the parameters are actually used by a particular instance. For example, every Action is passed the Response, but very few every actually use it. In a framework like Struts, we can be passing some type of ActionContext that would have JavaBean properties corresponding to the greatest-denominator signature. So, given the properties, we'd have the same level of documentation as we do now. In implementing a Strategy-based or Context-based business layer framework, something I'm starting to look at know is the idea of building validation into the Command processing. So just as we can validate ActionForms, you might also want to validate a Context for a particular Command, using the Command's Catalog name (to use the Chain classnames) as the key. Of course, here, I'm talking about that fabled business layer framework that would live below Struts but use the same architectural patterns =:0) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ActionForwards, et al (was SuccessAction)
On Tue, 12 Aug 2003, Mainguy, Mike wrote: Date: Tue, 12 Aug 2003 18:03:14 -0400 From: Mainguy, Mike [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: 'Struts Developers List' [EMAIL PROTECTED] Subject: RE: ActionForwards, et al (was SuccessAction) This conversation seems to be a by-product of looking at the Action classes as children of the servlet and consumers of messages instead of stand-alone entities. One intriguing way of dealing with this (IMHO) would be to consider elements as being able to Pull the required components out of some other area (Context?) (much like how the Turbine framework does). Instead of Chaining commands or passing a context to every execute(), you would make available a generic application infrastructure that you could pull your required components from. Really this is probably just a semantic difference as the implementation (in my mind) would probably be much the same, but, to me when you word it as something 'Pulling' something out of the Context it makes more sense (errr, I can visualize it better at least) than trying to guess what should be 'Passed' along. Comments? Doesn't pulling something from some application infrastructure imply that somebody else pushed it into that infrastructure? For example, if you expect to find the HttpServletRequest object in there, presumably the controller must have seeded that content. It's also perfectly reasonable for one Command in a Chain (in commons-sandbox/chain terms) to push something into the Context that another Command executed later will need. In terms of making the infrastructure available to callers, it's pretty clear how passing a context object around makes the infrastructure available to anyone who needs it. Are there other options for how you'd make the infrastructure available without passing it? I haven't thought of any. Craig -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 12, 2003 5:37 PM To: Struts Developers List Subject: Re: ActionForwards, et al (was SuccessAction) Craig R. McClanahan wrote: One of the potential problems in a Context-based environment is knowing which keys you are using to store and retrieve stuff -- obviously, the producer and consumer of a piece of data need to agree. It is also important that people looking at a Command should be able to determine what attributes will be used for what by this particular Command. The convention of exposing the keys that you're using seems quite helpful in this regard, for at least two reasons: * It's automatically configurable in case you want to reuse the Command implementation in a different way. * The fact that a fooKey property exists is automatically documentation that your Command is going to utilize a particular attribute for some purpose. And a potential problem in any Strategy-based implementation is that you don't know which of the parameters are actually used by a particular instance. For example, every Action is passed the Response, but very few every actually use it. In a framework like Struts, we can be passing some type of ActionContext that would have JavaBean properties corresponding to the greatest-denominator signature. So, given the properties, we'd have the same level of documentation as we do now. In implementing a Strategy-based or Context-based business layer framework, something I'm starting to look at know is the idea of building validation into the Command processing. So just as we can validate ActionForms, you might also want to validate a Context for a particular Command, using the Command's Catalog name (to use the Chain classnames) as the key. Of course, here, I'm talking about that fabled business layer framework that would live below Struts but use the same architectural patterns =:0) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message and its contents (to include attachments) are the property of Kmart Corporation (Kmart) and may contain confidential and proprietary information. You are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on information contained herein is strictly prohibited. Unauthorized use of information contained herein may subject you to civil and criminal prosecution and penalties. If you are not the intended recipient, you should delete this message immediately. - 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: ActionForwards, et al (was SuccessAction)
On Mon, 11 Aug 2003, Mike Jasnowski wrote: Date: Mon, 11 Aug 2003 09:50:29 -0400 From: Mike Jasnowski [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: RE: ActionForwards, et al (was SuccessAction) This may be a good time to add an ActionContext interface instead of passing all these individual pieces. This would also slightly remove the dependence on Servlet to allow us more flexibility when we look at the portlet API. As an outside observer I would like to see something like this added. We've already added something like you describe to our application. You'll also note that commons-chain (basis for the decomposable request processor proposal) does exactly this, with the added twist that it lets you specialize the Context implementation with typesafe property accessors if you want to, or use generic attributes otherwise. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ActionForwards, et al (was SuccessAction)
--- Joe Germuska [EMAIL PROTECTED] wrote: Just a little me-too here, but I think both Ted and David have good points. Ted's approach to adding a controller to the ActionForward is a relatively small change to the infrastructure that can offer a lot of gain. And I've been interested in seeing some kind of ActionContext class for quite a while now. I chose my words carefully when I said ActionContext interface. I *think* we can all agree that if we added this it should be an interface :-). David Joe At 6:47 -0700 8/11/03, David Graham wrote: --- Ted Husted [EMAIL PROTECTED] wrote: David Graham wrote: What I think we're seeing here is that we've outgrown our ActionForward declarations and need some new ones. I'm fine with adding a SuccessAction but would really like to see us discuss future possibilities in this area. This may not be what you meant, but I've been thinking that ActionForward could use a class extension point, same as ActionMapping. The idea would be to give ActionForward a type property for a Java class. If the property is specified, instead of just taking the path as it stands, the Controller would call a prepare method on the class, passing it the ActionForward, ActionForm, HttpRequest, and HttpResponse. This may be a good time to add an ActionContext interface instead of passing all these individual pieces. This would also slightly remove the dependence on Servlet to allow us more flexibility when we look at the Portlet API. The prepare method would return a String that the Controller would use for the path. This allows the ActionForward to act as a Page Controller for the path. If the particular page referenced by the path needs any special chrome the Page Controller can set that up. Or, if the path needs to be adjusted for Locale or device (PDA, browser, et al), then the Page Controller could adjust the path before returning it. If it were a virtual page, like an dynamic image, merge file, or PDF, the Page class could also render the Response, rather than have the Action do it. Right now, the Action is doing double duty. It first acts as a Dispatcher that acquires business resources and selects the logical view. But, in real life, many pages often need special runtime resources of their own. So, the Action also serves as a Page Controller for the page it selects. Many of us consider that a mixing of concerns, and so we start to use some Actions as Dispatchers and others as Page Controllers. Tiles also fills this gap and is essentially a hybrid of a Compositive View and a Page Controller framework. I'm thinking that, architecturally, the ActionForward represents some resource available to the application, of any type, that can be reached by the application's protocol. In an http environment, it's the job of a Resource object to provide a URI that the Controller can use the reach the actual resource. (And, in another environment, perhaps the path would not be a URI.) The Action, in its purest form, represents a Dispatcher. It's the job of a Dispatcher to select which (logical) Resource will handle the response. When we talk about selecting between success, failure, or glockenspiel, we're talking about dispatching. But, in real life, we often can't just dispatch to a page. The page needs certain resources to render, often to fill UI controls like select lists. Ideally, I believe another class, specified by the ActionForward, should be responsible for setting up any chrome a particular page may need. It's the one that knows where the page is (via the path property), and so it's the one that should be privy to these details. What would start to happen here, I think, is that people will put into the new class the code that now encourages them to chain some Actions. By providing a separation of concern between choosing the Resource and preparing the context for the Resource, it becomes easier for people to Do The Right Thing. I've had similar composition problems and agree that a separation makes sense. Tiles Controllers can be used to setup page data but that doesn't always work (especially if you're not using Tiles :-) so I end up chaining actions. None of the action chaining is due to bus. logic as that's properly factored into a Service layer; it has to do purely with setting up page data. Tiles Controllers are one of the major reasons I use Tiles and I think it's appropriate to move that concept into the Struts core. David The gotcha is that, to do its job, the ActionForward type may also need to interact with the business layer. It doesn't seem right that the Page Controller should try to branch to another page, like an Action might, if there's an error. But the declarative exception handling
Re: ActionForwards, et al (was SuccessAction)
--- Ted Husted [EMAIL PROTECTED] wrote: My only concern would be using the term context to imply more than one object. IMHO, there should be a functional non-httpd framework below Struts, that would provide things like a Context Object, which would be a generic version of the HttpRequest. At the Stuts level, you could then have available to you signatures that used a Context or a HttpContext. In the future, we should be able to write pure business Actions that don't use http semantics, and only use the http version when we absolutely need to. In practice, most of us rarely use the http services of the HttpRequest, and the same Actions could be coded using a generic Context (that might be chained to the HttpRequest, as is done with the Velocity Tools). [We started along this way with duel Action classes, but I've never even tried to use the non-http one.] So, if we're talking about the ActionContext interface being an abstraction of the Action class, I'd like to search for another name. No, I was thinking Actions would be passed an ActionContext in their execute() method similar to how Servlets know about a ServletContext. The ActionContext would contain the HttpServletRequest, form bean, etc. and would serve to keep the API stable while allowing flexibility in what the ActionContext actually contained. David My suggestion for an Action class interface would be Action - HttpDispatcher. As for the other core classes, I would suggest ActionForward - HttpResource ActionMapping - HttpCommand or, if you prefer, Action - WebDispatcher ActionForward - WebResource ActionMapping - WebCommand Since, I'm lead to understand Craig finds http hard to say when he gives talks =:) -Ted. David Graham wrote: --- Joe Germuska [EMAIL PROTECTED] wrote: Just a little me-too here, but I think both Ted and David have good points. Ted's approach to adding a controller to the ActionForward is a relatively small change to the infrastructure that can offer a lot of gain. And I've been interested in seeing some kind of ActionContext class for quite a while now. I chose my words carefully when I said ActionContext interface. I *think* we can all agree that if we added this it should be an interface :-). David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ActionForwards, et al (was SuccessAction)
My only concern would be using the term context to imply more than one object. IMHO, there should be a functional non-httpd framework below Struts, that would provide things like a Context Object, which would be a generic version of the HttpRequest. At the Stuts level, you could then have available to you signatures that used a Context or a HttpContext. In the future, we should be able to write pure business Actions that don't use http semantics, and only use the http version when we absolutely need to. In practice, most of us rarely use the http services of the HttpRequest, and the same Actions could be coded using a generic Context (that might be chained to the HttpRequest, as is done with the Velocity Tools). [We started along this way with duel Action classes, but I've never even tried to use the non-http one.] So, if we're talking about the ActionContext interface being an abstraction of the Action class, I'd like to search for another name. My suggestion for an Action class interface would be Action - HttpDispatcher. As for the other core classes, I would suggest ActionForward - HttpResource ActionMapping - HttpCommand or, if you prefer, Action - WebDispatcher ActionForward - WebResource ActionMapping - WebCommand Since, I'm lead to understand Craig finds http hard to say when he gives talks =:) -Ted. David Graham wrote: --- Joe Germuska [EMAIL PROTECTED] wrote: Just a little me-too here, but I think both Ted and David have good points. Ted's approach to adding a controller to the ActionForward is a relatively small change to the infrastructure that can offer a lot of gain. And I've been interested in seeing some kind of ActionContext class for quite a while now. I chose my words carefully when I said ActionContext interface. I *think* we can all agree that if we added this it should be an interface :-). David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ActionForwards, et al (was SuccessAction)
Hi Some time ago I submitted a couple of refactorings to the DispatchAction/LookupDispatchAction classes. Since there was a recent discussion on these actions, I was wondering if that patch was going to be submitted for 1.2. Is there anything else I need to do? the patch is here: http://issues.apache.org/bugzilla/show_bug.cgi?id=18002 Thanks Leonardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ActionForwards, et al (was SuccessAction)
--- Ted Husted [EMAIL PROTECTED] wrote: David Graham wrote: No, I was thinking Actions would be passed an ActionContext in their execute() method similar to how Servlets know about a ServletContext. The ActionContext would contain the HttpServletRequest, form bean, etc. and would serve to keep the API stable while allowing flexibility in what the ActionContext actually contained. Perhaps it's time for a Commons Context foundation class. Tiles uses a Context, Velocity uses a Context, the Commons-Chain sandbox package uses a Context, Struts wants to use a Context, and I'm sure that there are others. Ideally, we might want to be able to pass a Context between Struts and the business layer as well as other packages like Tiles and Velocity. So it might be helpful if they could be implementations of the same underlying interface. Perhaps we could squeeze it into Resources, since, in practice, messages are definitely something you would be attaching to a Context. =:0) I just don't want Geir coming along in a few months and pointing out how many Context implementations we have in Jakarta now =:0) I'm not sure that Context is a reusable idea. The ActionContext is likely to have very different attributes than a VelocityContext (or whatever they call it). For example, Servlet has ServletConfig and Portlet has PortletConfig but that doesn't mean they could both be crammed into OneBigConfig :-). David -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ActionForwards, et al (was SuccessAction)
This may be a good time to add an ActionContext interface instead of passing all these individual pieces. This would also slightly remove the dependence on Servlet to allow us more flexibility when we look at the portlet API. As an outside observer I would like to see something like this added. We've already added something like you describe to our application. -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Monday, August 11, 2003 9:47 AM To: Struts Developers List Subject: Re: ActionForwards, et al (was SuccessAction) --- Ted Husted [EMAIL PROTECTED] wrote: David Graham wrote: What I think we're seeing here is that we've outgrown our ActionForward declarations and need some new ones. I'm fine with adding a SuccessAction but would really like to see us discuss future possibilities in this area. This may not be what you meant, but I've been thinking that ActionForward could use a class extension point, same as ActionMapping. The idea would be to give ActionForward a type property for a Java class. If the property is specified, instead of just taking the path as it stands, the Controller would call a prepare method on the class, passing it the ActionForward, ActionForm, HttpRequest, and HttpResponse. This may be a good time to add an ActionContext interface instead of passing all these individual pieces. This would also slightly remove the dependence on Servlet to allow us more flexibility when we look at the Portlet API. The prepare method would return a String that the Controller would use for the path. This allows the ActionForward to act as a Page Controller for the path. If the particular page referenced by the path needs any special chrome the Page Controller can set that up. Or, if the path needs to be adjusted for Locale or device (PDA, browser, et al), then the Page Controller could adjust the path before returning it. If it were a virtual page, like an dynamic image, merge file, or PDF, the Page class could also render the Response, rather than have the Action do it. Right now, the Action is doing double duty. It first acts as a Dispatcher that acquires business resources and selects the logical view. But, in real life, many pages often need special runtime resources of their own. So, the Action also serves as a Page Controller for the page it selects. Many of us consider that a mixing of concerns, and so we start to use some Actions as Dispatchers and others as Page Controllers. Tiles also fills this gap and is essentially a hybrid of a Compositive View and a Page Controller framework. I'm thinking that, architecturally, the ActionForward represents some resource available to the application, of any type, that can be reached by the application's protocol. In an http environment, it's the job of a Resource object to provide a URI that the Controller can use the reach the actual resource. (And, in another environment, perhaps the path would not be a URI.) The Action, in its purest form, represents a Dispatcher. It's the job of a Dispatcher to select which (logical) Resource will handle the response. When we talk about selecting between success, failure, or glockenspiel, we're talking about dispatching. But, in real life, we often can't just dispatch to a page. The page needs certain resources to render, often to fill UI controls like select lists. Ideally, I believe another class, specified by the ActionForward, should be responsible for setting up any chrome a particular page may need. It's the one that knows where the page is (via the path property), and so it's the one that should be privy to these details. What would start to happen here, I think, is that people will put into the new class the code that now encourages them to chain some Actions. By providing a separation of concern between choosing the Resource and preparing the context for the Resource, it becomes easier for people to Do The Right Thing. I've had similar composition problems and agree that a separation makes sense. Tiles Controllers can be used to setup page data but that doesn't always work (especially if you're not using Tiles :-) so I end up chaining actions. None of the action chaining is due to bus. logic as that's properly factored into a Service layer; it has to do purely with setting up page data. Tiles Controllers are one of the major reasons I use Tiles and I think it's appropriate to move that concept into the Struts core. David The gotcha is that, to do its job, the ActionForward type may also need to interact with the business layer. It doesn't seem right that the Page Controller should try to branch to another page, like an Action might, if there's an error. But the declarative exception handling might be able to step in here. -Ted. -- Ted Husted, Junit in Action - http://www.manning.com/massol/, Struts in Action - http://husted.com/struts/book.html, JSP Site Design
RE: ActionForwards, et al (was SuccessAction)
Ideally, I believe another class, specified by the ActionForward, should be responsible for setting up any chrome a particular page may need. It's the one that knows where the page is (via the path property), and so it's the one that should be privy to these details. Not sure if this comment belongs in the context of here, but I'll throw it out. We use Tiles and Tiles Controllers heavily, and one thing I dislike about forwarding to a TileDefinition is that I cannot then easily figure out which Action I'm forwarding to ( The path names a definition which is the same for each view in my case). I'm currently appending information via an extension to the ActionForward, this extra info is then used in my controller to prepare the appropriate data for that view. If there was some more transparent way to do this that would be good. I currently have one controller per definition, which may encompass several related views. What would start to happen here, I think, is that people will put into the new class the code that now encourages them to chain some Actions. By providing a separation of concern between choosing the Resource and preparing the context for the Resource, it becomes easier for people to Do The Right Thing. -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Monday, August 11, 2003 9:47 AM To: Struts Developers List Subject: Re: ActionForwards, et al (was SuccessAction) --- Ted Husted [EMAIL PROTECTED] wrote: David Graham wrote: What I think we're seeing here is that we've outgrown our ActionForward declarations and need some new ones. I'm fine with adding a SuccessAction but would really like to see us discuss future possibilities in this area. This may not be what you meant, but I've been thinking that ActionForward could use a class extension point, same as ActionMapping. The idea would be to give ActionForward a type property for a Java class. If the property is specified, instead of just taking the path as it stands, the Controller would call a prepare method on the class, passing it the ActionForward, ActionForm, HttpRequest, and HttpResponse. This may be a good time to add an ActionContext interface instead of passing all these individual pieces. This would also slightly remove the dependence on Servlet to allow us more flexibility when we look at the Portlet API. The prepare method would return a String that the Controller would use for the path. This allows the ActionForward to act as a Page Controller for the path. If the particular page referenced by the path needs any special chrome the Page Controller can set that up. Or, if the path needs to be adjusted for Locale or device (PDA, browser, et al), then the Page Controller could adjust the path before returning it. If it were a virtual page, like an dynamic image, merge file, or PDF, the Page class could also render the Response, rather than have the Action do it. Right now, the Action is doing double duty. It first acts as a Dispatcher that acquires business resources and selects the logical view. But, in real life, many pages often need special runtime resources of their own. So, the Action also serves as a Page Controller for the page it selects. Many of us consider that a mixing of concerns, and so we start to use some Actions as Dispatchers and others as Page Controllers. Tiles also fills this gap and is essentially a hybrid of a Compositive View and a Page Controller framework. I'm thinking that, architecturally, the ActionForward represents some resource available to the application, of any type, that can be reached by the application's protocol. In an http environment, it's the job of a Resource object to provide a URI that the Controller can use the reach the actual resource. (And, in another environment, perhaps the path would not be a URI.) The Action, in its purest form, represents a Dispatcher. It's the job of a Dispatcher to select which (logical) Resource will handle the response. When we talk about selecting between success, failure, or glockenspiel, we're talking about dispatching. But, in real life, we often can't just dispatch to a page. The page needs certain resources to render, often to fill UI controls like select lists. Ideally, I believe another class, specified by the ActionForward, should be responsible for setting up any chrome a particular page may need. It's the one that knows where the page is (via the path property), and so it's the one that should be privy to these details. What would start to happen here, I think, is that people will put into the new class the code that now encourages them to chain some Actions. By providing a separation of concern between choosing the Resource and preparing the context for the Resource, it becomes easier for people to Do The Right Thing. I've had similar composition problems and agree that a separation makes sense. Tiles Controllers can
