Re: [OS-webwork] Action invocation
boxed wrote: I will run the action without a result a few times to start off to make sure it compiles and goes through to success and so forth. I also have some (very few) actions that don't actually have a view at all, but write directly to the servlet output stream. Yes I know it's ugly, I hate it too, but there are several cases where I am pretty much forced to do this, most notably when the output needs to be streaming in some way. There is another early development thing you can do to make initial development easier, but that includes a change to MakeIterator (my diff and source is attached) and a default mapping of success to a jsp that does: ww:iterator ww:print value=value/propertyType / ww:print value=key /br / /ww:iterator I find it very handy for initial debugging. That's a very good point. So, it seems that .action invocation is indeed something that is necessary to keep. The argument against .action invocation, then, is only with regard to declarative security. Would it be ok to declare what roles may access it in xwork.xml? (both on action and package level) One nice thing about that is that the information could be used by many different invokers, as opposed to the declarative security through web.xml option which only works for the web case. /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]] The argument against .action invocation, then, is only with regard to declarative security. Would it be ok to declare what roles may access it in xwork.xml? (both on action and package level) That's the argument against .action invocation with any path. If we pin actions to certain paths in the config files, as I've proposed, then this is not an issue. One nice thing about that is that the information could be used by many different invokers, as opposed to the declarative security through web.xml option which only works for the web case. Then you have to synchronize your roles in web.xml with the roles in xwork.xml. Plus, your servlet container can't automatically determine that you aren't logged in when you try to access a secured area and pop up the log-in prompt or load the log-in form. 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
Jason Carreira wrote: That's the argument against .action invocation with any path. If we pin actions to certain paths in the config files, as I've proposed, then this is not an issue. True, but it's more configuration to do. If it can be avoided that'd be nice. One nice thing about that is that the information could be used by many different invokers, as opposed to the declarative security through web.xml option which only works for the web case. Then you have to synchronize your roles in web.xml with the roles in xwork.xml. Plus, your servlet container can't automatically determine that you aren't logged in when you try to access a secured area and pop up the log-in prompt or load the log-in form. No, but the controller servlet can, I think. If the execution interceptor returns LOGIN, then the controller should be able to return headers that correspond to showing the log-in prompt, or one could simply have a view mapped to LOGIN that returns those headers. Or am I missing something? /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
Jason Carreira wrote: As opposed to the extra configuration to assign roles to packages and coordinate them with the roles in web.xml? I really don't like the idea of putting security information into xwork. If we pinned packages to URL paths, and protected the paths using J2EE declarative security, you've only got security information in one place, and it can be changed at deploy time (and even at run time, depending on your servlet container). Good point. I agree with that. But, there's still a need to add roles to xwork.xml I think, for the cases where the actions are invoked by other actions, or by some dispatcher other then a servlet controller. No, but the controller servlet can, I think. If the execution interceptor returns LOGIN, then the controller should be able to return headers that correspond to showing the log-in prompt, or one could simply have a view mapped to LOGIN that returns those headers. Or am I missing something? Can this be done? I'm not sure... I think this would require container-specific code for each container we support. Isn't just a case of returning standard HTTP headers? (for the prompt I mean). Also, what should happen if an action is invoked through an include and is not allowed access to. This is by far the most common case I have anyway (I don't have ANY other case). How would that 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 invocation
+1 here. Michael Blake Day Artistry Studios - e-commerce design, implementation and hosting email: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mobile: 770.480.1547 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Carreira Sent: Thursday, January 02, 2003 3:33 PM To: [EMAIL PROTECTED] Subject: 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 --- 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 may be late to the conversation, but I just wanted to mention the obvious. Having .action extensions does not expose the fact that a person is using WebWork (or XWork). You can even change the extension to whatever you want (try .dll, hehe). Michael Blake Day Artistry Studios - e-commerce design, implementation and hosting email: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mobile: 770.480.1547 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Rickard Oberg Sent: Thursday, January 02, 2003 1:27 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Action invocation Bruce Ritchie wrote: I'm with Pat here .. I actually prefer having urls with the .action in them to having pages with ww:action tags in them. But I didn't suggest that you'd use action tags... that was the WW way, and it worked, but with the filter it's much more transparent and the security problem with .action's is gone. 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). /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 invocation
It would seem some folks are assuming that all requests will go via the servlet and therefore if myAction is deemed to be an action then it will be executed. This obviously has a high overhead factor. On Thursday, January 2, 2003, at 08:47 PM, 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? /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
Actually, all this talk of filters, etc. makes me wonder if it *is* supposed to be WebWork 2.0 as opposed to XWork. Applying filters to a Swing app would be, um, great fun. On Fri, 3 Jan 2003, Jason Carreira wrote: As opposed to what? This is a model-2 MVC framework. It uses a controller servlet as its entry point. -Original Message- From: Robert Nicholson [mailto:[EMAIL PROTECTED]] Sent: Friday, January 03, 2003 5:59 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Action invocation It would seem some folks are assuming that all requests will go via the servlet and therefore if myAction is deemed to be an action then it will be executed. This obviously has a high overhead factor. On Thursday, January 2, 2003, at 08:47 PM, 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? /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 - Joseph B. Ottinger [EMAIL PROTECTED] http://enigmastation.comIT Consultant --- 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
Joseph Ottinger wrote: Actually, all this talk of filters, etc. makes me wonder if it *is* supposed to be WebWork 2.0 as opposed to XWork. Applying filters to a Swing app would be, um, great fun. Yes and no. Some of the stuff we're discussing here are definitely web-centric, but others is not. The filters, for example, are not web-centric. They are useful no matter what you're using the actions with. As a whole I do think that XWork will be rather web-centric though, for sure. /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
As opposed to what? This is a model-2 MVC framework. It uses a controller servlet as its entry point. -Original Message- From: Robert Nicholson [mailto:[EMAIL PROTECTED]] Sent: Friday, January 03, 2003 5:59 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Action invocation It would seem some folks are assuming that all requests will go via the servlet and therefore if myAction is deemed to be an action then it will be executed. This obviously has a high overhead factor. On Thursday, January 2, 2003, at 08:47 PM, 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? /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
Jason Carreira wrote: As opposed to what? This is a model-2 MVC framework. It uses a controller servlet as its entry point. Using a controller servlet that intercepts all requests but only deals with some of the requests is going to be unnecessary overhead. /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
Jason Carreira wrote: Maybe, but is it an acceptable level of complexity for the benefits (simplictiy, security, etc) it provides? For instance, I would like to have all of my JSP pages under WEB-INF, so they can only be used from the servlet, rather than being accessed directly, which would most likely cause them to break, since the context hasn't been set up for them. I don't think that's even theoretically possible. Velocity would work, of course, but I don't think JSP's would. Setting up a security constraint so that noone could access *.jsp would do the trick though. /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'm pretty sure I read an article about doing it... Anybody else have any experience doing this? -Original Message- From: Rickard Öberg [mailto:[EMAIL PROTECTED]] Sent: Friday, January 03, 2003 10:16 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Action invocation Jason Carreira wrote: Maybe, but is it an acceptable level of complexity for the benefits (simplictiy, security, etc) it provides? For instance, I would like to have all of my JSP pages under WEB-INF, so they can only be used from the servlet, rather than being accessed directly, which would most likely cause them to break, since the context hasn't been set up for them. I don't think that's even theoretically possible. Velocity would work, of course, but I don't think JSP's would. Setting up a security constraint so that noone could access *.jsp would do the trick though. /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
No, you are correct. If you put the JSPs in the WEB-INF directory, the servlet engine will not allow direct access. I do it all the time... IMHO, this is a very good practice! - Original Message - From: Jason Carreira [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 03, 2003 10:22 AM Subject: RE: [OS-webwork] Action invocation I'm pretty sure I read an article about doing it... Anybody else have any experience doing this? -Original Message- From: Rickard Öberg [mailto:[EMAIL PROTECTED]] Sent: Friday, January 03, 2003 10:16 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Action invocation Jason Carreira wrote: Maybe, but is it an acceptable level of complexity for the benefits (simplictiy, security, etc) it provides? For instance, I would like to have all of my JSP pages under WEB-INF, so they can only be used from the servlet, rather than being accessed directly, which would most likely cause them to break, since the context hasn't been set up for them. I don't think that's even theoretically possible. Velocity would work, of course, but I don't think JSP's would. Setting up a security constraint so that noone could access *.jsp would do the trick though. /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
If you put the jsp's in the WEB-INF what do your paths look like? I'm guessing your servlet has to requestdispatch to a path relative to WEB-INF? I think David Geary may have done something like this in his Advanced JSP book. On Friday, January 3, 2003, at 04:14 PM, Tim Dwelle wrote: No, you are correct. If you put the JSPs in the WEB-INF directory, the servlet engine will not allow direct access. I do it all the time... IMHO, this is a very good practice! - Original Message - From: Jason Carreira [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 03, 2003 10:22 AM Subject: RE: [OS-webwork] Action invocation I'm pretty sure I read an article about doing it... Anybody else have any experience doing this? -Original Message- From: Rickard Öberg [mailto:[EMAIL PROTECTED]] Sent: Friday, January 03, 2003 10:16 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Action invocation Jason Carreira wrote: Maybe, but is it an acceptable level of complexity for the benefits (simplictiy, security, etc) it provides? For instance, I would like to have all of my JSP pages under WEB-INF, so they can only be used from the servlet, rather than being accessed directly, which would most likely cause them to break, since the context hasn't been set up for them. I don't think that's even theoretically possible. Velocity would work, of course, but I don't think JSP's would. Setting up a security constraint so that noone could access *.jsp would do the trick though. /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 --- 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
Why is it more convenient than tying it to a result page? Or do you run
the action without a result?
I will run the action without a result a few times to start off to make sure
it compiles and goes through to success and so forth. I also have some (very
few) actions that don't actually have a view at all, but write directly to
the servlet output stream. Yes I know it's ugly, I hate it too, but there
are several cases where I am pretty much forced to do this, most notably
when the output needs to be streaming in some way. There is another early
development thing you can do to make initial development easier, but that
includes a change to MakeIterator (my diff and source is attached) and a
default mapping of success to a jsp that does:
ww:iterator
ww:print value=value/propertyType / ww:print value=key /br /
/ww:iterator
I find it very handy for initial debugging.
Anders Hovmöller
[EMAIL PROTECTED] http://boxed.killingar.net
MakeIterator.java
Description: Binary data
Index: src/main/webwork/util/MakeIterator.java
===
RCS file: /cvsroot/opensymphony/webwork/src/main/webwork/util/MakeIterator.java,v
retrieving revision 1.3
diff -r1.3 MakeIterator.java
13c13
---
15c15
---
46c46
else
---
else if (value instanceof Iterator)
49a50,54
else
{
value =
(BeanUtil.buildFieldMap(value.getClass())).entrySet();
iterator = ((Collection)value).iterator();
}
52c57
---
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] 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 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 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 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 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] 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 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 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
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 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] 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
