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

Reply via email to