RE: [OS-webwork] "best practices" around forms with multiple submit buttons
Just add names to the form elements, i.e. And then add setters in your action: setDoSave() and setDoCancel(). In the doExecute() method, branch logic depending on which value was set. Depending on JavaScript generally is a bad thing IMHO. Regards, Kirk Rasmussen Lucasfilm Ltd. > -Original Message- > From: Steve Conover [mailto:[EMAIL PROTECTED] > Sent: Monday, March 10, 2003 2:05 PM > To: Webwork > Subject: [OS-webwork] "best practices" around forms with > multiple submit > buttons > > > What's the recommended way of handling a situation where you > have multiple > form buttons? i.e. "Save" and "Cancel". There are probably > many ways to > approach this and I'd like to hear how people on this list handle it. > > One way might be to use javascript to change a hidden flag field, and > submit to an action that redirects to the right place. > > Another might be to use javascript to actually change the action...I > haven't tried that but my first impression is that might be > the cleanest > way. > > Any ideas/advice? > > Thanks, > Steve > > > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > Opensymphony-webwork mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] ui:textfield id attribute is missing
Awesome. Thanks so much. I think it just disappeared from the
*.tld file from what I can tell.
-Original Message-From: matt baldree
[mailto:[EMAIL PROTECTED]]Sent: Friday, February 07, 2003 6:40
AMTo: [EMAIL PROTECTED]Subject:
Re: [OS-webwork] ui:textfield id attribute is missing
This should not have dropped out. I just noticed
this myself on our project as we were migrating. I'll make the appropriate
fixes for 1.3.
- Original Message -
From:
Kirk Rasmussen
To: [EMAIL PROTECTED]
Sent: Thursday, February 06, 2003 7:42
PM
Subject: [OS-webwork] ui:textfield id
attribute is missing
Does anyone know
why the "id" attribute was removed from the ui tags?
I now get the
following runtime error:
unexpected
attribute `id' in `ui:textfield'
This now became
a very big issue with my migration from 1.2 to 1.3. I'm willing to
do
the work to put
it back in but I was just curious on the reason (e.g.
oversight).
Thanks,
Kirk
Rasmussen
Lucasfilm
Ltd.
[OS-webwork] ui:textfield id attribute is missing
Does anyone know why the "id" attribute was removed from the ui tags? I now get the following runtime error: unexpected attribute `id' in `ui:textfield' This now became a very big issue with my migration from 1.2 to 1.3. I'm willing to do the work to put it back in but I was just curious on the reason (e.g. oversight). Thanks, Kirk Rasmussen Lucasfilm Ltd.
RE: [OS-webwork] Graphical submit buttons and WW 1.2.1
I added the following to Wiki.
This is the cleanest solution I came up with without resorting to JavaScript.
public void doValidation()
{
ActionContext context = ActionContext.getContext();
Map parameters = context.getParameters();
for (Iterator iter = parameters.keySet().iterator(); iter.hasNext(); )
{
String key = (String) iter.next();
if (doSignIn == null && key.indexOf( "doSignIn" ) >= 0)
{
setDoSignIn( "true" );
}
else if (doUpdate == null && key.indexOf( "doUpdate" ) >=0)
{
setDoUpdate( "true" );
}
}
}
-Original Message-
From: Scott Farquhar [mailto:[EMAIL PROTECTED]]
Sent: Wed 2/5/2003 3:31 AM
To: [EMAIL PROTECTED]
Cc:
Subject:Re: [OS-webwork] Graphical submit buttons and WW 1.2.1
One thing we could do with the dispatcher is handle this? It should be
possible to write a webwork dispatcher (or even a webwork filter in 2.0)
that converts ABC.x and ABC.y to call ABC?
Would there be any problems with that? It would make the code a lot
simpler to do it in a dispatcher. Perhaps actions can be
ImageRequestAware or some sort?
Jason? Patrick?
Cheers,
Scott
Jason Carreira wrote:
> Good question. I don't have an answer, but whoever figures this out,
> please Wiki it too. :-)
>
>
>>-Original Message-
>>From: Kirk Rasmussen [mailto:[EMAIL PROTECTED]]
>>Sent: Tuesday, February 04, 2003 3:50 PM
>>To: webwork list
>>Subject: [OS-webwork] Graphical submit buttons and WW 1.2.1
>>
>>
>>Hi All,
>>
>>I was wondering if someone has tried using multiple graphical
>>submit buttons on a single form?
>>
>>For example let's say I have the following:
>>
>>
>>>maxlength="100"/> >name="'password'" maxlength="32"/>
>>
>>>value="Sign In" /> >name="doUpdate" value="Update Settings" />
>>
>>If I had regular submit buttons (i.e. type=submit), the
>>dispatcher would call "setDoSignIn()" and "setDoUpdate())
>>because the parameter name would simply be "doSignIn" and
>>"doUpdate" respectively.
>>
>>But in the case of graphical submit buttons the parameters
>>sent from the browser become "doSignIn.x" and "doSignIn.y"
>>and "doUpdate.x" and "doUpdate.y". Other than making my
>>action ServletRequestAware and using the servlet request
>>directly to look at the parameter is there a best practices
>>for dealing with this issue?
>>
>>Thanks,
>>Kirk Rasmussen
>>Lucasfilm Ltd.
>>
>>
>>
>>---
>>This SF.NET email is sponsored by:
>>SourceForge Enterprise Edition + IBM + LinuxWorld =omething 2
>>See! http://www.vasoftware.com
>>___
>>Opensymphony-webwork mailing list
>>[EMAIL PROTECTED]
>>https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
>>
>
>
>
> ---
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld http://www.vasoftware.com
> ___
> Opensymphony-webwork mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
>
--
ATLASSIAN - http://www.atlassian.com
Expert J2EE Software, Services and Support
---
Need a simple, powerful way to track and manage issues?
Try JIRA - http://www.atlassian.com/software/jira
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
[OS-webwork] WW 1.3 Release Vote
I added this under the WebWork cookbook. BTW can we take a vote or something on releasing 1.3 officially? I've been doing development with 1.2 for about a month now and there are a number of incompatibilities when switching to 1.3. Nothing major but annoying nevertheless. It is a little scary to depend on code being stable when the codebase is a moving target. After releasing 1.3 how about creating a 1.3 branch in CVS to support bug fixes and minor enhancements like we discussed previously? 1.4 can then continue on the head. -Original Message- From: Jason Carreira [mailto:[EMAIL PROTECTED]] Sent: Tue 2/4/2003 2:16 PM To: [EMAIL PROTECTED] Cc: Subject:RE: [OS-webwork] Graphical submit buttons and WW 1.2.1 Good question. I don't have an answer, but whoever figures this out, please Wiki it too. :-) > -Original Message- > From: Kirk Rasmussen [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, February 04, 2003 3:50 PM > To: webwork list > Subject: [OS-webwork] Graphical submit buttons and WW 1.2.1 > > > Hi All, > > I was wondering if someone has tried using multiple graphical > submit buttons on a single form? > > For example let's say I have the following: > > > maxlength="100"/> name="'password'" maxlength="32"/> > > value="Sign In" /> name="doUpdate" value="Update Settings" /> > > If I had regular submit buttons (i.e. type=submit), the > dispatcher would call "setDoSignIn()" and "setDoUpdate()) > because the parameter name would simply be "doSignIn" and > "doUpdate" respectively. > > But in the case of graphical submit buttons the parameters > sent from the browser become "doSignIn.x" and "doSignIn.y" > and "doUpdate.x" and "doUpdate.y". Other than making my > action ServletRequestAware and using the servlet request > directly to look at the parameter is there a best practices > for dealing with this issue? > > Thanks, > Kirk Rasmussen > Lucasfilm Ltd. > > > > --- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld =omething 2 > See! http://www.vasoftware.com > ___ > Opensymphony-webwork mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
[OS-webwork] Graphical submit buttons and WW 1.2.1
Hi All, I was wondering if someone has tried using multiple graphical submit buttons on a single form? For example let's say I have the following: If I had regular submit buttons (i.e. type=submit), the dispatcher would call "setDoSignIn()" and "setDoUpdate()) because the parameter name would simply be "doSignIn" and "doUpdate" respectively. But in the case of graphical submit buttons the parameters sent from the browser become "doSignIn.x" and "doSignIn.y" and "doUpdate.x" and "doUpdate.y". Other than making my action ServletRequestAware and using the servlet request directly to look at the parameter is there a best practices for dealing with this issue? Thanks, Kirk Rasmussen Lucasfilm Ltd. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Freemarker WAS Using SiteMesh for the UI tags
Just off the top of my head... Doesn't FreeMarker have a macro language similar to Velocity? I believe you could write custom functions to access the ValueStack. I was actually thinking about doing the FreeMarker integration just last week. Once I get some spare time I might look into this. Regards, Kirk Rasmussen Lucasfilm Ltd. > -Original Message- > From: James Cook [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, January 28, 2003 11:46 AM > To: [EMAIL PROTECTED] > Subject: Re: [OS-webwork] Freemarker WAS Using SiteMesh for > the UI tags > > > The one thing that may prevent FreeMarker from being "drop-in" > replacement for the WebWork JSP is the expression language > supported by > the WebWork taglibs. It also affects JSTL integration and Velocity > integration. It concerns the hierarchical nature of the ValueStack. > Most of these third-party view technologies don't understand the > concept of '../name'. We use WebWork/Velocity on a huge project and > have never had any need for this syntax, but some WebWork > developers (I > guess) use the hierarchical ValueStack quite often. > > Since you "own" the FreeMarker syntax and can modify it, perhaps you > may want to include such constructs. > > On Tuesday, January 28, 2003, at 01:59 PM, Attila Szegedi wrote: > > > Actually if I understand it right, the integration is quite > trivial. > > We have > > a Model2-compliant view servlet bundled into the core > distribution. It > > lets > > templates access request, session, and servlet context > attributes. It > > also > > lets templates use any JSP taglib present in the webapp. > Therefore it > > is > > pretty much a drop-in replacement for JSP as far as WebWork is > > concerned. Is > > there anything else codewise that should be done for > integration? (My > > feeling is that there isn't, but please correct me if there are some > > gotchas). > > > > --- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > ___ > Opensymphony-webwork mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Releasing 1.3 and new development
I am in total agreement. A stable 1.3 branch is definitely needed. I think it would be very confusing for a new WW user to be expected to pull from the CVS head when the head potentially changes minute by minute. The 1.2 release has been totally ignored because work continued on the head to create the 1.3 release. IMO the feature sets should be better defined with specific goals so that developers know when a release is ready to be baked. I might be wrong but it seems that 1.3 was arbitrarily created because its been long enough since the 1.2 release. Consistent logging, performance enhancements and stability seems to be the goals of 1.3 from what I can tell. I an very confident that myself and several others on this list would help to maintain the 1.3 branch if necessary. BTW great job guys! WW does indeed rock! Regards, Kirk Rasmussen Lucasfilm Ltd. > -Original Message- > From: Jason Carreira [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, January 28, 2003 7:36 AM > To: [EMAIL PROTECTED] > Subject: RE: [OS-webwork] Releasing 1.3 and new development > > > Nononono you misunderstood. My bad. > > I want to branch 1.3 to be able to do bug fixes for any future 1.3.x > releases. > > I want to keep the CVS head for continuing development and > new features > with a view to a 1.4 release. > > Xwork 1.0 and Webwork 2.0 can, and should, remain in the sandbox for > now, until a LOT of issues are worked out and it's been fleshed out to > do everything that WW 1.3 does. > > My point was really to be able to get back to 1.3 for bug fixes while > not keeping people from continuing to develop against the CVS > head. I'm > not terribly comfortable with CVS, so I was throwing this out for > someone to do. If we were using Perforce, I would create a branch, > because branching is fast and low cost and it's how you do most code > management in P4. > > Jason > > > -Original Message- > > From: Hani Suleiman [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, January 28, 2003 10:27 AM > > To: [EMAIL PROTECTED] > > Subject: Re: [OS-webwork] Releasing 1.3 and new development > > > > > > I like webwork head cvs, and want to see it keep moving > > forward. We can tag a release (1.3) anytime now, really. Only > > thing that perhaps needs doing is updating some of the docs, > > and having decent release notes. xwork is still sandbox, and > > is nowhere near production worthy (right?) and I'd much > > rather than those of us who enjoy webwork and contributing to > > it don't end up feeling like second class citizens in > favour of xwork. > > > > Quoting Jason Carreira <[EMAIL PROTECTED]>: > > > > > People have been adding new stuff, like the Velocity based > > templates, > > > while the head is still (as far as I know) supposed to be > > 1.3 RC2. I > > > like new stuff (see Xwork), but we really need to branch > > 1.3 to keep > > > it clean of new stuff so we can develop against the head. > > If we end up > > > needing to release 1.3.1 or somesuch to fix bugs, then > > we'll need the > > > 1.3 source tree as a base to work from without keeping > people from > > > moving forward. > > > > > > Jason > > > > > > -- > > > Jason Carreira > > > Technical Architect, Notiva Corp. > > > phone:585.240.2793 > > > fax:585.272.8118 > > > email:[EMAIL PROTECTED] > > > --- > > > Notiva - optimizing trade relationships (tm) > > > > > > > > > > > > --- > > > This SF.NET email is sponsored by: > > > SourceForge Enterprise Edition + IBM + LinuxWorld = > > Something 2 See! > > > http://www.vasoftware.com > > > ___ > > > Opensymphony-webwork mailing list > > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > > > > > > > > > > > > > > > > > > > > --- > > This SF.NET email is sponsored by: > > SourceForge Enterprise Edition + IBM + LinuxWorld = Something > > 2 See! http://www.vasoftware.com > > ___ > > Opensymphony-webwork mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > > > > > ---
RE: [OS-webwork] More tweaking of BeanUtil
Awesome!
Thanks Dick!
> -Original Message-
> From: Dick Zetterberg [mailto:[EMAIL PROTECTED]]
> Sent: Friday, January 24, 2003 4:10 PM
> To: [EMAIL PROTECTED]
> Subject: [OS-webwork] More tweaking of BeanUtil
>
>
> I have been doing some more tweaking of the BeanUtil class to
> improve its performance.
> This time I tried to remove duplicated hash lookups and other
> "costly" method calls like Method.getParameterTypes.
> I also made a change to the copy method as suggested by
> Robert on the list.
> So the total improvements compared to 1.3RC2 are now:
> Setting of non-string property: ~ 25% faster
> Setting of string property: ~ 10-15% faster
> Copy method: ~ 5-7% faster
>
> Is it ok to commit these changes for the 1.3 version as well?
>
> Cheers,
>
> Dick
>
>
> CVS diff follows:
>
> Index: BeanUtil.java
> ===
> RCS file:
> /cvsroot/opensymphony/webwork/src/main/webwork/util/BeanUtil.java,v
> retrieving revision 1.34
> diff -r1.34 BeanUtil.java
> 120c120,121
> < PropertyDescriptor[] propertiesTo =
> getPropertyDescriptors(to.getClass());
>
> ---
> > // Get the field map of the destination object once
>
> > Map fieldMap = getFieldMapForClass(to.getClass());
>
> 124,127c125,131
> < for (int j = 0; j < propertiesTo.length; j++)
>
> < {
>
>
>
> ---
> > // Look up the destination descriptor in the fieldMap
>
> > PropertyDescriptor pdTo = (PropertyDescriptor)
> fieldMap.get(pdFrom.getName());
>
> > if (pdTo != null)
>
> > {
>
> >Method readMethod = pdFrom.getReadMethod();
>
> >Method writeMethod = pdTo.getWriteMethod();
>
> >if (writeMethod != null && readMethod != null)
>
> 129,137c133,135
> < Method readMethod = pdFrom.getReadMethod();
>
> < Method writeMethod = pdTo.getWriteMethod();
>
> < if (writeMethod != null && readMethod != null)
>
> < {
>
> < writeParameters[0] =
> pdFrom.getReadMethod().invoke(from, readParameters);
>
> < if (!(!includeNull &&
> writeParameters[0] == null))
>
> < pdTo.getWriteMethod().invoke(to,
> writeParameters);
>
> < }
>
> < break;
>
> ---
> > writeParameters[0] =
> pdFrom.getReadMethod().invoke(from, readParameters);
>
> > if (!(!includeNull && writeParameters[0] == null))
>
> > pdTo.getWriteMethod().invoke(to,
> writeParameters);
>
> 165a164,167
> > Map fieldMap = null;
>
> > // Get the fieldMap of the destination object once
>
> > if (keys.hasNext())
>
> > fieldMap = getFieldMapForClass(to.getClass());
>
> 171c173
>
> ---
> >setProperty(key, from.get(key), to, fieldMap);
>
> 190a193
> >
>
> 203a207,228
> > if (obj == null)
>
> > {
>
> > throw new IllegalArgumentException("The target
> object for property '" + propertyName + "'. The target object
> needs to be initialized to a non-null value in order to set
> this property.");
>
> > }
>
> > Map fieldMap = getFieldMapForClass(obj.getClass());
>
> > setProperty(propertyName, val, obj, fieldMap);
>
> >}
>
> >
>
> >/**
>
> > * Set a single JavaBean property value on an object.
>
> > *
>
> > * If the values in the map are of type String or
> String[] they may be converted
>
> > * to the actual property type by the use of property editors.
>
> > *
>
> > * @param propertyName String representing the
> property or subproperty
>
> > * @param val the value to set
>
> > * @param obj the object to set the property on.
>
> > * @param fieldMap Map with the
> PropertyDescriptors of the obj
>
> > * @exception IllegalArgumentException
>
> > */
>
> >static protected void setProperty(String propertyName,
> Object val, Object obj, Map fieldMap) throws IllegalArgumentException
>
> >{
>
> 207a233
> > Map curFieldMap;
>
> 219,220c245,258
> < PropertyDescriptor descriptor =
> getPropertyDescriptor(curSegment.getId(), curObject);
>
> <
>
> ---
> > PropertyDescriptor descriptor;
>
> > // Is the current object the same as the original one?
>
> > // If not, get the field map for the new object
>
> > if (curObject != obj)
>
> > {
>
> > curFieldMap = getFieldMapForClass(curObject.getClass());
>
> > }
>
> > else
>
> > {
>
> >
RE: [OS-webwork] Scope for 1.4
Thanks Pat! > -Original Message- > From: Patrick Lightbody [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, January 22, 2003 7:25 PM > To: [EMAIL PROTECTED] > Subject: Re: [OS-webwork] Scope for 1.4 > > > Here it is... > --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Woohoo!
Hi Jason, Congrats! I had that same conversation 3 weeks ago with my management. Things are really cooking now. Regards, Kirk Rasmussen Lucasfilm Ltd. > > So we had our Webwork vs. Struts talk today, and I was able > to convince > people here that there was sufficiently enough better about WW to make > us use it instead of Struts, even though Struts is the "standard", of > sorts! Cool. > > Off to catch a plane home... > > -- --- This SF.NET email is sponsored by: Thawte.com Understand how to protect your customers personal information by implementing SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Scope for 1.4
Hi Pat, Any chance you could post that here? Thanks, Kirk Rasmussen Lucasfilm Lt.d > -Original Message- > From: Patrick Lightbody [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, January 14, 2003 5:42 PM > To: [EMAIL PROTECTED] > Subject: Re: [OS-webwork] Scope for 1.4 > > > Yup, Kirk's option here is the best way to get immediate performance > improvements. I've made a very generic "selectfastmap.jsp" > template for > large lists of Map objects. Works much faster. > > -Pat > --- This SF.NET email is sponsored by: A Thawte Code Signing Certificate is essential in establishing user confidence by providing assurance of authenticity and code integrity. Download our Free Code Signing guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Scope for 1.4
Mike, I should qualify that I am running the 1.2.1 build for my tests. I have not tried 1.3 RC1 yet. However, even when I eliminated the tag and used a straight to product the select list it only reduced the execution time to 10 secs versus 13 secs. To me this poses a significant problem, at least for the 1.2 build. Has anyone profiled webwork with JProbe or similar tools to look for hot spots that could be optimized? > -Original Message- > From: Mike Cannon-Brookes [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, January 14, 2003 5:56 PM > To: [EMAIL PROTECTED] > Subject: Re: [OS-webwork] Scope for 1.4 > > > Kirk, > > Well - yes and no. JIRA uses OSCache, but not for the UI > tags. None of those > are cached at all, and we have literally hundreds ;) > > OSCache is only used where certain pages take a long time to > generate for > various reasons (most often because of the computations required to > calculate the data set being displayed). > > We also use a lot of select tags, some with up to 100 > elements, and their > time to render is not significant? > > Cheers, > Mike > --- This SF.NET email is sponsored by: Take your first step towards giving your online business a competitive advantage. Test-drive a Thawte SSL certificate - our easy online guide will show you how. Click here to get started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Scope for 1.4
Not really. It gets its speed because the template is single purpose -- i.e. for creating the select list for countries (254 elements). The list is not passed in to the template. The list is obtained by calling another action within the template. This was just one example of how to optimize performance. Check out Dick Zetterberg [[EMAIL PROTECTED]] e-mails on this list for other suggestions. He has an outstanding patch for 1.3 that should improve the tablib performance across the board. > -Original Message- > From: Jason Carreira [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, January 14, 2003 5:31 PM > To: [EMAIL PROTECTED] > Subject: RE: [OS-webwork] Scope for 1.4 > > > Could this be applied as a patch of some sort to the template for the > select ui component? > --- This SF.NET email is sponsored by: Take your first step towards giving your online business a competitive advantage. Test-drive a Thawte SSL certificate - our easy online guide will show you how. Click here to get started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Scope for 1.4
I assume that JIRA uses OSCache, right? Jive 3.0 default skin uses webwork also but they avoid the UI tags completely. Here is what I did to make my countries list very fast. It isn't ideal but it works and it was plugin compatible to the tag. FYI I got the execution time down from 13 seconds to 0.0020 seconds. > -Original Message- > From: Peter Kelley [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, January 14, 2003 4:23 PM > To: [EMAIL PROTECTED] > Subject: Re: [OS-webwork] Scope for 1.4 > > > Mike, > > We use JIRA and the performance is fine but our product webwork code > performance is awful at the moment. Have you any tips for the > performance challenged ? > > > > On Tue, 2003-01-14 at 16:00, Mike Cannon-Brookes wrote: > > Kirk, > > > > As a guide, we've been shipping code based on 1.3 for a few > months now. And > > yes, we use millions of UI tags ;) > > > > I agree with you in general though - talk of 1.4 is silly > when 1.3 isn't out > > yet! > > > > Cheers, > > Mike > > > > ATLASSIAN - http://www.atlassian.com > > Expert J2EE Software, Services and Support > > > > On 14/1/03 7:34 AM, "Kirk Rasmussen" > ([EMAIL PROTECTED]) penned > > the words: > > > > > Hello everyone! > > > > > > I'm very pleased to make the transition towards using the WW > > > framework for our development group and I would like to > > > contribute back to the project. > > > > > > I choose to use WW over Struts as our standard MVC framework > > > about a month ago after reading about it in various blogs and > > > mailing lists. I downloaded the 1.2.1 version and started > > > developing with it because it was the only release available at > > > the time. > > > > > > After using WW for about 3 weeks and as an outside observer on > > > this list for some time now it seems to me that there needs to be > > > separate teams focused on the 1.2, 1.3, XWork, and now 1.4 > > > branches?? > > > > > > There are a number of issues that still need to be resolved with > > > the 1.2 release IMHO. I've spoken with a number of people with > > > more WW experience than I and the common theme I've heard is > > > "don't use the UI tags". > > > > > > Why is that? Now that I've used them I know why...performance. > > > As a new user it is disconcerting that the WW docs and examples > > > are geared towards using the UI tags but in real world usage now > > > I've been told not to use them by a number of people. I > have gotten > > > a lot of helpful advice on how to solve the performance problem > > > (e.g. OSCache, patching BeanUtil class, etc.) but if WW is to grow > > > as a community like Struts has, I think the current > branch needs to > > > be polished before moving on to the next big thing (1.3, XWork > > > or 1.4?) > > > > > > I realize that the UI tags aren't necessary and that they are only > > > a small part of the rest of the WW architecture. In our > environment, > > > the engineers are out numbered by the content folks by an > 5 to 1 ratio. > > > It is important that the pages be as simple as possible. > Our pages that > > > are released to production tend to get duplicated (copy & > paste from > > > examples) and maintenance of the pages becomes a nightmare. > > > > > > I think new users will tend to download the most stable > version of a product > > > instead of the latest cutting edge version especially > when documentation is > > > lacking. > > > > > > What do you guys think? Is 1.2 a lost cause at this > point? Is it better > > > to focus on the 1.3 release only? > > > > > > Regards, > > > Kirk Rasmussen > > > Lucasfilm Ltd. > > > > > >> -Original Message- > > >> From: Jason Carreira [mailto:[EMAIL PROTECTED]] > > >> Sent: Monday, January 13, 2003 11:17 AM > > >> To: [EMAIL PROTECTED] > > >> Subject: [OS-webwork] Scope for 1.4 > > >> > > >> > > >> So, after we finally push 1.3 out the door, we're going to > > >> need an idea > > >> of what should be in 1.4. My suggestion would be refactor the > > >> GenericDispatcher and ActionFactory to put the Interceptor > > >> code in, and > > >> have a rel
RE: [OS-webwork] Slow performance using ww:iterator tag (version 1.2.1)?
I agree. Just for comparison check out these numbers. Something is fundamentally
wrong
with how WW is implemented or how I am abusing it :)
case 1) tag
Execution Time=12.482 sec
case 2) tag only
Execution Time=10.709 sec
case 3) JSP scriplet using WW API
Execution Time=0.0020 sec
Here is the code:
<%@ taglib uri="webwork" prefix="ww" %>
<%@ taglib uri="webwork" prefix="ui" %>
<%@ page session="false" %>
<%
long start, end = -1;
%>
<% start = System.currentTimeMillis(); %>
<% end = System.currentTimeMillis(); %>
Execution Time=<%= ((double)end - start) / 1000.0 %> sec
<% start = System.currentTimeMillis(); %>
Country:
">
<% end = System.currentTimeMillis(); %>
Execution Time=<%= ((double)end - start) / 1000.0 %> sec
<% start = System.currentTimeMillis(); %>
<%
webwork.util.ValueStack vs = webwork.util.ValueStack.getStack( pageContext );
java.util.Collection countries =
(java.util.Collection)vs.findValue("@countrieslist/countries");
out.println("");
for(java.util.Iterator iter = countries.iterator(); iter.hasNext(); )
{
iter.next();
}
out.println("");
%>
<% end = System.currentTimeMillis(); %>
Execution Time=<%= ((double)end - start) / 1000.0 %> sec
> -Original Message-
> From: Hani Suleiman [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, January 12, 2003 3:04 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [OS-webwork] Slow performance using ww:iterator tag
> (version 1.2.1)?
>
>
> Only after the first try. I don't think slapping on oscache is the
> solution, as it just hides the performance problem (of course, adding
> oscache is always a good idea, but making that first hit faster would
> also be a good idea)
>
> On Sunday, January 12, 2003, at 06:00 PM, Mike Cannon-Brookes wrote:
>
> > Simple : OSCache with a session scoped cache entry. This
> will drop the
> > run
> > time down to about 1ms.
> >
> > Cheers,
> > Mike
> >
> > On 12/1/03 9:36 PM, "Robert Nicholson"
> ([EMAIL PROTECTED]) penned the
> > words:
> >
> >> That is flabbergasting. Couldn't you cache the list when
> the user logs
> >> in?
> >>
> >> Why don't you take a look at the template and see if you
> can nail down
> >> what's causing the delays assuming you haven't done that already of
> >> course. If it's user specific what does countries method look like?
> >>
> >> On Sunday, January 12, 2003, at 01:38 AM, Kirk Rasmussen wrote:
> >>
> >>> Happy new year everyone! I have a simple question about the
> >>> tag and performance using WW 1.2.1.
> >>>
> >>> I have this list of countries that contains 245 entries. When I
> >>> execute the following fragment, it takes about 15 seconds
> to execute
> >>> the iterator loop by itself. Any of you WW gurus have
> some pointers
> >>> on making it faster? I can't simply cache the select
> list because
> >>> the
> >>> form is for an address book so the selected value is user
> specific.
> >>>
> >>> <%@ taglib uri="webwork" prefix="ww" %>
> >>> <%@ taglib uri="webwork" prefix="ui" %>
> >>> <%
> >>> long start, end = -1;
> >>> %>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> <% start = System.currentTimeMillis(); %>
> >>> >>> list="@countrieslist/countries" listKey="'countryCode'"
> >>> listValue="'description'"/>
> >>> <% end = System.currentTimeMillis(); %>
> >>>
> >>>
> >>>
> >>>
> >>> Execution Time=<%= ((double)end - start) / 1000.0 %> sec
> >>>
> >>>
> >>> Thanks,
> >>> Kirk Rasmussen
> >>> Lucasfilm Ltd.
> >>>
> >>>
> >>> ---
> >>> This SF.NET email is sponsored by:
> >>> SourceForge Enterprise Edition + IBM + LinuxWorld
> Something 2 See!
> >>> http://www.vasoftware.com
> >>> ___
> >>> Open
RE: [OS-webwork] Scope for 1.4
Hello everyone! I'm very pleased to make the transition towards using the WW framework for our development group and I would like to contribute back to the project. I choose to use WW over Struts as our standard MVC framework about a month ago after reading about it in various blogs and mailing lists. I downloaded the 1.2.1 version and started developing with it because it was the only release available at the time. After using WW for about 3 weeks and as an outside observer on this list for some time now it seems to me that there needs to be separate teams focused on the 1.2, 1.3, XWork, and now 1.4 branches?? There are a number of issues that still need to be resolved with the 1.2 release IMHO. I've spoken with a number of people with more WW experience than I and the common theme I've heard is "don't use the UI tags". Why is that? Now that I've used them I know why...performance. As a new user it is disconcerting that the WW docs and examples are geared towards using the UI tags but in real world usage now I've been told not to use them by a number of people. I have gotten a lot of helpful advice on how to solve the performance problem (e.g. OSCache, patching BeanUtil class, etc.) but if WW is to grow as a community like Struts has, I think the current branch needs to be polished before moving on to the next big thing (1.3, XWork or 1.4?) I realize that the UI tags aren't necessary and that they are only a small part of the rest of the WW architecture. In our environment, the engineers are out numbered by the content folks by an 5 to 1 ratio. It is important that the pages be as simple as possible. Our pages that are released to production tend to get duplicated (copy & paste from examples) and maintenance of the pages becomes a nightmare. I think new users will tend to download the most stable version of a product instead of the latest cutting edge version especially when documentation is lacking. What do you guys think? Is 1.2 a lost cause at this point? Is it better to focus on the 1.3 release only? Regards, Kirk Rasmussen Lucasfilm Ltd. > -Original Message- > From: Jason Carreira [mailto:[EMAIL PROTECTED]] > Sent: Monday, January 13, 2003 11:17 AM > To: [EMAIL PROTECTED] > Subject: [OS-webwork] Scope for 1.4 > > > So, after we finally push 1.3 out the door, we're going to > need an idea > of what should be in 1.4. My suggestion would be refactor the > GenericDispatcher and ActionFactory to put the Interceptor > code in, and > have a relatively quick release after 1.3 with that stuff > added (and any > bug fixes). > > Thoughts? > > Jason > > -- > Jason Carreira > Technical Architect, Notiva Corp. > phone:585.240.2793 > fax:585.272.8118 > email:[EMAIL PROTECTED] > --- > Notiva - optimizing trade relationships (tm) > > > > --- > This SF.NET email is sponsored by: FREE SSL Guide from Thawte > are you planning your Web Server Security? Click here to get a FREE > Thawte SSL guide and find the answers to all your SSL > security issues. > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en > ___ > Opensymphony-webwork mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Slow performance using ww:iterator tag (version 1.2.1)?
Thanks Dick! After adding the following to my test JSP: java.beans.PropertyEditorManager.registerEditor(String.class, sun.beans.editors.StringEditor.class); I got a significant boost in performance but its still a little slow. 1) tag Execution Time=4.253 sec 2) with tag Execution Time=0.449 sec 3) JSP scriptlet using WW API Execution Time=0.0020 sec At this point I'm thinking of just implementing it as an include as a JSP scriplet using the WW API for the country list. Any other ideas (other than caching)? If I've exposed a bottleneck in the WW UI tags then I'd like to help to fix it. Thanks, Kirk Rasmussen Lucasfilm Ltd. > -Original Message- > From: Dick Zetterberg [mailto:[EMAIL PROTECTED]] > Sent: Monday, January 13, 2003 1:59 AM > To: [EMAIL PROTECTED] > Subject: Re: [OS-webwork] Slow performance using ww:iterator tag > (version 1.2.1)? > > > Hi Kirk, > > I do not use the ui: tags myself (I stick with property and > iterator etc), > so I cannot say for sure, but I believe the bad performance > is due to the > use of PropertyEditors when printing the select list. > > I had similar performance problems with the 1.2.1 version. The 1.3RC1 > version does not have this performance problem because there > one introduced > a cache of the PropertyEditors. Unfortunately that is not > allowed since it > is not thread-safe at all (as have been discussed on the list). > Last week I posted a patch to the list (and Jira), that would > fix this for > 1.3, but I still have not heard of any committer adding it to CVS. > > Anyway, back to your problem. What you can try is to patch > the BeanUtil > class. Change the method: > String toStringValue(Object obj) to just do a: > if (obj == null) return ""; else return obj.toString(); > However, then you cannot rely on any PropertyEditor to be used for > displaying your data. I do not know how important that is for > you. Or you > could change it to: > if (obj == null) return""; else if (obj instanceof String) > return (String) > obj; else ( do the method as it is today...). > > When I first had these performance problems I noticed that when the > PropertyEditorManager should return an editor for a String it > took even > longer that normal! It seemed as if this was because the > StringEditor was > not registered in the HashMap in the PropertyEditorManager, > so it was not > found on the first lookup, but later when the manager checks > for different > classnames etc. > So if you do not want to do the changes to Webwork code I > described above, > you can try to add a String editor to the PropertyEditorManager like: > PropertyEditorManager.registerEditor(String.class, > sun.beans.editors.StringEditor.class); > That might improve your performance a bit. > > Hope this helps! Good luck! > > Best regards, > > Dick Zetterberg > > [EMAIL PROTECTED] > > Original Message - > From: "Kirk Rasmussen" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Sunday, January 12, 2003 2:38 AM > Subject: [OS-webwork] Slow performance using ww:iterator tag (version > 1.2.1)? > > > > Happy new year everyone! I have a simple question about the > tag and performance using WW 1.2.1. > > > > I have this list of countries that contains 245 entries. > When I execute > the following fragment, it takes about 15 seconds to execute > the iterator > loop by itself. Any of you WW gurus have some pointers on > making it faster? > I can't simply cache the select list because the form is for > an address book > so the selected value is user specific. > > > > <%@ taglib uri="webwork" prefix="ww" %> > > <%@ taglib uri="webwork" prefix="ui" %> > > <% > > long start, end = -1; > > %> > > > > > > > > > > > > <% start = System.currentTimeMillis(); %> > > list="@countrieslist/countries" listKey="'countryCode'" > listValue="'description'"/> > > <% end = System.currentTimeMillis(); %> > > > > > > > > > > Execution Time=<%= ((double)end - start) / 1000.0 %> sec > > > > > > Thanks, > > Kirk Rasmussen > > Lucasfilm Ltd. > > > > > > --- > > This SF.NET email is sponsored by: > > SourceForge Enterprise Edition + IBM + LinuxWorld > http://www.vasoftware.com > > ___ > > Opensympho
[OS-webwork] Slow performance using ww:iterator tag (version 1.2.1)?
Happy new year everyone! I have a simple question about the tag
and performance using WW 1.2.1.
I have this list of countries that contains 245 entries. When I execute the following
fragment, it takes about 15 seconds to execute the iterator loop by itself. Any of
you WW gurus have some pointers on making it faster? I can't simply cache the select
list because the form is for an address book so the selected value is user specific.
<%@ taglib uri="webwork" prefix="ww" %>
<%@ taglib uri="webwork" prefix="ui" %>
<%
long start, end = -1;
%>
<% start = System.currentTimeMillis(); %>
<% end = System.currentTimeMillis(); %>
Execution Time=<%= ((double)end - start) / 1000.0 %> sec
Thanks,
Kirk Rasmussen
Lucasfilm Ltd.
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
[OS-webwork] WebWork 1.3 has disappeared
It looks like the 1.3 release has disappeared: http://jira.opensymphony.com/secure/BrowseProject.jspa?id=10030 Only 2.0 shows up now. There were a few issues I would like to log: WebWork 1.2.1: multiple checkboxes on the same form lead to blank values in cases of duplice fieldValue names. See my earlier e-mail for details. WebWork 1.2.1/1.3: Resin 2.1.6 fails to compile most examples using JDK 1.4 (probably a Resin issue). Looks like the compiler is smarted about uninitialized variables so it fails to compile with JDK 1.4. I have already opened a ticket with Caucho support. WebWork 1.3: /tests/expr.jsp fails in some cases. The following had Xs next them #12 webwork:elseIf test="settings['foo'] != 'bar'" #13 webwork:if test="settings['foo'] == 'wrong'" #15 webwork:elseIf test="settings['foo'] == 'bar'" #16 webwork:if test="settings['foo'] == 'wrong'" #17 webwork:elseIf test="settings['foo'] != 'bar'" #19 webwork:if test="settings['foo'] == 'wrong'" #29 webwork:else #31 webwork:if test="jibberish" #39 webwork:if test="true==true" webwork:if test="true==false" webwork:elseIf test="true==false" webwork:else #51 webwork:if test="(1==2 && 2==2) || (2==2 && 3==2)" Starting next year I would like to help work on coding for WebWork as we have decided to adopt it for our project. Once JIRA gets fixed up for 1.3 I'll take a look at the issues and see what I can help with. I've got a bunch of stuff I'm going to add to the cookbook as well. This is my new years resolution :) Thanks everyone. See you next year! Regards, Kirk Rasmussen Lucasfilm Ltd. --- This SF.NET email is sponsored by: Geek Gift Procrastinating? Get the perfect geek gift now! Before the Holidays pass you by. T H I N K G E E K . C O M http://www.thinkgeek.com/sf/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
[OS-webwork] WW 1.2.1 webwork:checkbox taglib bug?
Hello, The following form results in a blank value in the field value for the second checkbox: " method="POST"> Results in the following: Results in the following: http://www.thinkgeek.com/sf/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
[OS-webwork] RE: Opensymphony-webwork digest, Vol 1 #246 - 10 msgs
--__--__--
Message: 3
Date: Tue, 17 Dec 2002 18:46:02 -0800
From: "Kirk Rasmussen" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Subject: [OS-webwork] Maintaining checkbox state in feedback loop
Reply-To: [EMAIL PROTECTED]
Hello everyone,
Please excuse this newbie question but I'm still coming up to speed on =
WW and I've run into a little problem with checkboxes. There wasn't an =
example in the distribution that I could find for the following =
situation.
On my form I have the following:
" method=3D"POST">
On initial load I want the checkbox to default to checked. In my Action =
class I have:
protected boolean newsletter =3D true;
protected boolean promotions =3D true;
public boolean getNewsletter()
{
System.err.println( "getNewsletter()" );
=20
return newsletter;
}
=20
public void setNewsletter( boolean checked )
{
System.err.println( "setNewsletter()" );
=20
this.newsletter =3D checked;
}
This works fine on initial load (foo!default.action) but fails on the =
POST feedback loop (e.g. user enters invalid e-mail address) if I =
deselect the newsletter checkbox. The checkbox will stay checked =
because the internal state has already been set to true.
Since there is no parameter being passed to the WW dispatcher, =
setNewletter(false) will never get called, right? How do I handle a =
"missing" parameter in WW???
Am I missing something? =20
Thanks,
Kirk Rasmussen
Lucasfilm Ltd.
--__--__--
> Message: 4
> From: "Cameron Braid" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Subject: RE: [OS-webwork] Maintaining checkbox state in feedback loop
> Date: Wed, 18 Dec 2002 14:47:44 +1000
> Reply-To: [EMAIL PROTECTED]
>
> I am not an expert on WW, though the normal way to deal with 'missing'
> http data is to set a default value for the property and it can be
> overridden by the request parameter...
>
> i.e. if you set
>
> protected boolean newsletter = false;
>
> instead of true, then WW will call the setNewsletter(true) when the
> checkbox is checked.
>
> Cam
>
But the problem is I want the default to be true. I guess I
could have a hidden input value that set it to false so that
there is always at least one "newsletter" parameter passed to
the action, though it seems sort of hackish to me since it
has dependencies on the HTML form.
Is there a way to get the original parameter map? I looked at
the code for ActionSupport and it doesn't look like the map gets
saved. I suppose I could get the HttpServletRequest and look for
the parameter in there but it ties the action to the servlet API.
Is there a way to deal with this in a more generic fashion?
Thanks,
Kirk Rasmussen
Lucasfilm Ltd.
---
This SF.NET email is sponsored by: Order your Holiday Geek Presents Now!
Green Lasers, Hip Geek T-Shirts, Remote Control Tanks, Caffeinated Soap,
MP3 Players, XBox Games, Flying Saucers, WebCams, Smart Putty.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
[OS-webwork] Maintaining checkbox state in feedback loop
Hello everyone,
Please excuse this newbie question but I'm still coming up to speed on WW and I've run
into a little problem with checkboxes. There wasn't an example in the distribution
that I could find for the following situation.
On my form I have the following:
" method="POST">
On initial load I want the checkbox to default to checked. In my Action class I have:
protected boolean newsletter = true;
protected boolean promotions = true;
public boolean getNewsletter()
{
System.err.println( "getNewsletter()" );
return newsletter;
}
public void setNewsletter( boolean checked )
{
System.err.println( "setNewsletter()" );
this.newsletter = checked;
}
This works fine on initial load (foo!default.action) but fails on the POST feedback
loop (e.g. user enters invalid e-mail address) if I deselect the newsletter checkbox.
The checkbox will stay checked because the internal state has already been set to true.
Since there is no parameter being passed to the WW dispatcher, setNewletter(false)
will never get called, right? How do I handle a "missing" parameter in WW???
Am I missing something?
Thanks,
Kirk Rasmussen
Lucasfilm Ltd.
---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
[OS-webwork] 1.3 Release
There weresome messages earlier this week about a 1.3 release. Is there a new version available yet or is this still being worked on? Can I help with anything? I'm still getting up to speed with the 1.2.1 version. I'm not sure what new features are in the 1.3 branch. Is there a CVS tag? Thanks, Kirk Rasmussen Lucasfilm Ltd.
[OS-webwork] Dynamic action view mappings
Hello, I am curious if it is possible to dynamically create and/or modify an action's view mappings for a particular request with WW? I'm not sure if its necessary or not so you let me explain the problem. Lets say you have a multi-paged user profile service. After you submit a page, the destination success page depends on your current role (e.g. child vs. adult). How would you build that intelligence into a WW action? An action's success page depends on the role of the user. I guess in the JSP page I could change the action called based on the user's role but it seems sort of hackish to me. Another idea that occurred to me is to map the success view to another action that performs a redirect based on user's role. Again, it seems workable but kind of hackish. Does anyone else have some suggestions on how to handle this situation best? Thanks, Kirk Rasmussen Lucasfilm Ltd. --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
[OS-webwork] Multiple instances of WebWork
Hello, I was wondering if it is possible to have multiple instances of WebWork within the same applicaton server. For example, I have 4 virtual hosts running within Resin. I want each one of these to have distinct WW configurations (e.g. different templateDir for skinning). Is this possible to do? Thanks, Kirk Rasmussen Lucasfilm Ltd.
