Re: [OS-webwork] XWork Interceptors
Patrick Lightbody wrote:
So anyway, I'm just going to disregard the Documentation thread and start
a thread that is actually useful :)
Good idea :-)
(Though, Ken, we're still hoping your willing to do some Doc work!)
Same here!
So besides Action Chaining, Rickard made a good point that interceptors is
very important as well. I'd like to talk about the actual implementation
now -- using the transaction scenario as an example.
How will the interceptor know when to rollback or commit? Of course on an
Exception it should, but what about on ERROR or INPUT? What if the action,
to signify it's is complete, used COMPLETE instead of SUCCESS? Do you see my
point? How can we make interceptors work for all cases? I'm guessing some
sort of configuration is needed for each interceptor on each action, so we
could do something like:
interceptor class=...
param name=commit.valuessuccess, complete/param
/interceptor
And then the interceptot could know to rollback if the return value isn't
one of those two.
Rickard, is this what you had in mind?
In this particular case I think it's best to look at how EJB works: for
any application result from a method invocation (e.g. void, some value,
an application exception) the transaction is committed. The transaction
is ONLY rollbacked if a) a runtime exception was thrown b)
setRollbackOnly() has been called. I.e. the interceptor does not need to
be configured.
So, what if you (for some reason) really do want ERROR to lead to a
rollback? Well, simply add an interceptor that on ERROR calls
setRollbackOnly, and have it after the tx interceptor (i.e. it is
invoked before the tx interceptor on the way back). Have *that*
interceptor be configurable, and add it whereever you want this kind of
behaviour. That way the tx interceptor itself is nice and clean, and you
can still get app-specific behaviour at some points.
Also, Interceptors would fit in to the GenericDispatcher area. I think that
they would replace ActionFactoryProxies entirely, correct?
Yup. In my XWork implementation ActionFactory is now just a class that
instantiates an action directly, and initializes the interceptor chain
for it. Everything that the AF proxies used to do is now in interceptors
that are executed on execute() invoke. This means that the
GenericDispatcher is typically not needed. Just do this:
Action action = ActionFactory.getAction(foo);
action.execute();
And this can be done *within* another action without problem.
Also, maybe
Rickard you can provide some sample psuedo code for an Interceptor as well
as how it would go about being invoked in GenericDispatcher?
As I said, I don't think GD is needed anymore. Here's an example
interceptor I wrote:
public class ParameterInterceptor
implements ActionInterceptor
{
// ActionInterceptor implementation --
public String execute(ActionInvocation invocation)
throws Exception
{
// Set parameters
TypeConverter typeConverter =
Configuration.getInstance().getAction(invocation.getName()).getTypeConverter();
OgnlUtil.setProperties(ActionContext.getContext().getParameters(),
invocation.getAction(), typeConverter);
return invocation.next();
}
}
--
This replaces the action factory that transfers servlet parameters to
the action. Pretty straightforward. Note that the ActionInvocation is a
temporary object, i.e. it contains request-specific information in
addition to the static interceptor chain.
/Rickard
--
Rickard Öberg
[EMAIL PROTECTED]
Senselogic
Got blog? I do. http://dreambean.com
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] URLTag changes in ww 1.3
I remember that it was asked in the mailing list if this change would affect a existing webapp. I remember also that I made a grep through our code and I didn't see that we used the url tag directly without a value attribute. BUT what was missed (I also did forget) was to make a grep though the webwork templates but anyway, does someone has a good idea how to solve this issue best? thanks -Paolo -Original Message- From: Joseph Ottinger [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 1:10 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] URLTag changes in ww 1.3 Diese Nachricht enthält Zeichen, die vom Internet-Dienst nicht unterstützt werden. Zum Lesen doppelklicken Sie auf die beigefügte Anlage. Falls der Text inkorrekt angezeigt wird, speichern Sie die Anlage (Datei, Speichern unter) auf der Festplatte und öffnen Sie sie mit einem Programm, das die Zeichen darstellen kann. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
[OS-webwork] XWork: core concepts
All, Since quite a few of you disagreed with my resignation as XWork architect, I've given some thought to how it would be possible to merge my requirements with those that you have. It might be possible to do it, and if so I would reconsider re-starting my work on XWork. I'd like to begin with defining the core concepts that XWork would have, and also briefly list my requirements, and see what your thoughts on them are. The core concepts that I think must be included are the following: * Actions. These are the application implementations (generic or specific) that together define the behaviour of the application. No news here. * Interceptors. These are cross-cutting concerns that apply to several actions, and which may modify the behaviour of it, produce some side-effect to the execution of the Action, or modify the input or output of the Action. * Components. This is a new concept for WebWork. Instead of just having a bunch of non-related Action's, one would bundle some of them together into a Component. An Action may be part of several Components though. The main feature of a Component is to function as a state machine which determine what Action to execute during a page rendering. * Packages. Also a new concept. There are usually two approaches to configuration: coarse-grained or fine-grained. In the coarse-grained style a setting applies to EVERYTHING in the app. In the fine-grained style each part needs to be individually configured. The first focus on ease-of-use and the latter on flexibility. Packages allow for something in between. An Action, Interceptor or Component can be defined in a Package and can easily refer to one another within that package. By having hierarchical packages can easily refer to definitions in other Packages. For example, we would most likely define a number of Actions, Interceptors and possible Components that are in a default Package, which user Packages would then depend on. However, user Packages could then override any such definition made higher up. This gives the ease-of-use of a coarse-grained configuration together with the total control and flexibility of a fine-grained configuration, while still providing reasonably clear semantics. These are the core concepts that I can think of. Now, for my own portlet-ish needs (which I hope will be more common for others too in the future) the following applies: * Actions and Components, and their resulting views, are ALWAYS called through a servlet include. This means that the URL in a browser NEVER reveals that XWork is used. For example, an admin app would consist of an admin.jsp which includes the Actions/Components needed for that app. Not only does that make it easy to extend the admin app later on with more portlets, it also makes it possible (for those who are so inclined) to use J2EE declarative security very easily. Plus bookmarks are human-friendly. This means that the dispatcher would explicitly disallow Action invocation that are NOT a result of an include. This too adds some extra security, since only actions that YOU decide should be called are actually callable. Plus, your actions can decide much better in what order they are called, depending on your app requirements. The actual include would still be using the .action extension though. * For many simple portlets an include of a .action is fine. For complex portlets that require a state machine this is not ok. Instead, what one usually wants is to include a component that then delegates to some action depending on the *state* of some automata. This is similar to how the CardPane works in WebWork. Essentially, XWork would include this kind of state machine as a built-in concept instead of as an add-on like CardPane, since this is such an important and common case. It needs to be as simple and flexible as is possible. When a component renders its view it also creates URL's that define what the possible next states are. This means that the URL's in the generated HTML are shortlived (i.e. after one of the URL's have been clicked they are all invalid), which also means that it will be impossible to have a double form submit. After the first submit the URL will be invalid, so clicking again will not lead to a re-execution of the action. This also gives some extra security. * The execution of a Component (and maybe Action's too) needs to be split into two phases. The actual execution of an action is done at the *beginning* of a page render, and the rendering is done at the time of the include. Why? Because the action may influence what is shown on the page, and may also result in a redirect to another page. If the action execution is done at the point of the include it's too late to do a redirect, and other portlets may have rendered state that is then changed by the action execution. (This thinking, by coincidence, mirrors well how the portlet API will work) * When rendering URL's, the
Re: [OS-webwork] XWork Interceptors
Quoting Rickard Öberg [EMAIL PROTECTED]: Hani Suleiman wrote: Well, we're not talking about writing a tx system here, just providing the calls to begin/commit/rollback. And that's definitely a good idea to put here, especially if you're doing a straight servlets/db application, i.e. no EJB's to do the tx demarcation. And even if you *do* use EJB, sometimes it's better to do tx demarcation at this level instead of introducing a new session bean just to be able to do tx mgmt for a set of operations. Sure, however, please do keep in mind that many people do choose to use EJB's for the tx stuff. Session beans really are great for that kind of thing. I realise that you and others have much against EJBs, and that's fair enough, but I was just voicing the sentiment that I don't want xwork to become a framework that aims to replace EJBs. Hani --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] XWork Interceptors
Hani Suleiman wrote: Sure, however, please do keep in mind that many people do choose to use EJB's for the tx stuff. Session beans really are great for that kind of thing. I realise that you and others have much against EJBs, and that's fair enough, but I was just voicing the sentiment that I don't want xwork to become a framework that aims to replace EJBs. For those who want to use EJB's to do the tx demaraction, you'd simply remove the tx interceptor. /Rickard --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] XWork Interceptors
For those who want to use EJB's to do the tx demaraction, you'd simply remove the tx interceptor. Or, another way to put what Rickard said is: For those who don't want to use EJB's to do the tx demarcation, you'd simply add the tx interceptor. ;) --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] XWork Interceptors
No, of course not. Transactions are just a good base case because they are a type of interceptor that works on both sides of the action (before and after) and behavior can change based on possible configurations, changes in the action contex, etc. -Pat - Original Message - From: Hani Suleiman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 10, 2003 2:37 AM Subject: Re: [OS-webwork] XWork Interceptors Quoting Rickard Öberg [EMAIL PROTECTED]: Hani Suleiman wrote: Well, we're not talking about writing a tx system here, just providing the calls to begin/commit/rollback. And that's definitely a good idea to put here, especially if you're doing a straight servlets/db application, i.e. no EJB's to do the tx demarcation. And even if you *do* use EJB, sometimes it's better to do tx demarcation at this level instead of introducing a new session bean just to be able to do tx mgmt for a set of operations. Sure, however, please do keep in mind that many people do choose to use EJB's for the tx stuff. Session beans really are great for that kind of thing. I realise that you and others have much against EJBs, and that's fair enough, but I was just voicing the sentiment that I don't want xwork to become a framework that aims to replace EJBs. Hani --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] XWork Interceptors
For those who want to use EJB's to do the tx demaraction, you'd simply remove the tx interceptor. You mean not add it, I hope. The basic configuration should imho be as clean as possible. Anders Hovmöller [EMAIL PROTECTED] http://boxed.killingar.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] XWork: core concepts
On Fri, Jan 10, 2003 at 10:59:06AM +0100, Rickard Öberg wrote: These are the core concepts that I can think of. Now, for my own portlet-ish needs (which I hope will be more common for others too in the future) the following applies: * Actions and Components, and their resulting views, are ALWAYS called through a servlet include. This means that the URL in a browser NEVER reveals that XWork is used. [...] Just to make it clear: This is your needs, right? It doesn't prevents us from having a filter or servlet based dispatcher like webwork has now, right? They could even live happily together with one mapped to *.action and the other mapped to sth. else. My needs include a dispatcher like the current, so I'm happy to work on providing one. -billy. -- Meisterbohne Söflinger Straße 100 Tel: +49-731-399 499-0 eLösungen 89077 Ulm Fax: +49-731-399 499-9 msg01116/pgp0.pgp Description: PGP signature
RE: [OS-webwork] XWork Interceptors
As I said, I don't think GD is needed anymore. Here's an example
interceptor I wrote:
public class ParameterInterceptor
implements ActionInterceptor
{
// ActionInterceptor implementation --
public String execute(ActionInvocation invocation)
throws Exception
{
// Set parameters
TypeConverter typeConverter =
Configuration.getInstance().getAction(invocation.getName()).ge
tTypeConverter();
OgnlUtil.setProperties(ActionContext.getContext().getParameters(),
invocation.getAction(), typeConverter);
return invocation.next();
}
}
I'm not so sure about this case. In this case, you need to map the
interceptor to your classes, rather than it being the default. Yes, we
can work on packages and interceptor defaults, but the fact remains that
if you leave one line out of your xwork.xml, all of a sudden request
params don't get set on your actions which equals lots of confused
emails to the list.
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] XWork Interceptors
Typo. Rickard Öberg wrote: When configuring actions you don't typically specify individual actions, ...individual interceptors, --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
[OS-webwork] sorting collections
Title: sorting collections
My Action class has a method getCars() that returns a collection of Car objects.
The Car class has a method getMake(), along with several others.
I'd like to output a sorted table of the cars in my JSP, sorted on the make.
Here's what I tried.
table
webwork:bean name='webwork.util.Sorter' id=sorter/
iterator:sort source=cars comparator=@sorter/ascending('make')
webwork:iterator
tr
tdwebwork:property value=make//td
... other properties output here ...
/tr
/webwork:iterator
/iterator:sort
/table
I get a ClassCastException from webwork.util.MakeIterator.
I'm pretty sure it doesn't like the source attribute on the iterator:sort tag.
Can someone speculate as to what I'm doing wrong?
***
WARNING: All e-mail sent to and from this address will be received or
otherwise recorded by the A.G. Edwards corporate e-mail system and is
subject to archival, monitoring or review by, and/or disclosure to,
someone other than the recipient.
RE: [OS-webwork] Enhancements to Jasper Reports
On Sat, 2003-01-11 at 01:28, James Cook wrote: Is JasperReports already integrated as a view technology in 1.3? I saw some documentation regarding its use in WebWork. Yes. I've committed some enhancements to CVS that do more and I'll get around to updating the example code and documentation over the next couple of days. -- Peter Kelley [EMAIL PROTECTED] Moveit Pty Ltd --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] XWork: core concepts
Rickard, These are great, I've placed them on the Wiki (Which is now linked from the main site, yay!). -Pat - Original Message - From: Rickard Ã-berg [EMAIL PROTECTED] To: WebWork [EMAIL PROTECTED] Sent: Friday, January 10, 2003 1:59 AM Subject: [OS-webwork] XWork: core concepts All, Since quite a few of you disagreed with my resignation as XWork architect, I've given some thought to how it would be possible to merge my requirements with those that you have. It might be possible to do it, and if so I would reconsider re-starting my work on XWork. I'd like to begin with defining the core concepts that XWork would have, and also briefly list my requirements, and see what your thoughts on them are. The core concepts that I think must be included are the following: * Actions. These are the application implementations (generic or specific) that together define the behaviour of the application. No news here. * Interceptors. These are cross-cutting concerns that apply to several actions, and which may modify the behaviour of it, produce some side-effect to the execution of the Action, or modify the input or output of the Action. * Components. This is a new concept for WebWork. Instead of just having a bunch of non-related Action's, one would bundle some of them together into a Component. An Action may be part of several Components though. The main feature of a Component is to function as a state machine which determine what Action to execute during a page rendering. * Packages. Also a new concept. There are usually two approaches to configuration: coarse-grained or fine-grained. In the coarse-grained style a setting applies to EVERYTHING in the app. In the fine-grained style each part needs to be individually configured. The first focus on ease-of-use and the latter on flexibility. Packages allow for something in between. An Action, Interceptor or Component can be defined in a Package and can easily refer to one another within that package. By having hierarchical packages can easily refer to definitions in other Packages. For example, we would most likely define a number of Actions, Interceptors and possible Components that are in a default Package, which user Packages would then depend on. However, user Packages could then override any such definition made higher up. This gives the ease-of-use of a coarse-grained configuration together with the total control and flexibility of a fine-grained configuration, while still providing reasonably clear semantics. These are the core concepts that I can think of. Now, for my own portlet-ish needs (which I hope will be more common for others too in the future) the following applies: * Actions and Components, and their resulting views, are ALWAYS called through a servlet include. This means that the URL in a browser NEVER reveals that XWork is used. For example, an admin app would consist of an admin.jsp which includes the Actions/Components needed for that app. Not only does that make it easy to extend the admin app later on with more portlets, it also makes it possible (for those who are so inclined) to use J2EE declarative security very easily. Plus bookmarks are human-friendly. This means that the dispatcher would explicitly disallow Action invocation that are NOT a result of an include. This too adds some extra security, since only actions that YOU decide should be called are actually callable. Plus, your actions can decide much better in what order they are called, depending on your app requirements. The actual include would still be using the .action extension though. * For many simple portlets an include of a .action is fine. For complex portlets that require a state machine this is not ok. Instead, what one usually wants is to include a component that then delegates to some action depending on the *state* of some automata. This is similar to how the CardPane works in WebWork. Essentially, XWork would include this kind of state machine as a built-in concept instead of as an add-on like CardPane, since this is such an important and common case. It needs to be as simple and flexible as is possible. When a component renders its view it also creates URL's that define what the possible next states are. This means that the URL's in the generated HTML are shortlived (i.e. after one of the URL's have been clicked they are all invalid), which also means that it will be impossible to have a double form submit. After the first submit the URL will be invalid, so clicking again will not lead to a re-execution of the action. This also gives some extra security. * The execution of a Component (and maybe Action's too) needs to be split into two phases. The actual execution of an action is done at the *beginning* of a page render, and the rendering is done at the time of the include. Why? Because the action may influence what is shown on the page, and may also result in a redirect to another
