Re: [OS-webwork] Rethink
matt baldree wrote: Personally, I like these ideas. I think this design would lead people to cleaner solutions. I think it is time to make some decisions. I think Rickard should architect XWork. It would then be up to him to assign/delegate work on different modules, etc. I'm not convinced the current direction will lead to the best outcome. Rickard has established himself in past frameworks, application servers and his new portal product to earn the right to architect XWork. Besides, he mainly wrote WW. I may be wrong, but I don't remember an e-mail asking if he wanted to architect XWork or what role he wanted to play. I think this is a mistake. I think we should at least offer him the opportunity to architect XWork. I think his ideas have solidified and he is ready to right some code :). So, any dissenters? I'm not interested in getting XWork out the door quickly but when it does come out, I want it to be GREAT. No dissenters then? :-) I must admit that at first I was reluctant to the idea, since I already have so many irons in the fire, with the portal product and AOP framework coming along. However, since XWork could borrow so much from the AOP stuff, it's really not that much work, at least for the core (or so it seems). We (my company) are also greatly dependent on XWork being as good as it can be, so that's a huge motivational factor here. I would hence gladly take on this role, at least when it comes to shaping the core of it. Once the dust settles somewhat, and there will be a lot of dust initially, I think there will be great opportunities for others to do major contributions to it, especially when it comes to creating standard interceptors that can be shipped with the framework. Alternative dispatchers is also a very important part. So, if everyone is ok with me as (initially) main architect, I'll get to it. /Rickard --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
[OS-webwork] Action configuration XML
I'm fiddling with the action configuration XML, and here's what I have currently. xwork package name=standard prefixes=com.opensymphony.xwork interceptor name=parameter class=action.interceptor.ParameterInterceptor/ interceptors name=default interceptor-ref name=parameter/ /interceptors result name=error view=error.jsp/ /package package name=examples depends=standard prefixes=com.opensymphony.xwork.action result name=error view=exampleerror.jsp/ action name=foo class=SimpleAction interceptors-ref name=default/ result name=success view=bar.action/ /action action name=Bar class=SimpleAction interceptors-ref name=default/ result name=success view=success.jsp/ /action /package package name=examples2 depends=standard prefixes=com.opensymphony.xwork.action action name=foo class=SimpleAction interceptors-ref name=default/ result name=success view=bar.action/ /action action name=Bar class=SimpleAction interceptors-ref name=default/ result name=success view=success.jsp/ /action /package /xwork -- There are a couple of core ideas here. The first is the introduction of packages. This allows a single XML file to be built up of many individually developed packages. Typically one would use XML entities to refer to them, so the base XML file would typically look like this: xwork standard; examples; examples2; /xwork where those entities refer to the individual package files. It might even be a good idea to use a default entity resolver which understands .xml suffixes so one doesn't have to declare those entities: xwork standard.xml; examples.xml; examples2.xml; /xwork and here it would also be possible to add a standard entity resolver that understands properties files: xwork standard.xml; examples.xml; examples2.properties; /xwork so that simple packages can be defined using the old format. By using XML entities one can easily put several independent packages together into one coherent application. The next highlight is the notion of package specific prefixes. Pretty obvious what they're for I hope. Next up is the depends attribute, which is used to declare what packages it builds on, and this is mainly in order to do interceptor referencing. There will usually be a standard package with common interceptors and interceptor stacks (as shown above), and these can then be referenced easily, and application-specific interceptors can be introduced in ones own package. One can even override stacks and interceptors this way: package name=examples depends=standard prefixes=com.opensymphony.xwork.action interceptor name=mystuff class=MyInterceptor/ interceptors name=default interceptor-ref name=mystuff/ interceptors-ref name=default/ /interceptors action name=foo class=SimpleAction interceptors-ref name=default/ result name=success view=bar.action/ /action /package --- The above would override the default interceptor stack from the inherited package. We then come to the definition of a single action: action name=foo class=SimpleAction interceptors-ref name=default/ result name=success view=bar.action/ /action --- The big new thing is the reference to interceptors. Here one typically does two things: refer to a standard stack of interceptors, and then add action-specific interceptors that typically only apply to that single action. This can replace action chaining to a large extent I think. The result declaration is fairly simple, and is just a mapping from the string to the resulting view. .action is used to trigger chaining, to the extent that it's still needed. Default mappings can be declared at the package level (see error declarations above), and also follow the package dependency in order to allow overrides. The main idea with packages is hence to both allow for generic behaviour to be easily utilized, as well as allowing it to be overriden where necessary, while maintaining a fairly strict semantics. Or that's the idea anyway :-) When it comes to action referencing I haven't made up my mind yet what is best, but I think it's necessary to use the package name as prefix, unless an action references another action in the same package. E.g. if the foo action in examples wants to chain to bar in examples2 it would use the name examples2.bar instead of just bar. What is missing from this example currently is commands. Any ideas are welcome here. One option is to have the action declaration look like this: action name=fooDefault class=SimpleAction.doDefault interceptors-ref name=default/ result name=success view=bar.action/ /action i.e. suffix the class name with the method name. This means that any public method with a string result (or even void, which would default the result to SUCCESS) can be
Re: [OS-webwork] Rethink
Currently, there's no way to keep people from executing your actions without creating a separate J2EE declarative security entry for each action (and each alias, etc). This is, IMHO, a HUGE drawback. ...or just a servlet filter. Anders Hovmöller [EMAIL PROTECTED] http://boxed.killingar.net --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
[OS-webwork] ActionTag
If there is an exception during GenericDispatcher.executeAction() the ActionTag simply silently prints a stack trace and gets on with its business. This is not at all a good idea, since in doEndTag() GenericDispatcher.finish() is called without a try-catch block. This has the consequence that if the action isn't found it doesn't silently ignore this (as one would expect, given the try catch around executeAction()) but throws a NPE at doEndTag(). I personally would have preffered it if it blew up with an error message saying it couldn't find the action, do people have objections to this? Anders Hovmöller [EMAIL PROTECTED] http://boxed.killingar.net --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Rethink
Yep - +1 from me, but I think Patrick should also have a major role in contributing, he has done a lot of the initial Xwork thinking and I think his knowledge of OGNL etc would be valuable. -mike On 2/1/03 9:06 PM, Rickard Öberg ([EMAIL PROTECTED]) penned the words: matt baldree wrote: Personally, I like these ideas. I think this design would lead people to cleaner solutions. I think it is time to make some decisions. I think Rickard should architect XWork. It would then be up to him to assign/delegate work on different modules, etc. I'm not convinced the current direction will lead to the best outcome. Rickard has established himself in past frameworks, application servers and his new portal product to earn the right to architect XWork. Besides, he mainly wrote WW. I may be wrong, but I don't remember an e-mail asking if he wanted to architect XWork or what role he wanted to play. I think this is a mistake. I think we should at least offer him the opportunity to architect XWork. I think his ideas have solidified and he is ready to right some code :). So, any dissenters? I'm not interested in getting XWork out the door quickly but when it does come out, I want it to be GREAT. No dissenters then? :-) I must admit that at first I was reluctant to the idea, since I already have so many irons in the fire, with the portal product and AOP framework coming along. However, since XWork could borrow so much from the AOP stuff, it's really not that much work, at least for the core (or so it seems). We (my company) are also greatly dependent on XWork being as good as it can be, so that's a huge motivational factor here. I would hence gladly take on this role, at least when it comes to shaping the core of it. Once the dust settles somewhat, and there will be a lot of dust initially, I think there will be great opportunities for others to do major contributions to it, especially when it comes to creating standard interceptors that can be shipped with the framework. Alternative dispatchers is also a very important part. So, if everyone is ok with me as (initially) main architect, I'll get to it. /Rickard --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Action configuration XML
Copmments: - interceptor-ref name= is ugly XML! Why not just interceptor ref= / ? It's obvious that the name= attribute refers to the name of an interceptor from the tag name - is there a global package? - how are parameterised actions handled? (one of the other main xwork goals?) Looks good otherwise. -mike On 2/1/03 10:18 PM, Rickard Öberg ([EMAIL PROTECTED]) penned the words: I'm fiddling with the action configuration XML, and here's what I have currently. xwork package name=standard prefixes=com.opensymphony.xwork interceptor name=parameter class=action.interceptor.ParameterInterceptor/ interceptors name=default interceptor-ref name=parameter/ /interceptors result name=error view=error.jsp/ /package package name=examples depends=standard prefixes=com.opensymphony.xwork.action result name=error view=exampleerror.jsp/ action name=foo class=SimpleAction interceptors-ref name=default/ result name=success view=bar.action/ /action action name=Bar class=SimpleAction interceptors-ref name=default/ result name=success view=success.jsp/ /action /package package name=examples2 depends=standard prefixes=com.opensymphony.xwork.action action name=foo class=SimpleAction interceptors-ref name=default/ result name=success view=bar.action/ /action action name=Bar class=SimpleAction interceptors-ref name=default/ result name=success view=success.jsp/ /action /package /xwork -- There are a couple of core ideas here. The first is the introduction of packages. This allows a single XML file to be built up of many individually developed packages. Typically one would use XML entities to refer to them, so the base XML file would typically look like this: xwork standard; examples; examples2; /xwork where those entities refer to the individual package files. It might even be a good idea to use a default entity resolver which understands .xml suffixes so one doesn't have to declare those entities: xwork standard.xml; examples.xml; examples2.xml; /xwork and here it would also be possible to add a standard entity resolver that understands properties files: xwork standard.xml; examples.xml; examples2.properties; /xwork so that simple packages can be defined using the old format. By using XML entities one can easily put several independent packages together into one coherent application. The next highlight is the notion of package specific prefixes. Pretty obvious what they're for I hope. Next up is the depends attribute, which is used to declare what packages it builds on, and this is mainly in order to do interceptor referencing. There will usually be a standard package with common interceptors and interceptor stacks (as shown above), and these can then be referenced easily, and application-specific interceptors can be introduced in ones own package. One can even override stacks and interceptors this way: package name=examples depends=standard prefixes=com.opensymphony.xwork.action interceptor name=mystuff class=MyInterceptor/ interceptors name=default interceptor-ref name=mystuff/ interceptors-ref name=default/ /interceptors action name=foo class=SimpleAction interceptors-ref name=default/ result name=success view=bar.action/ /action /package --- The above would override the default interceptor stack from the inherited package. We then come to the definition of a single action: action name=foo class=SimpleAction interceptors-ref name=default/ result name=success view=bar.action/ /action --- The big new thing is the reference to interceptors. Here one typically does two things: refer to a standard stack of interceptors, and then add action-specific interceptors that typically only apply to that single action. This can replace action chaining to a large extent I think. The result declaration is fairly simple, and is just a mapping from the string to the resulting view. .action is used to trigger chaining, to the extent that it's still needed. Default mappings can be declared at the package level (see error declarations above), and also follow the package dependency in order to allow overrides. The main idea with packages is hence to both allow for generic behaviour to be easily utilized, as well as allowing it to be overriden where necessary, while maintaining a fairly strict semantics. Or that's the idea anyway :-) When it comes to action referencing I haven't made up my mind yet what is best, but I think it's necessary to use the package name as prefix, unless an action references another action in the same package. E.g. if the foo action in examples wants to chain to bar in examples2 it would use the name examples2.bar instead of just bar. What is missing from
Re: [OS-webwork] Action configuration XML
Mike Cannon-Brookes wrote: Copmments: - interceptor-ref name= is ugly XML! Why not just interceptor ref= / ? It's obvious that the name= attribute refers to the name of an interceptor from the tag name Because you'd then mix referring to an interceptor and defining one. Take a look again. If you can think of a better name I'm all for it, but there do need to be two. - is there a global package? No, that's why there's the depends thing, which usually includes standard which in a sense is the global package. - how are parameterised actions handled? (one of the other main xwork goals?) I didn't know that was a goal. The implementation that is currently in CVS sets these parameters on each request, which is a lot of reflection. It seemed too heavy to me. Isn't it better to have configuration be handled in a traditional way? (i.e. by calling some config API) Remember that actions are going to be instantiated ALL THE TIME. Using the Preferences API might be an option here. /Rickard --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Rethink
Agree. I think there is obvious areas certain people can help. -Matt - Original Message - From: Mike Cannon-Brookes [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Sent: Thursday, January 02, 2003 7:30 AM Subject: Re: [OS-webwork] Rethink Yep - +1 from me, but I think Patrick should also have a major role in contributing, he has done a lot of the initial Xwork thinking and I think his knowledge of OGNL etc would be valuable. -mike On 2/1/03 9:06 PM, Rickard Öberg ([EMAIL PROTECTED]) penned the words: matt baldree wrote: Personally, I like these ideas. I think this design would lead people to cleaner solutions. I think it is time to make some decisions. I think Rickard should architect XWork. It would then be up to him to assign/delegate work on different modules, etc. I'm not convinced the current direction will lead to the best outcome. Rickard has established himself in past frameworks, application servers and his new portal product to earn the right to architect XWork. Besides, he mainly wrote WW. I may be wrong, but I don't remember an e-mail asking if he wanted to architect XWork or what role he wanted to play. I think this is a mistake. I think we should at least offer him the opportunity to architect XWork. I think his ideas have solidified and he is ready to right some code :). So, any dissenters? I'm not interested in getting XWork out the door quickly but when it does come out, I want it to be GREAT. No dissenters then? :-) I must admit that at first I was reluctant to the idea, since I already have so many irons in the fire, with the portal product and AOP framework coming along. However, since XWork could borrow so much from the AOP stuff, it's really not that much work, at least for the core (or so it seems). We (my company) are also greatly dependent on XWork being as good as it can be, so that's a huge motivational factor here. I would hence gladly take on this role, at least when it comes to shaping the core of it. Once the dust settles somewhat, and there will be a lot of dust initially, I think there will be great opportunities for others to do major contributions to it, especially when it comes to creating standard interceptors that can be shipped with the framework. Alternative dispatchers is also a very important part. So, if everyone is ok with me as (initially) main architect, I'll get to it. /Rickard --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
[OS-webwork] Components
If the action invocation as described in the previous post is used, then an interesting possibility to do components arise. Basically, if one wants to do HMVC type pages (where a page consists of many smaller portlets) then it's useful to have a card layout of sorts, which can switch what to do and display depending on some parameter. In WW we had a CardPane action which handled this. Here we can do something similar, but a little more interesting with the following config XML: action name=mycomponent class=Component interceptors-ref name=default/ result name=success view=mycomponent.component/ result name=pane1 view=pane1.jsp/ result name=pane2 view=pane2.jsp/ result name=pane3 view=pane3.jsp/ /action So if you include mycomponent.component in a JSP page the filter will be triggered and the Component action is executed. Now, of course there's no such view, but execute() will never return SUCCESS anyway, so that doesn't matter. Instead it will return pane1/2/3 depending on some parameter (mycomponent=pane1 for example). Could work. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Action configuration XML
Great, I like this interceptor stuff, looks cool. Have a couple of doubt though: 1. Can the interceptor affect the view mapping in anyway ? 2. How about providing different view base on client device. For e.g, providing different view for html, xml, wml, xul, etc. 3. Can a package depends on more than one package ? 4. I don't really understand why the interceptor stack ( the interceptors tag ) is nested inside the package tag. It seems like the idea is we can construct an interceptor stack from multiple package. 5. May be there should be a packages tag so that we can package multiple dependent package together. 6. It seems like there could be many place that we can have name collision issue. Not sure whether this is a major issue, may be we need some namespace mechanism here. 7. Would like to see some sort of mechanism to pass some initialization parameter to the action. ( like the init param thing in servlet configuration ) 8. Is there anything in the config that would define the scope of the interceptor ( for e.g, pre/post action execution, pre/post entire action chain execution, etc ) ? Btw, just curious if u already using an AOP framework, wouldn't all this webwork-interceptor stuff redundant for u ? Regards, Low --- Rickard Öberg [EMAIL PROTECTED] wrote: I'm fiddling with the action configuration XML, and here's what I have currently. xwork package name=standard prefixes=com.opensymphony.xwork interceptor name=parameter class=action.interceptor.ParameterInterceptor/ interceptors name=default interceptor-ref name=parameter/ /interceptors result name=error view=error.jsp/ /package package name=examples depends=standard prefixes=com.opensymphony.xwork.action result name=error view=exampleerror.jsp/ action name=foo class=SimpleAction interceptors-ref name=default/ result name=success view=bar.action/ /action action name=Bar class=SimpleAction interceptors-ref name=default/ result name=success view=success.jsp/ /action /package package name=examples2 depends=standard prefixes=com.opensymphony.xwork.action action name=foo class=SimpleAction interceptors-ref name=default/ result name=success view=bar.action/ /action action name=Bar class=SimpleAction interceptors-ref name=default/ result name=success view=success.jsp/ /action /package /xwork -- There are a couple of core ideas here. The first is the introduction of packages. This allows a single XML file to be built up of many individually developed packages. Typically one would use XML entities to refer to them, so the base XML file would typically look like this: xwork standard; examples; examples2; /xwork where those entities refer to the individual package files. It might even be a good idea to use a default entity resolver which understands .xml suffixes so one doesn't have to declare those entities: xwork standard.xml; examples.xml; examples2.xml; /xwork and here it would also be possible to add a standard entity resolver that understands properties files: xwork standard.xml; examples.xml; examples2.properties; /xwork so that simple packages can be defined using the old format. By using XML entities one can easily put several independent packages together into one coherent application. The next highlight is the notion of package specific prefixes. Pretty obvious what they're for I hope. Next up is the depends attribute, which is used to declare what packages it builds on, and this is mainly in order to do interceptor referencing. There will usually be a standard package with common interceptors and interceptor stacks (as shown above), and these can then be referenced easily, and application-specific interceptors can be introduced in ones own package. One can even override stacks and interceptors this way: package name=examples depends=standard prefixes=com.opensymphony.xwork.action interceptor name=mystuff class=MyInterceptor/ interceptors name=default interceptor-ref name=mystuff/ interceptors-ref name=default/ /interceptors action name=foo class=SimpleAction interceptors-ref name=default/ result name=success view=bar.action/ /action /package --- The above would override the default interceptor stack from the inherited package. We then come to the definition of a single action: action name=foo class=SimpleAction interceptors-ref name=default/ result name=success view=bar.action/ /action --- The big new thing is the reference to interceptors. Here one typically does two things: refer to a standard stack of interceptors, and then add action-specific interceptors that typically only
RE: [OS-webwork] Rethink
-Original Message- From: Rickard Öberg [mailto:[EMAIL PROTECTED]] Here are some that I can think of: * Try to avoid .action URL's * Allow for multiple read-actions to be on the same page (HMVC) * Allow for multiple forms to be on the same page, and be developed independently (the portal case). This essentially means that parameters need to be prefixed so that they don't clash. * Allow write-actions to be performed before a page starts rendering, but then make the result of that action available DURING rendering. * Minimize coupling to servlet environment. XWork will probably still be a framework that is used mostly for web stuff, but it must be possible to use it in a non-servlet environment too. Having multiple dispatchers from the start is a great way to ensure this. * Allow sharing of view code between different views * Make it trivial to implement Portlets (JSR 168) using XWork. This is a personal pet peeve, but I think you'll love it once the Portlet API solidifies later this year. It's a great thing I think. /Rickard Some of the lifecycle and multi-component stuff here sounds a lot like Java Server Faces. I just finished reading the two articles on JSF at onJava.com: http://www.javaworld.com/javaworld/jw-11-2002/jw-1129-jsf.html http://www.javaworld.com/javaworld/jw-12-2002/jw-1227-jsf2.html I must say, I'm underwhelmed in a lot of areas, especially with how much processing has to be done for every request and the heavy dependency on JSP and the web, but the potential for real tool support is very appealing. What are people's thoughts on supporting JSF with Webwork, perhaps with a different Dispatcher? --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Rethink
-Original Message- From: Rickard Öberg [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 02, 2003 5:37 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Rethink Patrick Lightbody wrote: Great! So we can expect a finished product by Friday? :) Friday? *yawn* :-) Glad to have you on board with this. Of course, I'll be around to help in any way possible -- just gimme a holler. Will do. I'm afraid I'm gonna thrash around in the current sandbox code quite a lot. One thing though: I desperately need to know if chaining needs to be possible given the concept of interceptors. I want to see if there are easier ways to deal with the usecases where chaining is used currently. Yes, For our needs, chaining is very very helpful. More on this below... Also, I want to establish some design goals. IMHO the end result will be better with more strict requirements. Here are some that I can think of: * Try to avoid .action URL's * Allow for multiple read-actions to be on the same page (HMVC) * Allow for multiple forms to be on the same page, and be developed independently (the portal case). This essentially means that parameters need to be prefixed so that they don't clash. * Allow write-actions to be performed before a page starts rendering, but then make the result of that action available DURING rendering. * Minimize coupling to servlet environment. XWork will probably still be a framework that is used mostly for web stuff, but it must be possible to use it in a non-servlet environment too. Having multiple dispatchers from the start is a great way to ensure this. * Allow sharing of view code between different views * Make it trivial to implement Portlets (JSR 168) using XWork. This is a personal pet peeve, but I think you'll love it once the Portlet API solidifies later this year. It's a great thing I think. /Rickard Some goals I would hope for: * declarative security friendly URLs and the ability to protect your actions from being called. * multiple configuration files, to improve multi-user version control concurrency - In the current (proprietary) framework we use, this is done by having one main configuration file which maps certain paths to certain config files. These sub config files define the request handlers (like actions) and response handlers (like views). The nice thing about this is the way chaining is handled. Below a certain path, which is mapped to a sub-config file, every path segment is treated as a reference to a handler. So, for instance, if we have a sub-section with a separate config file mapped to /foo, this url: /foo/handler1/handler2/handler3 Would look up and invoke handler1, then handler2, then handler3 in that order, and return the response handler (view) associated with the final request handler (action), unless an error is encountered. This allows for very fine grained reusable application pieces, which can be put together dynamically by creating a URL. Unfortunately, the current framework doesn't have the concept of the value stack, and does everything by binding beans into the request. Handlers don't have properties like Actions, but are more stateless and just use the request parameters directly. Jason --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Rethink
Jason Carreira wrote: Some goals I would hope for: * declarative security friendly URLs and the ability to protect your actions from being called. See the Action invocation post. .action URL's should go away with that. * multiple configuration files, to improve multi-user version control concurrency See the Action configuration XML, and particularly the package idea. With XML entities you're there. - In the current (proprietary) framework we use, this is done by having one main configuration file which maps certain paths to certain config files. These sub config files define the request handlers (like actions) and response handlers (like views). The nice thing about this is the way chaining is handled. Below a certain path, which is mapped to a sub-config file, every path segment is treated as a reference to a handler. So, for instance, if we have a sub-section with a separate config file mapped to /foo, this url: /foo/handler1/handler2/handler3 Would look up and invoke handler1, then handler2, then handler3 in that order, and return the response handler (view) associated with the final request handler (action), unless an error is encountered. Which is bad because you're displaying the guts of your application to the user. URL's of that kind will likely be shortlived. No good. This allows for very fine grained reusable application pieces, which can be put together dynamically by creating a URL. You'll get the same with actions calling actions (easy with the new API) and action interceptors. Except it's all under the covers. Unfortunately, the current framework doesn't have the concept of the value stack, and does everything by binding beans into the request. Handlers don't have properties like Actions, but are more stateless and just use the request parameters directly. Ok, I see. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Action invocation
This sounds scary to me -- I'm not entirely convinced that URLs with .action in them are terribly bad. I do have cases where 4 different actions use that same SUCCESS view: ShowDocumentListA.success = doc_list.jsp ShowDocumentListB.success = doc_list.jsp ShowDocumentListC.success = doc_list.jsp -Pat - Original Message - From: Rickard Öberg [EMAIL PROTECTED] To: WebWork [EMAIL PROTECTED] Sent: Thursday, January 02, 2003 5:38 AM Subject: [OS-webwork] Action invocation I'm currently looking at how actions in a web setting are to be invoked in XWork. I've seen two main ways in which actions are used: for read-only stuff, such as getting model data and then rendering it, and for write actions that respond to a form submit. I'll deal with these cases one at a time. The descriptions cover the JSP case, but the same ideas can be applied to any view technology. First, I've argued that the read-only case is best done by referencing the success page itself, and have it contain an action tag, so that the URL itself is nice and clean. This works, but it's a bit of a kludge, and it's difficult to handle the error case, i.e. when the read-only action fails and an error page should be shown. Here's an alternative implementation. First of all, use a servlet filter which intercepts .jsp requests. When a request for that page is intercepted simply check if an action has a result view declaration with that page as SUCCESS. If so, then execute it. If SUCCESS is the result, then simply continue the rendering. If ERROR is the result, then instead do an include of the error page. This will automatically ensure that read-only actions are only executed for the specific page, so you can use declarative security for it. The main drawback with this approach is that a page can only have one action, but I'm not sure how common it is to have one page with many different actions providing data for it anyway. Second, write-actions that are executed as a result of a form submission are executed through basically the same mechanism. E.g. form.jsp may contain this: form action=xw:url page=results.jsp/ ... /form -- When the form is submitted the action will executed first, just as the read-only case, and if SUCCESS is the result then results.jsp is rendered. If any other case, then that is included instead. Such as INPUT=form.jsp, which will render the above form again. I'm not exactly sure how the doDefault thing will be handled yet, but it shouldn't be that much of a problem. Another common case is to have a single button point to a write-action which after execution redirects back to the same page (e.g. delete this entry). I'm not quite sure how to handle this either. The goal is to avoid having .action URL's at all, in order to keep URL's bookmark friendly and to avoid security issues. Those are my thoughts on this so far. Any thoughts/comments? Does it seem like a good direction? /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Rethink
Rickard, I don't know if interceptors will cover chaining needs entirely, but why not just start hacking away in the sandbox and we'll go from there. -Pat - Original Message - From: Rickard Öberg [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 02, 2003 2:36 AM Subject: Re: [OS-webwork] Rethink Patrick Lightbody wrote: Great! So we can expect a finished product by Friday? :) Friday? *yawn* :-) Glad to have you on board with this. Of course, I'll be around to help in any way possible -- just gimme a holler. Will do. I'm afraid I'm gonna thrash around in the current sandbox code quite a lot. One thing though: I desperately need to know if chaining needs to be possible given the concept of interceptors. I want to see if there are easier ways to deal with the usecases where chaining is used currently. Also, I want to establish some design goals. IMHO the end result will be better with more strict requirements. Here are some that I can think of: * Try to avoid .action URL's * Allow for multiple read-actions to be on the same page (HMVC) * Allow for multiple forms to be on the same page, and be developed independently (the portal case). This essentially means that parameters need to be prefixed so that they don't clash. * Allow write-actions to be performed before a page starts rendering, but then make the result of that action available DURING rendering. * Minimize coupling to servlet environment. XWork will probably still be a framework that is used mostly for web stuff, but it must be possible to use it in a non-servlet environment too. Having multiple dispatchers from the start is a great way to ensure this. * Allow sharing of view code between different views * Make it trivial to implement Portlets (JSR 168) using XWork. This is a personal pet peeve, but I think you'll love it once the Portlet API solidifies later this year. It's a great thing I think. /Rickard --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Action configuration XML [Commands]
Couldn't the Method objects found the first time through reflection for parameterizing the Action instances be cached and reused, making the reflection performance hit negligible? I've never profiled reflection to see where the biggest performance hit is, but if it's the Class and Method lookup, this could help (and be used for the Action field population, as well) -Original Message- From: Patrick Lightbody [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 02, 2003 11:59 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Action configuration XML [Commands] What is missing from this example currently is commands. Any ideas are welcome here. One option is to have the action declaration look like this: action name=fooDefault class=SimpleAction.doDefault interceptors-ref name=default/ result name=success view=bar.action/ /action i.e. suffix the class name with the method name. This means that any public method with a string result (or even void, which would default the result to SUCCESS) can be invoked. Any comments on this? I think that the ability to have parameters applied before the action is initialized is a feature needed, even if it could be slow. For the most part there will be zero params, so the slowdown isn't an issue. Commands, in my opinion, should not be part of the configuration if they aren't part of the core framework -- meaning that since ActionSupport deals with commands but Action is the only core part of the framework, commands don't deserve special treament. That was where I got the idea for having parameters that would be applied before the Action is executed. So with that said, I think commands should be configured like so: action name=fooDefault class=SimpleActiont interceptors-ref name=default/ result name=success view=bar.action/ params param name=commanddefault/param /params /action The end result is the same (since commands needed reflection anyway). The only difference is that there is an option for even more flexability, but no one has to use it if they are worried about reflection (though since every single HTTP request parameter is also reflected, I see no big problem by adding this as well). -Pat --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Action configuration XML [Commands]
What is missing from this example currently is commands. Any ideas are welcome here. One option is to have the action declaration look like this: action name=fooDefault class=SimpleAction.doDefault interceptors-ref name=default/ result name=success view=bar.action/ /action i.e. suffix the class name with the method name. This means that any public method with a string result (or even void, which would default the result to SUCCESS) can be invoked. Any comments on this? I think that the ability to have parameters applied before the action is initialized is a feature needed, even if it could be slow. For the most part there will be zero params, so the slowdown isn't an issue. Commands, in my opinion, should not be part of the configuration if they aren't part of the core framework -- meaning that since ActionSupport deals with commands but Action is the only core part of the framework, commands don't deserve special treament. That was where I got the idea for having parameters that would be applied before the Action is executed. So with that said, I think commands should be configured like so: action name=fooDefault class=SimpleActiont interceptors-ref name=default/ result name=success view=bar.action/ params param name=commanddefault/param /params /action The end result is the same (since commands needed reflection anyway). The only difference is that there is an option for even more flexability, but no one has to use it if they are worried about reflection (though since every single HTTP request parameter is also reflected, I see no big problem by adding this as well). -Pat --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Action invocation
Patrick Lightbody wrote: This sounds scary to me -- I'm not entirely convinced that URLs with .action in them are terribly bad. I do have cases where 4 different actions use that same SUCCESS view: ShowDocumentListA.success = doc_list.jsp ShowDocumentListB.success = doc_list.jsp ShowDocumentListC.success = doc_list.jsp hm.. but that sounds like a ShowDocumentList?x=A/B/C to me. I.e. why do you have three actions for it? /Rickard --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Action configuration XML [Commands]
See, I just think it's invaluable for action re-use to be able to lock down certain parameters for various aliases, even if the action classs is the same. For example: In my document/workflow management system, we have various businessgroups that can create documents. Ideally, there could be a FooCreateDocument and BarCreateDocument action aliasing, both maping to com.cisco.CreateDocument. The only different would be that each alias would have a different value for the businessGroup parameter (one has Foo, one has Bar). Yes, this could be done with CreateDocument.action?businessGroup=Foo, but then the burdon is on the HTML/JSP writers and not the application designer. -Pat - Original Message - From: Rickard Öberg [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 02, 2003 9:41 AM Subject: Re: [OS-webwork] Action configuration XML [Commands] Patrick Lightbody wrote: I think that the ability to have parameters applied before the action is initialized is a feature needed, even if it could be slow. For the most part there will be zero params, so the slowdown isn't an issue. But it's a dangerous option, since it may not be apparent that this slowdown will occur. If possible, configuration of actions should not occur this way. Commands, in my opinion, should not be part of the configuration if they aren't part of the core framework -- meaning that since ActionSupport deals with commands but Action is the only core part of the framework, commands don't deserve special treament. Well, I wanted to see if commands maybe could be put in as a core concept. That was where I got the idea for having parameters that would be applied before the Action is executed. So with that said, I think commands should be configured like so: action name=fooDefault class=SimpleActiont interceptors-ref name=default/ result name=success view=bar.action/ params param name=commanddefault/param /params /action The end result is the same (since commands needed reflection anyway). No, you now have two reflective calls: the parameter and the execution. If this is the only reason to use parameters, the case is a bit weak. The only difference is that there is an option for even more flexability, but no one has to use it if they are worried about reflection (though since every single HTTP request parameter is also reflected, I see no big problem by adding this as well). I think having an option which will lead to foot-shooting is a bad idea. And I don't think documentation is a solution for that either. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Action invocation
On Thu, Jan 02, 2003 at 06:37:03PM +0100, Rickard Öberg wrote: Patrick Lightbody wrote: This sounds scary to me -- I'm not entirely convinced that URLs with .action in them are terribly bad. I do have cases where 4 different actions use that same SUCCESS view: ShowDocumentListA.success = doc_list.jsp ShowDocumentListB.success = doc_list.jsp ShowDocumentListC.success = doc_list.jsp hm.. but that sounds like a ShowDocumentList?x=A/B/C to me. I.e. why do you have three actions for it? I often come to having the same view for different actions. One case is debugging and because I use XSLT-Stylesheets as views, I often have some rather generic stylesheet that formats different actions. But I don't understand how this relates to why .action-URL are bad. -billy. -- Meisterbohne Söflinger Straße 100 Tel: +49-731-399 499-0 eLösungen 89077 Ulm Fax: +49-731-399 499-9 msg00943/pgp0.pgp Description: PGP signature
Re: [OS-webwork] Action invocation
Patrick Lightbody wrote: They have very, VERY different ways to retrieve the data. But yes, I suppose one could design differently. Ok. Damn. Removing .action invocations would have made things much simpler, especially for the declarative security users. /Rickard --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Action configuration XML [Commands]
boxed wrote: I think having an option which will lead to foot-shooting is a bad idea. And I don't think documentation is a solution for that either. Correct me if I'm wrong, but didn't pat just suggest that you should be able to set default parameters on actions in the config file. I don't see how this can be a foot-shooting idea at all, but I do see it simplifying development. I just wish taglib definitions had this feature... If you read the whole email you'd know why. Let me quote: But it's a dangerous option, since it may not be apparent that this slowdown will occur. If possible, configuration of actions should not occur this way. /Rickard --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Action invocation
Philipp Meier wrote: I often come to having the same view for different actions. One case is debugging and because I use XSLT-Stylesheets as views, I often have some rather generic stylesheet that formats different actions. But I don't understand how this relates to why .action-URL are bad. .action is bad because it 1) is an implementation detail 2) disallows the use of J2EE declarative security Both of which are contrary to the goals of XWork IMHO. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Action invocation
I don't understand why URLs need to have .action OR .jsp. In my mind, direct requests to resources is okay for static files, but all action-related requests should flow through the action mappings. *If* actions are always tied to a path (or paths), *and* there is a filter controller, then: a) Your URLs can be anything you want. b) You can use the same JSP as the view for multiple actions. I think in the latest design there is a View factory chain which produces a View class, just like for actions. A .jsp view should result in a JSP View class, which will just forward the request to a JSP page via a RequestDispatcher. In servlet 2.3 (and by default in 2.4), a forward this way will *not* go through the filter chain again. This de-facto prevents against public requests to your jsp view pages--they can only be run by the controller. -Chris --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Action configuration XML [Commands]
Jason Carreira wrote: Couldn't the Method objects found the first time through reflection for parameterizing the Action instances be cached and reused, making the reflection performance hit negligible? I've never profiled reflection to see where the biggest performance hit is, but if it's the Class and Method lookup, this could help (and be used for the Action field population, as well) The biggest hit is in lookup, absolutely. However, there's overhead for type conversion too. And if you compare it with a simple Conf.getValue() call the overhead is MUCH higher. /Rickard --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Action configuration XML [Commands]
On Thu, Jan 02, 2003 at 06:41:59PM +0100, Rickard Öberg wrote: Patrick Lightbody wrote: I think that the ability to have parameters applied before the action is initialized is a feature needed, even if it could be slow. For the most part there will be zero params, so the slowdown isn't an issue. But it's a dangerous option, since it may not be apparent that this slowdown will occur. If possible, configuration of actions should not occur this way. I think it is a very useful feature, and this is to me this is an obvious case premature optimization. I should mention that I'm a developer at cglib.sf.net, and one of the things on my TODO list is write a bcel-ified bean copier. Webwork would benefit greatly from this, since the configuration is (totally?) static, which means the same beans are copied over and over again. The end result is that the overhead of having action properties work bean-style would probably be negligible, and for sure faster than using the Preferences API in execute(). -Chris --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Action configuration XML [Commands]
So then how would the situation outlined below work then? I understand the deployment-settings vs. business login parameter issue, but where would those kinds of parameters be set? I don't think in the HTML URL would be a good idea. I like being able to make two different alias names that are similar (same class) but behave differently based on settings. -Pat - Original Message - From: Rickard Ã-berg [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 02, 2003 10:30 AM Subject: Re: [OS-webwork] Action configuration XML [Commands] Patrick Lightbody wrote: See, I just think it's invaluable for action re-use to be able to lock down certain parameters for various aliases, even if the action classs is the same. For example: In my document/workflow management system, we have various businessgroups that can create documents. Ideally, there could be a FooCreateDocument and BarCreateDocument action aliasing, both maping to com.cisco.CreateDocument. The only different would be that each alias would have a different value for the businessGroup parameter (one has Foo, one has Bar). Yes, this could be done with CreateDocument.action?businessGroup=Foo, but then the burdon is on the HTML/JSP writers and not the application designer. Hm.. but that doesn't sound like an application deployment setting (which action parameterizing would be). Sounds more like a business logic parameter to me. And if you really want to an action configuration like that, the Preferences API should do the trick. /Rickard --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
[OS-webwork] Re: Action invocation
Ok. Damn. Removing .action invocations would have made things much simpler, especially for the declarative security users. Remind me again why .action causes problems with declaritive security? Surely the real problem is that Webwork currently doesn't care if an arbitrary path is specified in the URL. ie: http://www.me.com/abc123/admin/deleteUser.action is treated the same as http://www.me.com/admin/deleteUser.action - which makes it very messy to nail down in web.xml. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Action configuration XML [Commands]
Patrick Lightbody wrote: So then how would the situation outlined below work then? I understand the deployment-settings vs. business login parameter issue, but where would those kinds of parameters be set? I don't think in the HTML URL would be a good idea. I like being able to make two different alias names that are similar (same class) but behave differently based on settings. Ok. Well, if the performance overhead is so negligble as some suggest, then maybe it's ok. Can't say I like it though, for mentioned reasons. Plus, iff it's put into an interceptor then people like me can remove it :-) /Rickard --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Re: Action invocation
Chris Miller wrote: Remind me again why .action causes problems with declaritive security? Surely the real problem is that Webwork currently doesn't care if an arbitrary path is specified in the URL. ie: http://www.me.com/abc123/admin/deleteUser.action is treated the same as http://www.me.com/admin/deleteUser.action - which makes it very messy to nail down in web.xml. That *is* the problem. And itt's not messy; it's impossible! No matter how you construct your web.xml I can circumvent it by doing an arbitrary path like so: http://www.me.com/jkldsdfglkjglkdhgdklhg/asdasdasd/deleteUser.action If .action invocations are not allowed then it's possible to use declarative security. Plus if execution of actions is only possible if a URL has been previously associated with it during form creation, then it's even safer. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Action invocation
Chris Nokleberg wrote: I don't understand why URLs need to have .action OR .jsp. In my mind, direct requests to resources is okay for static files, but all action-related requests should flow through the action mappings. The point is to try and avoid .action URL's for mentioned reasons. Since we can filter calls to .jsp it's certainly doable. *If* actions are always tied to a path (or paths), *and* there is a filter controller, then: a) Your URLs can be anything you want. b) You can use the same JSP as the view for multiple actions. Pretty much, yes. There's no real trouble with allowing .action invocations as before, but if it's possible to get them to go away it would be nice. I think in the latest design there is a View factory chain which produces a View class, just like for actions. A .jsp view should result in a JSP View class, which will just forward the request to a JSP page via a RequestDispatcher. I don't see any point in having a JSP View class as opposed to a generic include a servlet View class. In servlet 2.3 (and by default in 2.4), a forward this way will *not* go through the filter chain again. This de-facto prevents against public requests to your jsp view pages--they can only be run by the controller. But the security problem is not with pages really, but with actions. If the request is stopped at the View stage it's already too late: you may have executed code that the user was not allowed to execute. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Action configuration XML [Commands]
Bruce Ritchie wrote: The unfortunate part about using the preferences API is that it ties xw to jdk 1.4, which will mean that it excludes many many people from using it (us for example) since many of our customers have and will continue to run jdk 1.3 for some time. I would prefer an alternate system that doesn't tie us to jdk 1.4. I said that you *could* use the Preferences API. If you don't want to, then don't. We deploy our stuff on all platforms on 1.4, so for our needs it's ok. Then again, we probably wouldn't do action-specific configuration anyway, and *if* we did we'd use runtime attributes. But that's a whole other story. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Action invocation
Pretty much, yes. There's no real trouble with allowing .action invocations as before, but if it's possible to get them to go away it would be nice. I find having the actions available directly with the .action notation very handy for developing/debugging. I am hoping you mean possible to avoid them if you want. It sounds to me like you want to force users to not use the .action notation, when it can definetely be useful. Anders Hovmöller [EMAIL PROTECTED] http://boxed.killingar.net - Original Message - From: Rickard Öberg [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 02, 2003 20:00 Subject: Re: [OS-webwork] Action invocation Chris Nokleberg wrote: I don't understand why URLs need to have .action OR .jsp. In my mind, direct requests to resources is okay for static files, but all action-related requests should flow through the action mappings. The point is to try and avoid .action URL's for mentioned reasons. Since we can filter calls to .jsp it's certainly doable. *If* actions are always tied to a path (or paths), *and* there is a filter controller, then: a) Your URLs can be anything you want. b) You can use the same JSP as the view for multiple actions. Pretty much, yes. There's no real trouble with allowing .action invocations as before, but if it's possible to get them to go away it would be nice. I think in the latest design there is a View factory chain which produces a View class, just like for actions. A .jsp view should result in a JSP View class, which will just forward the request to a JSP page via a RequestDispatcher. I don't see any point in having a JSP View class as opposed to a generic include a servlet View class. In servlet 2.3 (and by default in 2.4), a forward this way will *not* go through the filter chain again. This de-facto prevents against public requests to your jsp view pages--they can only be run by the controller. But the security problem is not with pages really, but with actions. If the request is stopped at the View stage it's already too late: you may have executed code that the user was not allowed to execute. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Action invocation
Jason Carreira wrote: I'm thinking we could use your idea of packages, and map packages to certain paths, then you could easily secure by package. What if you have 10 actions in a package, and 3 are public, 4 are allowed by one role, and 6 are allowed by another (i.e. there's an overlap). How do you do that with secure by package? /Rickard --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Re: Action invocation
You can put a declarative security line for */deleteUser.action, can't you? Not to say that this is good, in fact it's horrible, but at least it COULD work. -Original Message- From: Rickard Öberg [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 02, 2003 2:05 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Re: Action invocation Chris Miller wrote: Remind me again why .action causes problems with declaritive security? Surely the real problem is that Webwork currently doesn't care if an arbitrary path is specified in the URL. ie: http://www.me.com/abc123/admin/deleteUser.action is treated the same as http://www.me.com/admin/deleteUser.action - which makes it very messy to nail down in web.xml. That *is* the problem. And itt's not messy; it's impossible! No matter how you construct your web.xml I can circumvent it by doing an arbitrary path like so: http://www.me.com/jkldsdfglkjglkdhgdklhg/asdas dasd/deleteUser.action If .action invocations are not allowed then it's possible to use declarative security. Plus if execution of actions is only possible if a URL has been previously associated with it during form creation, then it's even safer. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Action invocation
I believe Rickard has made it clear both will be available. - Original Message - From: boxed [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 02, 2003 11:15 AM Subject: Re: [OS-webwork] Action invocation Pretty much, yes. There's no real trouble with allowing .action invocations as before, but if it's possible to get them to go away it would be nice. I find having the actions available directly with the .action notation very handy for developing/debugging. I am hoping you mean possible to avoid them if you want. It sounds to me like you want to force users to not use the .action notation, when it can definetely be useful. Anders Hovmöller [EMAIL PROTECTED] http://boxed.killingar.net - Original Message - From: Rickard Öberg [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 02, 2003 20:00 Subject: Re: [OS-webwork] Action invocation Chris Nokleberg wrote: I don't understand why URLs need to have .action OR .jsp. In my mind, direct requests to resources is okay for static files, but all action-related requests should flow through the action mappings. The point is to try and avoid .action URL's for mentioned reasons. Since we can filter calls to .jsp it's certainly doable. *If* actions are always tied to a path (or paths), *and* there is a filter controller, then: a) Your URLs can be anything you want. b) You can use the same JSP as the view for multiple actions. Pretty much, yes. There's no real trouble with allowing .action invocations as before, but if it's possible to get them to go away it would be nice. I think in the latest design there is a View factory chain which produces a View class, just like for actions. A .jsp view should result in a JSP View class, which will just forward the request to a JSP page via a RequestDispatcher. I don't see any point in having a JSP View class as opposed to a generic include a servlet View class. In servlet 2.3 (and by default in 2.4), a forward this way will *not* go through the filter chain again. This de-facto prevents against public requests to your jsp view pages--they can only be run by the controller. But the security problem is not with pages really, but with actions. If the request is stopped at the View stage it's already too late: you may have executed code that the user was not allowed to execute. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Action invocation
On Thu, Jan 02, 2003 at 08:00:41PM +0100, Rickard Öberg wrote: Chris Nokleberg wrote: I don't understand why URLs need to have .action OR .jsp. In my mind, direct requests to resources is okay for static files, but all action-related requests should flow through the action mappings. The point is to try and avoid .action URL's for mentioned reasons. Since we can filter calls to .jsp it's certainly doable. But one of the reasons to get rid of .action is that it exposes the implementation. .jsp does the same thing! Why not allow for arbitrary URLs, even when you want to use JSP as your view technology? Then it can just become another templating language. Intercepting calls to .jsp pages is not very Model 2. Maybe Model 1.5. *If* actions are always tied to a path (or paths), *and* there is a filter controller, then: a) Your URLs can be anything you want. b) You can use the same JSP as the view for multiple actions. Pretty much, yes. There's no real trouble with allowing .action invocations as before, but if it's possible to get them to go away it would be nice. I think in the latest design there is a View factory chain which produces a View class, just like for actions. A .jsp view should result in a JSP View class, which will just forward the request to a JSP page via a RequestDispatcher. I don't see any point in having a JSP View class as opposed to a generic include a servlet View class. The problem is that you have to then allow requests directly to .jsp files. What happens when you want to switch to velocity? In servlet 2.3 (and by default in 2.4), a forward this way will *not* go through the filter chain again. This de-facto prevents against public requests to your jsp view pages--they can only be run by the controller. But the security problem is not with pages really, but with actions. If the request is stopped at the View stage it's already too late: you may have executed code that the user was not allowed to execute. Since a request to a .jsp will not be mapped to any action, no action will be run. Only actions which have paths explicitly mapped to them will ever be run. There may be a wrinkle in that the filter controller would by default let any request flow through if there is no action mapping, which could still allow a request to a .jsp to find and execute a page, but fixing this is an implementation detail (maybe as simple as throwing an exception if the request matches *.jsp). -Chris --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Action invocation
You make a base package with the 3, then 2 other packages which extend the base package and add the actions for each role to its respective package. -Original Message- From: Rickard Öberg [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 02, 2003 2:26 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Action invocation Jason Carreira wrote: I'm thinking we could use your idea of packages, and map packages to certain paths, then you could easily secure by package. What if you have 10 actions in a package, and 3 are public, 4 are allowed by one role, and 6 are allowed by another (i.e. there's an overlap). How do you do that with secure by package? /Rickard --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Action configuration XML [Commands]
Rickard Öberg wrote: I said that you *could* use the Preferences API. If you don't want to, then don't. Fair enough. I just wanted to be clear that I don't want it as a dependency :) Regards, Bruce Ritchie smime.p7s Description: S/MIME Cryptographic Signature
Re: [OS-webwork] Action invocation
Jason Carreira wrote: You make a base package with the 3, then 2 other packages which extend the base package and add the actions for each role to its respective package. But then the actions will be packaged based on the security restrictins instead of their belonging together-ness, which is a kludge. /Rickard --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Action invocation
Chris Nokleberg wrote: On Thu, Jan 02, 2003 at 08:00:41PM +0100, Rickard Öberg wrote: But one of the reasons to get rid of .action is that it exposes the implementation. .jsp does the same thing! Absolutely. But at least XWork would be hidden. Why not allow for arbitrary URLs, even when you want to use JSP as your view technology? Then it can just become another templating language. Intercepting calls to .jsp pages is not very Model 2. Maybe Model 1.5. AFAICT there's no expressive difference between what I suggested and using the .action way, except that the former can only map a JSP to one action. Can you explain how is it not very Model 2? *If* actions are always tied to a path (or paths), *and* there is a filter controller, then: a) Your URLs can be anything you want. b) You can use the same JSP as the view for multiple actions. Pretty much, yes. There's no real trouble with allowing .action invocations as before, but if it's possible to get them to go away it would be nice. I think in the latest design there is a View factory chain which produces a View class, just like for actions. A .jsp view should result in a JSP View class, which will just forward the request to a JSP page via a RequestDispatcher. I don't see any point in having a JSP View class as opposed to a generic include a servlet View class. The problem is that you have to then allow requests directly to .jsp files. What happens when you want to switch to velocity? What does that have to do with having a JSP specific View class? If you have been using .jsp and want to switch to Velocity without breaking URL's then map the Velocity-servlet to .jsp and use that extension for the templates. Or, map JSP's to .html and use that for Velocity templates too in order to hide both completely. In servlet 2.3 (and by default in 2.4), a forward this way will *not* go through the filter chain again. This de-facto prevents against public requests to your jsp view pages--they can only be run by the controller. But the security problem is not with pages really, but with actions. If the request is stopped at the View stage it's already too late: you may have executed code that the user was not allowed to execute. Since a request to a .jsp will not be mapped to any action, no action will be run. With the servlet filter approach it would. We seem to be miscommunicating here, but I'm not sure where it gets wrong. There may be a wrinkle in that the filter controller would by default let any request flow through if there is no action mapping, which could still allow a request to a .jsp to find and execute a page, but fixing this is an implementation detail (maybe as simple as throwing an exception if the request matches *.jsp). That is how I have implemented the filter currently: if there's an action for the JSP, then execute it, otherwise do nothing (i.e. run JSP as usual). /Rickard --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Action configuration XML [Commands]
Chris Nokleberg wrote: Oops: this is to me an obvious case of premature optimization. But optimization is a maybe not the best word for omitting a feature completely :-) Right. The idea was to perhaps find a better way to accomplish the same thing. Once a good way has been found, then we can discuss various optimizations of it. I'd like to see properties on results as well as action mappings, which would be applied to the chained action. There are some interesting questions regarding the ordering of all the parameter setting, though. I'd prefer that the action properties overwrite any form parameters. If you're using the properties to parameterize the execution of the action from your config file, you don't want the user to be able to mess with things just by guessing the right property name. But that can break too, if you're using defaulted values. Let's say you have a property that can be set called foo and that default is 5. If you're happy with that then you do nothing in the XML descriptor, and thus expect 5 to be the value. Then a user could override it using a parameter. Another reason why doing action configuration this way is a bad idea in the first place I guess. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Action invocation
-Original Message- From: Rickard Öberg [mailto:[EMAIL PROTECTED]] That is how I have implemented the filter currently: if there's an action for the JSP, then execute it, otherwise do nothing (i.e. run JSP as usual). /Rickard I don't like the idea of exposing the view we're mapping to. What If I want to change the view that is mapped from the action? I think it would be better to have: http://somehost.com/myPackage/myAction So you don't have to have any kind of extension... Just logical URLs that make sense. Jason --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Action invocation
boxed wrote: I find having the actions available directly with the .action notation very handy for developing/debugging. I am hoping you mean possible to avoid them if you want. It sounds to me like you want to force users to not use the .action notation, when it can definetely be useful. Why is it more convenient than tying it to a result page? Or do you run the action without a result? /Rickard --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Action invocation
On Thu, Jan 02, 2003 at 09:15:44PM +0100, Rickard Öberg wrote: Chris Nokleberg wrote: On Thu, Jan 02, 2003 at 08:00:41PM +0100, Rickard Öberg wrote: But one of the reasons to get rid of .action is that it exposes the implementation. .jsp does the same thing! Absolutely. But at least XWork would be hidden. Why not allow for arbitrary URLs, even when you want to use JSP as your view technology? Then it can just become another templating language. Intercepting calls to .jsp pages is not very Model 2. Maybe Model 1.5. AFAICT there's no expressive difference between what I suggested and using the .action way, except that the former can only map a JSP to one action. Can you explain how is it not very Model 2? We are miscommunicating, I'm sure. From his responses I think Jason Carreira is on the same wavelength as me, though, if it helps. Anyway, here goes: Model 1: a) user requests /foo/bar.jsp b) request goes to servlet container jsp handler, runs bar.jsp c) bar.jsp uses scriptlets, beans to run business logic Model 2 (jsp view) a) user requests /foo/bar b) request is mapped to a servlet Bar c) servlet Bar runs business logic, sticks stuff in context d) servlet forwards to /some/arbitrary.jsp e) /some/arbitrary.jsp executed by container Model 2 (velocity, etc.) a-c) same d) servlet spits out result of velocity template What I hear you proposing: a) user requests /foo/bar.jsp -- Note .jsp b) request is mapped by xwork filter controller to action Bar c) action Bar runs business logic, returns success result d) success result mapped to LetItPassThrough view-string e) view-string looked up via view factory to return LetItPassThrough View f) LetItPassThrough View directs controller to let the servlet engine handle the request as normal, or something similar g) /foo/bar.jsp executed by container What I propose (jsp view) a) user requests /foo/bar -- Note NO .jsp b) request is mapped by xwork filter controller to action Bar c) action Bar runs business logic, returns success result d) success result mapped to /some/arbitrary.jsp view-string e) view-string looked up via view factory to return JSP View f) JSP View uses request dispatcher to forward to /some/arbitrary.jsp What I propose (velocity, etc.) a-c) same d) success result mapped to /some/arbitrary.vel view-string e) view-string looked up via view factory to return Velocity view f) Velocity View spits out result of /some/arbitrary.vel What you suggest has one major thing in common with Model 1, that is that the original request is to a .jsp page, instead of an arbitrary action URL. This is why I dubbed it Model 1.5. I think there are advantages to really treating .jsp pages just as templates. It will keep all view technologies on the same playing field and I imagine would simplify the code too. The problem is that you have to then allow requests directly to .jsp files. What happens when you want to switch to velocity? If you have been using .jsp and want to switch to Velocity without breaking URL's then map the Velocity-servlet to .jsp and use that extension for the templates. Or, map JSP's to .html and use that for Velocity templates too in order to hide both completely. What if you have static html pages too? It becomes to hackified this way. Better to let what view gets used be driven *completely* by the action mapping configuration, and not at all by web.xml servlet mappings. -Chris --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Action invocation
Yes, this is assuming that your servlet dispatcher is mapped to /*.. If you're building your whole app with xwork, this is an ok assumption. You could have it under something else, like /xwork, if you wanted. The ServletDispatcher would use the rest of the path info (/myPackage/myAction) to find the package (myPackage) and then find the action mapping (for myAction). -Original Message- From: Rickard Öberg [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 02, 2003 3:47 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Action invocation Jason Carreira wrote: I don't like the idea of exposing the view we're mapping to. What If I want to change the view that is mapped from the action? I think it would be better to have: http://somehost.com/myPackage/myAction So you don't have to have any kind of extension... Just logical URLs that make sense. What would trigger the action filter/servlet? /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Action invocation
On Thu, Jan 02, 2003 at 09:47:24PM +0100, Rickard Öberg wrote: Jason Carreira wrote: I don't like the idea of exposing the view we're mapping to. What If I want to change the view that is mapped from the action? I think it would be better to have: http://somehost.com/myPackage/myAction So you don't have to have any kind of extension... Just logical URLs that make sense. What would trigger the action filter/servlet? The filter would be mapped to /* in almost all scenarios. It would inspect all requests to see if the request uri (minus the context prefix) is mapped to an action via the request mappings. Otherwise it will let the (probably static file) pass through. -Chris --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
[OS-webwork] Talk vs Do
OK, so we've had quite a bit of communication on the list in the last few days, and to be honest, I'm having a hard time keeping up with it all. I mean, all the ideas and interest is great, but let's take a step at a time. Remember, the CVS module name is sandbox, nothing is golden in there. Rickard, I think you should just go ahead and hack away with your initial ideas (like I did) and then we can talk again. We'll continue the process until things settle down (in terms of core funcitonality), and then we can start an official design spec, docs, and full support (ie: ActionSupport, standard actions, views, configuration, etc). We're still very much in the exploratory phase (which is why it's in the sandbox module), so have at it and we can have another round of talks afterwards. -Pat --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
[OS-webwork] Re: Re: Action invocation
OK, I must be missing something here... I'm sure we discussed this previously and the only solid argument in support of the arbitrary paths was for skinning applications. I still can't see how the path/skinning functionality can be supported by having urls that end with .jsp instead of .action. Can you explain further (with an example perhaps) what you mean by If .action invocations are not allowed then it's possible to use declarative security? How does your approach allow web.xml to be configured to protect a path such as */admin/*? Rickard Öberg [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Chris Miller wrote: Remind me again why .action causes problems with declaritive security? Surely the real problem is that Webwork currently doesn't care if an arbitrary path is specified in the URL. ie: http://www.me.com/abc123/admin/deleteUser.action is treated the same as http://www.me.com/admin/deleteUser.action - which makes it very messy to nail down in web.xml. That *is* the problem. And itt's not messy; it's impossible! No matter how you construct your web.xml I can circumvent it by doing an arbitrary path like so: http://www.me.com/jkldsdfglkjglkdhgdklhg/asdasdasd/deleteUser.action If .action invocations are not allowed then it's possible to use declarative security. Plus if execution of actions is only possible if a URL has been previously associated with it during form creation, then it's even safer. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Action invocation
Ditto - we do this a lot. Ie on JavaBlogs, the 'blog entry display' is all a single JSP file, with many different ways to use it as a view (ie ViewPopularBlogs.jspa and ViewDaysBlogs.jspa both have the same JSP view file) I don't see why this is bad? (In fact - it's good - it makes the URLs simpler and more easily bookmarked / memorable!) -mike On 3/1/03 4:52 AM, Patrick Lightbody ([EMAIL PROTECTED]) penned the words: They have very, VERY different ways to retrieve the data. But yes, I suppose one could design differently. - Original Message - From: Rickard Ã-berg [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 02, 2003 9:37 AM Subject: Re: [OS-webwork] Action invocation Patrick Lightbody wrote: This sounds scary to me -- I'm not entirely convinced that URLs with .action in them are terribly bad. I do have cases where 4 different actions use that same SUCCESS view: ShowDocumentListA.success = doc_list.jsp ShowDocumentListB.success = doc_list.jsp ShowDocumentListC.success = doc_list.jsp hm.. but that sounds like a ShowDocumentList?x=A/B/C to me. I.e. why do you have three actions for it? /Rickard --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Action configuration XML [Commands]
If you read the whole email you'd know why. Let me quote: But it's a dangerous option, since it may not be apparent that this slowdown will occur. If possible, configuration of actions should not occur this way. Given the huge amount of reflection in webwork anyway, is a little more going to hurt? (And as someone said - wouldn't it all be cached anyway?) -mike PS I'm +1 for action parameters - v. useful! --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Action invocation
For one thing, they perform better. Another reason is that I have the same situation as Pat, the same jsp is the success page for multiple actions. One final reason is that the migration path from ww to xw for applications now requires filters to handle the (automatic) migration from the old .action urls to the new jsp only urls. I guess it would be possible to add .action support as well, but if it's possible to avoid I think we should, for reasons mentioned (hiding implementation, security). Maybe this is a little bit of personal preference - but as the webwork (and OS!) way, let's let the user decide! Why can't we just have a ServletDispatcher and a FilterDispatcher? For the record, I actually LIKE having .jspa and .jsp different - it reminds me which pages 'do things' and which are just 'pages'. -mike --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Re: Action invocation
Hrm - no, this is thinking the wrong way mate :) If webwork defined paths, security would work perfectly right? So why not have webwork only 'work' if the path is correct (and defined)? Ie /admin/foo.action would execute foo, but /bar/admin/foo.action would execute nothing. That way you keep .action, AND your security works fine? (And if you don't define paths - it works as it does now - principle of least surprise!) -mike On 3/1/03 6:05 AM, Rickard Öberg ([EMAIL PROTECTED]) penned the words: Chris Miller wrote: Remind me again why .action causes problems with declaritive security? Surely the real problem is that Webwork currently doesn't care if an arbitrary path is specified in the URL. ie: http://www.me.com/abc123/admin/deleteUser.action is treated the same as http://www.me.com/admin/deleteUser.action - which makes it very messy to nail down in web.xml. That *is* the problem. And itt's not messy; it's impossible! No matter how you construct your web.xml I can circumvent it by doing an arbitrary path like so: http://www.me.com/jkldsdfglkjglkdhgdklhg/asdasdasd/deleteUser.action If .action invocations are not allowed then it's possible to use declarative security. Plus if execution of actions is only possible if a URL has been previously associated with it during form creation, then it's even safer. /Rickard --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Re: Re: Action invocation
I use #2 quite a bit, and I'm not in any sort of portlet environment. I just have multiple ww:action tags in my JSPs. - Original Message - From: Hai Pham [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 02, 2003 2:12 PM Subject: Re: [OS-webwork] Re: Re: Action invocation Hi all, I think there are two major reasons why Rickard wants to discard URL with .action. 1. to get declarative security working 2. to make it possible to invoke multiple read-only actions within a page (in portlet environment for example) IMO, only #1 is reaonable. Still, lots of us already implement authentitation filter to get around the prob. with the path. That's not to say that we need not to fix that, but IMO there should be better way then getting rid of .action URL. #2 is most often applicable in portlet environment. In my project I don't need to use any action tag or #action macro. I believe this is true for the majority of other projects. Even if you want to do that, there are althernatives like Sitemesh or even ww:include tag. Rickard's comment about .action URL unstable (for bookmarking) and exposing the implementation is unconvincing to me. In fact, .action URL is more stable than a .jsp or something like that. You can map an action to various views like jsp, velocity... So even when you change the view name or view type, the URL is still the same. Well, that's my thought. I just hope that if you insist on these new implementation (related to portlet thingy), you still keep .action URL around and that its performance wouldn't be degraded. --- Chris Miller [EMAIL PROTECTED] a écrit : OK, I must be missing something here... I'm sure we discussed this previously and the only solid argument in support of the arbitrary paths was for skinning applications. I still can't see how the path/skinning functionality can be supported by having urls that end with .jsp instead of .action. Can you explain further (with an example perhaps) what you mean by If .action invocations are not allowed then it's possible to use declarative security? How does your approach allow web.xml to be configured to protect a path such as */admin/*? Rickard Öberg [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Chris Miller wrote: Remind me again why .action causes problems with declaritive security? Surely the real problem is that Webwork currently doesn't care if an arbitrary path is specified in the URL. ie: http://www.me.com/abc123/admin/deleteUser.action is treated the same as http://www.me.com/admin/deleteUser.action - which makes it very messy to nail down in web.xml. That *is* the problem. And itt's not messy; it's impossible! No matter how you construct your web.xml I can circumvent it by doing an arbitrary path like so: http://www.me.com/jkldsdfglkjglkdhgdklhg/asdasdasd/deleteUser.action If .action invocations are not allowed then it's possible to use declarative security. Plus if execution of actions is only possible if a URL has been previously associated with it during form creation, then it's even safer. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork = --- Hai Pham Quang --- __ Lèche-vitrine ou lèche-écran ? magasinage.yahoo.ca --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Re: Re: Action invocation
Hi all, I think there are two major reasons why Rickard wants to discard URL with .action. 1. to get declarative security working 2. to make it possible to invoke multiple read-only actions within a page (in portlet environment for example) IMO, only #1 is reaonable. Still, lots of us already implement authentitation filter to get around the prob. with the path. That's not to say that we need not to fix that, but IMO there should be better way then getting rid of .action URL. #2 is most often applicable in portlet environment. In my project I don't need to use any action tag or #action macro. I believe this is true for the majority of other projects. Even if you want to do that, there are althernatives like Sitemesh or even ww:include tag. Rickard's comment about .action URL unstable (for bookmarking) and exposing the implementation is unconvincing to me. In fact, .action URL is more stable than a .jsp or something like that. You can map an action to various views like jsp, velocity... So even when you change the view name or view type, the URL is still the same. Well, that's my thought. I just hope that if you insist on these new implementation (related to portlet thingy), you still keep .action URL around and that its performance wouldn't be degraded. --- Chris Miller [EMAIL PROTECTED] a écrit : OK, I must be missing something here... I'm sure we discussed this previously and the only solid argument in support of the arbitrary paths was for skinning applications. I still can't see how the path/skinning functionality can be supported by having urls that end with .jsp instead of .action. Can you explain further (with an example perhaps) what you mean by If .action invocations are not allowed then it's possible to use declarative security? How does your approach allow web.xml to be configured to protect a path such as */admin/*? Rickard Öberg [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Chris Miller wrote: Remind me again why .action causes problems with declaritive security? Surely the real problem is that Webwork currently doesn't care if an arbitrary path is specified in the URL. ie: http://www.me.com/abc123/admin/deleteUser.action is treated the same as http://www.me.com/admin/deleteUser.action - which makes it very messy to nail down in web.xml. That *is* the problem. And itt's not messy; it's impossible! No matter how you construct your web.xml I can circumvent it by doing an arbitrary path like so: http://www.me.com/jkldsdfglkjglkdhgdklhg/asdasdasd/deleteUser.action If .action invocations are not allowed then it's possible to use declarative security. Plus if execution of actions is only possible if a URL has been previously associated with it during form creation, then it's even safer. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork = --- Hai Pham Quang --- __ Lèche-vitrine ou lèche-écran ? magasinage.yahoo.ca --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Action invocation
Yes :) On 3/1/03 7:38 AM, Rickard Öberg ([EMAIL PROTECTED]) penned the words: Jason Carreira wrote: I dunno. I would argue that if they can't be run by the same role, then they don't belong together. So if you've made this cool weblog thingy (as an example) where half of the actions goes to rendering the weblog, and half are about administering it, you'd put them into two packages instead of one? Hm I still think it's a kludge. /Rickard --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Talk vs Do
Also, PLEASE USE THE WIKI SO WE CAN STORE IDEAS GENERATED! Apologies for the caps - some people don't get it :) http://www.opensymphony.com:8668/space/WebWork and even http://www.opensymphony.com:8668/space/XWork+Roadmap If we put all the generated ideas on the Wiki (don't worry - add a new page with your idea - it will never run out of space :)) we can much more easily keep / discard them? -mike On 3/1/03 8:08 AM, Patrick Lightbody ([EMAIL PROTECTED]) penned the words: OK, so we've had quite a bit of communication on the list in the last few days, and to be honest, I'm having a hard time keeping up with it all. I mean, all the ideas and interest is great, but let's take a step at a time. Remember, the CVS module name is sandbox, nothing is golden in there. Rickard, I think you should just go ahead and hack away with your initial ideas (like I did) and then we can talk again. We'll continue the process until things settle down (in terms of core funcitonality), and then we can start an official design spec, docs, and full support (ie: ActionSupport, standard actions, views, configuration, etc). We're still very much in the exploratory phase (which is why it's in the sandbox module), so have at it and we can have another round of talks afterwards. -Pat --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Talk vs Do
Mike, Can you get a this linked from the main OS web page? - Original Message - From: Mike Cannon-Brookes [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 02, 2003 2:34 PM Subject: Re: [OS-webwork] Talk vs Do Also, PLEASE USE THE WIKI SO WE CAN STORE IDEAS GENERATED! Apologies for the caps - some people don't get it :) http://www.opensymphony.com:8668/space/WebWork and even http://www.opensymphony.com:8668/space/XWork+Roadmap If we put all the generated ideas on the Wiki (don't worry - add a new page with your idea - it will never run out of space :)) we can much more easily keep / discard them? -mike On 3/1/03 8:08 AM, Patrick Lightbody ([EMAIL PROTECTED]) penned the words: OK, so we've had quite a bit of communication on the list in the last few days, and to be honest, I'm having a hard time keeping up with it all. I mean, all the ideas and interest is great, but let's take a step at a time. Remember, the CVS module name is sandbox, nothing is golden in there. Rickard, I think you should just go ahead and hack away with your initial ideas (like I did) and then we can talk again. We'll continue the process until things settle down (in terms of core funcitonality), and then we can start an official design spec, docs, and full support (ie: ActionSupport, standard actions, views, configuration, etc). We're still very much in the exploratory phase (which is why it's in the sandbox module), so have at it and we can have another round of talks afterwards. -Pat --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
[OS-webwork] Requirements
To Rickard's list of requirements, I would add the following requirements: * Simple to understand * Easy to configure My gripe with flexible feature sets is the complex configurations that often come with them. The application should have reasonable defaults (based on the principal of least surprise :) and allow developers to configure additional features as needed. -- Matt Ho Principal Indigo Egg, Inc. http://www.indigoegg.com/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
[OS-webwork] Struts Converts
I was curious if there are any people here who have converted from using struts to using webworks. If yes, then could you please give me some insight as to why you switched. Also, following are a few questions that I would appreciate an answer on if you would be willing. Struts comparison questions: How was your production time impacted by switching to Webworks? (quicker,slower,indifferent) What would you say is the main advantage(s) over struts? In what areas is struts better? General Webworks question: What would you say is the greatest weakness of webworks? What would you say is the greatest strength of webworks? Thanks for your time, Brandon Goodin Phase Web and Multimedia P (406) 862-2245 F (406) 862-0354 [EMAIL PROTECTED] http://www.phase.ws --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Re: Re: Action invocation
I think there are two major reasons why Rickard wants to discard URL with .action. 1. to get declarative security working [snip] IMO, only #1 is reaonable. Still, lots of us already implement authentitation filter to get around the prob. with the path. That's not to say that we need not to fix that, but IMO there should be better way then getting rid of .action URL. As a recent struts to WebWork convert, I was surprised to find that http://somesite.com/path/bar.action was exactly the same as http://somesite.com/path/foo/bar.action to webwork. While I've seen a couple posting asking this same question, I haven't seen an answer. I agree with Hai and a number of the other posters that this goes a long way to fixing the security issue. I look at it this way. There are a couple accepted ways of implementing declarative security: 1. Securing based on path (Servlets for example) 2. Securing based on authenticated role (EJBs for example) There are of course proprietary implementations. Ideally, I would love XWork to support 1 and 2 orthogonally. I can understand forcing developers to rely on approach 1 as it's a common web practice, but I can't agree with forcing developers to use approach 2 only. Production environments may combine a variety of different technologies. If a company already has a system that utilizes path based security (1), they shouldn't be forced to declare security in two places. Likewise, if EJB style security is already being used, it'd be nice to have the option of using that with their XWork actions. Note - I'm not proposing that we using EJB style security declarations, I'm just using it as an example of tying security to the action performed rather than the path requested. -- Matt Ho Principal Indigo Egg, Inc. http://www.indigoegg.com/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Struts Converts
I was curious if there are any people here who have converted from
using
struts to using webworks. If yes, then could you please give me some
insight as to why you switched. Also, following are a few questions
that I
would appreciate an answer on if you would be willing.
Struts comparison questions:
How was your production time impacted by switching to Webworks?
(quicker,slower,indifferent)
I had been using struts for some years now, but only recently looked
into WebWork. I've been amazed at how much faster development goes. I
would say the most significant aspect of that is the WebWork Expression
Language. One of my main gripes with Struts is how cumbersome the
configuration and the tag libraries were.
Although not enforced by Struts, Struts encourages you to use the
ActionForm to pass in parameters to your action and request attributes
to pass values back to the view. This gets bulks quickly.
What would you say is the main advantage(s) over struts?
Without a doubt, the expression language.
Here's an email I recently sent to a friend that compares the two. You
might find it interesting:
--[ snip ]
Struts has a number of things that it does well:
* good tag library support
* simple conceptual model
* large developer base
* excellent third party tools
* well understood
However, it also has a lot of warts:
* tag library is confusing to use. It's large and very fine grained.
* using struts ties the application to the web tier, so most people end
up
writing an intermediate layer. This is probably one of the more
egregious problems with struts as it causes a whole layer of crap.
To perform the simplest of actions, I probably need to:
i. extend ActionForm (a concrete class)
ii. extend Action (also a concrete class)
iii. update the struts-config.xml file
Webwork
* webwork looks a lot like struts, but I think it's far more clever
* the form and the action are bundled together so you never need to map
the
two
* the form need only implement Action (an interface) rather than a
concrete
* the configuration is much simpler.
Side by side example:
Let's say you wanted to lookup some data in the database and return it's
value.
Struts
==
public class MyForm extends ActionForm {
private String thingId ;
public String getThingId() { return this.thingId ; }
public void setThingId(String thingId) { this.thingId = thingId ; } }
public class MyAction extends Action {
public ActionForward execute(ActionMapping mapping, ActionForm form,
HttpServletRequest request, HttpServletResponse response) throws
Exception
{
MyForm myForm = (MyForm)form ;
String thingId = myForm.getThingId() ;
// do work here
Object result ; // set the result to object
request.setAttribute(ResultNames.RESULT, result) ;
}
}
public class ResultNames {
final public static String RESULT = project.result ;
}
form-beans
form-bean name=myForm type=com.indigoegg.project.MyForm/
/form-beans
actions
action name=myForm path=/doit
scope=request
type=com.indigoegg.project.MyAction
unknown=false validate=false
forward name=SUCCESS
path=/WEB-INF/views/doit-success.jsp
redirect=false/
forward name=INPUT
path=/WEB-INF/views/doit-input.jsp
redirect=false/
/actions
Bleh! Now the webwork way:
public class MyWebWorkAction implements Action {
private String thingId ;
private Object result ;
public void setThingId(String thingId) { this.thingId = thingId ; }
public Object getResult() { return this.result ; }
public String execute() throws Exception {
// set the result to object
}
}
done! The MyWebWorkAction is visible from the HTML page, so you can
just ask it for the result value. No funny traversals, etc. You can
access is by name or map it as you would in struts. The mapping is
optional. Here's an example mapping.
action name=com.indigoegg.project.MyWebWorkAction alias=go
view name=success/WEB-INF/views/doit-success.jsp/view
view name=input/WEB-INF/views/doit-input.jsp/view
/action
The action mapping is optional :)
--
Matt Ho
Principal
Indigo Egg, Inc.
http://www.indigoegg.com/
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Action configuration XML [Commands]
May be don't use reflection then and delegate this to the action itself. For e.g, this can be implemented by adding an init method to the Action interface that take a map as parameter. This would also allow us to differentiate between init parameter ( usually for configuration purpose ) and runtime parameter ( usually use input ). Regards, Low --- Rickard_Öberg [EMAIL PROTECTED] wrote: Jason Carreira wrote: Couldn't the Method objects found the first time through reflection for parameterizing the Action instances be cached and reused, making the reflection performance hit negligible? I've never profiled reflection to see where the biggest performance hit is, but if it's the Class and Method lookup, this could help (and be used for the Action field population, as well) The biggest hit is in lookup, absolutely. However, there's overhead for type conversion too. And if you compare it with a simple Conf.getValue() call the overhead is MUCH higher. /Rickard --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Re: Action invocation
May be we can add explicit url to action mapping instead of relying on using the success view. For e.g, something like: url path=/admin/deleteUser.jsp action-ref name=admin.deleteUser/ /url Or that can be implemented as part of a servlet filter configuration. Regards, Low --- Rickard_Öberg [EMAIL PROTECTED] wrote: Chris Miller wrote: Remind me again why .action causes problems with declaritive security? Surely the real problem is that Webwork currently doesn't care if an arbitrary path is specified in the URL. ie: http://www.me.com/abc123/admin/deleteUser.action is treated the same as http://www.me.com/admin/deleteUser.action - which makes it very messy to nail down in web.xml. That *is* the problem. And itt's not messy; it's impossible! No matter how you construct your web.xml I can circumvent it by doing an arbitrary path like so: http://www.me.com/jkldsdfglkjglkdhgdklhg/asdasdasd/deleteUser.action If .action invocations are not allowed then it's possible to use declarative security. Plus if execution of actions is only possible if a URL has been previously associated with it during form creation, then it's even safer. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
