Re: [OS-webwork] WebWork 1.4 release
Hani Suleiman wrote: WebWork 1.4 has been released, appropriate press blurbage will be showing up on your regular news channels in the next day or so I expect. You can grab it from https://webwork.dev.java.net/files/documents/693/1790/webwork-1.4.zip Any feedback/testing would be most appreciated. I think it's a pretty solid release with plenty of fixes and good reasons to upgrade. Release notes can be found at https://webwork.dev.java.net/servlets/ProjectDocumentView? documentID=1791noNav=true Thanks to all those who contributed, by filing issues, writing docs, fixing bugs, writing incredibly cool and fast new parsers, emailing in code, and providing encouragement. Thanks to the ww2 guys for providing motivation too (and I don't mean that in a snide way!). Way to go Hani! As we are currently basing our entire product on WW 1.3 this is great news! regards, Rickard --- 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] formatting dates and numbers
hmm having looked at text.vm template its used for displaying a input
type=text tag.. and what happened to textfield tag too?
Patrick Lightbody wrote:
Haha, examples. Good one :P
Actually, the examples for 1.3 should work, since i18n hasn't change in
2.0. Actually, if you know a bit about ResourceBundles and i18n in
general, the ww:text/ tag shouldn't be too tough.
Essentially, if your action is Foo (extends ActionSupport), and it has a
property date, then you do:
ww:text name='some.date' arg0=date/
OR
ww:text name='some.date'
ww:param value=date/
/ww:text
OR
ww:property value=text('some.date', {date})'/
All of those will result in ActionSupport.getText() being called. You'll
need a file called Foo.properties that has an entry:
some.date = {0,date}
-Pat
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Paul Knepper
Sent: Monday, November 17, 2003 1:46 PM
To: [EMAIL PROTECTED]
Subject: RE: [OS-webwork] formatting dates and numbers
I'm using WebWork2. Are there any examples?
-Original Message-
From: Cuong Tran [mailto:[EMAIL PROTECTED]
Sent: Monday, November 17, 2003 12:21 PM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] formatting dates and numbers
I'd use the ww:text tag for that.
--- Paul Knepper [EMAIL PROTECTED] wrote:
I'm using jsp pages with ww:property tags to output data.
How do I format dates and numbers? I would like to specify dates
as /mm/dd. And I'd like to format numbers regarding number of
digits for precision etc...
Thanks,
Paul
---
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
__
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree
---
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=/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
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Param directive
why create another property tag instead of just adding an attribute to handle escaping (which i thought it had..)? same thing for the param tag, couldnt an attribute be added to eval or not? Patrick Lightbody wrote: What we need to solve all this is: * two #param directives (one which evaluates, one which doesn't) * two #property directives (one which escapes, one which doesn't) With the above to things, velocity templates would be able to do all the things JSPs can. In fact, the two #param directives is something that JSP doesn't support, but that's because JSP doesn't have it's own EL, whereas Velocity does and so taking advantage of it is a good idea. Would that work for everyone? Got an suggestions for the names of the directives? -Pat -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Drew McAuliffe Sent: Monday, November 17, 2003 3:15 PM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] Param directive As I said in another reply, the biggest problem is that you can't use an object variable in velocity, since it always gets converted to a string first. If I have a collection of model objects, and want to call a component tag with them in an iteration through the collection, I can't, because a call to the component tag with the former behavior can only pass in the reference to the model object, converted to a string. For example, for a model object like PhoneNumber -number -area code -number type the new behavior will allow for syntax like this: #foreach ($number in $person.phoneNumbers) #bodytag (Component template=numberDisplay.vm) #param(phoneNumber $number) #end #end If you always call stack.findValue() behind the scenes, there's no way the value stack can know the value of a velocity variable unless you manually push it onto the stack, then pop it off. That's a hack to me, and is also inconsistent with the way every other velocity directive or macro works (directives and macros allow object references to be passed in, not just strings). The new approach still allows for strings evaluation, but it forces a manual call to $stack.findValue(). I think that's a fair tradeoff. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fred Lamuette Sent: Monday, November 17, 2003 9:16 AM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] Param directive As far as I am concerned this approach is not the correct one ! I explain my point of view with an example : With the latest XWork+WW2 cvs snapshot, you can write a select tag both ways : 1/ #tag(Select name='nameValue' ...) - in this case, the parameter with key=name and value=stack.findValue(nameValue) is added to the parameters map. is equivalent to #bodytag(Select ) #param(name nameValue) - in this case, the parameter with key=name and value=nameValue is added to the parameters map. #end 2/ #tag(Select name=nameValue ...) is equivalent to #bodytag(Select ) #param(name $stack.findValue($nameValue)) #end You can admit it's not very coherent, you have two different behaviors according to what you use (extra tags or external params) whereas the same handling behind is used (extra tags are converted as parameters). Can you explain to me what are your arguments ? Richard HALLIER Chef de projet [EMAIL PROTECTED] 01.40.12.41.52 www.uniclick.org UNICLICK I believe some people asked for it to be that way as it's more natural for a Velocity context... I may be wrong though.. -Original Message- From: Fred Lamuette [mailto:[EMAIL PROTECTED] Sent: Monday, November 17, 2003 9:34 AM To: [EMAIL PROTECTED] Subject: [OS-webwork] Param directive Having the latest XWork+WW2 cvs snapshot, I can notice a behavior change for the param directive. Before #param(paramName paramValue) - store in the parameters list, the value OgnlValueStack.findValue(paramValue) From now #param(paramName paramValue) - store in the parameters list, the value paramValue Why did you change the previous behavior ? Richard HALLIER Chef de projet [EMAIL PROTECTED] 01.40.12.41.52 www.uniclick.org UNICLICK --- 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=/g22lp.tmpl ___ Opensymphony-webwork mailing list
Re: [OS-webwork] [OS-xwork] Spring IoC integration
Cheers mate. I've just attached the SpringExternalReferenceResolver implmentation and tests to the Jira Issue. http://jira.opensymphony.com/secure/ViewIssue.jspa?key=XW-122 Ross Patrick Lightbody wrote: This is good stuff -- not sure about a 1.0 release though. We'll try to get a point release out shortly after though to support this. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ross Mason Sent: Monday, November 17, 2003 8:02 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] [OS-xwork] Spring IoC integration I'll fix the commons dependancies first :-) Ross Mason wrote: I've tried running the patch again (through Eclipse) and I get the same problem - It only creates patch entries for new files? I know this isn't a subject for this list, but does anyone know why this happens? Anyway Cameron, I'll create a zip of the changes for now and attach it to the the issue and this list. Cheers, Ross Cameron Braid wrote: The patch seems to be missing code in the configuration classes... since I have applied it, I am geting compilation errors : not defined : invocation.getProxy().getConfig().getPackageName() invocation.getProxy().getConfig().getExternalRefs(); packageConfig.getExternalRefResolver() Thanks, Cameron Ross Mason wrote: Hi, As per the discussion late last week, we have a patch for Xwork so that it can use an external container to resolve component references. I've created the following issue - http://jira.opensymphony.com/secure/ViewIssue.jspa?key=XW-122 I've added a breakdown of the changes below, in summary, this is how it works- You can configure a action to have external references in the xwork.xml using a new external-ref tag on the action When the action is configured the external refs are stored on the action config. When the action is invoked, there is a new interceptor that will resolve these references. It does this by using a new attribute on the package config called externalReferenceResolver i.e. package name=default externalReferenceResolver=com.atlassian.xwork.ext.SpringServletContextR eferenceResolver In this case, the SpringServletContextReferenceResolver implementation will handle the work of looking up and setting the references on the action. Note, if a resolver is not found on the actions package, it will tranverse up the package heirarchy to find one. We have an implementation for Spring, but I have not included it in this patch as it should probably go into an xwork-ext sub-project. Let me know what you want me to do with this... Here are the changes and additions to the xwork codebase - 1. added 2 new config attributes - - a new element external-ref to the action element in the config. i.e external-ref name=fooFoo/external-ref where name is the setter method name and Foo is the reference to lookup. - added an attribute to the package element called externalReferenceResolver which supplies a FQ classname to an ExternalReferenceResolver implementation. 2. Updated the xwork DTD accordingly. 3. Added 4 new classes - - External Reference - an encapsulation of the external-ref tag - ExternalReferenceResolver - an interface to provide implementations for resolving references from an external container - ExternalReferencesInterceptor - will resolve references on a given ActionInvocation - ReferenceResolverException - thrown by ExternalReferenceResolver 4. Added support for external references to the ActionConfig. I also added the attribute packageName to the ActionConfig, so that the Interceptor could determine which package the action belonged to in order to find the externalReferenceResolver. 5. Added support for the externalReferenceResolver attribute to the PackageConfig. 6. Added support for the extra configuration to the XMLConfigurationProvider and DefaultConfigurationProvider 7. Added tests in the org.opensymphony.xwork.config.ExternalReferenceResolverTest I've attached a cvs patch with all the changes. I built the patch against the latest src. Cheers, Ross --- 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]
Re: [OS-webwork] WebWork 1.4 release
On Mon, Nov 17, 2003 at 08:35:48PM -0500, Hani Suleiman wrote: All, WebWork 1.4 has been released, appropriate press blurbage will be showing up on your regular news channels in the next day or so I expect. You can grab it from https://webwork.dev.java.net/files/documents/693/1790/webwork-1.4.zip WebWork is dead, Long Live WebWork! Great work Hani, very nice to see that WW1.x is still alive and kickin' :) //Anders -- . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Anders Engström [EMAIL PROTECTED] . http://www.gnejs.netPGP-Key: ED010E7F . [Your mind is like an umbrella. It doesn't work unless you open it.] signature.asc Description: Digital signature
RE: [OS-webwork] Changes in validationFramework?
Hmm, you right! Why have i done this change...Anyways, tx now it works
again.
The validation xml file is now named, DemoAction-demoStep1-validation.xml.
/Mathias.
-Original Message-
From: Jason Carreira [mailto:[EMAIL PROTECTED]
Sent: den 17 november 2003 17:31
To: [EMAIL PROTECTED]
Subject: RE: [OS-webwork] Changes in validationFramework?
Your form is posting to demoStep1.action, but the config you show is for
doStep1.action... Is that the problem?
-Original Message-
From: Mathias Berg [mailto:[EMAIL PROTECTED]
Sent: Monday, November 17, 2003 3:46 AM
To: WebWork (E-mail)
Subject: [OS-webwork] Changes in validationFramework?
Hi, i wonder if the validation framework has been changed in
the recent time, say 1-2 weeks ago?
I wonder for my test validation page doesn't longer work for
me, it work ok for about 2 weeks :/ I got the validation
file, interceptor ref, and the action's validation xml file
is included as well under the class catalogue.
xwork--
action name=demoStep1 class=com.tradedoubler.ui.test.DemoAction
method=doStep1
result name=success
type=dispatcher/test/demo/DemoFormStep2.jsp/result
result name=input
type=dispatcher/test/demo/DemoFormStep1.jsp/result
interceptor-ref name=component/
interceptor-ref name=static-params/
interceptor-ref name=params/
interceptor-ref name=validation/
/action
the action has a check on errors.
public class DemoAction extends ActionSupport implements
DemoAware { .
public DemoTransport getDemo() {
return demo;
}
public void setDemo(DemoTransport demo) {
this.demo = demo;
}
public String doStep1() throws Exception {
if(hasErrors()){
return INPUT;
}else{
return SUCCESS;
}
}
...
}
validation-
DemoAction-doStep1-validation.xml
!DOCTYPE validators PUBLIC -//OpenSymphony Group//XWork
Validator 1.0//EN
http://www.opensymphony.com/xwork/xwork-validator-1.0.dtd;
validators
field name=demo.message
field-validator type=requiredstring
messageYou must fill in a message!./message
/field-validator
/field
field name=demo.countryId
field-validator type=requiredstring
messageYou must choose a country!./message
/field-validator
/field
/validators
JSP-
...
body
ww:include page=/include/errorDisplay.jsp /
table
ww:form action='demoStep1.action' method='post' name='frm'
tr
ww:select label='Country' name='demo.countryId'
list=demo.countries listKey=key listValue=value
multiple=true size=8 /
/tr
tr
ww:textarea label='Skriv ett meddelande'
name='demo.message' cols='10' rows='5' value='' /
/tr
tr
ww:submit value='Skicka' /
/tr
/ww:form
/table
/body
--
What else do you need ... I get no errors, only a dispatch to
the second page.
/Mathias
---
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
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
[OS-webwork] Page attribute gone
How come the page attribute of the URL tag has been removed? It is a little annoying to have to tripple quote static values (and hard to spot when you've missed one). The tld still allows a page attribute. Also, what is the com.opensymphony.veiws.jsp.vui package about? John.
RE: [OS-webwork] Param directive
I dont think two #param directives are a good idea. What about a default behaviour defined in the webwork.properties ? With an attribute in param tag to override the default, it would be nice. Cheers. Richard HALLIER Chef de projet [EMAIL PROTECTED] 01.40.12.41.52 www.uniclick.org UNICLICK -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] la part de Francisco Hernandez Envoye : mardi 18 novembre 2003 08:33 A : [EMAIL PROTECTED] Objet : Re: [OS-webwork] Param directive why create another property tag instead of just adding an attribute to handle escaping (which i thought it had..)? same thing for the param tag, couldnt an attribute be added to eval or not? Patrick Lightbody wrote: What we need to solve all this is: * two #param directives (one which evaluates, one which doesn't) * two #property directives (one which escapes, one which doesn't) With the above to things, velocity templates would be able to do all the things JSPs can. In fact, the two #param directives is something that JSP doesn't support, but that's because JSP doesn't have it's own EL, whereas Velocity does and so taking advantage of it is a good idea. Would that work for everyone? Got an suggestions for the names of the directives? -Pat -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Drew McAuliffe Sent: Monday, November 17, 2003 3:15 PM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] Param directive As I said in another reply, the biggest problem is that you can't use an object variable in velocity, since it always gets converted to a string first. If I have a collection of model objects, and want to call a component tag with them in an iteration through the collection, I can't, because a call to the component tag with the former behavior can only pass in the reference to the model object, converted to a string. For example, for a model object like PhoneNumber -number -area code -number type the new behavior will allow for syntax like this: #foreach ($number in $person.phoneNumbers) #bodytag (Component template=numberDisplay.vm) #param(phoneNumber $number) #end #end If you always call stack.findValue() behind the scenes, there's no way the value stack can know the value of a velocity variable unless you manually push it onto the stack, then pop it off. That's a hack to me, and is also inconsistent with the way every other velocity directive or macro works (directives and macros allow object references to be passed in, not just strings). The new approach still allows for strings evaluation, but it forces a manual call to $stack.findValue(). I think that's a fair tradeoff. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fred Lamuette Sent: Monday, November 17, 2003 9:16 AM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] Param directive As far as I am concerned this approach is not the correct one ! I explain my point of view with an example : With the latest XWork+WW2 cvs snapshot, you can write a select tag both ways : 1/ #tag(Select name='nameValue' ...) - in this case, the parameter with key=name and value=stack.findValue(nameValue) is added to the parameters map. is equivalent to #bodytag(Select ) #param(name nameValue) - in this case, the parameter with key=name and value=nameValue is added to the parameters map. #end 2/ #tag(Select name=nameValue ...) is equivalent to #bodytag(Select ) #param(name $stack.findValue($nameValue)) #end You can admit it's not very coherent, you have two different behaviors according to what you use (extra tags or external params) whereas the same handling behind is used (extra tags are converted as parameters). Can you explain to me what are your arguments ? Richard HALLIER Chef de projet [EMAIL PROTECTED] 01.40.12.41.52 www.uniclick.org UNICLICK I believe some people asked for it to be that way as it's more natural for a Velocity context... I may be wrong though.. -Original Message- From: Fred Lamuette [mailto:[EMAIL PROTECTED] Sent: Monday, November 17, 2003 9:34 AM To: [EMAIL PROTECTED] Subject: [OS-webwork] Param directive Having the latest XWork+WW2 cvs snapshot, I can notice a behavior change for the param directive. Before #param(paramName paramValue) - store in the parameters list, the value OgnlValueStack.findValue(paramValue) From now #param(paramName paramValue) - store in the parameters list, the value paramValue Why did you change the previous behavior ? Richard HALLIER Chef de projet [EMAIL PROTECTED] 01.40.12.41.52 www.uniclick.org UNICLICK --- 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!
RE: [OS-webwork] Param directive
Here is the different point of view. I personnaly think the push/pop actions are NOT a hack. Either you have a WW2 approach or a Velocity one. I think we are in the first one, that makes all the difference, the stack is the main way to access data. If you need to pass reference objects without pushing on the stack, just use velocity macros, it works perfectly. And I'd like to point out that you can ALWAYS pass in any object references via ognl (stack.findValue), you have just to push the needed object, in your example : #foreach( $number in $person.phoneNumbers ) $stack.push($number) #bodytag(Component template=numberDisplay.vm) #param(phoneNumber top) - actually, (behavior in the previous release) you pass $stack.findValue(top) = $number. #end #set ($trash = $stack.pop()) #end In your component numberDisplay.vm, you can use $parameters.phoneNumber as a direct reference : -- #set($phoneNumer = $parameters.phoneNumber ) $phoneNumber.number $phoneNumber.areaCode ... My conclusion would be : 1/ All you found impossible (pass in object references) is actually possible via the stack. 2/ I think it's important to keep the WebWork philosophy (data in a stack) to not break the consistency. 3/ Keep in mind, accessing the stack relies on ognl which is very very powerfull (projection for instance). I hope I convince you to keep as a standard the data access via the stack. Richard HALLIER Chef de projet [EMAIL PROTECTED] 01.40.12.41.52 www.uniclick.org UNICLICK -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] la part de Drew McAuliffe Envoye : mardi 18 novembre 2003 00:15 A : [EMAIL PROTECTED] Objet : RE: [OS-webwork] Param directive As I said in another reply, the biggest problem is that you can't use an object variable in velocity, since it always gets converted to a string first. If I have a collection of model objects, and want to call a component tag with them in an iteration through the collection, I can't, because a call to the component tag with the former behavior can only pass in the reference to the model object, converted to a string. For example, for a model object like PhoneNumber -number -area code -number type the new behavior will allow for syntax like this: #foreach ($number in $person.phoneNumbers) #bodytag (Component template=numberDisplay.vm) #param(phoneNumber $number) #end #end If you always call stack.findValue() behind the scenes, there's no way the value stack can know the value of a velocity variable unless you manually push it onto the stack, then pop it off. That's a hack to me, and is also inconsistent with the way every other velocity directive or macro works (directives and macros allow object references to be passed in, not just strings). The new approach still allows for strings evaluation, but it forces a manual call to $stack.findValue(). I think that's a fair tradeoff. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fred Lamuette Sent: Monday, November 17, 2003 9:16 AM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] Param directive As far as I am concerned this approach is not the correct one ! I explain my point of view with an example : With the latest XWork+WW2 cvs snapshot, you can write a select tag both ways : 1/ #tag(Select name='nameValue' ...) - in this case, the parameter with key=name and value=stack.findValue(nameValue) is added to the parameters map. is equivalent to #bodytag(Select ) #param(name nameValue) - in this case, the parameter with key=name and value=nameValue is added to the parameters map. #end 2/ #tag(Select name=nameValue ...) is equivalent to #bodytag(Select ) #param(name $stack.findValue($nameValue)) #end You can admit it's not very coherent, you have two different behaviors according to what you use (extra tags or external params) whereas the same handling behind is used (extra tags are converted as parameters). Can you explain to me what are your arguments ? Richard HALLIER Chef de projet [EMAIL PROTECTED] 01.40.12.41.52 www.uniclick.org UNICLICK I believe some people asked for it to be that way as it's more natural for a Velocity context... I may be wrong though.. -Original Message- From: Fred Lamuette [mailto:[EMAIL PROTECTED] Sent: Monday, November 17, 2003 9:34 AM To: [EMAIL PROTECTED] Subject: [OS-webwork] Param directive Having the latest XWork+WW2 cvs snapshot, I can notice a behavior change for the param directive. Before #param(paramName paramValue) - store in the parameters list, the value OgnlValueStack.findValue(paramValue) From now #param(paramName paramValue) - store in the parameters list, the value paramValue Why did you change the previous behavior ? Richard HALLIER Chef de projet [EMAIL PROTECTED] 01.40.12.41.52
Re: [OS-webwork] Param directive
Fred Lamuette wrote: I dont think two #param directives are a good idea. What about a default behaviour defined in the webwork.properties ? With an attribute in param tag to override the default, it would be nice. This is now done in CVS. The param supports an optional eval attribute. If eval is not defined or true, then the value will be evaluated against the value stack. Otherwise, the value will be passed as is. 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
[OS-webwork] Pre-validation Processing Question
Title: Pre-validation Processing Question Hi gang, I have an action that will either submit a form's contents, if it passes validation, or dispatch the form for completion if it doesn't pass validation. Basically, it's my way of being lazy so I don't have to write one action to render a form and post to another action to process it. However, I've run into a hitch because the form will always fail validation until it is completed but I need to populate a drop-down field on it from a List attribute in the action which never gets populated because validation fails So, what are my options here? Should I stick with two separate actions or use a component or interceptor to populate my list? Are there any other options that webwork provides that I haven't considered? Thanks! Peter
RE: [OS-webwork] Pre-validation Processing Question
Title: Pre-validation Processing Question I forgot to mention, I'm using the XML based ActionName-validation.xml mechanism this time around vs. rolling my own validation code in my model's validate() methods since I'm working with static forms this time. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter WhiteSent: Tuesday, November 18, 2003 2:11 AMTo: [EMAIL PROTECTED]Subject: [OS-webwork] Pre-validation Processing Question Hi gang, I have an action that will either submit a form's contents, if it passes validation, or dispatch the form for completion if it doesn't pass validation. Basically, it's my way of being lazy so I don't have to write one action to render a form and post to another action to process it. However, I've run into a hitch because the form will always fail validation until it is completed but I need to populate a drop-down field on it from a List attribute in the action which never gets populated because validation fails So, what are my options here? Should I stick with two separate actions or use a component or interceptor to populate my list? Are there any other options that webwork provides that I haven't considered? Thanks! Peter
Re: [OS-webwork] Param directive
what if in your example you needed 2 objects to be avaiable in your Component? would a ww:set be needed? Fred Lamuette wrote: Here is the different point of view. I personnaly think the push/pop actions are NOT a hack. Either you have a WW2 approach or a Velocity one. I think we are in the first one, that makes all the difference, the stack is the main way to access data. If you need to pass reference objects without pushing on the stack, just use velocity macros, it works perfectly. And I'd like to point out that you can ALWAYS pass in any object references via ognl (stack.findValue), you have just to push the needed object, in your example : #foreach( $number in $person.phoneNumbers ) $stack.push($number) #bodytag(Component template=numberDisplay.vm) #param(phoneNumber top) - actually, (behavior in the previous release) you pass $stack.findValue(top) = $number. #end #set ($trash = $stack.pop()) #end In your component numberDisplay.vm, you can use $parameters.phoneNumber as a direct reference : -- #set($phoneNumer = $parameters.phoneNumber ) $phoneNumber.number $phoneNumber.areaCode ... My conclusion would be : 1/ All you found impossible (pass in object references) is actually possible via the stack. 2/ I think it's important to keep the WebWork philosophy (data in a stack) to not break the consistency. 3/ Keep in mind, accessing the stack relies on ognl which is very very powerfull (projection for instance). I hope I convince you to keep as a standard the data access via the stack. Richard HALLIER Chef de projet [EMAIL PROTECTED] 01.40.12.41.52 www.uniclick.org UNICLICK -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] la part de Drew McAuliffe Envoye : mardi 18 novembre 2003 00:15 A : [EMAIL PROTECTED] Objet : RE: [OS-webwork] Param directive As I said in another reply, the biggest problem is that you can't use an object variable in velocity, since it always gets converted to a string first. If I have a collection of model objects, and want to call a component tag with them in an iteration through the collection, I can't, because a call to the component tag with the former behavior can only pass in the reference to the model object, converted to a string. For example, for a model object like PhoneNumber -number -area code -number type the new behavior will allow for syntax like this: #foreach ($number in $person.phoneNumbers) #bodytag (Component template=numberDisplay.vm) #param(phoneNumber $number) #end #end If you always call stack.findValue() behind the scenes, there's no way the value stack can know the value of a velocity variable unless you manually push it onto the stack, then pop it off. That's a hack to me, and is also inconsistent with the way every other velocity directive or macro works (directives and macros allow object references to be passed in, not just strings). The new approach still allows for strings evaluation, but it forces a manual call to $stack.findValue(). I think that's a fair tradeoff. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fred Lamuette Sent: Monday, November 17, 2003 9:16 AM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] Param directive As far as I am concerned this approach is not the correct one ! I explain my point of view with an example : With the latest XWork+WW2 cvs snapshot, you can write a select tag both ways : 1/ #tag(Select name='nameValue' ...) - in this case, the parameter with key=name and value=stack.findValue(nameValue) is added to the parameters map. is equivalent to #bodytag(Select ) #param(name nameValue) - in this case, the parameter with key=name and value=nameValue is added to the parameters map. #end 2/ #tag(Select name=nameValue ...) is equivalent to #bodytag(Select ) #param(name $stack.findValue($nameValue)) #end You can admit it's not very coherent, you have two different behaviors according to what you use (extra tags or external params) whereas the same handling behind is used (extra tags are converted as parameters). Can you explain to me what are your arguments ? Richard HALLIER Chef de projet [EMAIL PROTECTED] 01.40.12.41.52 www.uniclick.org UNICLICK I believe some people asked for it to be that way as it's more natural for a Velocity context... I may be wrong though.. -Original Message- From: Fred Lamuette [mailto:[EMAIL PROTECTED] Sent: Monday, November 17, 2003 9:34 AM To: [EMAIL PROTECTED] Subject: [OS-webwork] Param directive Having the latest XWork+WW2 cvs snapshot, I can notice a behavior change for the param directive. Before #param(paramName paramValue) - store in the parameters list, the value OgnlValueStack.findValue(paramValue) From now #param(paramName paramValue) - store in the parameters list, the value paramValue Why did you change the
[OS-webwork] velocity tool support
I've opted to move this to the webwork extensions rather than have it part of the webwork core. Although the VelocityServlet will be deprecated, that won't be til Velocity 1.5! One of the features that's extremely appealing about the velocity tool project is the ability to easily add your own helpers to the velocity context. To that end, I've added a ToolContext (similar to velocity tools ToolboxContext) that allows you to add objects to the velocity context. Finally, to enable this, I added support for chaining additional VelocityContexts to the end of the WebWorkVelocityContext. Here's a snippet from webwork.properties # # Allow user defined VelocityContexts to be chained to the end of # the WebWorkVelocityContext # webwork.velocity.contexts=com.opensymphony.webwork.views.velocity.ToolContext # # Allow users to place objects into the VelocityContext. For example, # the following snippet would place 3 objects in the VelocityContext; # $name1, $name2, and $name3 that would be references to instances of # $classname1, $classname2, and $classname3 respectively. if # the classname value is not a class, then the value will resolve to a # string. For example, $name4 would resolve to 'hello world' # #webwork.velocity.tool.name1 = classname1 #webwork.velocity.tool.name2 = classname2 #webwork.velocity.tool.name3 = classname3 #webwork.velocity.tool.name4 = hello world 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] Pre-validation Processing Question
you can use a chain to populate that list or maybe lazily load the list in your getter (i think chain would work better..) One common use of Action chaining is to provide lookup lists (like for a dropdown list of states, etc). Since these Actions get put on the ValueStack, these properties will be available in the view. see: http://wiki.opensymphony.com/space/Webwork+-+Why+would+I+use+Action+Chaining%3F hope it helps! Peter White wrote: Hi gang, I have an action that will either submit a form's contents, if it passes validation, or dispatch the form for completion if it doesn't pass validation. Basically, it's my way of being lazy so I don't have to write one action to render a form and post to another action to process it. However, I've run into a hitch because the form will always fail validation until it is completed but I need to populate a drop-down field on it from a List attribute in the action which never gets populated because validation fails So, what are my options here? Should I stick with two separate actions or use a component or interceptor to populate my list? Are there any other options that webwork provides that I haven't considered? Thanks! Peter --- 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] Pre-validation Processing Question
Francisco, Thanks for the tip, I'll give it a shot! -Peter -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Francisco Hernandez Sent: Tuesday, November 18, 2003 2:26 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Pre-validation Processing Question you can use a chain to populate that list or maybe lazily load the list in your getter (i think chain would work better..) One common use of Action chaining is to provide lookup lists (like for a dropdown list of states, etc). Since these Actions get put on the ValueStack, these properties will be available in the view. see: http://wiki.opensymphony.com/space/Webwork+-+Why+would+I+use+A ction+Chaining%3F hope it helps! Peter White wrote: Hi gang, I have an action that will either submit a form's contents, if it passes validation, or dispatch the form for completion if it doesn't pass validation. Basically, it's my way of being lazy so I don't have to write one action to render a form and post to another action to process it. However, I've run into a hitch because the form will always fail validation until it is completed but I need to populate a drop-down field on it from a List attribute in the action which never gets populated because validation fails. So, what are my options here? Should I stick with two separate actions or use a component or interceptor to populate my list? Are there any other options that webwork provides that I haven't considered? Thanks! Peter --- 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] velocity tool support
I totally agree about putting it in webwork extensions! Jonas Matt Ho wrote: I've opted to move this to the webwork extensions rather than have it part of the webwork core. Although the VelocityServlet will be deprecated, that won't be til Velocity 1.5! One of the features that's extremely appealing about the velocity tool project is the ability to easily add your own helpers to the velocity context. To that end, I've added a ToolContext (similar to velocity tools ToolboxContext) that allows you to add objects to the velocity context. Finally, to enable this, I added support for chaining additional VelocityContexts to the end of the WebWorkVelocityContext. Here's a snippet from webwork.properties # # Allow user defined VelocityContexts to be chained to the end of # the WebWorkVelocityContext # webwork.velocity.contexts=com.opensymphony.webwork.views.velocity.ToolContext # # Allow users to place objects into the VelocityContext. For example, # the following snippet would place 3 objects in the VelocityContext; # $name1, $name2, and $name3 that would be references to instances of # $classname1, $classname2, and $classname3 respectively. if # the classname value is not a class, then the value will resolve to a # string. For example, $name4 would resolve to 'hello world' # #webwork.velocity.tool.name1 = classname1 #webwork.velocity.tool.name2 = classname2 #webwork.velocity.tool.name3 = classname3 #webwork.velocity.tool.name4 = hello world 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
RE: [OS-webwork] Param directive
what if in your example you needed 2 objects to be avaiable in your Component? double push would a ww:set be needed? ??? Richard HALLIER Chef de projet [EMAIL PROTECTED] 01.40.12.41.52 www.uniclick.org UNICLICK -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] la part de Francisco Hernandez Envoye : mardi 18 novembre 2003 11:21 A : [EMAIL PROTECTED] Objet : Re: [OS-webwork] Param directive what if in your example you needed 2 objects to be avaiable in your Component? would a ww:set be needed? Fred Lamuette wrote: Here is the different point of view. I personnaly think the push/pop actions are NOT a hack. Either you have a WW2 approach or a Velocity one. I think we are in the first one, that makes all the difference, the stack is the main way to access data. If you need to pass reference objects without pushing on the stack, just use velocity macros, it works perfectly. And I'd like to point out that you can ALWAYS pass in any object references via ognl (stack.findValue), you have just to push the needed object, in your example : #foreach( $number in $person.phoneNumbers ) $stack.push($number) #bodytag(Component template=numberDisplay.vm) #param(phoneNumber top) - actually, (behavior in the previous release) you pass $stack.findValue(top) = $number. #end #set ($trash = $stack.pop()) #end In your component numberDisplay.vm, you can use $parameters.phoneNumber as a direct reference : -- -- -- #set($phoneNumer = $parameters.phoneNumber ) $phoneNumber.number $phoneNumber.areaCode ... My conclusion would be : 1/ All you found impossible (pass in object references) is actually possible via the stack. 2/ I think it's important to keep the WebWork philosophy (data in a stack) to not break the consistency. 3/ Keep in mind, accessing the stack relies on ognl which is very very powerfull (projection for instance). I hope I convince you to keep as a standard the data access via the stack. Richard HALLIER Chef de projet [EMAIL PROTECTED] 01.40.12.41.52 www.uniclick.org UNICLICK -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] la part de Drew McAuliffe Envoye : mardi 18 novembre 2003 00:15 A : [EMAIL PROTECTED] Objet : RE: [OS-webwork] Param directive As I said in another reply, the biggest problem is that you can't use an object variable in velocity, since it always gets converted to a string first. If I have a collection of model objects, and want to call a component tag with them in an iteration through the collection, I can't, because a call to the component tag with the former behavior can only pass in the reference to the model object, converted to a string. For example, for a model object like PhoneNumber -number -area code -number type the new behavior will allow for syntax like this: #foreach ($number in $person.phoneNumbers) #bodytag (Component template=numberDisplay.vm) #param(phoneNumber $number) #end #end If you always call stack.findValue() behind the scenes, there's no way the value stack can know the value of a velocity variable unless you manually push it onto the stack, then pop it off. That's a hack to me, and is also inconsistent with the way every other velocity directive or macro works (directives and macros allow object references to be passed in, not just strings). The new approach still allows for strings evaluation, but it forces a manual call to $stack.findValue(). I think that's a fair tradeoff. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fred Lamuette Sent: Monday, November 17, 2003 9:16 AM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] Param directive As far as I am concerned this approach is not the correct one ! I explain my point of view with an example : With the latest XWork+WW2 cvs snapshot, you can write a select tag both ways : 1/ #tag(Select name='nameValue' ...) - in this case, the parameter with key=name and value=stack.findValue(nameValue) is added to the parameters map. is equivalent to #bodytag(Select ) #param(name nameValue) - in this case, the parameter with key=name and value=nameValue is added to the parameters map. #end 2/ #tag(Select name=nameValue ...) is equivalent to #bodytag(Select ) #param(name $stack.findValue($nameValue)) #end You can admit it's not very coherent, you have two different behaviors according to what you use (extra tags or external params) whereas the same handling behind is used (extra tags are converted as parameters). Can you explain to me what are your arguments ? Richard HALLIER Chef de projet [EMAIL PROTECTED] 01.40.12.41.52 www.uniclick.org UNICLICK I believe some people asked for it to be that way as it's more natural for a Velocity
Re: [OS-webwork] velocity tool support
Matt Ho wrote: I've opted to move this to the webwork extensions rather than have it part of the webwork core. Although the VelocityServlet will be deprecated, that won't be til Velocity 1.5! One of the features that's extremely appealing about the velocity tool project is the ability to easily add your own helpers to the velocity context. To that end, I've added a ToolContext (similar to velocity tools ToolboxContext) that allows you to add objects to the velocity context. What does this buy you that the #bean macro doesn't? The problem with this proposal, as I see it, is that they will always be instantiated, even if they're not used. By using #bean macro only those tools that are actually used will be created. IMO that's better. /Rickard --- 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] velocity tool support
Is this then to the point of actually being usable? I have exactly this requirement and i'd like to use this. Or, is this going to be part of the WW2 next release? Eric -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jonas Eriksson Sent: Tuesday, November 18, 2003 11:42 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] velocity tool support I totally agree about putting it in webwork extensions! Jonas Matt Ho wrote: I've opted to move this to the webwork extensions rather than have it part of the webwork core. Although the VelocityServlet will be deprecated, that won't be til Velocity 1.5! One of the features that's extremely appealing about the velocity tool project is the ability to easily add your own helpers to the velocity context. To that end, I've added a ToolContext (similar to velocity tools ToolboxContext) that allows you to add objects to the velocity context. Finally, to enable this, I added support for chaining additional VelocityContexts to the end of the WebWorkVelocityContext. Here's a snippet from webwork.properties # # Allow user defined VelocityContexts to be chained to the end of # the WebWorkVelocityContext # webwork.velocity.contexts=com.opensymphony.webwork.views.veloc ity.ToolContext # # Allow users to place objects into the VelocityContext. For example, # the following snippet would place 3 objects in the VelocityContext; # $name1, $name2, and $name3 that would be references to instances of # $classname1, $classname2, and $classname3 respectively. if # the classname value is not a class, then the value will resolve to a # string. For example, $name4 would resolve to 'hello world' # #webwork.velocity.tool.name1 = classname1 #webwork.velocity.tool.name2 = classname2 #webwork.velocity.tool.name3 = classname3 #webwork.velocity.tool.name4 = hello world 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 --- 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] API changes, again!
hehe I know how you feel, im in the process of upgrading to a newer version of ww2 and running into a bunch of problems, but its mainly lots of small tedious changes, like having to add single quotes tags and such, oh well. BOGAERT Mathias wrote: Hi, Just to let you guys know that I *again* have to upgrade my entire WebWork2 application. My previous version was from CVS 10/8/2003, and a lot of things seem to have changed. For instance, HttpServletRequestAware got ServletRequestAware (but still setting a HttpServletRequest??). All the templates have a new format, using parameters, so I have to migrate all my own templates (using CSS for tables) to the new format. I'm getting tired of migrating. If this happens again, I'm switching back to WW 1.3, at least I'll be ok for the next 6 months then. Mathias --- 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] formatting dates and numbers
--- Paul Knepper [EMAIL PROTECTED] wrote: I'm using jsp pages with ww:property tags to output data. How do I format dates and numbers? I would like to specify dates as /mm/dd. And I'd like to format numbers regarding number of digits for precision etc... ww:property would do toString(), which is not what you want... I put formatter tool ( bean ) into respective context instead, and use it. regards, = [ Konstantin Pribluda ( ko5tik ) ] Zu Verstärkung meines Teams suche ich ab Sofort einen Softwareentwickler[In] für die Festanstellung. Arbeitsort: Mainz Skills: Programieren, Kentnisse in OpenSource-Bereich [ http://www.pribluda.de ] __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree --- 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
[OS-webwork] theres a new FAQ in town..
ok, i created this FAQ, hopefully you guys can help me out and fill it in whenever you guys ask a question and get it answered or just put something in it whenever.. http://wiki.opensymphony.com/space/Webwork2+FAQ --- 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
[OS-webwork] Problems with tags?
There seem to be some problems with the Tags in the latest CVS checkout. Specifically IncludeTag and UrlTag cause exceptions when used. Is that a known problem? /Daniel --- 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] velocity tool support
I agree, and having just refactored these bits in ww1 I think that adding all this velocity config stuff to webwork is duplication and unnecessary. The jsp equivalent for example would be to suddenly allow for the ability to define various scoped objects in the webwork config. Use a startup listener instead, or subclass the appropriate class that creates the velocity context and puts in your custom stuff. On Nov 18, 2003, at 6:18 AM, Rickard Öberg wrote: Matt Ho wrote: I've opted to move this to the webwork extensions rather than have it part of the webwork core. Although the VelocityServlet will be deprecated, that won't be til Velocity 1.5! One of the features that's extremely appealing about the velocity tool project is the ability to easily add your own helpers to the velocity context. To that end, I've added a ToolContext (similar to velocity tools ToolboxContext) that allows you to add objects to the velocity context. What does this buy you that the #bean macro doesn't? The problem with this proposal, as I see it, is that they will always be instantiated, even if they're not used. By using #bean macro only those tools that are actually used will be created. IMO that's better. /Rickard --- 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] [OS-xwork] Spring IoC integration
I have downloaded and integrated this code though and the tests run perfectly (after creating my my own ServletContextAware interface and removing refrences to the confluence packages) I really like the work that you have done. Though I think some more work is required to be able to integrate into xwork/webwork I can't see how the servlet context is set onto the SpringServletContextReferenceResolver or the ApplicationContext is set onto the SpringApplicationContextReferenceResolver (depending on the one that is used) you construct the ExternalReferenceResolver using this code, and immediately add it to the package config. Class erResolverClazz = ClassLoaderUtil.loadClass(externalReferenceResolver, ExternalReferenceResolver.class); erResolver = (ExternalReferenceResolver) erResolverClazz.newInstance(); I guess that the ServletContextAware interface could be added to webwork, though the question remains - how is the ServletContextAware.setServletContext(..) method going to get called ? I propost the following soloution : 1 : have different SpringXXXReferenceResolver classes in xwork and webwork like this : xwork : SpringClassPathXmlApplicationContextReferenceResolver or a SpringFileSystemXmlApplicationContextReferenceResolver webwork : SpringWebApplicationContextReferenceResolver - using WebApplicationContextUtils.getWebApplicationContext(ServletActionContext.getServletContext()) to obtain the application context This works find for webwork based apps, though for xwork based apps that the SpringClassPathXmlApplicationContextReferenceResolver and SpringFileSystemXmlApplicationContextReferenceResolver require configuration to specify the filename.. therfore step two is required : 2 : allow for external refrence resolvers to be declards by name, class and to be parameterizable like interceptors. the refer to the by name instead of className e.g. : xwork package ... externalReferenceResolver="spring" !-- NEW FEATURE : new node set -- externalRefrenceResolvers externalRefrenceResolver name='spring' class="SpringWebApplicationContextReferenceResolver"/ externalRefrenceResolver name='springXmlFile' class="SpringClassPathXmlApplicationContextReferenceResolver" param name="filename"myApplicationContext.xml/param /externalRefrenceResolver /externalRefrenceResolvers action name='...' class='...' !-- NEW FEATURE : externalRefrenceResolver attribute -- external-ref externalRefrenceResolver='springXmlFile' name='foo'myFoo/external-ref external-ref name='bar'myBar/external-ref /action /package /xwork this allows for reusing the same configured resolver in multiple packages - which you can do now, though without configuration. this allows for each external-ref tag to optionally use a different resolver as in the example above I am sure that other frameworks will require some sort of runtime configuration for the external reference resolvers as well. Any comments ? Cameron Ross Mason wrote: Cheers mate. I've just attached the SpringExternalReferenceResolver implmentation and tests to the Jira Issue. http://jira.opensymphony.com/secure/ViewIssue.jspa?key=XW-122 Ross Patrick Lightbody wrote: This is good stuff -- not sure about a 1.0 release though. We'll try to get a point release out shortly after though to support this. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Ross Mason Sent: Monday, November 17, 2003 8:02 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] [OS-xwork] Spring IoC integration I'll fix the commons dependancies first :-) Ross Mason wrote: I've tried running the patch again (through Eclipse) and I get the same problem - It only creates patch entries for new files? I know this isn't a subject for this list, but does anyone know why this happens? Anyway Cameron, I'll create a zip of the changes for now and attach it to the the issue and this list. Cheers, Ross Cameron Braid wrote: The patch seems to be missing code in the configuration classes... since I have applied it, I am geting compilation errors : not defined : invocation.getProxy().getConfig().getPackageName() invocation.getProxy().getConfig().getExternalRefs(); packageConfig.getExternalRefResolver() Thanks, Cameron Ross Mason wrote: Hi, As per the discussion late last week, we have a patch for Xwork so that it can use an external container to resolve component references. I've created the following issue -
RE: [OS-webwork] Latest xwork cvs snapshot
Richard, I've fixed this. The down side of all this is that if you have null as an arg to a method call, the optimizations I made to get monthlist from 4X to 2X will be lost. In the future I could probably get those optimizations back, but for now this works and is really simple. -Pat -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fred Lamuette Sent: Monday, November 17, 2003 9:37 AM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] Latest xwork cvs snapshot Jira is down for the while, but as soon as possible, I'm gonna to open a jira issue. As far as I have seen your code improvment, I believe it will appreciably increase the speed. Pat, what about the real problem that Ognl 2.6.4 should fix ? Do you wait for the next release of Ognl ? Richard. -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] la part de Patrick Lightbody Envoye : lundi 17 novembre 2003 17:08 A : [EMAIL PROTECTED] Objet : RE: [OS-webwork] Latest xwork cvs snapshot Richard, Thanks, I wasn't expecting a null argument. I'll need to fix that. This change was an optimization that got us from 4X to 2X speed difference in the monthlist tests. Anyway, please open a bug and I'll get to it promptly. -Pat -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fred Lamuette Sent: Monday, November 17, 2003 5:56 AM To: [EMAIL PROTECTED] Subject: [OS-webwork] Latest xwork cvs snapshot I guess many refactorings happens in xwork (possibly to fix invalid methods ?) , especially in CompoundRootAccessor, and my current code is not working. The following example doesnt work anymore : stack.findValue(format(myDate)). The error comes from the fact that the (Object[] objects ) argument passed to the CompoundRootAccessor.callMethod(...) is an array of size 1 containing a null object. Thus, the getArgTypes(objects) throws a NPE. Hope it can help. Richard. --- 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 ___ 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] API changes, again!
The same for me. I think personnaly that too much stuff included in this endless beta 2 prevents it from being stable (yes i know it's a beta). But it is the choice of the project team, not mine. And I can only support the project with my patches, bugs submissions, remarks, but I do it with pleasure, because I believe in this project. But yess, it's very very painfull to upgrade and upgrade and upgrade and ... Cheers. Richard HALLIER Chef de projet [EMAIL PROTECTED] 01.40.12.41.52 www.uniclick.org UNICLICK -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] la part de Francisco Hernandez Envoye : mardi 18 novembre 2003 12:42 A : [EMAIL PROTECTED] Objet : Re: [OS-webwork] API changes, again! hehe I know how you feel, im in the process of upgrading to a newer version of ww2 and running into a bunch of problems, but its mainly lots of small tedious changes, like having to add single quotes tags and such, oh well. BOGAERT Mathias wrote: Hi, Just to let you guys know that I *again* have to upgrade my entire WebWork2 application. My previous version was from CVS 10/8/2003, and a lot of things seem to have changed. For instance, HttpServletRequestAware got ServletRequestAware (but still setting a HttpServletRequest??). All the templates have a new format, using parameters, so I have to migrate all my own templates (using CSS for tables) to the new format. I'm getting tired of migrating. If this happens again, I'm switching back to WW 1.3, at least I'll be ok for the next 6 months then. Mathias --- 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 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Latest xwork cvs snapshot
I get right now the latest cvs snapshot. Thank you, Pat. Richard. -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] la part de Patrick Lightbody Envoye : mardi 18 novembre 2003 07:41 A : [EMAIL PROTECTED] Objet : RE: [OS-webwork] Latest xwork cvs snapshot Richard, I've fixed this. The down side of all this is that if you have null as an arg to a method call, the optimizations I made to get monthlist from 4X to 2X will be lost. In the future I could probably get those optimizations back, but for now this works and is really simple. -Pat -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fred Lamuette Sent: Monday, November 17, 2003 9:37 AM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] Latest xwork cvs snapshot Jira is down for the while, but as soon as possible, I'm gonna to open a jira issue. As far as I have seen your code improvment, I believe it will appreciably increase the speed. Pat, what about the real problem that Ognl 2.6.4 should fix ? Do you wait for the next release of Ognl ? Richard. -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] la part de Patrick Lightbody Envoye : lundi 17 novembre 2003 17:08 A : [EMAIL PROTECTED] Objet : RE: [OS-webwork] Latest xwork cvs snapshot Richard, Thanks, I wasn't expecting a null argument. I'll need to fix that. This change was an optimization that got us from 4X to 2X speed difference in the monthlist tests. Anyway, please open a bug and I'll get to it promptly. -Pat -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fred Lamuette Sent: Monday, November 17, 2003 5:56 AM To: [EMAIL PROTECTED] Subject: [OS-webwork] Latest xwork cvs snapshot I guess many refactorings happens in xwork (possibly to fix invalid methods ?) , especially in CompoundRootAccessor, and my current code is not working. The following example doesnt work anymore : stack.findValue(format(myDate)). The error comes from the fact that the (Object[] objects ) argument passed to the CompoundRootAccessor.callMethod(...) is an array of size 1 containing a null object. Thus, the getArgTypes(objects) throws a NPE. Hope it can help. Richard. --- 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 ___ 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 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
[OS-webwork] ExceptionHandlerIntercepter
I just discovered a problem with my
ExceptionHandlerInterceptor due to the design of the DefaultActionInvocation
class. I have made some changes to this class which fix the problem and
wouldlike to run them past everybody.
The ExceptionHandlerInterceptor catches any
exceptions that occur during the invoking of the action (and result) and shows
the ERROR result instead. During previous discussions on this list, no
alternative approaches were suggested that would allow for:
1 - Catch exceptions occurring
in the Action AND Result
2 - Enable specific error pages
to be defined for each package or action
3 - Useaction
definitions definedin the xwork.xml (eg ERROR)
4 - Retain the offending
Action on the stackso it can be examined in an error page.
Strangely enough, it appeared to be working fine
before (but for the wrong reasons).
The problem is this: if an exception occurs while
processing an Action then the interceptor can return ERROR and the error Result
is executed. However, if an exception occurs while processing the Result
and the interceptor returns ERROR, the error Result isNOT executed.
In fact the original result is executed again (which will probably cause the
exception again).
This is because once a Result has been instantiated
it is retained and reused no matter what resultCode is returned from the
interceptor. executeResult() calls getResult() which returns the Result
stored in an instance variable. It seems that the only reason for this is
so that other objects can get the result after it has executed.
Some may say "Exceptions that happen while
executing the result should just be rethrown". But then how are we to
implement the error handling requirements above?
Anyway, the changes I made to
DefaultActionInvocation are VERY simple and fix the problem by splitting
getResult() into two methods (createResult() and getResult()).
executeResult() now calls createResult() instead of recycling the old
result.
It all seems to work OK and allows an interceptor
to return a result code which will not be ignored unless the result has already
executed (executed = true)
Index:
DefaultActionInvocation.java===RCS
file:
/cvs/xwork/src/java/com/opensymphony/xwork/DefaultActionInvocation.java,vretrieving
revision 1.10diff -u -r1.10 DefaultActionInvocation.java---
DefaultActionInvocation.java15 Nov 2003 05:50:15 -1.10+++
DefaultActionInvocation.java18 Nov 2003 15:18:34 -@@ -93,49 +93,50
@@* @throws Exception*/ public
Result getResult() throws Exception
{- if (result != null)
{- Result
returnResult =
result;--
// If we've chained to other Actions, we need to find the last
result-
while (returnResult instanceof ActionChainResult)
{-
ActionProxy aProxy = ((ActionChainResult)
returnResult).getProxy();--
if (aProxy != null)
{-
Result proxyResult =
aProxy.getInvocation().getResult();--
if ((proxyResult != null) (aProxy.getExecuteResult()))
{-
returnResult =
proxyResult;-
} else
{-
break;-
}-
} else
{-
break;-
}-
}--
return returnResult;- } else
{- Map
results =
proxy.getConfig().getResults();-
ResultConfig resultConfig = (ResultConfig)
results.get(resultCode);--
if (resultConfig != null)
{-
Class resultClass = resultConfig.getClazz();+ Result
returnResult = result;++ // If we've
chained to other Actions, we need to find the last
result+ while (returnResult instanceof
ActionChainResult) {+
ActionProxy aProxy = ((ActionChainResult)
returnResult).getProxy();++
if (aProxy != null)
{+
Result proxyResult =
aProxy.getInvocation().getResult();++
if ((proxyResult != null) (aProxy.getExecuteResult()))
{+
returnResult =
proxyResult;+
} else
{+
break;+
}+ } else
{+
break;+
}+ }++ return
returnResult;+ }+
+ public Result createResult() throws Exception
{+ Map results =
proxy.getConfig().getResults();+ ResultConfig resultConfig
= (ResultConfig) results.get(resultCode);+ Result
newResult = null;+ + if
(resultConfig != null) {+ Class resultClass =
resultConfig.getClazz();++ if (resultClass
!= null) {+ try
{+ newResult =
(Result)
resultClass.newInstance();+ }
catch (Exception e) {+
LOG.error("There was an exception while instantiating the result of type " +
resultClass, e);+
throw e;+
}++
OgnlUtil.setProperties(resultConfig.getParams(), newResult,
ActionContext.getContext().getContextMap());+
}+
}-
if (resultClass != null)
{-
try
{-
result = (Result)
resultClass.newInstance();-
} catch (Exception e)
{-
LOG.error("There was an exception while instantiating the result of type " +
resultClass,
e);-
throw
e;-
}--
OgnlUtil.setProperties(resultConfig.getParams(), result,
ActionContext.getContext().getContextMap());-
}-
}--
return result;-
}- }+ return newResult;+
} public String getResultCode()
{ return resultCode;@@
-260,13 +261,13 @@
} /**-* Uses getResult to get the
final Result and executes it+* Creates a new Result
RE: [OS-webwork] ExceptionHandlerIntercepter
+1
(I've written the same exception handler interceptor)
-Message d'origine-De:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]De la part de
John PattersonEnvoyé: mardi 18 novembre 2003
16:21À: WebworkObjet: [OS-webwork]
ExceptionHandlerIntercepter
I just discovered a problem with my
ExceptionHandlerInterceptor due to the design of the DefaultActionInvocation
class. I have made some changes to this class which fix the problem and
wouldlike to run them past everybody.
The ExceptionHandlerInterceptor catches any
exceptions that occur during the invoking of the action (and result) and shows
the ERROR result instead. During previous discussions on this list, no
alternative approaches were suggested that would allow for:
1 - Catch exceptions occurring
in the Action AND Result
2 - Enable specific error
pages to be defined for each package or action
3 - Useaction
definitions definedin the xwork.xml (eg ERROR)
4 - Retain the offending
Action on the stackso it can be examined in an error page.
Strangely enough, it appeared to be working fine
before (but for the wrong reasons).
The problem is this: if an exception occurs while
processing an Action then the interceptor can return ERROR and the error
Result is executed. However, if an exception occurs while processing the
Result and the interceptor returns ERROR, the error Result isNOT
executed. In fact the original result is executed again (which will
probably cause the exception again).
This is because once a Result has been
instantiated it is retained and reused no matter what resultCode is returned
from the interceptor. executeResult() calls getResult() which returns
the Result stored in an instance variable. It seems that the only reason
for this is so that other objects can get the result after it has
executed.
Some may say "Exceptions that happen while
executing the result should just be rethrown". But then how are we to
implement the error handling requirements above?
Anyway, the changes I made to
DefaultActionInvocation are VERY simple and fix the problem by splitting
getResult() into two methods (createResult() and getResult()).
executeResult() now calls createResult() instead of recycling the old
result.
It all seems to work OK and allows an interceptor
to return a result code which will not be ignored unless the result has
already executed (executed = true)
Index:
DefaultActionInvocation.java===RCS
file:
/cvs/xwork/src/java/com/opensymphony/xwork/DefaultActionInvocation.java,vretrieving
revision 1.10diff -u -r1.10 DefaultActionInvocation.java---
DefaultActionInvocation.java15 Nov 2003 05:50:15 -1.10+++
DefaultActionInvocation.java18 Nov 2003 15:18:34 -@@ -93,49
+93,50 @@* @throws Exception*/
public Result getResult() throws Exception
{- if (result != null)
{-
Result returnResult =
result;--
// If we've chained to other Actions, we need to find the last
result-
while (returnResult instanceof ActionChainResult)
{-
ActionProxy aProxy = ((ActionChainResult)
returnResult).getProxy();--
if (aProxy != null)
{-
Result proxyResult =
aProxy.getInvocation().getResult();--
if ((proxyResult != null) (aProxy.getExecuteResult()))
{-
returnResult =
proxyResult;-
} else
{-
break;-
}-
} else
{-
break;-
}-
}--
return returnResult;- } else
{- Map
results =
proxy.getConfig().getResults();-
ResultConfig resultConfig = (ResultConfig)
results.get(resultCode);--
if (resultConfig != null)
{-
Class resultClass = resultConfig.getClazz();+
Result returnResult = result;++ // If
we've chained to other Actions, we need to find the last
result+ while (returnResult instanceof
ActionChainResult) {+
ActionProxy aProxy = ((ActionChainResult)
returnResult).getProxy();++
if (aProxy != null)
{+
Result proxyResult =
aProxy.getInvocation().getResult();++
if ((proxyResult != null) (aProxy.getExecuteResult()))
{+
returnResult =
proxyResult;+
} else
{+
break;+
}+ } else
{+
break;+
}+ }++
return returnResult;+ }+
+ public Result createResult() throws Exception
{+ Map results =
proxy.getConfig().getResults();+ ResultConfig
resultConfig = (ResultConfig) results.get(resultCode);+
Result newResult = null;+ + if
(resultConfig != null) {+ Class resultClass
= resultConfig.getClazz();++ if
(resultClass != null) {+ try
{+ newResult =
(Result)
resultClass.newInstance();+ }
catch (Exception e)
{+ LOG.error("There
was an exception while instantiating the result of type " + resultClass,
e);+ throw
e;+
}++
OgnlUtil.setProperties(resultConfig.getParams(), newResult,
ActionContext.getContext().getContextMap());+
}+
RE: [OS-webwork] Pre-validation Processing Question
The other option is to have an Action which creates that list and use the webwork:action tag to execute it and then use the list from the other tags... (see the examples or wiki(?) for examples) -Original Message- From: Peter White [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 18, 2003 5:37 AM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] Pre-validation Processing Question Francisco, Thanks for the tip, I'll give it a shot! -Peter -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Francisco Hernandez Sent: Tuesday, November 18, 2003 2:26 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Pre-validation Processing Question you can use a chain to populate that list or maybe lazily load the list in your getter (i think chain would work better..) One common use of Action chaining is to provide lookup lists (like for a dropdown list of states, etc). Since these Actions get put on the ValueStack, these properties will be available in the view. see: http://wiki.opensymphony.com/space/Webwork+-+Why+would+I+use+A ction+Chaining%3F hope it helps! Peter White wrote: Hi gang, I have an action that will either submit a form's contents, if it passes validation, or dispatch the form for completion if it doesn't pass validation. Basically, it's my way of being lazy so I don't have to write one action to render a form and post to another action to process it. However, I've run into a hitch because the form will always fail validation until it is completed but I need to populate a drop-down field on it from a List attribute in the action which never gets populated because validation fails. So, what are my options here? Should I stick with two separate actions or use a component or interceptor to populate my list? Are there any other options that webwork provides that I haven't considered? Thanks! Peter --- 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 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] [OS-xwork] Spring IoC integration
I'll take a look after the 2.0 beta2 release -Original Message- From: Ross Mason [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 18, 2003 12:01 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] [OS-xwork] Spring IoC integration I've updated the Issue, and attached the patch as a zip. Give that a go. Also, I've removed the commons-x dependancies and used the OgnlUtil like Jason suggested (cheers for that ;-) Ross Cameron Braid wrote: The patch seems to be missing code in the configuration classes... since I have applied it, I am geting compilation errors : not defined : invocation.getProxy().getConfig().getPackageName() invocation.getProxy().getConfig().getExternalRefs(); packageConfig.getExternalRefResolver() Thanks, Cameron Ross Mason wrote: Hi, As per the discussion late last week, we have a patch for Xwork so that it can use an external container to resolve component references. I've created the following issue - http://jira.opensymphony.com/secure/ViewIssue.jspa?key=XW-122 I've added a breakdown of the changes below, in summary, this is how it works- You can configure a action to have external references in the xwork.xml using a new external-ref tag on the action When the action is configured the external refs are stored on the action config. When the action is invoked, there is a new interceptor that will resolve these references. It does this by using a new attribute on the package config called externalReferenceResolver i.e. package name=default externalReferenceResolver=com.atlassian.xwork.ext.SpringServl etContextReferenceResolver In this case, the SpringServletContextReferenceResolver implementation will handle the work of looking up and setting the references on the action. Note, if a resolver is not found on the actions package, it will tranverse up the package heirarchy to find one. We have an implementation for Spring, but I have not included it in this patch as it should probably go into an xwork-ext sub-project. Let me know what you want me to do with this... Here are the changes and additions to the xwork codebase - 1. added 2 new config attributes - - a new element external-ref to the action element in the config. i.e external-ref name=fooFoo/external-ref where name is the setter method name and Foo is the reference to lookup. - added an attribute to the package element called externalReferenceResolver which supplies a FQ classname to an ExternalReferenceResolver implementation. 2. Updated the xwork DTD accordingly. 3. Added 4 new classes - - External Reference - an encapsulation of the external-ref tag - ExternalReferenceResolver - an interface to provide implementations for resolving references from an external container - ExternalReferencesInterceptor - will resolve references on a given ActionInvocation - ReferenceResolverException - thrown by ExternalReferenceResolver 4. Added support for external references to the ActionConfig. I also added the attribute packageName to the ActionConfig, so that the Interceptor could determine which package the action belonged to in order to find the externalReferenceResolver. 5. Added support for the externalReferenceResolver attribute to the PackageConfig. 6. Added support for the extra configuration to the XMLConfigurationProvider and DefaultConfigurationProvider 7. Added tests in the org.opensymphony.xwork.config.ExternalReferenceResolverTest I've attached a cvs patch with all the changes. I built the patch against the latest src. Cheers, Ross --- 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] API changes, again!
Sorry about that... I assume Pat changed the HttpServletRequestAware to ServletRequestAware to be more like WW1.x and make it a little easier to upgrade. The reason things have changed so much was to make backward compatibility easier. All major API changes should be over now. The tags, unless there's little issues, should be working like they will (i.e. we're not changing what is evaluated and what is not anymore). I'm very sorry for the frustration, but we're approaching a stable point and want to make sure we get all of our i's dotted and t's crossed. Jason -Original Message- From: BOGAERT Mathias [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 18, 2003 5:52 AM To: [EMAIL PROTECTED] Subject: [OS-webwork] API changes, again! Hi, Just to let you guys know that I *again* have to upgrade my entire WebWork2 application. My previous version was from CVS 10/8/2003, and a lot of things seem to have changed. For instance, HttpServletRequestAware got ServletRequestAware (but still setting a HttpServletRequest??). All the templates have a new format, using parameters, so I have to migrate all my own templates (using CSS for tables) to the new format. I'm getting tired of migrating. If this happens again, I'm switching back to WW 1.3, at least I'll be ok for the next 6 months then. Mathias --- 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] ExceptionHandlerIntercepter
Title: Message
How
does this handle the issue of content having been written out by the first
result? Would you end up with part of the first page, then the error
page?
-Original Message-From: John Patterson
[mailto:[EMAIL PROTECTED] Sent: Tuesday, November 18,
2003 10:21 AMTo: WebworkSubject: [OS-webwork]
ExceptionHandlerIntercepter
I just discovered a problem with my
ExceptionHandlerInterceptor due to the design of the DefaultActionInvocation
class. I have made some changes to this class which fix the problem and
wouldlike to run them past everybody.
The ExceptionHandlerInterceptor catches any
exceptions that occur during the invoking of the action (and result) and shows
the ERROR result instead. During previous discussions on this list, no
alternative approaches were suggested that would allow for:
1 - Catch exceptions occurring
in the Action AND Result
2 - Enable specific error
pages to be defined for each package or action
3 - Useaction
definitions definedin the xwork.xml (eg ERROR)
4 - Retain the offending
Action on the stackso it can be examined in an error page.
Strangely enough, it appeared to be working fine
before (but for the wrong reasons).
The problem is this: if an exception occurs while
processing an Action then the interceptor can return ERROR and the error
Result is executed. However, if an exception occurs while processing the
Result and the interceptor returns ERROR, the error Result isNOT
executed. In fact the original result is executed again (which will
probably cause the exception again).
This is because once a Result has been
instantiated it is retained and reused no matter what resultCode is returned
from the interceptor. executeResult() calls getResult() which returns
the Result stored in an instance variable. It seems that the only reason
for this is so that other objects can get the result after it has
executed.
Some may say "Exceptions that happen while
executing the result should just be rethrown". But then how are we to
implement the error handling requirements above?
Anyway, the changes I made to
DefaultActionInvocation are VERY simple and fix the problem by splitting
getResult() into two methods (createResult() and getResult()).
executeResult() now calls createResult() instead of recycling the old
result.
It all seems to work OK and allows an interceptor
to return a result code which will not be ignored unless the result has
already executed (executed = true)
Index:
DefaultActionInvocation.java===RCS
file:
/cvs/xwork/src/java/com/opensymphony/xwork/DefaultActionInvocation.java,vretrieving
revision 1.10diff -u -r1.10 DefaultActionInvocation.java---
DefaultActionInvocation.java15 Nov 2003 05:50:15 -1.10+++
DefaultActionInvocation.java18 Nov 2003 15:18:34 -@@ -93,49
+93,50 @@* @throws Exception*/
public Result getResult() throws Exception
{- if (result != null)
{-
Result returnResult =
result;--
// If we've chained to other Actions, we need to find the last
result-
while (returnResult instanceof ActionChainResult)
{-
ActionProxy aProxy = ((ActionChainResult)
returnResult).getProxy();--
if (aProxy != null)
{-
Result proxyResult =
aProxy.getInvocation().getResult();--
if ((proxyResult != null) (aProxy.getExecuteResult()))
{-
returnResult =
proxyResult;-
} else
{-
break;-
}-
} else
{-
break;-
}-
}--
return returnResult;- } else
{- Map
results =
proxy.getConfig().getResults();-
ResultConfig resultConfig = (ResultConfig)
results.get(resultCode);--
if (resultConfig != null)
{-
Class resultClass = resultConfig.getClazz();+
Result returnResult = result;++ // If
we've chained to other Actions, we need to find the last
result+ while (returnResult instanceof
ActionChainResult) {+
ActionProxy aProxy = ((ActionChainResult)
returnResult).getProxy();++
if (aProxy != null)
{+
Result proxyResult =
aProxy.getInvocation().getResult();++
if ((proxyResult != null) (aProxy.getExecuteResult()))
{+
returnResult =
proxyResult;+
} else
{+
break;+
}+ } else
{+
break;+
}+ }++
return returnResult;+ }+
+ public Result createResult() throws Exception
{+ Map results =
proxy.getConfig().getResults();+ ResultConfig
resultConfig = (ResultConfig) results.get(resultCode);+
Result newResult = null;+ + if
(resultConfig != null) {+ Class resultClass
= resultConfig.getClazz();++ if
(resultClass != null) {+ try
{+ newResult =
(Result)
resultClass.newInstance();+ }
catch (Exception e)
{+ LOG.error("There
was an exception while instantiating the result of type " + resultClass,
e);+ throw
e;+
}++
RE: [OS-webwork] Page attribute gone
I made the URLTag exactly like the 1.3/1.4 release. In fact, in 1.4 the page attribute does exist, but it is deprecated. Can someone explain the difference to me? Im a bit unfamiliar with all the URLTag stuff. VUI is the VoiceXML stuff from the 1.x line. -Pat -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Patterson Sent: Tuesday, November 18, 2003 12:54 AM To: Webwork Subject: [OS-webwork] Page attribute gone How come the page attribute of the URL tag has been removed? It is a little annoying to have to tripple quote static values (and hard to spot when you've missed one). The tld still allows a page attribute. Also, what is the com.opensymphony.veiws.jsp.vui package about? John.
RE: [OS-webwork] API changes, again!
I apologize for all the changes. The reason for the changes was to make 2.0 more compatible with 1.3 and to take advantage of all the things they learned and not toss it out the window. We don't plan on any major changes at this point. Again, my deepest apologies -- we should be through all the rough waters now. -Pat -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fred Lamuette Sent: Tuesday, November 18, 2003 6:10 AM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] API changes, again! The same for me. I think personnaly that too much stuff included in this endless beta 2 prevents it from being stable (yes i know it's a beta). But it is the choice of the project team, not mine. And I can only support the project with my patches, bugs submissions, remarks, but I do it with pleasure, because I believe in this project. But yess, it's very very painfull to upgrade and upgrade and upgrade and ... Cheers. Richard HALLIER Chef de projet [EMAIL PROTECTED] 01.40.12.41.52 www.uniclick.org UNICLICK -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] la part de Francisco Hernandez Envoye : mardi 18 novembre 2003 12:42 A : [EMAIL PROTECTED] Objet : Re: [OS-webwork] API changes, again! hehe I know how you feel, im in the process of upgrading to a newer version of ww2 and running into a bunch of problems, but its mainly lots of small tedious changes, like having to add single quotes tags and such, oh well. BOGAERT Mathias wrote: Hi, Just to let you guys know that I *again* have to upgrade my entire WebWork2 application. My previous version was from CVS 10/8/2003, and a lot of things seem to have changed. For instance, HttpServletRequestAware got ServletRequestAware (but still setting a HttpServletRequest??). All the templates have a new format, using parameters, so I have to migrate all my own templates (using CSS for tables) to the new format. I'm getting tired of migrating. If this happens again, I'm switching back to WW 1.3, at least I'll be ok for the next 6 months then. Mathias --- 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 ___ 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] ExceptionHandlerIntercepter
Title: Message
I
think you can do the trick with a stand-in stream, a response wrapper like the
one from Sitemesh is ok.
Richard.
-Message d'origine-De:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]De la part de
Jason CarreiraEnvoy: mardi 18 novembre 2003
16:59:
[EMAIL PROTECTED]Objet: RE:
[OS-webwork] ExceptionHandlerIntercepter
How
does this handle the issue of content having been written out by the first
result? Would you end up with part of the first page, then the error
page?
-Original Message-From: John Patterson
[mailto:[EMAIL PROTECTED] Sent: Tuesday, November
18, 2003 10:21 AMTo: WebworkSubject: [OS-webwork]
ExceptionHandlerIntercepter
I just discovered a problem with my
ExceptionHandlerInterceptor due to the design of the DefaultActionInvocation
class. I have made some changes to this class which fix the problem
and wouldlike to run them past everybody.
The ExceptionHandlerInterceptor catches any
exceptions that occur during the invoking of the action (and result) and
shows the ERROR result instead. During previous discussions on this
list, no alternative approaches were suggested that would allow
for:
1 - Catch exceptions
occurring in the Action AND Result
2 - Enable specific error
pages to be defined for each package or action
3 - Useaction
definitions definedin the xwork.xml (eg ERROR)
4 - Retain the
offending Action on the stackso it can be examined in an error
page.
Strangely enough, it appeared to be working
fine before (but for the wrong reasons).
The problem is this: if an exception occurs
while processing an Action then the interceptor can return ERROR and the
error Result is executed. However, if an exception occurs while
processing the Result and the interceptor returns ERROR, the error Result
isNOT executed. In fact the original result is executed again
(which will probably cause the exception again).
This is because once a Result has been
instantiated it is retained and reused no matter what resultCode is returned
from the interceptor. executeResult() calls getResult() which returns
the Result stored in an instance variable. It seems that the only
reason for this is so that other objects can get the result after it has
executed.
Some may say "Exceptions that happen while
executing the result should just be rethrown". But then how are we to
implement the error handling requirements above?
Anyway, the changes I made to
DefaultActionInvocation are VERY simple and fix the problem by splitting
getResult() into two methods (createResult() and getResult()).
executeResult() now calls createResult() instead of recycling the old
result.
It all seems to work OK and allows an
interceptor to return a result code which will not be ignored unless the
result has already executed (executed = true)
Index:
DefaultActionInvocation.java===RCS
file:
/cvs/xwork/src/java/com/opensymphony/xwork/DefaultActionInvocation.java,vretrieving
revision 1.10diff -u -r1.10 DefaultActionInvocation.java---
DefaultActionInvocation.java15 Nov 2003 05:50:15
-1.10+++ DefaultActionInvocation.java18 Nov 2003
15:18:34 -@@ -93,49 +93,50 @@* @throws
Exception*/ public Result getResult()
throws Exception {- if (result
!= null)
{-
Result returnResult =
result;--
// If we've chained to other Actions, we need to find the last
result-
while (returnResult instanceof ActionChainResult)
{-
ActionProxy aProxy = ((ActionChainResult)
returnResult).getProxy();--
if (aProxy != null)
{-
Result proxyResult =
aProxy.getInvocation().getResult();--
if ((proxyResult != null) (aProxy.getExecuteResult()))
{-
returnResult =
proxyResult;-
} else
{-
break;-
}-
} else
{-
break;-
}-
}--
return returnResult;- } else
{- Map
results =
proxy.getConfig().getResults();-
ResultConfig resultConfig = (ResultConfig)
results.get(resultCode);--
if (resultConfig != null)
{-
Class resultClass = resultConfig.getClazz();+
Result returnResult = result;++ // If
we've chained to other Actions, we need to find the last
result+ while (returnResult instanceof
ActionChainResult) {+
ActionProxy aProxy = ((ActionChainResult)
returnResult).getProxy();++
if (aProxy != null)
{+
Result proxyResult =
aProxy.getInvocation().getResult();++
if ((proxyResult != null) (aProxy.getExecuteResult()))
{+
returnResult =
proxyResult;+
} else
{+
break;+
}+ } else
{+
Re: [OS-webwork] ExceptionHandlerIntercepter
Title: Message
If the request has not been committed then the
ServletDispatcher is clever enough to doa dispatcher.forward() instead of
a dispatcher.include(). Therefore any uncommitted content in the buffer is
cleared. However, if the response is already committed
thenthere is no wayto handle an
exception gracefully.
If you want to make sure errors are handled
gracefully then you must set a reasonably large response buffer size. The
WW2 IncludeTag also buffers all content, no matter how large,so if you use
this then your error pages should be displayed OK (at the expense of higher
memory use).
As an aside, I use a customised IncludeTag that
does not buffer the contents but I will replace this with the ActionTag now that
it supports executing a result.
My HandleExceptionAction detects if the response
has been committed and if so it merely writes "There has been an error while
executing the action" using the JspWriter (or the response writer if there is no
page context). It will then return NONE to indicate that no Result is to
be executed.
However, the normal case is where the response has
not been committed and a nice error page specific to the section of the site
where the error occurred is shown to the user.
I have tested this with both a committed response
and a non-committed response and it works fine.
John.
- Original Message -
From:
Jason Carreira
To: [EMAIL PROTECTED]
Sent: Tuesday, November 18, 2003 3:58
PM
Subject: RE: [OS-webwork]
ExceptionHandlerIntercepter
How
does this handle the issue of content having been written out by the first
result? Would you end up with part of the first page, then the error
page?
-Original Message-From: John Patterson
[mailto:[EMAIL PROTECTED] Sent: Tuesday, November
18, 2003 10:21 AMTo: WebworkSubject: [OS-webwork]
ExceptionHandlerIntercepter
I just discovered a problem with my
ExceptionHandlerInterceptor due to the design of the DefaultActionInvocation
class. I have made some changes to this class which fix the problem
and wouldlike to run them past everybody.
The ExceptionHandlerInterceptor catches any
exceptions that occur during the invoking of the action (and result) and
shows the ERROR result instead. During previous discussions on this
list, no alternative approaches were suggested that would allow
for:
1 - Catch exceptions
occurring in the Action AND Result
2 - Enable specific error
pages to be defined for each package or action
3 - Useaction
definitions definedin the xwork.xml (eg ERROR)
4 - Retain the
offending Action on the stackso it can be examined in an error
page.
Strangely enough, it appeared to be working
fine before (but for the wrong reasons).
The problem is this: if an exception occurs
while processing an Action then the interceptor can return ERROR and the
error Result is executed. However, if an exception occurs while
processing the Result and the interceptor returns ERROR, the error Result
isNOT executed. In fact the original result is executed again
(which will probably cause the exception again).
This is because once a Result has been
instantiated it is retained and reused no matter what resultCode is returned
from the interceptor. executeResult() calls getResult() which returns
the Result stored in an instance variable. It seems that the only
reason for this is so that other objects can get the result after it has
executed.
Some may say "Exceptions that happen while
executing the result should just be rethrown". But then how are we to
implement the error handling requirements above?
Anyway, the changes I made to
DefaultActionInvocation are VERY simple and fix the problem by splitting
getResult() into two methods (createResult() and getResult()).
executeResult() now calls createResult() instead of recycling the old
result.
It all seems to work OK and allows an
interceptor to return a result code which will not be ignored unless the
result has already executed (executed = true)
Index:
DefaultActionInvocation.java===RCS
file:
/cvs/xwork/src/java/com/opensymphony/xwork/DefaultActionInvocation.java,vretrieving
revision 1.10diff -u -r1.10 DefaultActionInvocation.java---
DefaultActionInvocation.java15 Nov 2003 05:50:15
-1.10+++ DefaultActionInvocation.java18 Nov 2003
15:18:34 -@@ -93,49 +93,50 @@* @throws
Exception*/ public Result getResult()
throws Exception {- if (result
!= null)
{-
Result returnResult =
result;--
// If we've chained to other Actions, we need to find the last
result-
while (returnResult instanceof
RE: [OS-webwork] ExceptionHandlerIntercepter
Title: Message I'll take a look at the changes tonight... sounds like it's minor with no changes visible to the user. -Original Message-From: John Patterson [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 18, 2003 11:30 AMTo: [EMAIL PROTECTED]Subject: Re: [OS-webwork] ExceptionHandlerIntercepter If the request has not been committed then the ServletDispatcher is clever enough to doa dispatcher.forward() instead of a dispatcher.include(). Therefore any uncommitted content in the buffer is cleared. However, if the response is already committed thenthere is no wayto handle an exception gracefully. If you want to make sure errors are handled gracefully then you must set a reasonably large response buffer size. The WW2 IncludeTag also buffers all content, no matter how large,so if you use this then your error pages should be displayed OK (at the expense of higher memory use). As an aside, I use a customised IncludeTag that does not buffer the contents but I will replace this with the ActionTag now that it supports executing a result. My HandleExceptionAction detects if the response has been committed and if so it merely writes "There has been an error while executing the action" using the JspWriter (or the response writer if there is no page context). It will then return NONE to indicate that no Result is to be executed. However, the normal case is where the response has not been committed and a nice error page specific to the section of the site where the error occurred is shown to the user. I have tested this with both a committed response and a non-committed response and it works fine. John. - Original Message - From: Jason Carreira To: [EMAIL PROTECTED] Sent: Tuesday, November 18, 2003 3:58 PM Subject: RE: [OS-webwork] ExceptionHandlerIntercepter How does this handle the issue of content having been written out by the first result? Would you end up with part of the first page, then the error page? -Original Message-From: John Patterson [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 18, 2003 10:21 AMTo: WebworkSubject: [OS-webwork] ExceptionHandlerIntercepter I just discovered a problem with my ExceptionHandlerInterceptor due to the design of the DefaultActionInvocation class. I have made some changes to this class which fix the problem and wouldlike to run them past everybody. The ExceptionHandlerInterceptor catches any exceptions that occur during the invoking of the action (and result) and shows the ERROR result instead. During previous discussions on this list, no alternative approaches were suggested that would allow for: 1 - Catch exceptions occurring in the Action AND Result 2 - Enable specific error pages to be defined for each package or action 3 - Useaction definitions definedin the xwork.xml (eg ERROR) 4 - Retain the offending Action on the stackso it can be examined in an error page. Strangely enough, it appeared to be working fine before (but for the wrong reasons). The problem is this: if an exception occurs while processing an Action then the interceptor can return ERROR and the error Result is executed. However, if an exception occurs while processing the Result and the interceptor returns ERROR, the error Result isNOT executed. In fact the original result is executed again (which will probably cause the exception again). This is because once a Result has been instantiated it is retained and reused no matter what resultCode is returned from the interceptor. executeResult() calls getResult() which returns the Result stored in an instance variable. It seems that the only reason for this is so that other objects can get the result after it has executed. Some may say "Exceptions that happen while executing the result should just be rethrown". But then how are we to implement the error handling requirements above? Anyway, the changes I made to DefaultActionInvocation are VERY simple and fix the problem by splitting getResult() into two methods (createResult() and getResult()). executeResult() now calls createResult() instead of recycling the old result. It all seems to work OK and allows an interceptor to return a result code which will not be ignored unless the result has already executed (executed = true) Index: DefaultActionInvocation.java===RCS file:
Re: [OS-webwork] ExceptionHandlerIntercepter
any chance of getting this into webwork-ext?
John Patterson wrote:
I just discovered a problem with my ExceptionHandlerInterceptor due to
the design of the DefaultActionInvocation class. I have made some
changes to this class which fix the problem and would like to run them
past everybody.
The ExceptionHandlerInterceptor catches any exceptions that occur during
the invoking of the action (and result) and shows the ERROR result
instead. During previous discussions on this list, no alternative
approaches were suggested that would allow for:
1 - Catch exceptions occurring in the Action AND Result
2 - Enable specific error pages to be defined for each package or action
3 - Use action definitions defined in the xwork.xml (eg ERROR)
4 - Retain the offending Action on the stack so it can be examined
in an error page.
Strangely enough, it appeared to be working fine before (but for the
wrong reasons).
The problem is this: if an exception occurs while processing an Action
then the interceptor can return ERROR and the error Result is executed.
However, if an exception occurs while processing the Result and the
interceptor returns ERROR, the error Result is NOT executed. In fact
the original result is executed again (which will probably cause the
exception again).
This is because once a Result has been instantiated it is retained and
reused no matter what resultCode is returned from the interceptor.
executeResult() calls getResult() which returns the Result stored in an
instance variable. It seems that the only reason for this is so that
other objects can get the result after it has executed.
Some may say Exceptions that happen while executing the result should
just be rethrown. But then how are we to implement the error handling
requirements above?
Anyway, the changes I made to DefaultActionInvocation are VERY simple
and fix the problem by splitting getResult() into two methods
(createResult() and getResult()). executeResult() now calls
createResult() instead of recycling the old result.
It all seems to work OK and allows an interceptor to return a result
code which will not be ignored unless the result has already executed
(executed = true)
Index: DefaultActionInvocation.java
===
RCS file:
/cvs/xwork/src/java/com/opensymphony/xwork/DefaultActionInvocation.java,v
retrieving revision 1.10
diff -u -r1.10 DefaultActionInvocation.java
--- DefaultActionInvocation.java 15 Nov 2003 05:50:15 - 1.10
+++ DefaultActionInvocation.java 18 Nov 2003 15:18:34 -
@@ -93,49 +93,50 @@
* @throws Exception
*/
public Result getResult() throws Exception {
-if (result != null) {
-Result returnResult = result;
-
-// If we've chained to other Actions, we need to find the
last result
-while (returnResult instanceof ActionChainResult) {
-ActionProxy aProxy = ((ActionChainResult)
returnResult).getProxy();
-
-if (aProxy != null) {
-Result proxyResult =
aProxy.getInvocation().getResult();
-
-if ((proxyResult != null)
(aProxy.getExecuteResult())) {
-returnResult = proxyResult;
-} else {
-break;
-}
-} else {
-break;
-}
-}
-
-return returnResult;
-} else {
-Map results = proxy.getConfig().getResults();
-ResultConfig resultConfig = (ResultConfig)
results.get(resultCode);
-
-if (resultConfig != null) {
-Class resultClass = resultConfig.getClazz();
+ Result returnResult = result;
+
+ // If we've chained to other Actions, we need to find the last result
+ while (returnResult instanceof ActionChainResult) {
+ ActionProxy aProxy = ((ActionChainResult)
returnResult).getProxy();
+
+ if (aProxy != null) {
+ Result proxyResult = aProxy.getInvocation().getResult();
+
+ if ((proxyResult != null) (aProxy.getExecuteResult())) {
+ returnResult = proxyResult;
+ } else {
+ break;
+ }
+ } else {
+ break;
+ }
+ }
+
+ return returnResult;
+}
+
+public Result createResult() throws Exception {
+Map results = proxy.getConfig().getResults();
+ResultConfig resultConfig = (ResultConfig) results.get(resultCode);
+Result newResult = null;
+
+if (resultConfig != null) {
+ Class resultClass = resultConfig.getClazz();
+
+ if (resultClass != null) {
+try {
+ newResult = (Result) resultClass.newInstance();
+} catch (Exception e) {
+ LOG.error(There was an exception while instantiating the
result of type + resultClass, e);
+ throw e;
+}
+
+
RE: [OS-webwork] formatting dates and numbers
Actually, ww:property doesn't not to toString(). It calls findValue(expr, String.class) and then let's Ognl try to do some type-conversion. You are more than welcome to add a type converter that does what you need. Or you can use i18n :) -Pat -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Konstantin Priblouda Sent: Tuesday, November 18, 2003 3:42 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] formatting dates and numbers --- Paul Knepper [EMAIL PROTECTED] wrote: I'm using jsp pages with ww:property tags to output data. How do I format dates and numbers? I would like to specify dates as /mm/dd. And I'd like to format numbers regarding number of digits for precision etc... ww:property would do toString(), which is not what you want... I put formatter tool ( bean ) into respective context instead, and use it. regards, = [ Konstantin Pribluda ( ko5tik ) ] Zu Verstärkung meines Teams suche ich ab Sofort einen Softwareentwickler[In] für die Festanstellung. Arbeitsort: Mainz Skills: Programieren, Kentnisse in OpenSource-Bereich [ http://www.pribluda.de ] __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree --- 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] formatting dates and numbers
ok I was confused because I saw a text.vm and not a textfield.vm but the
textfield tag is still there.
Jason Carreira wrote:
ww:text is for finding localized text messages... It's not a UI
component
-Original Message-
From: Francisco Hernandez [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 18, 2003 2:29 AM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] formatting dates and numbers
hmm having looked at text.vm template its used for displaying
a input
type=text tag.. and what happened to textfield tag too?
Patrick Lightbody wrote:
Haha, examples. Good one :P
Actually, the examples for 1.3 should work, since i18n
hasn't change
in 2.0. Actually, if you know a bit about ResourceBundles
and i18n in
general, the ww:text/ tag shouldn't be too tough.
Essentially, if your action is Foo (extends ActionSupport),
and it has
a property date, then you do:
ww:text name='some.date' arg0=date/
OR
ww:text name='some.date'
ww:param value=date/
/ww:text
OR
ww:property value=text('some.date', {date})'/
All of those will result in ActionSupport.getText() being called.
You'll need a file called Foo.properties that has an entry:
some.date = {0,date}
-Pat
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
On Behalf Of
Paul Knepper
Sent: Monday, November 17, 2003 1:46 PM
To: [EMAIL PROTECTED]
Subject: RE: [OS-webwork] formatting dates and numbers
I'm using WebWork2. Are there any examples?
-Original Message-
From: Cuong Tran [mailto:[EMAIL PROTECTED]
Sent: Monday, November 17, 2003 12:21 PM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] formatting dates and numbers
I'd use the ww:text tag for that.
--- Paul Knepper [EMAIL PROTECTED] wrote:
I'm using jsp pages with ww:property tags to output data.
How do I format dates and numbers? I would like to specify
dates as
/mm/dd. And I'd like to format numbers regarding
number of digits
for precision etc...
Thanks,
Paul
---
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.tm
pl
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
__
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree
---
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.tm
pl
___
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=/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.tm
pl
___
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=/g22lp.tmpl
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
RE: [OS-webwork] formatting dates and numbers
On a minor note, should the template be named textfield instead of
text?
--- Jason Carreira [EMAIL PROTECTED] wrote:
ww:text is for finding localized text messages... It's not a UI
component
-Original Message-
From: Francisco Hernandez [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 18, 2003 2:29 AM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] formatting dates and numbers
hmm having looked at text.vm template its used for displaying
a input
type=text tag.. and what happened to textfield tag too?
Patrick Lightbody wrote:
Haha, examples. Good one :P
Actually, the examples for 1.3 should work, since i18n
hasn't change
in 2.0. Actually, if you know a bit about ResourceBundles
and i18n in
general, the ww:text/ tag shouldn't be too tough.
Essentially, if your action is Foo (extends ActionSupport),
and it has
a property date, then you do:
ww:text name='some.date' arg0=date/
OR
ww:text name='some.date'
ww:param value=date/
/ww:text
OR
ww:property value=text('some.date', {date})'/
All of those will result in ActionSupport.getText() being
called.
You'll need a file called Foo.properties that has an entry:
some.date = {0,date}
-Pat
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
On Behalf Of
Paul Knepper
Sent: Monday, November 17, 2003 1:46 PM
To: [EMAIL PROTECTED]
Subject: RE: [OS-webwork] formatting dates and numbers
I'm using WebWork2. Are there any examples?
-Original Message-
From: Cuong Tran [mailto:[EMAIL PROTECTED]
Sent: Monday, November 17, 2003 12:21 PM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] formatting dates and numbers
I'd use the ww:text tag for that.
--- Paul Knepper [EMAIL PROTECTED] wrote:
I'm using jsp pages with ww:property tags to output data.
How do I format dates and numbers? I would like to specify
dates as
/mm/dd. And I'd like to format numbers regarding
number of digits
for precision etc...
Thanks,
Paul
---
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.tm
pl
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
__
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree
---
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.tm
pl
___
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=/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.tm
pl
___
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] ExceptionHandlerIntercepter
Title: Message I will put the related files (interceptor, sample action) into Jira as soon as I can. - Original Message - From: Jason Carreira To: [EMAIL PROTECTED] Sent: Tuesday, November 18, 2003 4:41 PM Subject: RE: [OS-webwork] ExceptionHandlerIntercepter I'll take a look at the changes tonight... sounds like it's minor with no changes visible to the user. -Original Message-From: John Patterson [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 18, 2003 11:30 AMTo: [EMAIL PROTECTED]Subject: Re: [OS-webwork] ExceptionHandlerIntercepter If the request has not been committed then the ServletDispatcher is clever enough to doa dispatcher.forward() instead of a dispatcher.include(). Therefore any uncommitted content in the buffer is cleared. However, if the response is already committed thenthere is no wayto handle an exception gracefully. If you want to make sure errors are handled gracefully then you must set a reasonably large response buffer size. The WW2 IncludeTag also buffers all content, no matter how large,so if you use this then your error pages should be displayed OK (at the expense of higher memory use). As an aside, I use a customised IncludeTag that does not buffer the contents but I will replace this with the ActionTag now that it supports executing a result. My HandleExceptionAction detects if the response has been committed and if so it merely writes "There has been an error while executing the action" using the JspWriter (or the response writer if there is no page context). It will then return NONE to indicate that no Result is to be executed. However, the normal case is where the response has not been committed and a nice error page specific to the section of the site where the error occurred is shown to the user. I have tested this with both a committed response and a non-committed response and it works fine. John. - Original Message - From: Jason Carreira To: [EMAIL PROTECTED] Sent: Tuesday, November 18, 2003 3:58 PM Subject: RE: [OS-webwork] ExceptionHandlerIntercepter How does this handle the issue of content having been written out by the first result? Would you end up with part of the first page, then the error page? -Original Message-From: John Patterson [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 18, 2003 10:21 AMTo: WebworkSubject: [OS-webwork] ExceptionHandlerIntercepter I just discovered a problem with my ExceptionHandlerInterceptor due to the design of the DefaultActionInvocation class. I have made some changes to this class which fix the problem and wouldlike to run them past everybody. The ExceptionHandlerInterceptor catches any exceptions that occur during the invoking of the action (and result) and shows the ERROR result instead. During previous discussions on this list, no alternative approaches were suggested that would allow for: 1 - Catch exceptions occurring in the Action AND Result 2 - Enable specific error pages to be defined for each package or action 3 - Useaction definitions definedin the xwork.xml (eg ERROR) 4 - Retain the offending Action on the stackso it can be examined in an error page. Strangely enough, it appeared to be working fine before (but for the wrong reasons). The problem is this: if an exception occurs while processing an Action then the interceptor can return ERROR and the error Result is executed. However, if an exception occurs while processing the Result and the interceptor returns ERROR, the error Result isNOT executed. In fact the original result is executed again (which will probably cause the exception again). This is because once a Result has been instantiated it is retained and reused no matter what resultCode is returned from the interceptor. executeResult() calls getResult() which returns the Result stored in an instance variable. It seems that the only reason for this is so that other objects can get the result after it has executed. Some may say "Exceptions that happen while executing the result should just be rethrown". But then how are we to implement the error handling requirements above? Anyway, the changes I made to DefaultActionInvocation are VERY simple and fix the problem by splitting getResult() into two methods
RE: [OS-webwork] Param directive
That would be fine by me. Being able to set the default would be especially nice. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fred Lamuette Sent: Tuesday, November 18, 2003 1:13 AM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] Param directive I dont think two #param directives are a good idea. What about a default behaviour defined in the webwork.properties ? With an attribute in param tag to override the default, it would be nice. Cheers. Richard HALLIER Chef de projet [EMAIL PROTECTED] 01.40.12.41.52 www.uniclick.org UNICLICK -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] la part de Francisco Hernandez Envoye : mardi 18 novembre 2003 08:33 A : [EMAIL PROTECTED] Objet : Re: [OS-webwork] Param directive why create another property tag instead of just adding an attribute to handle escaping (which i thought it had..)? same thing for the param tag, couldnt an attribute be added to eval or not? Patrick Lightbody wrote: What we need to solve all this is: * two #param directives (one which evaluates, one which doesn't) * two #property directives (one which escapes, one which doesn't) With the above to things, velocity templates would be able to do all the things JSPs can. In fact, the two #param directives is something that JSP doesn't support, but that's because JSP doesn't have it's own EL, whereas Velocity does and so taking advantage of it is a good idea. Would that work for everyone? Got an suggestions for the names of the directives? -Pat -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Drew McAuliffe Sent: Monday, November 17, 2003 3:15 PM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] Param directive As I said in another reply, the biggest problem is that you can't use an object variable in velocity, since it always gets converted to a string first. If I have a collection of model objects, and want to call a component tag with them in an iteration through the collection, I can't, because a call to the component tag with the former behavior can only pass in the reference to the model object, converted to a string. For example, for a model object like PhoneNumber -number -area code -number type the new behavior will allow for syntax like this: #foreach ($number in $person.phoneNumbers) #bodytag (Component template=numberDisplay.vm) #param(phoneNumber $number) #end #end If you always call stack.findValue() behind the scenes, there's no way the value stack can know the value of a velocity variable unless you manually push it onto the stack, then pop it off. That's a hack to me, and is also inconsistent with the way every other velocity directive or macro works (directives and macros allow object references to be passed in, not just strings). The new approach still allows for strings evaluation, but it forces a manual call to $stack.findValue(). I think that's a fair tradeoff. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fred Lamuette Sent: Monday, November 17, 2003 9:16 AM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] Param directive As far as I am concerned this approach is not the correct one ! I explain my point of view with an example : With the latest XWork+WW2 cvs snapshot, you can write a select tag both ways : 1/ #tag(Select name='nameValue' ...) - in this case, the parameter with key=name and value=stack.findValue(nameValue) is added to the parameters map. is equivalent to #bodytag(Select ) #param(name nameValue) - in this case, the parameter with key=name and value=nameValue is added to the parameters map. #end 2/ #tag(Select name=nameValue ...) is equivalent to #bodytag(Select ) #param(name $stack.findValue($nameValue)) #end You can admit it's not very coherent, you have two different behaviors according to what you use (extra tags or external params) whereas the same handling behind is used (extra tags are converted as parameters). Can you explain to me what are your arguments ? Richard HALLIER Chef de projet [EMAIL PROTECTED] 01.40.12.41.52 www.uniclick.org UNICLICK I believe some people asked for it to be that way as it's more natural for a Velocity context... I may be wrong though.. -Original Message- From: Fred Lamuette [mailto:[EMAIL PROTECTED] Sent: Monday, November 17, 2003 9:34 AM To: [EMAIL PROTECTED] Subject: [OS-webwork] Param directive Having the latest XWork+WW2 cvs snapshot, I can notice a behavior change for the param directive. Before #param(paramName paramValue) - store in the parameters list, the value OgnlValueStack.findValue(paramValue) From now #param(paramName paramValue) - store in the parameters list, the value paramValue Why did you change the previous behavior ? Richard HALLIER Chef de projet [EMAIL
RE: [OS-webwork] Param directive
My biggest problem with this is that it basically eliminates any advantage to using velocity as far as ease of use is concerned. One of the main reasons I prefer velocity over JSP is that the syntax is more natural, especially for things like iterations. Requiring two extra lines makes the whole thing ugly, unintuitive, and increases the possibility of errors (what if you forget to pop the item off of the stack? The possibility of subtle, hard to find errors over a large code base is definitely there). Also, the value stack should be used when it is necessary to be used. Passing a variable to a tag via a velocity directive doesn't seem to me like it needs to get the stack involved. You have a velocity approach the moment you start to use velocity as your templating language. The stack is a utility object that is available to your pages, and is obviously a core part of the framework, but if it doesn't need to get involved, it shouldn't. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fred Lamuette Sent: Tuesday, November 18, 2003 1:06 AM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] Param directive Here is the different point of view. I personnaly think the push/pop actions are NOT a hack. Either you have a WW2 approach or a Velocity one. I think we are in the first one, that makes all the difference, the stack is the main way to access data. If you need to pass reference objects without pushing on the stack, just use velocity macros, it works perfectly. And I'd like to point out that you can ALWAYS pass in any object references via ognl (stack.findValue), you have just to push the needed object, in your example : #foreach( $number in $person.phoneNumbers ) $stack.push($number) #bodytag(Component template=numberDisplay.vm) #param(phoneNumber top) - actually, (behavior in the previous release) you pass $stack.findValue(top) = $number. #end #set ($trash = $stack.pop()) #end In your component numberDisplay.vm, you can use $parameters.phoneNumber as a direct reference : -- #set($phoneNumer = $parameters.phoneNumber ) $phoneNumber.number $phoneNumber.areaCode ... My conclusion would be : 1/ All you found impossible (pass in object references) is actually possible via the stack. 2/ I think it's important to keep the WebWork philosophy (data in a stack) to not break the consistency. 3/ Keep in mind, accessing the stack relies on ognl which is very very powerfull (projection for instance). I hope I convince you to keep as a standard the data access via the stack. Richard HALLIER Chef de projet [EMAIL PROTECTED] 01.40.12.41.52 www.uniclick.org UNICLICK -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] la part de Drew McAuliffe Envoye : mardi 18 novembre 2003 00:15 A : [EMAIL PROTECTED] Objet : RE: [OS-webwork] Param directive As I said in another reply, the biggest problem is that you can't use an object variable in velocity, since it always gets converted to a string first. If I have a collection of model objects, and want to call a component tag with them in an iteration through the collection, I can't, because a call to the component tag with the former behavior can only pass in the reference to the model object, converted to a string. For example, for a model object like PhoneNumber -number -area code -number type the new behavior will allow for syntax like this: #foreach ($number in $person.phoneNumbers) #bodytag (Component template=numberDisplay.vm) #param(phoneNumber $number) #end #end If you always call stack.findValue() behind the scenes, there's no way the value stack can know the value of a velocity variable unless you manually push it onto the stack, then pop it off. That's a hack to me, and is also inconsistent with the way every other velocity directive or macro works (directives and macros allow object references to be passed in, not just strings). The new approach still allows for strings evaluation, but it forces a manual call to $stack.findValue(). I think that's a fair tradeoff. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fred Lamuette Sent: Monday, November 17, 2003 9:16 AM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] Param directive As far as I am concerned this approach is not the correct one ! I explain my point of view with an example : With the latest XWork+WW2 cvs snapshot, you can write a select tag both ways : 1/ #tag(Select name='nameValue' ...) - in this case, the parameter with key=name and value=stack.findValue(nameValue) is added to the parameters map. is equivalent to #bodytag(Select ) #param(name nameValue) - in this case, the parameter with key=name and value=nameValue is added to the parameters map. #end 2/ #tag(Select name=nameValue ...) is equivalent to
RE: [OS-webwork] Param directive
That's when stuff starts to get REALLY ugly. Though I guess there's no sense arguing about it now, since it looks like we get the best of both worlds. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fred Lamuette Sent: Tuesday, November 18, 2003 2:56 AM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] Param directive what if in your example you needed 2 objects to be avaiable in your Component? double push would a ww:set be needed? ??? Richard HALLIER Chef de projet [EMAIL PROTECTED] 01.40.12.41.52 www.uniclick.org UNICLICK -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] la part de Francisco Hernandez Envoye : mardi 18 novembre 2003 11:21 A : [EMAIL PROTECTED] Objet : Re: [OS-webwork] Param directive what if in your example you needed 2 objects to be avaiable in your Component? would a ww:set be needed? Fred Lamuette wrote: Here is the different point of view. I personnaly think the push/pop actions are NOT a hack. Either you have a WW2 approach or a Velocity one. I think we are in the first one, that makes all the difference, the stack is the main way to access data. If you need to pass reference objects without pushing on the stack, just use velocity macros, it works perfectly. And I'd like to point out that you can ALWAYS pass in any object references via ognl (stack.findValue), you have just to push the needed object, in your example : #foreach( $number in $person.phoneNumbers ) $stack.push($number) #bodytag(Component template=numberDisplay.vm) #param(phoneNumber top) - actually, (behavior in the previous release) you pass $stack.findValue(top) = $number. #end #set ($trash = $stack.pop()) #end In your component numberDisplay.vm, you can use $parameters.phoneNumber as a direct reference : -- -- -- #set($phoneNumer = $parameters.phoneNumber ) $phoneNumber.number $phoneNumber.areaCode ... My conclusion would be : 1/ All you found impossible (pass in object references) is actually possible via the stack. 2/ I think it's important to keep the WebWork philosophy (data in a stack) to not break the consistency. 3/ Keep in mind, accessing the stack relies on ognl which is very very powerfull (projection for instance). I hope I convince you to keep as a standard the data access via the stack. Richard HALLIER Chef de projet [EMAIL PROTECTED] 01.40.12.41.52 www.uniclick.org UNICLICK -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] la part de Drew McAuliffe Envoye : mardi 18 novembre 2003 00:15 A : [EMAIL PROTECTED] Objet : RE: [OS-webwork] Param directive As I said in another reply, the biggest problem is that you can't use an object variable in velocity, since it always gets converted to a string first. If I have a collection of model objects, and want to call a component tag with them in an iteration through the collection, I can't, because a call to the component tag with the former behavior can only pass in the reference to the model object, converted to a string. For example, for a model object like PhoneNumber -number -area code -number type the new behavior will allow for syntax like this: #foreach ($number in $person.phoneNumbers) #bodytag (Component template=numberDisplay.vm) #param(phoneNumber $number) #end #end If you always call stack.findValue() behind the scenes, there's no way the value stack can know the value of a velocity variable unless you manually push it onto the stack, then pop it off. That's a hack to me, and is also inconsistent with the way every other velocity directive or macro works (directives and macros allow object references to be passed in, not just strings). The new approach still allows for strings evaluation, but it forces a manual call to $stack.findValue(). I think that's a fair tradeoff. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fred Lamuette Sent: Monday, November 17, 2003 9:16 AM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] Param directive As far as I am concerned this approach is not the correct one ! I explain my point of view with an example : With the latest XWork+WW2 cvs snapshot, you can write a select tag both ways : 1/ #tag(Select name='nameValue' ...) - in this case, the parameter with key=name and value=stack.findValue(nameValue) is added to the parameters map. is equivalent to #bodytag(Select ) #param(name nameValue) - in this case, the parameter with key=name and value=nameValue is added to the parameters map. #end 2/ #tag(Select name=nameValue ...) is equivalent to #bodytag(Select ) #param(name $stack.findValue($nameValue)) #end You can admit it's not very coherent, you have two
Re: [OS-webwork] Param directive
+1, the valuestack is a neat thing and all that, but having random pushs/pops happen in UI tags of all things just feels wrong. Drew McAuliffe wrote: My biggest problem with this is that it basically eliminates any advantage to using velocity as far as ease of use is concerned. One of the main reasons I prefer velocity over JSP is that the syntax is more natural, especially for things like iterations. Requiring two extra lines makes the whole thing ugly, unintuitive, and increases the possibility of errors (what if you forget to pop the item off of the stack? The possibility of subtle, hard to find errors over a large code base is definitely there). Also, the value stack should be used when it is necessary to be used. Passing a variable to a tag via a velocity directive doesn't seem to me like it needs to get the stack involved. You have a velocity approach the moment you start to use velocity as your templating language. The stack is a utility object that is available to your pages, and is obviously a core part of the framework, but if it doesn't need to get involved, it shouldn't. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fred Lamuette Sent: Tuesday, November 18, 2003 1:06 AM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] Param directive Here is the different point of view. I personnaly think the push/pop actions are NOT a hack. Either you have a WW2 approach or a Velocity one. I think we are in the first one, that makes all the difference, the stack is the main way to access data. If you need to pass reference objects without pushing on the stack, just use velocity macros, it works perfectly. And I'd like to point out that you can ALWAYS pass in any object references via ognl (stack.findValue), you have just to push the needed object, in your example : #foreach( $number in $person.phoneNumbers ) $stack.push($number) #bodytag(Component template=numberDisplay.vm) #param(phoneNumber top) - actually, (behavior in the previous release) you pass $stack.findValue(top) = $number. #end #set ($trash = $stack.pop()) #end In your component numberDisplay.vm, you can use $parameters.phoneNumber as a direct reference : -- #set($phoneNumer = $parameters.phoneNumber ) $phoneNumber.number $phoneNumber.areaCode ... My conclusion would be : 1/ All you found impossible (pass in object references) is actually possible via the stack. 2/ I think it's important to keep the WebWork philosophy (data in a stack) to not break the consistency. 3/ Keep in mind, accessing the stack relies on ognl which is very very powerfull (projection for instance). I hope I convince you to keep as a standard the data access via the stack. Richard HALLIER Chef de projet [EMAIL PROTECTED] 01.40.12.41.52 www.uniclick.org UNICLICK -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] la part de Drew McAuliffe Envoye : mardi 18 novembre 2003 00:15 A : [EMAIL PROTECTED] Objet : RE: [OS-webwork] Param directive As I said in another reply, the biggest problem is that you can't use an object variable in velocity, since it always gets converted to a string first. If I have a collection of model objects, and want to call a component tag with them in an iteration through the collection, I can't, because a call to the component tag with the former behavior can only pass in the reference to the model object, converted to a string. For example, for a model object like PhoneNumber -number -area code -number type the new behavior will allow for syntax like this: #foreach ($number in $person.phoneNumbers) #bodytag (Component template=numberDisplay.vm) #param(phoneNumber $number) #end #end If you always call stack.findValue() behind the scenes, there's no way the value stack can know the value of a velocity variable unless you manually push it onto the stack, then pop it off. That's a hack to me, and is also inconsistent with the way every other velocity directive or macro works (directives and macros allow object references to be passed in, not just strings). The new approach still allows for strings evaluation, but it forces a manual call to $stack.findValue(). I think that's a fair tradeoff. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fred Lamuette Sent: Monday, November 17, 2003 9:16 AM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] Param directive As far as I am concerned this approach is not the correct one ! I explain my point of view with an example : With the latest XWork+WW2 cvs snapshot, you can write a select tag both ways : 1/ #tag(Select name='nameValue' ...) - in this case, the parameter with key=name and value=stack.findValue(nameValue) is added to the parameters map. is equivalent to #bodytag(Select ) #param(name nameValue) - in this case, the parameter
RE: [OS-webwork] Param directive
I keep my opinion, but I'm happy to see the different points of view are respected by choosing to solve elegantly the problem :-). Richard. -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] la part de Hani Suleiman Envoye : mardi 18 novembre 2003 18:10 A : [EMAIL PROTECTED] Objet : Re: [OS-webwork] Param directive +1, the valuestack is a neat thing and all that, but having random pushs/pops happen in UI tags of all things just feels wrong. Drew McAuliffe wrote: My biggest problem with this is that it basically eliminates any advantage to using velocity as far as ease of use is concerned. One of the main reasons I prefer velocity over JSP is that the syntax is more natural, especially for things like iterations. Requiring two extra lines makes the whole thing ugly, unintuitive, and increases the possibility of errors (what if you forget to pop the item off of the stack? The possibility of subtle, hard to find errors over a large code base is definitely there). Also, the value stack should be used when it is necessary to be used. Passing a variable to a tag via a velocity directive doesn't seem to me like it needs to get the stack involved. You have a velocity approach the moment you start to use velocity as your templating language. The stack is a utility object that is available to your pages, and is obviously a core part of the framework, but if it doesn't need to get involved, it shouldn't. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fred Lamuette Sent: Tuesday, November 18, 2003 1:06 AM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] Param directive Here is the different point of view. I personnaly think the push/pop actions are NOT a hack. Either you have a WW2 approach or a Velocity one. I think we are in the first one, that makes all the difference, the stack is the main way to access data. If you need to pass reference objects without pushing on the stack, just use velocity macros, it works perfectly. And I'd like to point out that you can ALWAYS pass in any object references via ognl (stack.findValue), you have just to push the needed object, in your example : #foreach( $number in $person.phoneNumbers ) $stack.push($number) #bodytag(Component template=numberDisplay.vm) #param(phoneNumber top) - actually, (behavior in the previous release) you pass $stack.findValue(top) = $number. #end #set ($trash = $stack.pop()) #end In your component numberDisplay.vm, you can use $parameters.phoneNumber as a direct reference : -- -- -- #set($phoneNumer = $parameters.phoneNumber ) $phoneNumber.number $phoneNumber.areaCode ... My conclusion would be : 1/ All you found impossible (pass in object references) is actually possible via the stack. 2/ I think it's important to keep the WebWork philosophy (data in a stack) to not break the consistency. 3/ Keep in mind, accessing the stack relies on ognl which is very very powerfull (projection for instance). I hope I convince you to keep as a standard the data access via the stack. Richard HALLIER Chef de projet [EMAIL PROTECTED] 01.40.12.41.52 www.uniclick.org UNICLICK -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] la part de Drew McAuliffe Envoye : mardi 18 novembre 2003 00:15 A : [EMAIL PROTECTED] Objet : RE: [OS-webwork] Param directive As I said in another reply, the biggest problem is that you can't use an object variable in velocity, since it always gets converted to a string first. If I have a collection of model objects, and want to call a component tag with them in an iteration through the collection, I can't, because a call to the component tag with the former behavior can only pass in the reference to the model object, converted to a string. For example, for a model object like PhoneNumber -number -area code -number type the new behavior will allow for syntax like this: #foreach ($number in $person.phoneNumbers) #bodytag (Component template=numberDisplay.vm) #param(phoneNumber $number) #end #end If you always call stack.findValue() behind the scenes, there's no way the value stack can know the value of a velocity variable unless you manually push it onto the stack, then pop it off. That's a hack to me, and is also inconsistent with the way every other velocity directive or macro works (directives and macros allow object references to be passed in, not just strings). The new approach still allows for strings evaluation, but it forces a manual call to $stack.findValue(). I think that's a fair tradeoff. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fred Lamuette Sent: Monday, November 17, 2003 9:16 AM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] Param
RE: [OS-webwork] API changes, again!
Whoa trigger. Please don't blame WebWork2 for being beta. I would much rather they get this right in beta regardless of how many changes they have to make then to either lock us into a bad solution or change after the production release is made. When developing on the bleeding edge you usually do get cut every now and then. Kris Thompson -Original Message- From: BOGAERT Mathias [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 18, 2003 3:52 AM To: [EMAIL PROTECTED] Subject: [OS-webwork] API changes, again! Hi, Just to let you guys know that I *again* have to upgrade my entire WebWork2 application. My previous version was from CVS 10/8/2003, and a lot of things seem to have changed. For instance, HttpServletRequestAware got ServletRequestAware (but still setting a HttpServletRequest??). All the templates have a new format, using parameters, so I have to migrate all my own templates (using CSS for tables) to the new format. I'm getting tired of migrating. If this happens again, I'm switching back to WW 1.3, at least I'll be ok for the next 6 months then. Mathias --- 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: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] API changes, again!
Well, it is kind of amusing Mathias is saying he'll switch to 1.3, given that these changes make 2.0 have the exact same interface/tags/etc as 1.x :P -Pat -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thompson, Christopher C (Kris) Sent: Tuesday, November 18, 2003 12:54 PM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] API changes, again! Whoa trigger. Please don't blame WebWork2 for being beta. I would much rather they get this right in beta regardless of how many changes they have to make then to either lock us into a bad solution or change after the production release is made. When developing on the bleeding edge you usually do get cut every now and then. Kris Thompson -Original Message- From: BOGAERT Mathias [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 18, 2003 3:52 AM To: [EMAIL PROTECTED] Subject: [OS-webwork] API changes, again! Hi, Just to let you guys know that I *again* have to upgrade my entire WebWork2 application. My previous version was from CVS 10/8/2003, and a lot of things seem to have changed. For instance, HttpServletRequestAware got ServletRequestAware (but still setting a HttpServletRequest??). All the templates have a new format, using parameters, so I have to migrate all my own templates (using CSS for tables) to the new format. I'm getting tired of migrating. If this happens again, I'm switching back to WW 1.3, at least I'll be ok for the next 6 months then. Mathias --- 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: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] API changes, again!
Actually, I agree with this. It's stupid of people to hop on a beta bandwagon then express indignation when the rug is pulled from under them. That's the whole POINT of a beta, to stumble about in various directions until the correct one reveals itself. Thompson, Christopher C (Kris) wrote: Whoa trigger. Please don't blame WebWork2 for being beta. I would much rather they get this right in beta regardless of how many changes they have to make then to either lock us into a bad solution or change after the production release is made. When developing on the bleeding edge you usually do get cut every now and then. Kris Thompson -Original Message- From: BOGAERT Mathias [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 18, 2003 3:52 AM To: [EMAIL PROTECTED] Subject: [OS-webwork] API changes, again! Hi, Just to let you guys know that I *again* have to upgrade my entire WebWork2 application. My previous version was from CVS 10/8/2003, and a lot of things seem to have changed. For instance, HttpServletRequestAware got ServletRequestAware (but still setting a HttpServletRequest??). All the templates have a new format, using parameters, so I have to migrate all my own templates (using CSS for tables) to the new format. I'm getting tired of migrating. If this happens again, I'm switching back to WW 1.3, at least I'll be ok for the next 6 months then. Mathias --- 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: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Param directive
Hani Suleiman wrote: +1, the valuestack is a neat thing and all that, but having random pushs/pops happen in UI tags of all things just feels wrong. Agreed. However, I'm unclear why pushes and pops are required though. #foreach( $number in $person.phoneNumbers ) $stack.push($number) #bodytag(Component template=numberDisplay.vm) #param(phoneNumber top) #end #set ($trash = $stack.pop()) #end Why wouldn't you just write: #foreach( $number in $person.phoneNumbers ) #bodytag( Component template=numberDisplay.vm ) #param( phoneNumber $number ) #end #end Or what I'd be more inclined to write: #foreach( $number in $person.phoneNumbers ) #tag( Component template=numberDisplay.vm params.phoneNumber=person.phoneNumbers[$velocityCount] ) #end Although I do admit the latter is less intuitive than the former. M --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] API changes, again!
Patrick Lightbody wrote: Well, it is kind of amusing Mathias is saying he'll switch to 1.3, given that these changes make 2.0 have the exact same interface/tags/etc as 1.x :P -Pat Except the property tag I hope :P Anders Hovmöller --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] WebWork 1.4 release
Hi Hani, I think it would be good if you put the release on sourceforge as well since people might find webwork there also. Cheers, Dick Zetterberg [EMAIL PROTECTED] - Original Message - From: Hani Suleiman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, November 18, 2003 2:35 AM Subject: [OS-webwork] WebWork 1.4 release All, WebWork 1.4 has been released, appropriate press blurbage will be showing up on your regular news channels in the next day or so I expect. You can grab it from https://webwork.dev.java.net/files/documents/693/1790/webwork-1.4.zip Any feedback/testing would be most appreciated. I think it's a pretty solid release with plenty of fixes and good reasons to upgrade. Release notes can be found at https://webwork.dev.java.net/servlets/ProjectDocumentView? documentID=1791noNav=true Thanks to all those who contributed, by filing issues, writing docs, fixing bugs, writing incredibly cool and fast new parsers, emailing in code, and providing encouragement. Thanks to the ww2 guys for providing motivation too (and I don't mean that in a snide way!). Enjoy! --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] API changes, again!
:-) Yes, the property tag is an exception a couple times over -Original Message- From: boxed [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 18, 2003 4:24 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] API changes, again! Patrick Lightbody wrote: Well, it is kind of amusing Mathias is saying he'll switch to 1.3, given that these changes make 2.0 have the exact same interface/tags/etc as 1.x :P -Pat Except the property tag I hope :P Anders Hovmöller --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Latest xwork cvs snapshot
I'm wondering if this fix is in also. I am still breaking like this in CVS. Thanks, Anoop On Nov 18, 2003, at 9:23 AM, Fred Lamuette wrote: Is your fix committed ? -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] la part de Patrick Lightbody Envoye : mardi 18 novembre 2003 07:41 A : [EMAIL PROTECTED] Objet : RE: [OS-webwork] Latest xwork cvs snapshot Richard, I've fixed this. The down side of all this is that if you have null as an arg to a method call, the optimizations I made to get monthlist from 4X to 2X will be lost. In the future I could probably get those optimizations back, but for now this works and is really simple. -Pat -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fred Lamuette Sent: Monday, November 17, 2003 9:37 AM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] Latest xwork cvs snapshot Jira is down for the while, but as soon as possible, I'm gonna to open a jira issue. As far as I have seen your code improvment, I believe it will appreciably increase the speed. Pat, what about the real problem that Ognl 2.6.4 should fix ? Do you wait for the next release of Ognl ? Richard. -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] la part de Patrick Lightbody Envoye : lundi 17 novembre 2003 17:08 A : [EMAIL PROTECTED] Objet : RE: [OS-webwork] Latest xwork cvs snapshot Richard, Thanks, I wasn't expecting a null argument. I'll need to fix that. This change was an optimization that got us from 4X to 2X speed difference in the monthlist tests. Anyway, please open a bug and I'll get to it promptly. -Pat -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fred Lamuette Sent: Monday, November 17, 2003 5:56 AM To: [EMAIL PROTECTED] Subject: [OS-webwork] Latest xwork cvs snapshot I guess many refactorings happens in xwork (possibly to fix invalid methods ?) , especially in CompoundRootAccessor, and my current code is not working. The following example doesnt work anymore : stack.findValue(format(myDate)). The error comes from the fact that the (Object[] objects ) argument passed to the CompoundRootAccessor.callMethod(...) is an array of size 1 containing a null object. Thus, the getArgTypes(objects) throws a NPE. Hope it can help. Richard. --- 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 ___ 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 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here:
Re: [OS-webwork] WebWork 1.4 release
Done Dick Zetterberg wrote: Hi Hani, I think it would be good if you put the release on sourceforge as well since people might find webwork there also. Cheers, Dick Zetterberg [EMAIL PROTECTED] - Original Message - From: Hani Suleiman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, November 18, 2003 2:35 AM Subject: [OS-webwork] WebWork 1.4 release All, WebWork 1.4 has been released, appropriate press blurbage will be showing up on your regular news channels in the next day or so I expect. You can grab it from https://webwork.dev.java.net/files/documents/693/1790/webwork-1.4.zip Any feedback/testing would be most appreciated. I think it's a pretty solid release with plenty of fixes and good reasons to upgrade. Release notes can be found at https://webwork.dev.java.net/servlets/ProjectDocumentView? documentID=1791noNav=true Thanks to all those who contributed, by filing issues, writing docs, fixing bugs, writing incredibly cool and fast new parsers, emailing in code, and providing encouragement. Thanks to the ww2 guys for providing motivation too (and I don't mean that in a snide way!). Enjoy! --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Param directive
The pushes and pops were necessary before recent changes made it possible to pass in objects directly to the velocity directive. Also, there is now talk about having two separate tags, one that does a stack.findValue automatically and one that doesn't. Your second example shows that parameters passed in as attributes of the tag or bodytag directive will be evaluated against the stack, and that those passed in via param directives won't. That's interesting, but I don't know that it's 100% intuitive or self-evident. I'm only recently aware of your second example, and your third example is the first I've heard of that technique. It sounds like there's something for everybody. It would be great if the section on the wiki on using the tags in velocity were updated to show the various ways in which the directives can be used. So now I'm confused. What's the official next step on this? Are we going to -come up with two separate param directives? -go the way Matt's second example went, evaluating params against the stack if they are part of the tag or bodytag directive, and not if they are part of a param directive? (from what I understand, this is what's in CVS right now). OR something else? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Ho Sent: Tuesday, November 18, 2003 1:24 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Param directive Hani Suleiman wrote: +1, the valuestack is a neat thing and all that, but having random pushs/pops happen in UI tags of all things just feels wrong. Agreed. However, I'm unclear why pushes and pops are required though. #foreach( $number in $person.phoneNumbers ) $stack.push($number) #bodytag(Component template=numberDisplay.vm) #param(phoneNumber top) #end #set ($trash = $stack.pop()) #end Why wouldn't you just write: #foreach( $number in $person.phoneNumbers ) #bodytag( Component template=numberDisplay.vm ) #param( phoneNumber $number ) #end #end Or what I'd be more inclined to write: #foreach( $number in $person.phoneNumbers ) #tag( Component template=numberDisplay.vm params.phoneNumber=person.phoneNumbers[$velocityCount] ) #end Although I do admit the latter is less intuitive than the former. M --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Velocimacro registration?
Drew McAuliffe wrote: Recent changes to webwork included the addition of some macros for backwards compatibility. As part of this change, though, I'm seeing problems with configuring other macros. I've been using a velocity.properties file that includes declarations of 2 additional macro files. This has been working for a while. Now, macros defined here don't seem to make their way into webwork, even though my servlet startup log contains the following line: 2003-11-18 11:43:34,449 [INFO] velocity.VelocityManager - Initializing velocity using 'velocity.properties' I've noticed that the velocityManager class includes the following line in applyDefaultConfiguration: p.setProperty(velocimacro.library, webwork.vm); I don't know if this is overwriting any other settings or what, but including the line velocimacro.library=mymacro.vm doesn't seem to prepare any custom macros for use. I've tried this in both velocity.properties and webwork.properties, to no avail. I have a set of libraries under the macro directory of my source directory, and declare them as follows (previously in velocity.properties): velocimacro.library=macros/mymacrofile1.vm,macros/mymacrofile2.vm This worked up until the version of webwork I pulled down lsat Friday. Give it a whirl again Drew. I've pulled the p.setProperty(velocimacro.library, webwork.vm); which shouldn't have been in there and placed it into velocity.properties. So you're free to use the macros if you like or override them. M --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Problems with tags?
Daniel Pfeifer wrote: There seem to be some problems with the Tags in the latest CVS checkout. Specifically IncludeTag and UrlTag cause exceptions when used. Is that a known problem? Nope, but it's fixed in CVS now :) M --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] API changes, again!
To me 'beta' indicates a fairly stable API (not 3 times major API changes), but with bugfixes and improvements along the way (eg. Hibernate). OTOH alpha quality software can be ripped apart. PS Patrick, is your book up to date with these new changes in WW2? Does it contain ww:textfield label='Single Quotes Extra' name=blah/ ? Mathias - Original Message - From: Hani Suleiman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, November 18, 2003 10:21 PM Subject: Re: [OS-webwork] API changes, again! Actually, I agree with this. It's stupid of people to hop on a beta bandwagon then express indignation when the rug is pulled from under them. That's the whole POINT of a beta, to stumble about in various directions until the correct one reveals itself. Thompson, Christopher C (Kris) wrote: Whoa trigger. Please don't blame WebWork2 for being beta. I would much rather they get this right in beta regardless of how many changes they have to make then to either lock us into a bad solution or change after the production release is made. When developing on the bleeding edge you usually do get cut every now and then. Kris Thompson -Original Message- From: BOGAERT Mathias [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 18, 2003 3:52 AM To: [EMAIL PROTECTED] Subject: [OS-webwork] API changes, again! Hi, Just to let you guys know that I *again* have to upgrade my entire WebWork2 application. My previous version was from CVS 10/8/2003, and a lot of things seem to have changed. For instance, HttpServletRequestAware got ServletRequestAware (but still setting a HttpServletRequest??). All the templates have a new format, using parameters, so I have to migrate all my own templates (using CSS for tables) to the new format. I'm getting tired of migrating. If this happens again, I'm switching back to WW 1.3, at least I'll be ok for the next 6 months then. Mathias --- 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: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
[OS-webwork] Checking out xwork and webwork
I seem to recall going thru this before but guest/guest isn't working for me at cvs.dev.java.net which is what is refered to on the following page https://webwork.dev.java.net/servlets/ProjectSource --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Checking out xwork and webwork
Try empty password On Nov 18, 2003, at 6:28 PM, Robert Nicholson wrote: I seem to recall going thru this before but guest/guest isn't working for me at cvs.dev.java.net which is what is refered to on the following page https://webwork.dev.java.net/servlets/ProjectSource --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Checking out xwork and webwork
Ok never mind I found the bit on the other page that tells that the guest password should be blank. http://www.opensymphony.com/cvs.jsp The confusion for those who are interested is if you go to the following page https://xwork.dev.java.net/source/browse/xwork/ It clearly states under Setup CVS Command line client ie. https://xwork.dev.java.net/servlets/ProjectSource#commandlinecvs cvs -d :pserver:[EMAIL PROTECTED]:/cvs login The cvs password for guest is guest. On Nov 18, 2003, at 5:28 PM, Robert Nicholson wrote: I seem to recall going thru this before but guest/guest isn't working for me at cvs.dev.java.net which is what is refered to on the following page https://webwork.dev.java.net/servlets/ProjectSource --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Checking out xwork and webwork
Q. How do I get the latest version of Webwork2 and XWork from CVS? cvs -d :pserver:[EMAIL PROTECTED]:/cvs login (Use an empty password, just hit enter..) cvs -d :pserver:[EMAIL PROTECTED]:/cvs checkout webwork cvs -d :pserver:[EMAIL PROTECTED]:/cvs checkout xwork from the FAQ: http://wiki.opensymphony.com/space/Webwork2+FAQ Robert Nicholson wrote: I seem to recall going thru this before but guest/guest isn't working for me at cvs.dev.java.net which is what is refered to on the following page https://webwork.dev.java.net/servlets/ProjectSource --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] [OS-xwork] Spring IoC integration
Cameron Braid wrote: I have downloaded and integrated this code though and the tests run perfectly (after creating my my own ServletContextAware interface and removing refrences to the confluence packages) I really like the work that you have done. Though I think some more work is required to be able to integrate into xwork/webwork Cool! I can't see how the servlet context is set onto the SpringServletContextReferenceResolver or the ApplicationContext is set onto the SpringApplicationContextReferenceResolver (depending on the one that is used) you construct the ExternalReferenceResolver using this code, and immediately add it to the package config. Class erResolverClazz = ClassLoaderUtil.loadClass(externalReferenceResolver, ExternalReferenceResolver.class); erResolver = (ExternalReferenceResolver) erResolverClazz.newInstance(); I guess that the ServletContextAware interface could be added to webwork, though the question remains - how is the ServletContextAware.setServletContext(..) method going to get called ? We could use a ServletContextListener to set the contexts on our resolvers... Could we access the packageConfig from a listener? I propost the following soloution : 1 : have different SpringXXXReferenceResolver classes in xwork and webwork like this : xwork : Spring/ClassPathXmlApplicationContext/ReferenceResolver or a Spring/FileSystemXmlApplicationContext/ReferenceResolver webwork : Spring/WebApplicationContext/ReferenceResolver - using WebApplicationContextUtils.getWebApplicationContext(ServletActionContext.getServletContext()) to obtain the application context I agree, we should have different implementations, separated like this. In my test case I have provided a Spring/XmlFileApplicationContext, so we could just refactor that out. This works find for webwork based apps, though for xwork based apps that the SpringClassPathXmlApplicationContextReferenceResolver and SpringFileSystemXmlApplicationContextReferenceResolver require configuration to specify the filename.. therfore step two is required : 2 : allow for external refrence resolvers to be declards by name, class and to be parameterizable like interceptors. the refer to the by name instead of className e.g. : xwork package ... externalReferenceResolver=spring !-- NEW FEATURE : new node set -- externalRefrenceResolvers externalRefrenceResolver name='spring' class=SpringWebApplicationContextReferenceResolver/ externalRefrenceResolver name='springXmlFile' class=SpringClassPathXmlApplicationContextReferenceResolver param name=filenamemyApplicationContext.xml/param /externalRefrenceResolver /externalRefrenceResolvers action name='...' class='...' !-- NEW FEATURE : externalRefrenceResolver attribute -- external-ref externalRefrenceResolver='springXmlFile' name='foo'myFoo/external-ref external-ref name='bar'myBar/external-ref /action /package /xwork this allows for reusing the same configured resolver in multiple packages - which you can do now, though without configuration. this allows for each external-ref tag to optionally use a different resolver as in the example above Ok that looks like it would work, I think we should declare resolvers the way you suggested. Though I don't think we need then externalReferenceResolver attrib on the external-ref element. We can just assume all actions in a package use the same Resolver. I think it's neater that way; You can still use different Containers on different packages to resolve your references and there would be a more logical grouping of package/container. I am sure that other frameworks will require some sort of runtime configuration for the external reference resolvers as well. Any comments ? yep! Cameron Cheers, ross Ross Mason wrote: Cheers mate. I've just attached the SpringExternalReferenceResolver implmentation and tests to the Jira Issue. http://jira.opensymphony.com/secure/ViewIssue.jspa?key=XW-122 Ross Patrick Lightbody wrote: This is good stuff -- not sure about a 1.0 release though. We'll try to get a point release out shortly after though to support this. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ross Mason Sent: Monday, November 17, 2003 8:02 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] [OS-xwork] Spring IoC integration I'll fix the commons dependancies first :-) Ross Mason wrote: I've tried running the patch again (through Eclipse) and I get the same problem - It only creates patch entries for new files? I know this isn't a subject for this list, but does anyone know why this happens? Anyway Cameron, I'll create a zip of the changes for now and attach it to the the issue and this list. Cheers, Ross Cameron Braid wrote: The patch seems to be missing code in the configuration
[OS-webwork] Official OS repository?
Isn't Opensymphony (thus WW2, XW) hosted on opensymphony.sourceforge.net? All the urls I've seen flying around on this list show *.java.net. Have you moved? Ciao! Wayland Chan email: wchanATtrekspaceDOTcom -- Get your free email account from http://www.trekspace.com Your Internet Virtual Desktop! --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Official OS repository?
Yes, we have moved. WebWork2 : http://webwork.dev.java.net Xwork : http://xwork.dev.java.net I suggest that someone looks into seeing if the webwork/xwork sourceforge cvs repos can be shutdown, or maybe delete everything from them. Cameron Wayland Chan wrote: Isn't Opensymphony (thus WW2, XW) hosted on opensymphony.sourceforge.net? All the urls I've seen flying around on this list show *.java.net. Have you moved? Ciao! Wayland Chan email: wchanATtrekspaceDOTcom -- Get your free email account from http://www.trekspace.com Your Internet Virtual Desktop! --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork -- 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 is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Checking out xwork and webwork
...which is why I wrote http://www.opensymphony.com/cvs.jsp to have the 'official' list, unfortunately there's no way of controlling sf.net or java.net's docs. On Nov 18, 2003, at 7:37 PM, Robert Nicholson wrote: Unfortunately there are many places with this information and the information is inconsistent. See https://xwork.dev.java.net/source/browse/xwork/ for example That's where I ended up at first. --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Official OS repository?
We, not quite. 1.x will remain on sf.net (files will be posted to java.net though), since the original developers have moved on and so having cvs history is pretty vital to figure out why certain things were done the way they were. Plus it's a stable codebase so the one day delay for anon cvs isn't such an impediment. On Nov 18, 2003, at 7:55 PM, Bruce Ritchie wrote: Wayland Chan wrote: Isn't Opensymphony (thus WW2, XW) hosted on opensymphony.sourceforge.net? All the urls I've seen flying around on this list show *.java.net. Have you moved? WW2 has moved to java.net and I believe WW 1.x has also moved (however Hani did post the latest 1.4 release to sourceforge as well). The reason is basically pragmatic - java.net works, sourceforge.net didn't (and probably still doesn't). Regards, Bruce Ritchie --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
[OS-webwork] Newbie - CDList.jsp
Hello I just started looking at Webwork and checking out the examples. One thing i noticed in cdlist.jsp is this code webwork:iterator value=CDList option value=webwork:property value=album/ webwork:property value=album/, webwork:property value=artist/, webwork:property value=country/, webwork:text name='price' value0=@pricer/computePrice(price)/ /option /webwork:iterator CDList is actually a List of CD objects, but i couldnt find anywhere in the code where this cast is made back. So how does webwork know which object to call when the getAlbum() is called? TIA Raj __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
[OS-webwork] WebWork 1.4 startup error
Hello, I'm currently using webwork 1.3 with weblogic 6.1 SP5. When I replace webwork 1.3 with 1.4, my weblogic app fails to start with the following startup error: --- translation of /template/xhtml/checkbox.jsp failed: weblogic.servlet.jsp.JspException: (line 22): Error in using tag library uri='webwork' prefix='webwork': The Tag class 'webwork.view.taglib.URLTag' has no setter method corresponding to TLD declared attribute 'includeParams', (JSP 1.1 spec, 5.4.1) --- Any ideas? Thanks, Dave --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Newbie - CDList.jsp
have a look at the webwork.examples.i18n.CDList class. That is the action class, so when the page makes a call to CDList, that automatically calls the getCDList method in that action class. The CDList is now iterated through and within the iterate block, the top of the value stack now has the current CD at the top, so when the propertytag tries to display 'album', the method called will be getAlbum() on the particular CD that the iterator now points at. On Nov 18, 2003, at 8:25 PM, Rajagopal. V wrote: Hello I just started looking at Webwork and checking out the examples. One thing i noticed in cdlist.jsp is this code webwork:iterator value=CDList option value=webwork:property value=album/ webwork:property value=album/, webwork:property value=artist/, webwork:property value=country/, webwork:text name='price' value0=@pricer/computePrice(price)/ /option /webwork:iterator CDList is actually a List of CD objects, but i couldnt find anywhere in the code where this cast is made back. So how does webwork know which object to call when the getAlbum() is called? TIA Raj __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] WebWork 1.4 startup error
Do you have a taglib tld file in your WEB-INF directory? if you do, then either delete it or upgrade it to the one from the webwork jar (in META-INF/taglib.tld) On Nov 18, 2003, at 8:47 PM, Dave Ballard wrote: Hello, I'm currently using webwork 1.3 with weblogic 6.1 SP5. When I replace webwork 1.3 with 1.4, my weblogic app fails to start with the following startup error: --- translation of /template/xhtml/checkbox.jsp failed: weblogic.servlet.jsp.JspException: (line 22): Error in using tag library uri='webwork' prefix='webwork': The Tag class 'webwork.view.taglib.URLTag' has no setter method corresponding to TLD declared attribute 'includeParams', (JSP 1.1 spec, 5.4.1) --- Any ideas? Thanks, Dave --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Newbie - CDList.jsp
Hani Thanks for the reply. I did take a look at CDList class and the one thing thats puzzling me is that in the doStartTag and doAfterBody of IteratorTag, all its doing is a iterator.next() which should return a Object. My problem is how does that automatically get cast down to a CD Class. I come from a Struts background and in that case, the logic:iterate has a type attribute which specifies what is the type of the individual elements in a Collection. I couldnt find a similar match in Webwork. Thanks Raj --- Hani Suleiman [EMAIL PROTECTED] wrote: have a look at the webwork.examples.i18n.CDList class. That is the action class, so when the page makes a call to CDList, that automatically calls the getCDList method in that action class. The CDList is now iterated through and within the iterate block, the top of the value stack now has the current CD at the top, so when the propertytag tries to display 'album', the method called will be getAlbum() on the particular CD that the iterator now points at. On Nov 18, 2003, at 8:25 PM, Rajagopal. V wrote: Hello I just started looking at Webwork and checking out the examples. One thing i noticed in cdlist.jsp is this code webwork:iterator value=CDList option value=webwork:property value=album/ webwork:property value=album/, webwork:property value=artist/, webwork:property value=country/, webwork:text name='price' value0=@pricer/computePrice(price)/ /option /webwork:iterator CDList is actually a List of CD objects, but i couldnt find anywhere in the code where this cast is made back. So how does webwork know which object to call when the getAlbum() is called? TIA Raj __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
[OS-webwork] Anybody checkout with Eclipse?
I'm quite new to Eclipse but can anybody tell me why only some projects show the check a project configured in the new project wizard when you are checking stuff out of a CVS location? I don't understand why it shows me that option for many projects but not others including Webwork 1.4. For instance I can go to jakarta-velocity and it will show me that option but whenever I try either jakarta-tapestry or webwork 1.4 the only option is to check it out into the default work space path or an existing project but not thru the wizard. --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Param directive
I think we're going with what's in CVS unless there's bugs... -Original Message- From: Drew McAuliffe [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 18, 2003 4:51 PM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] Param directive The pushes and pops were necessary before recent changes made it possible to pass in objects directly to the velocity directive. Also, there is now talk about having two separate tags, one that does a stack.findValue automatically and one that doesn't. Your second example shows that parameters passed in as attributes of the tag or bodytag directive will be evaluated against the stack, and that those passed in via param directives won't. That's interesting, but I don't know that it's 100% intuitive or self-evident. I'm only recently aware of your second example, and your third example is the first I've heard of that technique. It sounds like there's something for everybody. It would be great if the section on the wiki on using the tags in velocity were updated to show the various ways in which the directives can be used. So now I'm confused. What's the official next step on this? Are we going to -come up with two separate param directives? -go the way Matt's second example went, evaluating params against the stack if they are part of the tag or bodytag directive, and not if they are part of a param directive? (from what I understand, this is what's in CVS right now). OR something else? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Ho Sent: Tuesday, November 18, 2003 1:24 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Param directive Hani Suleiman wrote: +1, the valuestack is a neat thing and all that, but having random pushs/pops happen in UI tags of all things just feels wrong. Agreed. However, I'm unclear why pushes and pops are required though. #foreach( $number in $person.phoneNumbers ) $stack.push($number) #bodytag(Component template=numberDisplay.vm) #param(phoneNumber top) #end #set ($trash = $stack.pop()) #end Why wouldn't you just write: #foreach( $number in $person.phoneNumbers ) #bodytag( Component template=numberDisplay.vm ) #param( phoneNumber $number ) #end #end Or what I'd be more inclined to write: #foreach( $number in $person.phoneNumbers ) #tag( Component template=numberDisplay.vm params.phoneNumber=person.phoneNumbers[$velocityCount] ) #end Although I do admit the latter is less intuitive than the former. M --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
