Re: [OS-webwork] Rethink
Patrick Lightbody wrote: I can apply some real-world examples here: I'm in a screen that is updating document metadata, and the form submits to UpdateMetadata.action. But UpdateMetadata.action is actually an alias for a complex chain: ValidateMetadata - BeginTx - StoreMetadata - CommitTx - StoreMetadataInHtmlFiles - LoadMetadata - showmetadata.jsp Well, that could then probably be rewritten as: ValidateMetadataProxy - TxProxy - StoreMetadataInHtmlFilesProxy - StoreMetadata action where SUCCESS = showmetadata.jsp and the JSP has an action tag pointing to LoadMetadata. Much nicer. Less code. Are there any other cases where the side-effects *should be* real actions, or could all of those be rewritten with action proxies? /Rickard --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
[OS-webwork] Debugging webwork
Can anybody tell him how they currently have webwork set up in their ide's? Is it possible to run a servlet container and debug webwork from within eclipse or Idea? --- 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] Debugging webwork
Is it possible to run a servlet container and debug webwork from within eclipse or Idea? Yes of course, it's just like any other remote debugging in java. I use resin and they have a description on how to set this up on their homepage. It's basically just starting the JVM with remote debugging enabled and then have your IDE connect to it. Anders Hovmöller [EMAIL PROTECTED] http://boxed.killingar.net --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Rethink
By all means, go for it! - Original Message - From: Rickard Öberg [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, December 31, 2002 1:21 AM Subject: Re: [OS-webwork] Rethink Patrick Lightbody wrote: Yeah, doesn't yet, but the plan is to add that in soon. Tonight I'll make the code quicker and then start incorporating Rickards ideas. Well, since this is looking more and more like a lightweight version of my AOP framework I can do the interceptor/XML fixes myself, if that's ok with you. /Rickard --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
[OS-webwork] Code in Servlet Dispatcher?
From what I can see the following lines don't do anything. // Get action String servletPath = (String) aRequest.getAttribute(javax.servlet.include.servlet_path); if (servletPath == null) servletPath = aRequest.getServletPath(); // Path is always original path, even if it is included in page with another path String actionPath = aRequest.getServletPath(); actionPath = actionPath.substring(0, actionPath.lastIndexOf(/) + 1); String actionName = getActionName(servletPath); actionPath is never used. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Rethink
On Tue, Dec 31, 2002 at 10:21:21AM +0100, Rickard Öberg wrote: Patrick Lightbody wrote: Yeah, doesn't yet, but the plan is to add that in soon. Tonight I'll make the code quicker and then start incorporating Rickards ideas. Well, since this is looking more and more like a lightweight version of my AOP framework I can do the interceptor/XML fixes myself, if that's ok with you. I think it would be more useful if instead of applying directly to actions, the filters/interceptors applied to paths (URLs). The paths could support wildcards, either Servlet-style or a more complete regexp style. e.g. define secure = persist, security, execute define open = standard - security map /* = open map /admin/* = secure (but probably in xml) There would need to be some thought about how to combine stacks of interceptors, path matching precedence, etc. This is probably best done in conjuction with nailing down actions to specific paths. -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] Ognl as replacement for WW EL
Write a script. 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 Hani Suleiman Sent: Sunday, December 29, 2002 10:30 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Ognl as replacement for WW EL On Sunday, December 29, 2002, at 10:20 PM, Patrick Lightbody wrote: However, by using Ognl we gain not having to maintian our own EL and a whole bunch of speed, as well as more powerful features (Ognl can even do lamba expressions). The only cost is switching your brain to use . instead of / and [1] instead of ../. Err, and also the cost of switching however many pages you've chosen to commit to webwork for. So if you've chosen to use webwork for a few hundred of your pages, the 'cost' of upgrading will be to manually go through every single page and change it. Some users might end up being rather cheesed off at having to make such a change. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Rethink
Along this line, I've mentioned before that one of the top requirements I've got for a framework, and we're hopefully going to be switching to a new (better) framework in the next few months, is the ability to use J2EE declarative security to secure paths. This means that the way actions are invoked needs to be rethought. Currently, there's no way to keep people from executing your actions without creating a separate J2EE declarative security entry for each action (and each alias, etc). This is, IMHO, a HUGE drawback. Jason -Original Message- From: Chris Nokleberg [mailto:[EMAIL PROTECTED]] I think it would be more useful if instead of applying directly to actions, the filters/interceptors applied to paths (URLs). The paths could support wildcards, either Servlet-style or a more complete regexp style. e.g. define secure = persist, security, execute define open = standard - security map /* = open map /admin/* = secure (but probably in xml) There would need to be some thought about how to combine stacks of interceptors, path matching precedence, etc. This is probably best done in conjuction with nailing down actions to specific paths. -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] context and pre/post processing
Wow, I'm just reading through the posts in this list (got a little behind) and this is
AWESOME. This definitely should be done.
-Original Message-
From: Rickard Öberg [mailto:[EMAIL PROTECTED]]
Sent: Monday, December 30, 2002 3:31 AM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] context and pre/post processing
Patrick Lightbody wrote:
In your last email you talked about changes in the context and
pre/post processing. I think I know what you are hinting at (simply
the ActionFactory and move the work in the Action implementation
itself), but maybe you can go in to more detail here? Also, how could
it be an alternative way of chaining?
As I've been working a LOT with AOP lately some of the ideas could be
easily applied here too. One of the ideas is the generic interceptor
chain, i.e. to chain a bunch of proxies together and start it by simply
invoking the first.
For example:
Action myAction = ActionFactory.getAction(foo); myAction.execute();
---
Action getAction(String name)
{
return new SecureAction(new ChainAction(new FooAction()));
}
---
public class SecureAction
extends ActionProxy
{
public SecureAction(Action nextAction)
{
this.next = nextAction;
}
public String execute()
throws Exception
{
// Do security check
// Delegate to next
return next.execute();
}
}
---
I hope the basic idea is obvious. Some chaining could be done by simply
having proxies do stuff either before or after the execute() invocation.
Having such things be proxies instead of actions separates them from
real actions as they should typically not influence the result string
(i.e. they have side-effects but don't effect the flow). Of course, just
as servlet filters *can* return immediately instead of delegating to the
next servlet, proxies can shortcut the flow here too (the SecureAction
would be one example, which would return unauthorized if the executor
is not allowed to call the action.
The ChainAction would be used to transfer parameters when a chain is
executing. Like so:
ThreadLocal previousAction = new ThreadLocal();
public String execute()
throws Exception
{
Object previous = previousAction.get();
if (previous != null)
// Copy parameters from previous to current
previousAction.set(currentTargetAction);
try
{
return next.execute();
} finally
{
if (previous != null)
previousAction.set(previous);
}
}
---
This would allow the action itself to call other actions in its
execute() method and have parameters be transferred transparently: public String
execute()
throws Exception
{
Action myAction1 = ActionFactory.getAction(foo1);
Action myAction2 = ActionFactory.getAction(foo2);
myAction1.execute();
myAction2.execute();
return SUCCESS;
}
--
Both the above actions would have secured execution (thanks to
SecureAction) and copied parameters from the parent, and with very
little work. The action can then also decide whether to ignore what they
return, or to return SUCCESS iff all actions succeed. A helper can
easily run them in parallel. Etc. There are LOTS of possibilities here,
but the main point is that the code would be very clean.
And, the old way to do augmented actions was to do a subclass and
override execute(), do stuff (e.g. security checks), then do
super.execute() which in turn could do things, and finally call
doExecute(). That is (obviously?) a rather cumbersome, static, and
generally boring way to do things, and I think using action proxy chains
would be both easier and more dynamic. Plus, they could be configured in
XML instead of specified explicitly through inheritance.
And, once you get into runtime attributes (which I have, courtesy of the
AOP framework I'm fiddling with) it gets even cooler, because then you
can configure the chain by using attributes. Like so:
/**
* @attributes
*filters=secure,chain,validation
*success=blah.vm
*error=failure.vm
*/
---
And if you feel like the above is providing too much info in code then
simply introduce pre-packaged stacks:
config
filters name=standard
filter name=secure/
filter name=chain/
filter name=validation/
/filters
/config
along with the runtime attribute definition:
/**
* @attributes
*filters=standard
*/
(BTW, I can *guarantee* you that before long we're going to see runtime
attributes being pushed into IDE's rather than having them as Javadoc,
so it's going to be really truly awesome)
and if you want to go really funky then redefine stacks like so: config
filters name=standard
filter name=mycustomfilter/
filters name=defaultstandard/
/filters
filters name=defaultstandard
filter name=secure/
filter name=chain/
filter name=validation/
/filters
/config
and without changing any code/javadoc you just changed the way all
actions that use the standard filter stack works. Pretty neat.
Have you
