Re: [OS-webwork] EL Performance Between 1.3 and 2.0
Drew McAuliffe wrote: That's consistent with numbers I've found in migrating one app from 1.3 to 2.0. I've always held out hope that this was just something that optimization could take care of. In the meantime, my performance isn't terrible, but it doesn't fly like it did in 1.3, either. Here's hoping the optimization works! I'd offer help except I'm terrible at profiling. If you identify things that profiling indicates need work and need someone to handle some grunt work, let me know. I'm eager to get my old performance back. If you want a good profiler to test with I can really really really really recommend JProfiler. The latest version is a dream to work with. regards, Rickard --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Problems with code after actionInvocation.invoke()
what if instead of having another Interceptor class we can just add a
new method to the Interceptor interface like beforeResult() ?
Jason Carreira wrote:
I've just checked in the code for PreResultListener to XW/WW2... No
changes to Interceptor base classes, etc... You guys try this out and
see how you like it and how you're using it.
PreResultListener is an Interface, with one method:
void beforeResult(ActionInvocation invocation, String resultCode);
So don't limit yourself to just registering Interceptors which implement
this Interface That was just off the top of my head.
For now, I don't want to change the AroundInterceptor, since if they
don't need it it's just extra overhead to register the listeners and
call back to them for nothing... After some people start using them and
we see how they're useful we can standardize usage in base classes.
Jason
-Original Message-
From: Drew McAuliffe [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 13, 2003 11:48 PM
To: [EMAIL PROTECTED]
Subject: RE: [OS-webwork] Problems with code after
actionInvocation.invoke()
Scratch my last comment; your example is exactly what I had
in mind as a new superclass to use for this kind of
functionality. I think such a superclass would be a great
addition to the framework, though it would have to be
documented very well so that the difference between before,
beforeResult, and after is explicitly clear This is
especially important considering the fact that the
JSP/velocity pages are already loaded before after() gets
called; that wasn't immediately apparent to me, and I'd
imagine I'm not alone.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Jason Carreira
Sent: Thursday, November 13, 2003 5:55 PM
To: [EMAIL PROTECTED]
Subject: RE: [OS-webwork] Problems with code after
actionInvocation.invoke()
No, it would be like this:
Public class MyInterceptor implements Interceptor, PreResultListener {
Public String intercept(ActionInvocation invocation) {
invocation.addPreResultListener(this);
String result;
before();
result = invocation.invoke();
after();
return result;
}
Public void beforeResult(ActionInvocation invocation) {
// do something before the result executes }
}
So it would be like this:
Interceptor1.before()
Interceptor2.before()
Action.execute()
Interceptor1.beforeResult()
Interceptor2.beforeResult()
Result.execute()
Interceptor2.after()
Interceptor2.after()
Assuming both of these interceptors implemented
PreResultListener and registered themselves with the ActionInvocation.
Jason
-Original Message-
From: Francisco Hernandez [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 13, 2003 6:40 PM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] Problems with code after
actionInvocation.invoke()
so let me get this straight with PreResultListener would be able to
have interceptors work before/after execute before the Result gets
called?
that way we can have a flow like this using regular interceptors and
also PreResultInterceptors:
before0
PreResultbefore1
PreResultbefore2
execute
PreResultafter2
PreResultafter1
executeResult
after0
am i understanding this correctly?
Jason Carreira wrote:
Yes, this is the intended behavior.
The issue is that Interceptors are stateless, so you can't do:
Intercept() - before - execute - after
Dispose()
Because your Interceptor can't keep request specific state to be
disposed in another call...
I'm wondering if it would be a good idea to have an
Observer pattern
in here... PreResultListener.beforeResult(ActionInvocation
invocation)... Then Interceptors that want to be notified
before the
Result could register with the ActionInvocation to have a
callback...
This shouldn't affect any of the current code, and would
just allow
for one more lifecycle point.. Thoughts?
-Original Message-
From: Daniel Pfeifer [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 13, 2003 11:06 AM
To: '[EMAIL PROTECTED]'
Subject: [OS-webwork] Problems with code after
actionInvocation.invoke()
I am currently having trouble with a custom interceptor. The
Interceptor is supposed to determine which values to set on the
ValueStack by the resultstring it receives from
actionInvocation.invoke(). The problem is: Once
actionInvocation.invoke() is executed the whole flow is executed,
even the ServletDispatcherResult is executed and thus the
JSP page
is already loaded before my interceptor had a chance to
modify some
invocation result based values.
Is this the standard behaviour of Webwork 2.0 (latest CVS
checkout) or should I file a bugreport in JIRA? If this is the
standard behaviour the reason for an after() in
AroundInterceptor is
beyond my comprehension (other than possibly doing some
clean-up and
in that case it should be called something like dispose()).
Thanks in advance,
/Daniel
---
This SF.Net email sponsored by: ApacheCon 2003,
Re: [OS-webwork] Problems with code after actionInvocation.invoke()
I think that this is a better idea.
AroundInterceptor could have an empty implementation for this method...
simple :)
Cameron
Francisco Hernandez wrote:
what if instead of having another Interceptor class we can just add a
new method to the Interceptor interface like beforeResult() ?
Jason Carreira wrote:
I've just checked in the code for PreResultListener to XW/WW2... No
changes to Interceptor base classes, etc... You guys try this out and
see how you like it and how you're using it.
PreResultListener is an Interface, with one method:
void beforeResult(ActionInvocation invocation, String resultCode);
So don't limit yourself to just registering Interceptors which implement
this Interface That was just off the top of my head.
For now, I don't want to change the AroundInterceptor, since if they
don't need it it's just extra overhead to register the listeners and
call back to them for nothing... After some people start using them and
we see how they're useful we can standardize usage in base classes.
Jason
-Original Message-
From: Drew McAuliffe [mailto:[EMAIL PROTECTED] Sent: Thursday,
November 13, 2003 11:48 PM
To: [EMAIL PROTECTED]
Subject: RE: [OS-webwork] Problems with code after
actionInvocation.invoke()
Scratch my last comment; your example is exactly what I had in mind
as a new superclass to use for this kind of functionality. I think
such a superclass would be a great addition to the framework, though
it would have to be documented very well so that the difference
between before, beforeResult, and after is explicitly clear This is
especially important considering the fact that the JSP/velocity
pages are already loaded before after() gets called; that wasn't
immediately apparent to me, and I'd imagine I'm not alone.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of Jason Carreira
Sent: Thursday, November 13, 2003 5:55 PM
To: [EMAIL PROTECTED]
Subject: RE: [OS-webwork] Problems with code after
actionInvocation.invoke()
No, it would be like this:
Public class MyInterceptor implements Interceptor, PreResultListener {
Public String intercept(ActionInvocation invocation) {
invocation.addPreResultListener(this);
String result;
before();
result = invocation.invoke();
after();
return result;
}
Public void beforeResult(ActionInvocation invocation) {
// do something before the result executes }
}
So it would be like this:
Interceptor1.before()
Interceptor2.before()
Action.execute()
Interceptor1.beforeResult()
Interceptor2.beforeResult()
Result.execute()
Interceptor2.after()
Interceptor2.after()
Assuming both of these interceptors implemented PreResultListener
and registered themselves with the ActionInvocation.
Jason
-Original Message-
From: Francisco Hernandez [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 13, 2003 6:40 PM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] Problems with code after
actionInvocation.invoke()
so let me get this straight with PreResultListener would be able to
have interceptors work before/after execute before the Result gets
called?
that way we can have a flow like this using regular interceptors and
also PreResultInterceptors:
before0
PreResultbefore1
PreResultbefore2
execute
PreResultafter2
PreResultafter1
executeResult
after0
am i understanding this correctly?
Jason Carreira wrote:
Yes, this is the intended behavior.
The issue is that Interceptors are stateless, so you can't do:
Intercept() - before - execute - after
Dispose()
Because your Interceptor can't keep request specific state to be
disposed in another call...
I'm wondering if it would be a good idea to have an
Observer pattern
in here... PreResultListener.beforeResult(ActionInvocation
invocation)... Then Interceptors that want to be notified
before the
Result could register with the ActionInvocation to have a
callback...
This shouldn't affect any of the current code, and would
just allow
for one more lifecycle point.. Thoughts?
-Original Message-
From: Daniel Pfeifer [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 13, 2003 11:06 AM
To: '[EMAIL PROTECTED]'
Subject: [OS-webwork] Problems with code after
actionInvocation.invoke()
I am currently having trouble with a custom interceptor. The
Interceptor is supposed to determine which values to set on the
ValueStack by the resultstring it receives from
actionInvocation.invoke(). The problem is: Once
actionInvocation.invoke() is executed the whole flow is executed,
even the ServletDispatcherResult is executed and thus the
JSP page
is already loaded before my interceptor had a chance to
modify some
invocation result based values.
Is this the standard behaviour of Webwork 2.0 (latest CVS
checkout) or should I file a bugreport in JIRA? If this is the
standard behaviour the reason for an after() in
AroundInterceptor is
beyond my comprehension (other than possibly doing some
clean-up and
in that case it should be called
Re: [OS-webwork] EL Performance Between 1.3 and 2.0
Just out of curiosity, did you measure against the released version of 1.3 or the CVS version? Did you use JSP or Velocity for presentation? Could you perhaps post your testcases here so that we may have a look at them and perhaps try them ourselves? Best regards, Dick Zetterberg [EMAIL PROTECTED] - Original Message - From: Patrick Lightbody [EMAIL PROTECTED] To: WebWork [EMAIL PROTECTED] Sent: Friday, November 14, 2003 4:43 AM Subject: [OS-webwork] EL Performance Between 1.3 and 2.0 I've finished the backwards support for the 1.3 EL and have migrated the first mini-app over from 1.3 to 2.0 with almost zero effort: the monthlist test. I wanted to share the performance numbers: * WebWork 1.3 scored 80ms * WebWork 2.0 w/ old EL support scored 550ms * WebWork 2.0 w/ new EL scored 300ms I'm not really worried about the old EL support, as I can speed up in a few areas (especially by caching the Pattern objects used in the regex logic). However, the 3X - 4X speed decrease is certainly not good. I expect the new EL to be a bit slower given new features added (type conversion requires evaluation tracing). My target is no more than a 10% slowdown. Anyway, I'll be working on this for the next couple of days. -Pat --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Problems with code after actionInvocation.invoke()
I think that this is a better idea.
AroundInterceptor could have an empty implementation for this method...
simple :)
Cameron
Francisco Hernandez wrote:
what if instead of having another Interceptor class we can just add a
new method to the Interceptor interface like beforeResult() ?
Jason Carreira wrote:
I've just checked in the code for PreResultListener to XW/WW2... No
changes to Interceptor base classes, etc... You guys try this out and
see how you like it and how you're using it.
PreResultListener is an Interface, with one method:
void beforeResult(ActionInvocation invocation, String resultCode);
So don't limit yourself to just registering Interceptors which implement
this Interface That was just off the top of my head.
For now, I don't want to change the AroundInterceptor, since if they
don't need it it's just extra overhead to register the listeners and
call back to them for nothing... After some people start using them and
we see how they're useful we can standardize usage in base classes.
Jason
-Original Message-
From: Drew McAuliffe [mailto:[EMAIL PROTECTED] Sent: Thursday,
November 13, 2003 11:48 PM
To: [EMAIL PROTECTED]
Subject: RE: [OS-webwork] Problems with code after
actionInvocation.invoke()
Scratch my last comment; your example is exactly what I had in mind
as a new superclass to use for this kind of functionality. I think
such a superclass would be a great addition to the framework, though
it would have to be documented very well so that the difference
between before, beforeResult, and after is explicitly clear This is
especially important considering the fact that the JSP/velocity
pages are already loaded before after() gets called; that wasn't
immediately apparent to me, and I'd imagine I'm not alone.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of Jason Carreira
Sent: Thursday, November 13, 2003 5:55 PM
To: [EMAIL PROTECTED]
Subject: RE: [OS-webwork] Problems with code after
actionInvocation.invoke()
No, it would be like this:
Public class MyInterceptor implements Interceptor, PreResultListener {
Public String intercept(ActionInvocation invocation) {
invocation.addPreResultListener(this);
String result;
before();
result = invocation.invoke();
after();
return result;
}
Public void beforeResult(ActionInvocation invocation) {
// do something before the result executes }
}
So it would be like this:
Interceptor1.before()
Interceptor2.before()
Action.execute()
Interceptor1.beforeResult()
Interceptor2.beforeResult()
Result.execute()
Interceptor2.after()
Interceptor2.after()
Assuming both of these interceptors implemented PreResultListener
and registered themselves with the ActionInvocation.
Jason
-Original Message-
From: Francisco Hernandez [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 13, 2003 6:40 PM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] Problems with code after
actionInvocation.invoke()
so let me get this straight with PreResultListener would be able to
have interceptors work before/after execute before the Result gets
called?
that way we can have a flow like this using regular interceptors and
also PreResultInterceptors:
before0
PreResultbefore1
PreResultbefore2
execute
PreResultafter2
PreResultafter1
executeResult
after0
am i understanding this correctly?
Jason Carreira wrote:
Yes, this is the intended behavior.
The issue is that Interceptors are stateless, so you can't do:
Intercept() - before - execute - after
Dispose()
Because your Interceptor can't keep request specific state to be
disposed in another call...
I'm wondering if it would be a good idea to have an
Observer pattern
in here... PreResultListener.beforeResult(ActionInvocation
invocation)... Then Interceptors that want to be notified
before the
Result could register with the ActionInvocation to have a
callback...
This shouldn't affect any of the current code, and would
just allow
for one more lifecycle point.. Thoughts?
-Original Message-
From: Daniel Pfeifer [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 13, 2003 11:06 AM
To: '[EMAIL PROTECTED]'
Subject: [OS-webwork] Problems with code after
actionInvocation.invoke()
I am currently having trouble with a custom interceptor. The
Interceptor is supposed to determine which values to set on the
ValueStack by the resultstring it receives from
actionInvocation.invoke(). The problem is: Once
actionInvocation.invoke() is executed the whole flow is executed,
even the ServletDispatcherResult is executed and thus the
JSP page
is already loaded before my interceptor had a chance to
modify some
invocation result based values.
Is this the standard behaviour of Webwork 2.0 (latest CVS
checkout) or should I file a bugreport in JIRA? If this is the
standard behaviour the reason for an after() in
AroundInterceptor is
beyond my comprehension (other than possibly doing some
clean-up and
in that case it should be called
RE: [OS-webwork] Boo
It sounds good. -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] la part de Cameron Braid Envoye : vendredi 14 novembre 2003 01:33 A : Opensymphony-Webwork Objet : [OS-webwork] Boo Does anyone mind if I modify the XWorkBasicConverter to allow nulls for empty string Booleans (not booleans) Since if you have a Boolean action property.. you really have a tri state representation If you want a two state, use the primitive boolean, and nulls will become false. How does that sound ? Cameron -- Any damn fool can write code that a computer can understand... The trick is to write code that humans can understand. [Martin Fowler http://www.martinfowler.com/distributedComputing/refactoring.pdf] --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
[OS-webwork] Multiple submit buttons from forms
I used to have this working but it doesn't seem to anymore. I had a look at: http://wiki.opensymphony.com/space/Multiple+Submit+Buttons http://wiki.opensymphony.com/space/Webwork+2+HTML+form+buttons+Howto I've followed all their instructions but everytime my boolean setter gets called, the value is always false. I noticed my url has submit=Submit in it - is there a problem converting this value in to a boolean ? I'm using a newish version from CVS (taken earlier this week). Does anyone else have this working with a current version ? Thanks, Ben. ___ HPD Software Ltd. - Helping Business Finance Business Email terms and conditions: www.hpdsoftware.com/disclaimer --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Multiple submit buttons from forms
The XWorkBasicConverter now uses Boolean.valueOf() to convert Strings to
booleans. So only true is converted to the boolean true. I make my
action properties take a String value and no matter what the parameter is,
set the instance variable to true.
public void setCancel(String value)
{
_cancel = true;
}
John.
- Original Message -
From: Ben Hall [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, November 14, 2003 1:03 PM
Subject: [OS-webwork] Multiple submit buttons from forms
I used to have this working but it doesn't seem to anymore.
I had a look at:
http://wiki.opensymphony.com/space/Multiple+Submit+Buttons
http://wiki.opensymphony.com/space/Webwork+2+HTML+form+buttons+Howto
I've followed all their instructions but everytime my boolean setter gets
called, the value is always false.
I noticed my url has submit=Submit in it - is there a problem converting
this value in to a boolean ?
I'm using a newish version from CVS (taken earlier this week).
Does anyone else have this working with a current version ?
Thanks,
Ben.
___
HPD Software Ltd. - Helping Business Finance Business
Email terms and conditions: www.hpdsoftware.com/disclaimer
---
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
---
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RES: [OS-webwork] Boo
Title: RES: [OS-webwork] Boo +1 -Mensagem original- De: Fred Lamuette [mailto:[EMAIL PROTECTED]] Enviada em: sexta-feira, 14 de novembro de 2003 11:08 Para: [EMAIL PROTECTED] Assunto: RE: [OS-webwork] Boo It sounds good. -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]De la part de Cameron Braid Envoye : vendredi 14 novembre 2003 01:33 A : Opensymphony-Webwork Objet : [OS-webwork] Boo Does anyone mind if I modify the XWorkBasicConverter to allow nulls for empty string Booleans (not booleans) Since if you have a Boolean action property.. you really have a tri state representation If you want a two state, use the primitive boolean, and nulls will become false. How does that sound ? Cameron -- Any damn fool can write code that a computer can understand... The trick is to write code that humans can understand. [Martin Fowler http://www.martinfowler.com/distributedComputing/refactoring.pdf] --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Problems with code after actionInvocation.invoke()
I don't want to add it to the base class, since none of our current
bundled Interceptors need this. It should be easy enough for people who
need it to have their own base Interceptor class to do this (heck, I
wrote it for you in a previous message)...
-Original Message-
From: Cameron Braid [mailto:[EMAIL PROTECTED]
Sent: Friday, November 14, 2003 7:27 AM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] Problems with code after
actionInvocation.invoke()
I think that this is a better idea.
AroundInterceptor could have an empty implementation for this
method...
simple :)
Cameron
Francisco Hernandez wrote:
what if instead of having another Interceptor class we can
just add a
new method to the Interceptor interface like beforeResult() ?
Jason Carreira wrote:
I've just checked in the code for PreResultListener to
XW/WW2... No
changes to Interceptor base classes, etc... You guys try
this out and
see how you like it and how you're using it.
PreResultListener is an
Interface, with one method:
void beforeResult(ActionInvocation invocation, String resultCode);
So don't limit yourself to just registering Interceptors which
implement this Interface That was just off the top of my head.
For now, I don't want to change the AroundInterceptor,
since if they
don't need it it's just extra overhead to register the
listeners and
call back to them for nothing... After some people start
using them
and we see how they're useful we can standardize usage in base
classes.
Jason
-Original Message-
From: Drew McAuliffe [mailto:[EMAIL PROTECTED] Sent: Thursday,
November 13, 2003 11:48 PM
To: [EMAIL PROTECTED]
Subject: RE: [OS-webwork] Problems with code after
actionInvocation.invoke()
Scratch my last comment; your example is exactly what I
had in mind
as a new superclass to use for this kind of
functionality. I think
such a superclass would be a great addition to the
framework, though
it would have to be documented very well so that the difference
between before, beforeResult, and after is explicitly
clear This is
especially important considering the fact that the JSP/velocity
pages are already loaded before after() gets called; that wasn't
immediately apparent to me, and I'd imagine I'm not alone.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
On Behalf
Of Jason Carreira
Sent: Thursday, November 13, 2003 5:55 PM
To: [EMAIL PROTECTED]
Subject: RE: [OS-webwork] Problems with code after
actionInvocation.invoke()
No, it would be like this:
Public class MyInterceptor implements Interceptor,
PreResultListener
{
Public String intercept(ActionInvocation invocation) {
invocation.addPreResultListener(this);
String result;
before();
result = invocation.invoke();
after();
return result;
}
Public void beforeResult(ActionInvocation invocation) {
// do something before the result executes }
}
So it would be like this:
Interceptor1.before()
Interceptor2.before()
Action.execute()
Interceptor1.beforeResult()
Interceptor2.beforeResult()
Result.execute()
Interceptor2.after()
Interceptor2.after()
Assuming both of these interceptors implemented PreResultListener
and registered themselves with the ActionInvocation.
Jason
-Original Message-
From: Francisco Hernandez [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 13, 2003 6:40 PM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] Problems with code after
actionInvocation.invoke()
so let me get this straight with PreResultListener would
be able to
have interceptors work before/after execute before the
Result gets
called?
that way we can have a flow like this using regular interceptors
and also PreResultInterceptors:
before0
PreResultbefore1
PreResultbefore2
execute
PreResultafter2
PreResultafter1
executeResult
after0
am i understanding this correctly?
Jason Carreira wrote:
Yes, this is the intended behavior.
The issue is that Interceptors are stateless, so you can't do:
Intercept() - before - execute - after
Dispose()
Because your Interceptor can't keep request specific
state to be
disposed in another call...
I'm wondering if it would be a good idea to have an
Observer pattern
in here... PreResultListener.beforeResult(ActionInvocation
invocation)... Then Interceptors that want to be notified
before the
Result could register with the ActionInvocation to have a
callback...
This shouldn't affect any of the current code, and would
just allow
for one more lifecycle point.. Thoughts?
-Original Message-
From: Daniel Pfeifer [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 13, 2003 11:06 AM
To: '[EMAIL PROTECTED]'
Subject: [OS-webwork] Problems
RE: [OS-webwork] Problems with code after actionInvocation.invoke()
Gavin King has convinced me to take another look at this... Tonight I'll
look at creating another base class which has:
before()
beforeResult()
after()
handleException()
And will have a try/catch to allow you to be informed of Exceptions in
handleException().
AroundInterceptor will remain the simple class that it is...
-Original Message-
From: Jason Carreira
Sent: Friday, November 14, 2003 9:33 AM
To: [EMAIL PROTECTED]
Subject: RE: [OS-webwork] Problems with code after
actionInvocation.invoke()
I don't want to add it to the base class, since none of our
current bundled Interceptors need this. It should be easy
enough for people who need it to have their own base
Interceptor class to do this (heck, I wrote it for you in a
previous message)...
-Original Message-
From: Cameron Braid [mailto:[EMAIL PROTECTED]
Sent: Friday, November 14, 2003 7:27 AM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] Problems with code after
actionInvocation.invoke()
I think that this is a better idea.
AroundInterceptor could have an empty implementation for this
method...
simple :)
Cameron
Francisco Hernandez wrote:
what if instead of having another Interceptor class we can
just add a
new method to the Interceptor interface like beforeResult() ?
Jason Carreira wrote:
I've just checked in the code for PreResultListener to
XW/WW2... No
changes to Interceptor base classes, etc... You guys try
this out and
see how you like it and how you're using it.
PreResultListener is an
Interface, with one method:
void beforeResult(ActionInvocation invocation, String
resultCode);
So don't limit yourself to just registering Interceptors which
implement this Interface That was just off the top
of my head.
For now, I don't want to change the AroundInterceptor,
since if they
don't need it it's just extra overhead to register the
listeners and
call back to them for nothing... After some people start
using them
and we see how they're useful we can standardize usage in base
classes.
Jason
-Original Message-
From: Drew McAuliffe [mailto:[EMAIL PROTECTED] Sent:
Thursday,
November 13, 2003 11:48 PM
To: [EMAIL PROTECTED]
Subject: RE: [OS-webwork] Problems with code after
actionInvocation.invoke()
Scratch my last comment; your example is exactly what I
had in mind
as a new superclass to use for this kind of
functionality. I think
such a superclass would be a great addition to the
framework, though
it would have to be documented very well so that the difference
between before, beforeResult, and after is explicitly
clear This is
especially important considering the fact that the JSP/velocity
pages are already loaded before after() gets called;
that wasn't
immediately apparent to me, and I'd imagine I'm not alone.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
On Behalf
Of Jason Carreira
Sent: Thursday, November 13, 2003 5:55 PM
To: [EMAIL PROTECTED]
Subject: RE: [OS-webwork] Problems with code after
actionInvocation.invoke()
No, it would be like this:
Public class MyInterceptor implements Interceptor,
PreResultListener
{
Public String intercept(ActionInvocation invocation) {
invocation.addPreResultListener(this);
String result;
before();
result = invocation.invoke();
after();
return result;
}
Public void beforeResult(ActionInvocation invocation) { // do
something before the result executes }
}
So it would be like this:
Interceptor1.before()
Interceptor2.before()
Action.execute()
Interceptor1.beforeResult()
Interceptor2.beforeResult()
Result.execute()
Interceptor2.after()
Interceptor2.after()
Assuming both of these interceptors implemented
PreResultListener
and registered themselves with the ActionInvocation.
Jason
-Original Message-
From: Francisco Hernandez [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 13, 2003 6:40 PM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] Problems with code after
actionInvocation.invoke()
so let me get this straight with PreResultListener would
be able to
have interceptors work before/after execute before the
Result gets
called?
that way we can have a flow like this using regular
interceptors
and also PreResultInterceptors:
before0
PreResultbefore1
PreResultbefore2
execute
PreResultafter2
PreResultafter1
executeResult
after0
am i understanding this correctly?
Jason Carreira wrote:
Yes, this is the intended behavior.
The issue is that Interceptors are stateless, so you can't do:
Intercept() - before - execute - after
Dispose()
Because your Interceptor
Re: [OS-webwork] Problems with code after actionInvocation.invoke()
I know its a bit more radical... but it seems to me that a better solution
would be to move the code for dispatching to the appropriate result into its
own interceptor.
Then you don't need these lifecycle methods. And more importantly, it
eliminates this uncomfortable mix of some workflow is handled by
interceptors, while others are not.
Just a suggestion...
-Tim.
- Original Message -
From: Jason Carreira [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, November 14, 2003 10:07 AM
Subject: RE: [OS-webwork] Problems with code after actionInvocation.invoke()
Gavin King has convinced me to take another look at this... Tonight I'll
look at creating another base class which has:
before()
beforeResult()
after()
handleException()
And will have a try/catch to allow you to be informed of Exceptions in
handleException().
AroundInterceptor will remain the simple class that it is...
-Original Message-
From: Jason Carreira
Sent: Friday, November 14, 2003 9:33 AM
To: [EMAIL PROTECTED]
Subject: RE: [OS-webwork] Problems with code after
actionInvocation.invoke()
I don't want to add it to the base class, since none of our
current bundled Interceptors need this. It should be easy
enough for people who need it to have their own base
Interceptor class to do this (heck, I wrote it for you in a
previous message)...
-Original Message-
From: Cameron Braid [mailto:[EMAIL PROTECTED]
Sent: Friday, November 14, 2003 7:27 AM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] Problems with code after
actionInvocation.invoke()
I think that this is a better idea.
AroundInterceptor could have an empty implementation for this
method...
simple :)
Cameron
Francisco Hernandez wrote:
what if instead of having another Interceptor class we can
just add a
new method to the Interceptor interface like beforeResult() ?
Jason Carreira wrote:
I've just checked in the code for PreResultListener to
XW/WW2... No
changes to Interceptor base classes, etc... You guys try
this out and
see how you like it and how you're using it.
PreResultListener is an
Interface, with one method:
void beforeResult(ActionInvocation invocation, String
resultCode);
So don't limit yourself to just registering Interceptors which
implement this Interface That was just off the top
of my head.
For now, I don't want to change the AroundInterceptor,
since if they
don't need it it's just extra overhead to register the
listeners and
call back to them for nothing... After some people start
using them
and we see how they're useful we can standardize usage in base
classes.
Jason
-Original Message-
From: Drew McAuliffe [mailto:[EMAIL PROTECTED] Sent:
Thursday,
November 13, 2003 11:48 PM
To: [EMAIL PROTECTED]
Subject: RE: [OS-webwork] Problems with code after
actionInvocation.invoke()
Scratch my last comment; your example is exactly what I
had in mind
as a new superclass to use for this kind of
functionality. I think
such a superclass would be a great addition to the
framework, though
it would have to be documented very well so that the difference
between before, beforeResult, and after is explicitly
clear This is
especially important considering the fact that the JSP/velocity
pages are already loaded before after() gets called;
that wasn't
immediately apparent to me, and I'd imagine I'm not alone.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
On Behalf
Of Jason Carreira
Sent: Thursday, November 13, 2003 5:55 PM
To: [EMAIL PROTECTED]
Subject: RE: [OS-webwork] Problems with code after
actionInvocation.invoke()
No, it would be like this:
Public class MyInterceptor implements Interceptor,
PreResultListener
{
Public String intercept(ActionInvocation invocation) {
invocation.addPreResultListener(this);
String result;
before();
result = invocation.invoke();
after();
return result;
}
Public void beforeResult(ActionInvocation invocation) { // do
something before the result executes }
}
So it would be like this:
Interceptor1.before()
Interceptor2.before()
Action.execute()
Interceptor1.beforeResult()
Interceptor2.beforeResult()
Result.execute()
Interceptor2.after()
Interceptor2.after()
Assuming both of these interceptors implemented
PreResultListener
and registered themselves with the ActionInvocation.
Jason
-Original Message-
From: Francisco Hernandez [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 13, 2003 6:40 PM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] Problems with code
RE: [OS-webwork] Problems with code after actionInvocation.invoke()
This was the original design, but we were unable to adequately control
whether the results were executed or not (sometimes you don't want them
to be).
I'll take a look again and see if this would be possible (since it
really would simplify things a bit)...
Jason
-Original Message-
From: Tim Dwelle [mailto:[EMAIL PROTECTED]
Sent: Friday, November 14, 2003 10:40 AM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] Problems with code after
actionInvocation.invoke()
I know its a bit more radical... but it seems to me that a
better solution would be to move the code for dispatching to
the appropriate result into its own interceptor.
Then you don't need these lifecycle methods. And more
importantly, it eliminates this uncomfortable mix of some
workflow is handled by interceptors, while others are not.
Just a suggestion...
-Tim.
- Original Message -
From: Jason Carreira [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, November 14, 2003 10:07 AM
Subject: RE: [OS-webwork] Problems with code after
actionInvocation.invoke()
Gavin King has convinced me to take another look at this... Tonight
I'll look at creating another base class which has:
before()
beforeResult()
after()
handleException()
And will have a try/catch to allow you to be informed of
Exceptions in
handleException().
AroundInterceptor will remain the simple class that it is...
-Original Message-
From: Jason Carreira
Sent: Friday, November 14, 2003 9:33 AM
To: [EMAIL PROTECTED]
Subject: RE: [OS-webwork] Problems with code after
actionInvocation.invoke()
I don't want to add it to the base class, since none of
our current
bundled Interceptors need this. It should be easy enough
for people
who need it to have their own base Interceptor class to do this
(heck, I wrote it for you in a previous message)...
-Original Message-
From: Cameron Braid [mailto:[EMAIL PROTECTED]
Sent: Friday, November 14, 2003 7:27 AM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] Problems with code after
actionInvocation.invoke()
I think that this is a better idea.
AroundInterceptor could have an empty implementation for this
method... simple :)
Cameron
Francisco Hernandez wrote:
what if instead of having another Interceptor class we can
just add a
new method to the Interceptor interface like beforeResult() ?
Jason Carreira wrote:
I've just checked in the code for PreResultListener to
XW/WW2... No
changes to Interceptor base classes, etc... You guys try
this out and
see how you like it and how you're using it.
PreResultListener is an
Interface, with one method:
void beforeResult(ActionInvocation invocation, String
resultCode);
So don't limit yourself to just registering
Interceptors which
implement this Interface That was just off the top
of my head.
For now, I don't want to change the AroundInterceptor,
since if they
don't need it it's just extra overhead to register the
listeners and
call back to them for nothing... After some people start
using them
and we see how they're useful we can standardize
usage in base
classes.
Jason
-Original Message-
From: Drew McAuliffe [mailto:[EMAIL PROTECTED] Sent:
Thursday,
November 13, 2003 11:48 PM
To: [EMAIL PROTECTED]
Subject: RE: [OS-webwork] Problems with code after
actionInvocation.invoke()
Scratch my last comment; your example is exactly what I
had in mind
as a new superclass to use for this kind of
functionality. I think
such a superclass would be a great addition to the
framework, though
it would have to be documented very well so that the
difference between before, beforeResult, and after is
explicitly
clear This is
especially important considering the fact that the
JSP/velocity pages are already loaded before after() gets
called;
that wasn't
immediately apparent to me, and I'd imagine I'm not alone.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
On Behalf
Of Jason Carreira
Sent: Thursday, November 13, 2003 5:55 PM
To: [EMAIL PROTECTED]
Subject: RE: [OS-webwork] Problems with code after
actionInvocation.invoke()
No, it would be like this:
Public class MyInterceptor implements Interceptor,
PreResultListener
{
Public String intercept(ActionInvocation invocation) {
invocation.addPreResultListener(this);
String result;
before();
result = invocation.invoke();
after();
return result;
}
Public void beforeResult(ActionInvocation
invocation) { //
RE: [OS-webwork] PrepareInterceptor?
It's not there? It calls prepare() on Actions which implement Preparable... This is in Xwork. I added this while implementing the MigrationConfiguration which supports WW1.x views.properties and actions.xml. We were missing the prepare() method in WW2, so I added it. Jason -Original Message- From: Matthew E. Porter [mailto:[EMAIL PROTECTED] Sent: Friday, November 14, 2003 10:51 AM To: [EMAIL PROTECTED] Subject: [OS-webwork] PrepareInterceptor? The webwork-default.xml file lists a PrepareInterceptor. However, this class does not exist. What is/was this? Cheers, matthew --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Problems with code after actionInvocation.invoke()
This makes more sense to me. You would expect an interceptor to wrap a single method call. However, you still need the ability to wrap an interceptor around the entire double whammy action-result invocation. There are really 3 separate invocations going on here - one which wraps the other two (action and result invocations). If an action interceptor returned a null value then the result would not be executed. If WW2 gave the ability to intercept any of these then you could choose whether you wanted the result invocation bundled up. Almost like real AOP! All this is related to the fact that the String return value from the ActionInvocation.invoke() method is currently never used. - Original Message - From: Tim Dwelle [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, November 14, 2003 3:39 PM Subject: Re: [OS-webwork] Problems with code after actionInvocation.invoke() I know its a bit more radical... but it seems to me that a better solution would be to move the code for dispatching to the appropriate result into its own interceptor. Then you don't need these lifecycle methods. And more importantly, it eliminates this uncomfortable mix of some workflow is handled by interceptors, while others are not. Just a suggestion... -Tim. - Original Message - From: Jason Carreira [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, November 14, 2003 10:07 AM Subject: RE: [OS-webwork] Problems with code after actionInvocation.invoke() Gavin King has convinced me to take another look at this... Tonight I'll look at creating another base class which has: before() beforeResult() after() handleException() And will have a try/catch to allow you to be informed of Exceptions in handleException(). AroundInterceptor will remain the simple class that it is... -Original Message- From: Jason Carreira Sent: Friday, November 14, 2003 9:33 AM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] Problems with code after actionInvocation.invoke() I don't want to add it to the base class, since none of our current bundled Interceptors need this. It should be easy enough for people who need it to have their own base Interceptor class to do this (heck, I wrote it for you in a previous message)... -Original Message- From: Cameron Braid [mailto:[EMAIL PROTECTED] Sent: Friday, November 14, 2003 7:27 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Problems with code after actionInvocation.invoke() I think that this is a better idea. AroundInterceptor could have an empty implementation for this method... simple :) Cameron Francisco Hernandez wrote: what if instead of having another Interceptor class we can just add a new method to the Interceptor interface like beforeResult() ? Jason Carreira wrote: I've just checked in the code for PreResultListener to XW/WW2... No changes to Interceptor base classes, etc... You guys try this out and see how you like it and how you're using it. PreResultListener is an Interface, with one method: void beforeResult(ActionInvocation invocation, String resultCode); So don't limit yourself to just registering Interceptors which implement this Interface That was just off the top of my head. For now, I don't want to change the AroundInterceptor, since if they don't need it it's just extra overhead to register the listeners and call back to them for nothing... After some people start using them and we see how they're useful we can standardize usage in base classes. Jason -Original Message- From: Drew McAuliffe [mailto:[EMAIL PROTECTED] Sent: Thursday, November 13, 2003 11:48 PM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] Problems with code after actionInvocation.invoke() Scratch my last comment; your example is exactly what I had in mind as a new superclass to use for this kind of functionality. I think such a superclass would be a great addition to the framework, though it would have to be documented very well so that the difference between before, beforeResult, and after is explicitly clear This is especially important considering the fact that the JSP/velocity pages are already loaded before after() gets called; that wasn't immediately apparent to me, and I'd imagine I'm not alone. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Carreira Sent: Thursday, November 13, 2003 5:55 PM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] Problems with code after actionInvocation.invoke() No, it would be like this: Public class
[OS-webwork] Hibernate Session as Request Scoped Component
Instead of using a ThreadLocal Hibernate Session, has anyone played
with having a HibernateSessionProvider component at the request scope?
Here is how I would envision the code:
public class HibernateSessionProvider implements SessionProvider,
Disposable {
private SessionFactoryProvider sessionFactoryProvider;
private Session session;
public SessionFactoryProvider getSessionFactoryProvider() {
return this.sessionFactoryProvider;
}
public void setSessionFactoryProvider(SessionFactoryProvider
sessionFactoryProvider) {
this.sessionFactoryProvider = sessionFactoryProvider;
}
public Session getSession() throws PersistenceException {
if ((this.session == null) || (!this.session.isOpen())) {
try {
return
this.sessionFactoryProvider.getSessionFactory().openSession();
} catch (HibernateException he) {
throw new PersistenceException(HibernateException
caught building hibernate hibernate, he);
}
}
return this.session;
}
public void dispose() {
if ((this.session != null) (this.session.isOpen())
(this.session.isConnected()) {
try {
this.session.flush();
this.session.connection().commit();
this.session.close();
} catch (Exception e) {
// do something
}
}
}
}
Is there anything wrong with doing it this way? All of the components
needing a Hibernate session (Persistence Manager and DAOs) are scoped
at the same level. SessionFactoryProvider is another component but
scoped at the application.
Cheers,
matthew
---
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Component object setting
The ComponentInterceptor as implemented today provides a reasonable
implementation of IoC. It will I'm sure work very well to provide actions
with instances of DAO's or maybe Hibernate Sessions and such.
However there is a separate, but perhaps slightly related issue that
ComponentInterceptor almost solves. For the sake of simplicity I will
express this in terms of web applications, although I suspect that the
concept might be transferable to a general XWork discussion.
Many web applications use the http session to store Data Transfer Objects
between requests. For example the application might load a UserDTO from the
database in one action, present some of it's values in a jsp form that the
user can edit, and finally write back the new state of the UserDTO to the
database in the next action.
A way of dealing with this without using the http session would be to write
out all the values to the form (perhaps using hidden tags for some data),
and then let webwork copy all values into a new instance of the UserDTO with
the ParameterInterceptor. Making sure all the fields of the object are in
some way present in the jsp becomes tedious and bug prone when the DTO
contains a lot of fields and maybe a graph of connected object (let's say a
couple of AddressDTO instances).
Jason suggests saving the DTO objects in the http session manually. This is
essentially how our web applications have been implemented in the past. The
problem with this approach is that in a large application it becomes
difficult to get a good idea of what is stored in the http session
throughout the application. Also looking at a single action you can not tell
what it expects to be present in the session without reading all the code
for that action.
These are issues that would be solved by moving the session related code to
an interceptor. The interceptor could examine the interfaces that the action
implements to determine what fields of the action to set with objects from
the session, and what fields to write back to the session after the action
completes. This would also allow programmers to easily identify what each
action expects from the session.
An xml configuration file could contain any extra information necessary,
which would also provide a single location where programmers could see
everything that the application puts in the session.
OK, so you're starting to get my drift. Session scope components in webwork
allready provide almost all of this, except writing back the state of the
action field to the session in the interceptor's after() method.
Perhaps some more tweaks would be benefitial as far as configuration options
in components.xml etc, but this is the basic idea.
If someone feels that this is conceptually a completely different beast from
what components are today then maybe this should be a separate interceptor,
config file etc. But as far as I can see this is not incompatible with the
general idea of components and the IoC in webwork today.
Since we are on a tight schedule we will most likely take a stab at this
ourselves at Tradedoubler. But of course we would prefer something like this
in the official webwork release rather than having our own custom behaviour.
What do other people think? Is this a valid idea?
// Per Mellqvist
-Original Message-
From: Jason Carreira [mailto:[EMAIL PROTECTED]
Sent: Friday, November 14, 2003 3:48 PM
To: [EMAIL PROTECTED]
Subject: RE: [OS-webwork] Component object setting
The ComponentInterceptor will create and store your component in the
Session. It will not pick up the fact that you've created a new one and
put it into your Action.
I think we're talking about a persistent object here, right? IMO this is
not a good fit for a component. A good component would be something like
a DAO which will load and save objects for you, not the objects
themselves.
For doing this kind of editing, you're going to want to save your
Objects in the Session manually. You could make your Action ModelDriven
and have something like this:
Public Object getModel() {
Map session = ActionContext.getContext().getSession();
MyObject obj = session.get(MY_OBJECT_KEY);
if (obj == null) {
obj = // get an object or create a new one
session.put(MY_OBJECT_KEY);
}
return obj;
}
Then form fields will be set on the obj...
Jason
---
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] More about velocity directives
Drew McAuliffe wrote: I couldn't find my previous email on the SF list yet to keep this reply there, but I believe I understand now why the velocity directives act the way they do. In my post, I indicated that it would be easier to pass objects from the velocity context into bodytag params if you could do so without popping things onto the stack. For example, where this works now, #foreach ($item in $myItems) $stack.push($item) #bodytag(Component template=mytemplate.vm) #param(param1 $item) #end #set ($item = $stack.pop()) #end , the following would be preferable: #foreach ($item in $myItems) #bodytag(Component template=mytemplate.vm) #param(param1 $item) #end #end +1 I went ahead and made this change to CVS. Also, I fixed another issue with the velocity directives where the attributes were being set before doStartTag() was called. The net result is that calling: #tag( Component template=mytemplate.vm params.param1=foo ) is now valid. For consistency, you'll need to put the 's around the value unless you want the value to be rendered against the value stack. As another option, I would write the above loop as: #foreach( $item in $myItems ) #tag( Component ... params.param1=myItems[$velocityCount] ) #end assuming that $velocityCount is 0 indexed and myItems can be resolved on the value stack. M --- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Parametized tags question
Patrick Lightbody wrote: Open a jira issue for this, but I suspect it'll be a post 2.0 thing. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ben Hall Sent: Wednesday, November 12, 2003 12:05 AM To: '[EMAIL PROTECTED]' Subject: [OS-webwork] Parametized tags question Hi, Is it possible at all to add additional parameters to a tag without using the nested #param directive within Velocity ? Currently, i'd do something like this: #bodytag (Component template=..) #param (extraField value) #end Is it posible to do it somehow like this: #tag (Component template=.. extraField='value') I'd basically like my extra field(s) to be available as $parameters within my template without bulking up my templates. You can now :) Since the Component tag extends the ParameterizedTag (which has a getParams() method), the following is now legal: #tag( Component params.extraField='value' ) There was an issue before with the order that attributes were applied in. From your template, you can reference extraField as $parameters.extraField ... like other arguments to tag, the value associated with the parameter will be evaluated against the value stack. M --- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] EL Performance Between 1.3 and 2.0
Dick Zetterberg wrote: Just out of curiosity, did you measure against the released version of 1.3 or the CVS version? Did you use JSP or Velocity for presentation? Could you perhaps post your testcases here so that we may have a look at them and perhaps try them ourselves? I'd also be interested if you used a 1.4 jvm or a 1.3 jvm. M --- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Component object setting
In an initial implementation it would be OK to receive an empty DTO (whatever comes out of the default constructor), with the first request to the action. Obviously the DTO will in most cases be loaded from the database based on some input from the user, so this part would be a good fit for normal action code. When the flow moves on to a different part of the application logic it would also be nice to be able to cleanup the session. In a more advanced implementation maybe this could be defined on an action or action-alias level. Which session scoped DTOs each action expects to receive, and which ones it should set in the session after action invocation. That way my initial action that loads the DTO from the database would only be configured to set the DTO in the session (not receive one), While the following action might both receive and set the DTO. Finally the last action in this application flow would only receive and not set the DTO I don't know. Haven't thought this all the way through yet. It is hard to find a good balance between ease of use and power of configuration. // Per Mellqvist -Original Message- From: Jason Carreira [mailto:[EMAIL PROTECTED] Sent: Friday, November 14, 2003 8:15 PM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] Component object setting I think that this is a very interesting idea, but the problem is that of object creation... For an Update use-case like this, you don't want to create a NEW DTO, you want to load one from your persistence manager. How do you supply this object factory? --- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Hibernate Session as Request Scoped Component
I think this is a good solution, except I think you forgot to save the
Session if it's null. I would optimize it by having two methods:
getReadOnlySession
getReadWriteSession
Which both return the same Session, but getReadWriteSession sets a flag
to do the flush()... If the flag is not set, you can skip the flush and
roll back the transaction.
Jason
-Original Message-
From: Matthew E. Porter [mailto:[EMAIL PROTECTED]
Sent: Friday, November 14, 2003 12:16 PM
To: [EMAIL PROTECTED]
Subject: [OS-webwork] Hibernate Session as Request Scoped Component
Instead of using a ThreadLocal Hibernate Session, has anyone played
with having a HibernateSessionProvider component at the
request scope?
Here is how I would envision the code:
public class HibernateSessionProvider implements SessionProvider,
Disposable {
private SessionFactoryProvider sessionFactoryProvider;
private Session session;
public SessionFactoryProvider getSessionFactoryProvider() {
return this.sessionFactoryProvider;
}
public void setSessionFactoryProvider(SessionFactoryProvider
sessionFactoryProvider) {
this.sessionFactoryProvider = sessionFactoryProvider;
}
public Session getSession() throws PersistenceException {
if ((this.session == null) || (!this.session.isOpen())) {
try {
return
this.sessionFactoryProvider.getSessionFactory().openSession();
} catch (HibernateException he) {
throw new PersistenceException(HibernateException
caught building hibernate hibernate, he);
}
}
return this.session;
}
public void dispose() {
if ((this.session != null) (this.session.isOpen())
(this.session.isConnected()) {
try {
this.session.flush();
this.session.connection().commit();
this.session.close();
} catch (Exception e) {
// do something
}
}
}
}
Is there anything wrong with doing it this way? All of the
components
needing a Hibernate session (Persistence Manager and DAOs) are scoped
at the same level. SessionFactoryProvider is another component but
scoped at the application.
Cheers,
matthew
---
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your
computer from any Web browser or wireless device. Click here
to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/
g22lp.tmpl
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
---
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Hibernate Session as Request Scoped Component
Hibernate is smart enough to know when to do the flush.. Yes, it has to
check internally that nothing changed, but you would be doing that anyway.
So, when you call the flush command, Hibernate then figures out what needs
to be saved, and if nothing needs to be saved, then it won't...
Eric
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of
Jason Carreira
Sent: Friday, November 14, 2003 8:50 PM
To: [EMAIL PROTECTED]
Subject: RE: [OS-webwork] Hibernate Session as Request Scoped
Component
I think this is a good solution, except I think you forgot to save the
Session if it's null. I would optimize it by having two methods:
getReadOnlySession
getReadWriteSession
Which both return the same Session, but getReadWriteSession
sets a flag
to do the flush()... If the flag is not set, you can skip the
flush and
roll back the transaction.
Jason
-Original Message-
From: Matthew E. Porter [mailto:[EMAIL PROTECTED]
Sent: Friday, November 14, 2003 12:16 PM
To: [EMAIL PROTECTED]
Subject: [OS-webwork] Hibernate Session as Request Scoped Component
Instead of using a ThreadLocal Hibernate Session, has anyone played
with having a HibernateSessionProvider component at the
request scope?
Here is how I would envision the code:
public class HibernateSessionProvider implements SessionProvider,
Disposable {
private SessionFactoryProvider sessionFactoryProvider;
private Session session;
public SessionFactoryProvider getSessionFactoryProvider() {
return this.sessionFactoryProvider;
}
public void setSessionFactoryProvider(SessionFactoryProvider
sessionFactoryProvider) {
this.sessionFactoryProvider = sessionFactoryProvider;
}
public Session getSession() throws PersistenceException {
if ((this.session == null) || (!this.session.isOpen())) {
try {
return
this.sessionFactoryProvider.getSessionFactory().openSession();
} catch (HibernateException he) {
throw new PersistenceException(HibernateException
caught building hibernate hibernate, he);
}
}
return this.session;
}
public void dispose() {
if ((this.session != null) (this.session.isOpen())
(this.session.isConnected()) {
try {
this.session.flush();
this.session.connection().commit();
this.session.close();
} catch (Exception e) {
// do something
}
}
}
}
Is there anything wrong with doing it this way? All of the
components
needing a Hibernate session (Persistence Manager and DAOs)
are scoped
at the same level. SessionFactoryProvider is another component but
scoped at the application.
Cheers,
matthew
---
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your
computer from any Web browser or wireless device. Click here
to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/
g22lp.tmpl
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
---
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/
g22lp.tmpl
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
attachment: winmail.dat
RE: [OS-webwork] Hibernate Session as Request Scoped Component
Ok... Looking back at what we did here (and bugging Gavin)...
We always set mySession.setFlushMode(FlushMode.NEVER);
And have a flag that is set in the getReadWrite() that tells it to
manually flush() on dispose, otherwise it doesn't flush at all, which
saves it from having to check the objects.
Jason
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Eric Pugh
Sent: Friday, November 14, 2003 5:51 PM
To: [EMAIL PROTECTED]
Subject: RE: [OS-webwork] Hibernate Session as Request Scoped
Component
Hibernate is smart enough to know when to do the flush..
Yes, it has to check internally that nothing changed, but you
would be doing that anyway. So, when you call the flush
command, Hibernate then figures out what needs to be saved,
and if nothing needs to be saved, then it won't...
Eric
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Behalf Of
Jason Carreira
Sent: Friday, November 14, 2003 8:50 PM
To: [EMAIL PROTECTED]
Subject: RE: [OS-webwork] Hibernate Session as Request Scoped
Component
I think this is a good solution, except I think you forgot
to save the
Session if it's null. I would optimize it by having two methods:
getReadOnlySession
getReadWriteSession
Which both return the same Session, but getReadWriteSession
sets a flag
to do the flush()... If the flag is not set, you can skip the
flush and
roll back the transaction.
Jason
-Original Message-
From: Matthew E. Porter [mailto:[EMAIL PROTECTED]
Sent: Friday, November 14, 2003 12:16 PM
To: [EMAIL PROTECTED]
Subject: [OS-webwork] Hibernate Session as Request Scoped
Component
Instead of using a ThreadLocal Hibernate Session, has
anyone played
with having a HibernateSessionProvider component at the
request scope?
Here is how I would envision the code:
public class HibernateSessionProvider implements SessionProvider,
Disposable {
private SessionFactoryProvider sessionFactoryProvider;
private Session session;
public SessionFactoryProvider getSessionFactoryProvider() {
return this.sessionFactoryProvider;
}
public void setSessionFactoryProvider(SessionFactoryProvider
sessionFactoryProvider) {
this.sessionFactoryProvider = sessionFactoryProvider;
}
public Session getSession() throws PersistenceException {
if ((this.session == null) || (!this.session.isOpen())) {
try {
return
this.sessionFactoryProvider.getSessionFactory().openSession();
} catch (HibernateException he) {
throw new
PersistenceException(HibernateException
caught building hibernate hibernate, he);
}
}
return this.session;
}
public void dispose() {
if ((this.session != null) (this.session.isOpen())
(this.session.isConnected()) {
try {
this.session.flush();
this.session.connection().commit();
this.session.close();
} catch (Exception e) {
// do something
}
}
}
}
Is there anything wrong with doing it this way? All of the
components
needing a Hibernate session (Persistence Manager and DAOs)
are scoped
at the same level. SessionFactoryProvider is another
component but
scoped at the application.
Cheers,
matthew
---
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your
computer from any Web browser or wireless device. Click here
to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/
g22lp.tmpl
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
---
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your
computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/
g22lp.tmpl
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
---
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
RE: [OS-webwork] Hibernate Session as Request Scoped Component
Public flogging? You'll get errors that you have to track down...
-Original Message-
From: Matthew E. Porter [mailto:[EMAIL PROTECTED]
Sent: Friday, November 14, 2003 9:53 PM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] Hibernate Session as Request Scoped
Component
Jason:
What happens if some *accidentally* calls getReadOnly()
and performs
a write?
Cheers,
matthew
On Nov 14, 2003, at 8:01 PM, Jason Carreira wrote:
Ok... Looking back at what we did here (and bugging Gavin)...
We always set mySession.setFlushMode(FlushMode.NEVER);
And have a flag that is set in the getReadWrite() that tells it to
manually flush() on dispose, otherwise it doesn't flush at
all, which
saves it from having to check the objects.
Jason
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
On Behalf
Of Eric Pugh
Sent: Friday, November 14, 2003 5:51 PM
To: [EMAIL PROTECTED]
Subject: RE: [OS-webwork] Hibernate Session as Request Scoped
Component
Hibernate is smart enough to know when to do the flush..
Yes, it has
to check internally that nothing changed, but you would be
doing that
anyway. So, when you call the flush command, Hibernate
then figures
out what needs to be saved, and if nothing needs to be
saved, then it
won't...
Eric
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Behalf Of
Jason Carreira
Sent: Friday, November 14, 2003 8:50 PM
To: [EMAIL PROTECTED]
Subject: RE: [OS-webwork] Hibernate Session as Request Scoped
Component
I think this is a good solution, except I think you forgot
to save the
Session if it's null. I would optimize it by having two methods:
getReadOnlySession
getReadWriteSession
Which both return the same Session, but
getReadWriteSession sets a
flag to do the flush()... If the flag is not set, you can skip the
flush and
roll back the transaction.
Jason
-Original Message-
From: Matthew E. Porter [mailto:[EMAIL PROTECTED]
Sent: Friday, November 14, 2003 12:16 PM
To: [EMAIL PROTECTED]
Subject: [OS-webwork] Hibernate Session as Request Scoped
Component
Instead of using a ThreadLocal Hibernate Session, has
anyone played
with having a HibernateSessionProvider component at the request
scope? Here is how I would envision the code:
public class HibernateSessionProvider implements
SessionProvider,
Disposable {
private SessionFactoryProvider sessionFactoryProvider;
private Session session;
public SessionFactoryProvider getSessionFactoryProvider() {
return this.sessionFactoryProvider;
}
public void setSessionFactoryProvider(SessionFactoryProvider
sessionFactoryProvider) {
this.sessionFactoryProvider = sessionFactoryProvider;
}
public Session getSession() throws PersistenceException {
if ((this.session == null) ||
(!this.session.isOpen())) {
try {
return
this.sessionFactoryProvider.getSessionFactory().openSession();
} catch (HibernateException he) {
throw new
PersistenceException(HibernateException
caught building hibernate hibernate, he);
}
}
return this.session;
}
public void dispose() {
if ((this.session != null) (this.session.isOpen())
(this.session.isConnected()) {
try {
this.session.flush();
this.session.connection().commit();
this.session.close();
} catch (Exception e) {
// do something
}
}
}
}
Is there anything wrong with doing it this way? All of the
components needing a Hibernate session (Persistence Manager and
DAOs)
are scoped
at the same level. SessionFactoryProvider is another
component but
scoped at the application.
Cheers,
matthew
---
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your
computer
from any Web browser or wireless device. Click here to
Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/
g22lp.tmpl
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
---
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your
computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/
g22lp.tmpl
___
Opensymphony-webwork mailing list
RE: [OS-webwork] EL Performance Between 1.3 and 2.0
I was using 1.4.2, running against 1.3 from CVS. Both are using monthlist.jsp from WW 1.3 CVS -- so the presentation is all JSP. I got the performance of 2.0 EL much better -- it is now taking on average 150ms compared to 1.3's 80ms. Still 2X slower, but much better than the 4X slower a few days ago. I'll keep at it. -Pat -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Ho Sent: Friday, November 14, 2003 11:30 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] EL Performance Between 1.3 and 2.0 Dick Zetterberg wrote: Just out of curiosity, did you measure against the released version of 1.3 or the CVS version? Did you use JSP or Velocity for presentation? Could you perhaps post your testcases here so that we may have a look at them and perhaps try them ourselves? I'd also be interested if you used a 1.4 jvm or a 1.3 jvm. M --- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
