Re: [OS-webwork] Re: Action invocation
Mike Cannon-Brookes wrote: 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. Then the action would be pinned to that particular path, and skinning wouldn't work. That way you keep .action, AND your security works fine? Here's another way: define the roles that are allowed to access an action in xwork.xml, and create an interceptor that checks it. Then it can work exactly like how web.xml works, except it can do so for the case where an unsecure action calls a secure action too. /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
Matt Ho wrote: 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. snip This would essentially mean that XWork would have to support these two invocation types: /action/bar /foo/bar.action The first case would work well with path based security and roles, and the other would have no choice but to use roles. However, feature-wise the second case supports skinning. And then there's the third case which also supports path based security: /foo/xyzzy.jsp (which invokes bar action) Maybe it's possible to support all three. Question is: is it better to support as many options as possible, or is it better to have one way to do things? I suppose it's a tradeoff between flexibility and complexity. /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
This would essentially mean that XWork would have to support these two
invocation types:
/action/bar
/foo/bar.action
I'm probably not explaining myself well. To me, these are both examples
of path based security, struts style. Your second example with the jsp
was what I was considering role based security.
I'd like to propose the following approach as a potential solution.
Below are two examples of what modified actions.xml files (or whatever
xworks uses) might look like:
Let's assume for both these examples that a Filter is being used. The
traditional Servlet controller doesn't support a /foo/xyzzy.jsp
implementation.
Example 1:
In this example, our Servlet filter is mapped to *.action so that a
request to http://somesite.com/{context}/some.action invokes the
SomeAction while
http://somesite.com/{context}/xzy/another.some.action
invokes AnotherAction. The security role would be optional and
could
also be specified inside the body of the action tag if the xwork
was
to support multiple roles.
action name=com.indigoegg.SomeAction alias=/some role=xyz
view name=input/WEB-INF/views/some-input.jsp/view
view name=success/WEB-INF/views/some-success.jsp/view
/action
action name=com.indigoegg.AnotherAction alias=another.some
view name=input/WEB-INF/views/another-input.jsp/view
view name=success/WEB-INF/views/another-success.jsp/view
/action
Example 2:
In this example, our Servlet filter is mapped to *.jsp so that
requests
for /foo/xyzzy.jsp are intercepted by the filter. A couple things
changed in our configuration. The first is the addition of an
action-mapping section.
action name=com.indigoegg.SomeAction ref=some/
view name=input/WEB-INF/views/some-input.jsp/view
/action
action-mapping
action-refsome/action-alias
url-pattern/foo/xyzzy/url-pattern
!-- apply security here --
/action-mapping
Example 3:
This example combines both styles and maps to *.jsp. In this case,
a request for /path.jsp would map to /WEB-INF/views/some-success.jsp
whereas a request for /foo/xyzzy.jsp would be directed to
/foo/xyzzy.jsp
action name=com.indigoegg.Bar alias=/path ref=bar/
view name=success/WEB-INF/views/some-success.jsp/view
view name=input/WEB-INF/views/some-input.jsp/view
/action
action-mapping
action-refsome/action-alias
url-pattern/foo/xyzzy/url-pattern
!-- apply security here --
/action-mapping
While I think the style in Example 2 is very flexible, it comes at the
cost of increased configuration file complexity.
--
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]
Heng Sin Low wrote: 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 ). That would work just fine. You could do this in the prepare() step. Making a baseclass that has an implementation that does BeanUtil.copy(Map, this); would do the trick. /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] Re: Re: Action invocation
Chris Miller wrote: What would happen if the skins had to be explicitly defined in the configuration, or if none were defined then XWork would default to pinned paths? Then there would be an outcry of too much to configure.. waaah. :-) That way people that were not using the skinning would be able to use declaritive security as in a normal webapp, while the skinners could still use it to with relatively minor inconvenience - they'd have to declare a separate security constraint for each skin, eg: web-resource-collection web-resource-nameManagement Application/web-resource-name url-pattern/admin/*/url-pattern url-pattern/skin1/admin/*/url-pattern url-pattern/skin2/admin/*/url-pattern http-method*/http-method /web-resource-collection So those paths would then be duplicated in xwork.xml? Doesn't sound very appealing to me. /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
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
[OS-webwork] Skinning configuration
Then there would be an outcry of too much to configure.. waaah. :-) Well I did say it wasn't perfect :-) However, there would be *nothing* to configure if the user wasn't skinning their app. If they were skinning, then I agree that the configuration in web.xml is still awkward. If you can think of a cleaner solution for that problem I'm all for it. So those paths would then be duplicated in xwork.xml? Doesn't sound very appealing to me. Not quite. I was thinking more along the lines of this in xwork.xml: skins skin name=skin1/ skin name=skin2/ ... /skins Plus that could be extended to perhaps specify a default set of UI components for each skin or whatever. I think this sounds quite nice, web.xml configuration aside. --- 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] Skinning configuration
Chris Miller wrote: Then there would be an outcry of too much to configure.. waaah. :-) Well I did say it wasn't perfect :-) However, there would be *nothing* to configure if the user wasn't skinning their app. If they were skinning, then I agree that the configuration in web.xml is still awkward. If you can think of a cleaner solution for that problem I'm all for it. Well, specifying roles (as already described in previous post) that may access actions would work. So those paths would then be duplicated in xwork.xml? Doesn't sound very appealing to me. Not quite. I was thinking more along the lines of this in xwork.xml: skins skin name=skin1/ skin name=skin2/ ... /skins That is a duplication. You have stuff in web.xml and xwork.xml about it. Plus, I don't quite see how the above would be used? Plus that could be extended to perhaps specify a default set of UI components for each skin or whatever. I think this sounds quite nice, web.xml configuration aside. default? Default for what? You'd have to describe this a whole lot more to make any sense. I don't see what this would do or how it would work. /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
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
[OS-webwork] Actions and Dialogs
In current WebWork the main focus is on actions. I miss the EXPLICIT implementation of the concept dialog. In my view a dialog is a finite state machine implementation (FSM), an action causes a state transition in the active state machine(s) (the (s) is because an application will usually contain layered state machines). I think this relates to my previous posting on reusing actions as current WebWork registers actions with their follow-up in views.properties, in the FSM model views.properties would register action bindings, which are unique (state machine plus action). I posted the above before, later I found an interesting link to a ready-to-run and free implementation of a FSM as dialog controller: http://www.jstatemachine.org/ In my view this approach is very clean and appropriate. --- 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 configuration XML [Commands]
On Thu, Jan 02, 2003 at 09:23:19PM +0100, Rickard Öberg wrote: Chris Nokleberg wrote: 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. I don't understand this logic. A property default is a default for form parameters, obviously it can change. If you want to fix the value for a particular mapping, you add it to actions.xml. The argument that it will hurt performance is really misleading IMHO. You're assuming a certain implementation. For one thing, since the parameters and values and destination classes are known ahead of time, you can pre-convert all of the values. etc., etc. -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] Re: Action invocation
On Fri, Jan 03, 2003 at 09:25:43AM +0100, Rickard Öberg wrote: Mike Cannon-Brookes wrote: 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. Then the action would be pinned to that particular path, and skinning wouldn't work. That way you keep .action, AND your security works fine? Here's another way: define the roles that are allowed to access an action in xwork.xml, and create an interceptor that checks it. Then it can work exactly like how web.xml works, except it can do so for the case where an unsecure action calls a secure action too. That is a lot of extra machinery where pinning the action would work instead. Between skinning and support for declarative security, it seems to me the latter is wanted by more people. BTW, if interceptors had at least an optional URL-mapping component, you could do skinning via /* - DefaultSkinInterceptor /bar/* - BarSkinInterceptor I find it strange how on one hand you argue against triggering functionality based on URL-matching, but on the other hand argue for that exactly through your skinning examples. -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
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] Struts Converts
Hi Matt, Could you post your Struts comparison info into the Wiki (http://www.opensymphony.com:8668/space/WebWork)? The current WW docs don't really say anything substantive along this line. Thanks for the info. -Bill Matt Ho wrote: snip/ Here's an email I recently sent to a friend that compares the two. You might find it interesting: snip/ --- 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
FW: [OS-webwork] Re: Re: Action invocation
Did anyone have any thoughts on this skin / package config stuff I sent this morning? -Original Message- From: Jason Carreira Sent: Friday, January 03, 2003 9:47 AM To: '[EMAIL PROTECTED]' Subject: RE: [OS-webwork] Re: Re: Action invocation -Original Message- From: Rickard Öberg [mailto:[EMAIL PROTECTED]] Sent: Friday, January 03, 2003 6:06 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Re: Re: Action invocation Chris Miller wrote: What would happen if the skins had to be explicitly defined in the configuration, or if none were defined then XWork would default to pinned paths? Then there would be an outcry of too much to configure.. waaah. :-) What if we just had the skins defined either at a global level, or at a package by package level (or even down to the action, if needed). Sorry, I've forgotten the exact details of Rickard's XML config stuff skins skin name=default root=/WEB-INF/jsp/default/ skin name=neon root=/WEB-INF/jsp/neon/ /skins package name=default classes=com.example.actions skin=default view type=ERROR/WEB-INF/jsp/error.jsp/view action name=common class=CommonAction view type=INPUTcommon.jsp/view view type=SUCCESScommon.jsp/view /action /package package name=foo classes=com.example.actions.foo extends=default path=/foo action name=foo1 class=FooOne view type=INPUTfoo1.jsp/view view type=SUCCESSfoo1.jsp/view /action /package package name=neonfoo extends=foo path=/neon/ This shows a couple of ideas: 1) The skins are defined at the top and define the base path to look under for pages 2) Packages have paths which define the URL path under the webapp for which they apply (to make path based security easy) 3) Packages with no path are not directly executable, so you can have your default package which cannot be accessed, and only holds common config information for its children 4) Packages inherit from their parent packages, so that all 3 packages have a common action defined 5) The neon package has both common and foo1 actions defined, and needs to have JSPs under /WEB-INF/jsp/neon for error.jsp, common.jsp, and foo1.jsp --- 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
