Re: [OS-webwork] WebWork 2.0: FilterDispatcher? [Small problem +solution?]
Patrick Lightbody wrote: I found a possible way around this, but I'm not sure if it's a good idea or not :) What if the FilterDispatcher never actually makes a call to filterChain.doFilter()? This would get around the duplicate view request problem outlined below, but would require that the filter -must- be the last one applied or else you'll loose the application of filters further down the chain. I don't think this is too bad though, since we can just -clearly- document that the FilterDispatcher (if you want to use it) must be applied last. Thoughts? Works for me :-) /Rickard --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
[OS-webwork] Using SiteMesh for the UI tags
As I've mentioned in the past, I wanted to explore using SiteMesh to power the UI taglibs, at least for JSP. I know Rickard threw out the idea of using velocity for all taglibs (regardless if your view is JSP), so what I'd like to see happen is this: 1) I'll commit my sitemesh integration stuff with a simple TextFieldTag implementation that is literally 4 lines of code, since it extends ApplyDecoratorTag from SiteMesh while adding a few attribute elements. 2) Rickard or someone else commit an equally simple veloctiy implementation -called from jsp- so that we can compare side-by-side with the current success.jsp. Very rough performance tests showed that when about 50 ww:textfield/ tags were placed in a row, the page took about 170ms to load on average. However, when I help to ctrl-r and forced about 20 page reloads within about 10ms, average response time shot up to about 2000ms. OK, I'll commit tomorrow morning. In the meantime, Rickard can you hack together a velocity-powered taglib? -Pat --- 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] Configuration question
Looking over the *Configuration framework, it looks like keys that aren't found result in a IllegalArgumentException being thrown. Now, the DelegatingConfiguration goes through all configurations when trying to find any named property. This means that there are a *lot* of getString calls to each configuration, hence a lot of new exceptions being thrown and caught which is rather expensive. My question is, why was this done this way? Why not just use nulls or some other static marker object if we need to distinguish between 'the value is null' and 'I don't know anything about this value'? --- 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] Configuration question
Hani Suleiman wrote: Looking over the *Configuration framework, it looks like keys that aren't found result in a IllegalArgumentException being thrown. Now, the DelegatingConfiguration goes through all configurations when trying to find any named property. This means that there are a *lot* of getString calls to each configuration, hence a lot of new exceptions being thrown and caught which is rather expensive. My question is, why was this done this way? Why not just use nulls or some other static marker object if we need to distinguish between 'the value is null' and 'I don't know anything about this value'? The reason is that it's easier to code client-code using exceptions. Instead of doing null-checks all the time you can write code that assume that certain settings are available, and then simply try/catch it in case it wasn't available. That was the reason. Improving performance may be a more important factor though, so go ahead and change it if you want to. Just make sure that all calls to the conf. does proper null checking. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] WebWork 2.0: FilterDispatcher? [Small problem + solution?]
I don't plan on using it, so as long as it doesn't mess up the core +1 -Original Message- From: Patrick Lightbody [mailto:[EMAIL PROTECTED]] Sent: Monday, January 27, 2003 2:37 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] WebWork 2.0: FilterDispatcher? [Small problem + solution?] I found a possible way around this, but I'm not sure if it's a good idea or not :) What if the FilterDispatcher never actually makes a call to filterChain.doFilter()? This would get around the duplicate view request problem outlined below, but would require that the filter -must- be the last one applied or else you'll loose the application of filters further down the chain. I don't think this is too bad though, since we can just -clearly- document that the FilterDispatcher (if you want to use it) must be applied last. Thoughts? -Pat - Original Message - From: Patrick Lightbody [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 23, 2003 1:33 AM Subject: Re: [OS-webwork] WebWork 2.0: FilterDispatcher? [Small problem] Found one small problem with this approach (and it may just be that using the filter + the servlet at all times just can't always work perfectly): If you are using the filter and servlet and access success.jsp, the action will be invoked, then the ResultInterceptor will kick in, call ServletDispatcherResult, which will see that the filter is in use and _not_ dispatch, since the filter is going to chain right after. This is the correct behavior. But if the result of the action executing is _different_ than the URL being request (ie: error.jsp), the ServletDispatcherResult does what it should (dispatch out to error.jsp) but the filter will still try to grab the original request to success.jsp. Thoughts? One way would be to make the WW 2.0 framework/config more rigid and to remove the ResultInterceptor stuff and specifically hard code the ServletDispatcher to doing the dispatching _in_ the servlet itself (problem solved, but then generic results aren't possible in WW, which includes chaining, and then we open up the door to possibly more hardcoding). Anyway, I'm outta here, let me know what you guys think. -Pat - Original Message - From: Rickard Öberg [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 23, 2003 12:06 AM Subject: Re: [OS-webwork] WebWork 2.0: FilterDispatcher? Patrick Lightbody wrote: snippetysnap What do you think? Rickard, would this work for you? Everyone else, would this work for YOU? ;) Works for me! :-) /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ 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 --- 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] Xwork configuration update
I've checked in some new Xwork configuration code. Here's the test xwork.xml file: xwork package name=default result-types result-type name=chain class=com.opensymphony.xwork.ActionChainResult/ /result-types interceptors interceptor name=timer class=com.opensymphony.xwork.interceptor.TimerInterceptor/ interceptor name=logger class=com.opensymphony.xwork.interceptor.LoggingInterceptor/ interceptor name=chain class=com.opensymphony.xwork.interceptor.ChainingInterceptor/ interceptor name=params class=com.opensymphony.xwork.interceptor.ParametersInterceptor/ interceptor name=static-params class=com.opensymphony.xwork.interceptor.StaticParametersInterceptor/ interceptor name=component class=com.opensymphony.xwork.interceptor.component.ComponentInterceptor / interceptor name=result class=com.opensymphony.xwork.interceptor.ResultInterceptor/ interceptor name=stack class=com.opensymphony.xwork.interceptor.StackInterceptor/ interceptor-stack name=defaultStack interceptor-ref name=result/ interceptor-ref name=static-params/ interceptor-ref name=params/ interceptor-ref name=stack/ /interceptor-stack interceptor-stack name=debugStack interceptor-ref name=timer/ interceptor-ref name=logger/ /interceptor-stack /interceptors action name=Foo class=com.opensymphony.xwork.SimpleAction action-params param name=foo17/param param name=bar23/param /action-params result name=success type=chain param name=actionNameBar/param /result interceptor-ref name=debugStack/ interceptor-ref name=defaultStack/ /action /package package name=bar extends=default namespace=/foo/bar interceptors interceptor-stack name=barDefaultStack interceptor-ref name=debugStack/ interceptor-ref name=defaultStack/ /interceptor-stack /interceptors action name=Bar class=com.opensymphony.xwork.SimpleAction interceptor-ref name=barDefaultStack/ /action /package /xwork Here you can see that I've implemented Rickard's ideas (see http://www.opensymphony.com:8668/space/RickardXWorkThoughts). 1) Packages - All configuration settings are in a package. Result types, interceptors, and actions are all package context specific, no more global settings (unless you have a default package and have your other packages extend it). Result, Interceptor, and Action configurations are inherited by packages which extend another package, such as package bar above, which extends default. 2) Interceptor stacks - Make it easier to have sets of interceptors you apply together in a certain order. These are also inherited as part of the interceptor definition inheritance. Essentially these are just name mappings to lists of interceptors instead of one Interceptor. 3)Namespaces - a new idea of mine, this allows actions to be aliased with the same name, providing they are in different namespaces. With the ServletDispatcher, this equates to the path before the action name, which will allow for J2EE declarative security. Namespaces are optional attributes of package definitions and, if excluded, defaults to . If the action configuration is not found with the supplied namespace, the namespace is checked as the default namespace, which makes it work like we have now (any path works, you get the action aliased with the name). Check out the code in the sandbox in CVS. 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
[OS-webwork] Wiki dammit
Can someone please explain to me how to publish a page on the Wiki? I can't seem to find a link to create a new page Gaah! 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
RE: [OS-webwork] Using the WiKi
Cool. Got it. It sure wasn't obvious though! Maybe my wiki paradigm has been messed up because we use Traction at work. -Original Message- From: Erik Beeson [mailto:[EMAIL PROTECTED]] Sent: Monday, January 27, 2003 10:40 PM To: Subject: [OS-webwork] Using the WiKi To add a page to the WiKi (as I understand it): Create and account and login. Go to the page that you want to link to your new page. Edit the page by clicking the [edit] link in the upper right hand corner. Create a link to your new page by putting the link text in []. (See http://snipsnap.org/space/snipsnap-QuickTour) Save the page. You'll have a link on the page saying [create MyLinkText] Go to your new page and edit it as desired. --Erik See the following for more help: http://snipsnap.org/space/snipsnap-QuickTour http://snipsnap.org/space/snipsnap-help --- 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] Using SiteMesh for the UI tags
OK, I've commited them. Try it out and let's have some feedback! - Original Message - From: Patrick Lightbody [EMAIL PROTECTED] To: os-ww [EMAIL PROTECTED] Sent: Monday, January 27, 2003 12:57 AM Subject: [OS-webwork] Using SiteMesh for the UI tags As I've mentioned in the past, I wanted to explore using SiteMesh to power the UI taglibs, at least for JSP. I know Rickard threw out the idea of using velocity for all taglibs (regardless if your view is JSP), so what I'd like to see happen is this: 1) I'll commit my sitemesh integration stuff with a simple TextFieldTag implementation that is literally 4 lines of code, since it extends ApplyDecoratorTag from SiteMesh while adding a few attribute elements. 2) Rickard or someone else commit an equally simple veloctiy implementation -called from jsp- so that we can compare side-by-side with the current success.jsp. Very rough performance tests showed that when about 50 ww:textfield/ tags were placed in a row, the page took about 170ms to load on average. However, when I help to ctrl-r and forced about 20 page reloads within about 10ms, average response time shot up to about 2000ms. OK, I'll commit tomorrow morning. In the meantime, Rickard can you hack together a velocity-powered taglib? -Pat --- 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
