Re: [OS-webwork] Reflection
Erik Beeson wrote: Rickard, as I understood, XWork was to break away from J2EE, hence removing web from the name. If new versions with strong web ties are going to remain, shouldn't they remain under the original WebWork name? That is something I wanted to gauge by my last couple of emails. I personally do not believe (at this point) that making the web part optional is going to work very well. I certainly don't believe that it is going to be feasible, or even a good idea, to make a framework that allows code to be written for both Swing and the web. They're different beasts with different requirements, with completely different thinking behind how code gets written. We have a lot of Swing code in our project, and when I look at it I simply don't see how something like XWork would fit in, or why it would be useful. What *is* useful is to allow actions to be called without a servlet environment, but more or less *only* for testing/debugging purposes. Executing actions as a response to asynchronous messages could work too. But that's about it. I do not believe that actions (except for maybe 1% of special cases) can be reused in so different spaces. I remain open to the *possibility* of it, but so far I just haven't seen it. So, given all of this, my resignation from XWork still holds. The requirements that have been voiced the last few days are not mine, and I don't think they're compatible with my goals, at least not without serious compromises that will only hurt the end result. The question then becomes: would it be useful to do *both* XWork and WebWork, but as separate projects with these different goals? /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] Reflection
What kind of real world example applications do you want? Wafer has a working webwork example... And docs? Who needs them - they're for people who aren't willing to roll their sleeves up and dig directly into the code, right? (Note droll humour.) On Sun, 12 Jan 2003, Heng Sin Low wrote: I think it might be beneficial to do both xwork and webwork as separate project at this point of time. At least, people will spent less time debating at mailing list and get things done. I guess there is no right or wrong here, it is just that people have different preference and needs. For instance, I only do webapp and certainly don't want all the extra complexity/coolness of xwork. IMHO, xwork if implemented base on idea presented here so far is a very different beast from existing webwork and might as well start off as a fresh project. Also, if we just concentrate all the efforts on xwork ( which will probably need sometime to mature ), we are neglecting the immediate need of existing webwork users. Look at webwork 1.3, it have been at rc1 for sometime and nobody seems to care about its status. Not to mention it still lack documentation, real world example application, have outstanding xdoclet bug, etc. --- Rickard_Öberg [EMAIL PROTECTED] wrote: Erik Beeson wrote: Rickard, as I understood, XWork was to break away from J2EE, hence removing web from the name. If new versions with strong web ties are going to remain, shouldn't they remain under the original WebWork name? That is something I wanted to gauge by my last couple of emails. I personally do not believe (at this point) that making the web part optional is going to work very well. I certainly don't believe that it is going to be feasible, or even a good idea, to make a framework that allows code to be written for both Swing and the web. They're different beasts with different requirements, with completely different thinking behind how code gets written. We have a lot of Swing code in our project, and when I look at it I simply don't see how something like XWork would fit in, or why it would be useful. What *is* useful is to allow actions to be called without a servlet environment, but more or less *only* for testing/debugging purposes. Executing actions as a response to asynchronous messages could work too. But that's about it. I do not believe that actions (except for maybe 1% of special cases) can be reused in so different spaces. I remain open to the *possibility* of it, but so far I just haven't seen it. So, given all of this, my resignation from XWork still holds. The requirements that have been voiced the last few days are not mine, and I don't think they're compatible with my goals, at least not without serious compromises that will only hurt the end result. The question then becomes: would it be useful to do *both* XWork and WebWork, but as separate projects with these different goals? /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 __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.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 - Joseph B. Ottinger [EMAIL PROTECTED] http://enigmastation.comIT Consultant --- 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] Reflection
I think it might be beneficial to do both xwork and webwork as separate project at this point of time. At least, people will spent less time debating at mailing list and get things done. I guess there is no right or wrong here, it is just that people have different preference and needs. For instance, I only do webapp and certainly don't want all the extra complexity/coolness of xwork. IMHO, xwork if implemented base on idea presented here so far is a very different beast from existing webwork and might as well start off as a fresh project. Also, if we just concentrate all the efforts on xwork ( which will probably need sometime to mature ), we are neglecting the immediate need of existing webwork users. Look at webwork 1.3, it have been at rc1 for sometime and nobody seems to care about its status. Not to mention it still lack documentation, real world example application, have outstanding xdoclet bug, etc. --- Rickard_Öberg [EMAIL PROTECTED] wrote: Erik Beeson wrote: Rickard, as I understood, XWork was to break away from J2EE, hence removing web from the name. If new versions with strong web ties are going to remain, shouldn't they remain under the original WebWork name? That is something I wanted to gauge by my last couple of emails. I personally do not believe (at this point) that making the web part optional is going to work very well. I certainly don't believe that it is going to be feasible, or even a good idea, to make a framework that allows code to be written for both Swing and the web. They're different beasts with different requirements, with completely different thinking behind how code gets written. We have a lot of Swing code in our project, and when I look at it I simply don't see how something like XWork would fit in, or why it would be useful. What *is* useful is to allow actions to be called without a servlet environment, but more or less *only* for testing/debugging purposes. Executing actions as a response to asynchronous messages could work too. But that's about it. I do not believe that actions (except for maybe 1% of special cases) can be reused in so different spaces. I remain open to the *possibility* of it, but so far I just haven't seen it. So, given all of this, my resignation from XWork still holds. The requirements that have been voiced the last few days are not mine, and I don't think they're compatible with my goals, at least not without serious compromises that will only hurt the end result. The question then becomes: would it be useful to do *both* XWork and WebWork, but as separate projects with these different goals? /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 __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.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
[OS-webwork] ww:include broken in RC1?
Is anyone having success with the ww:include when the value is an action? Sure it executes the action just fine, but I am not getting any callbacks from the view to hit the ValueStack. Calling the action directly, _does_ result in the action and page being executed correctly. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of James Cook Sent: Thursday, January 09, 2003 9:18 PM To: [EMAIL PROTECTED] Subject: [OS-webwork] Inclusion of a webwork call invoked by JSTL I have a web page coded as a JSP and utilizing JSTL tags. On this page, I have a dynamic report that is generated by a webwork call. I am using the c:include tag to reference the webwork action, and it is mapped to a JSP view for rendering. Time for a visual? index.jsp +--+ | | | | | | | +--+ | | | | | | | |-- report.action (mapped to a view report.jsp) | | | | invoked by using JSTL c:import | +--+ | url=/report.action/ | | | | | | | | +--+ The c:include invokes the webwork action and the view is returned, however the view is returned as a String! It is not parsed by the JSP engine, so the callbacks to the ValueStack never occur. I have also tried the jsp:include tag, but it does not render the included JSP either. Perhaps there is a webwork tag to handle this? I would prefer a pure JSTL solution, but at this point, I am open. :) What is the best way to handle this simplified problem? --- 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: Re: [OS-webwork] Reflection
I have been following this list for quite some time with great interest. I really like all the new ideas for XWork. I think it would be sad not to see those ideas become implemented only because it would be difficult to keep it Swing compatible. If an alternative is to break Webwork and XWork into two different projects I think it would be unfortunate, however, considering the alternative (miss out on all the great new functionality) I still think it would be worth it, but that's just my thinking for all it's worth. /Robert -Original Message- From: Rickard Öberg [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Sun, 12 Jan 2003 14:24:26 +0100 Subject: Re: [OS-webwork] Reflection Erik Beeson wrote: Rickard, as I understood, XWork was to break away from J2EE, hence removing web from the name. If new versions with strong web ties are going to remain, shouldn't they remain under the original WebWork name? That is something I wanted to gauge by my last couple of emails. I personally do not believe (at this point) that making the web part optional is going to work very well. I certainly don't believe that it is going to be feasible, or even a good idea, to make a framework that allows code to be written for both Swing and the web. They're different beasts with different requirements, with completely different thinking behind how code gets written. We have a lot of Swing code in our project, and when I look at it I simply don't see how something like XWork would fit in, or why it would be useful. What *is* useful is to allow actions to be called without a servlet environment, but more or less *only* for testing/debugging purposes. Executing actions as a response to asynchronous messages could work too. But that's about it. I do not believe that actions (except for maybe 1% of special cases) can be reused in so different spaces. I remain open to the *possibility* of it, but so far I just haven't seen it. So, given all of this, my resignation from XWork still holds. The requirements that have been voiced the last few days are not mine, and I don't think they're compatible with my goals, at least not without serious compromises that will only hurt the end result. The question then becomes: would it be useful to do *both* XWork and WebWork, but as separate projects with these different goals? /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 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
RE: [OS-webwork] Reflection
I'm not sure I see the disconnect here. What's so different about Xwork? Views can still be JSP / Velocity / XSLT which generates HTML. It's still a great framework for web app development. If the ThreadLocal thing is the only sticking point, then lets talk about that. I'm personally for the changes Patrick made, as I think it makes the framework much more flexible. For instance, you could queue actions using JMS with all of the context (the ActionInvocation, or whatever Patrick has named it) carried along. However, that said, if it's such a big deal that people are talking about forking the code base and splitting Xwork and Webwork, then I think we should roll it back and discuss. -Original Message- From: matt baldree [mailto:[EMAIL PROTECTED]] Sent: Sunday, January 12, 2003 10:18 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Reflection I think there are two directions here and I don't see any easy resolution at this stage. So, yes I think two projects make sense. My next question is Is there room for these two projects at OS? Does it make sense or will it be a distraction since they do have overlap? Should WW move back out on its own? -Matt - Original Message - From: Rickard Öberg [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, January 12, 2003 7:24 AM Subject: Re: [OS-webwork] Reflection Erik Beeson wrote: Rickard, as I understood, XWork was to break away from J2EE, hence removing web from the name. If new versions with strong web ties are going to remain, shouldn't they remain under the original WebWork name? That is something I wanted to gauge by my last couple of emails. I personally do not believe (at this point) that making the web part optional is going to work very well. I certainly don't believe that it is going to be feasible, or even a good idea, to make a framework that allows code to be written for both Swing and the web. They're different beasts with different requirements, with completely different thinking behind how code gets written. We have a lot of Swing code in our project, and when I look at it I simply don't see how something like XWork would fit in, or why it would be useful. What *is* useful is to allow actions to be called without a servlet environment, but more or less *only* for testing/debugging purposes. Executing actions as a response to asynchronous messages could work too. But that's about it. I do not believe that actions (except for maybe 1% of special cases) can be reused in so different spaces. I remain open to the *possibility* of it, but so far I just haven't seen it. So, given all of this, my resignation from XWork still holds. The requirements that have been voiced the last few days are not mine, and I don't think they're compatible with my goals, at least not without serious compromises that will only hurt the end result. The question then becomes: would it be useful to do *both* XWork and WebWork, but as separate projects with these different goals? /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 =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 --- 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] Reflection
It's not that it's difficult to keep it Swing compatible and it's not a choice of loosing features. The new features, the biggest one being Interceptors, IMHO, are in no way involved in this. This is really a question of cleaning up some (IMO) ugliness in the original code that was put in to keep backward compatibility. Actions were originally spec'd to have a method, execute(), with no parameters. That was back when we had ServletAware, etc., and the context information would be made available to the Action before it was executed. When it was decided to get rid of these interfaces, to decouple Webwork from Servlets, it was decided to move to ActionContext, which uses a ThreadLocal to save the execution context for the Action in a way that is easily available, local to the current execution, and doesn't have to be passed as a parameter. Unfortunately, if you want Action preparation, execution, etc, to be able to be run from multiple threads, ThreadLocals are, at the very least, very difficult to use, and, at the worst, unworkable. Is this a huge deal? No, not really. Would it be nice to be able to do this the right way? Yes. But, if it is a requirement that old Actions not have to change their method signature and be able to get the params from the ActionContext ThreadLocal, then this is a limitation that can be documented and worked around. Just my $0.02 Jason -Original Message- From: Robert Carlens [mailto:[EMAIL PROTECTED]] Sent: Sunday, January 12, 2003 1:11 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Reflection I have been following this list for quite some time with great interest. I really like all the new ideas for XWork. I think it would be sad not to see those ideas become implemented only because it would be difficult to keep it Swing compatible. If an alternative is to break Webwork and XWork into two different projects I think it would be unfortunate, however, considering the alternative (miss out on all the great new functionality) I still think it would be worth it, but that's just my thinking for all it's worth. /Robert -Original Message- From: Rickard Öberg [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Sun, 12 Jan 2003 14:24:26 +0100 Subject: Re: [OS-webwork] Reflection Erik Beeson wrote: Rickard, as I understood, XWork was to break away from J2EE, hence removing web from the name. If new versions with strong web ties are going to remain, shouldn't they remain under the original WebWork name? That is something I wanted to gauge by my last couple of emails. I personally do not believe (at this point) that making the web part optional is going to work very well. I certainly don't believe that it is going to be feasible, or even a good idea, to make a framework that allows code to be written for both Swing and the web. They're different beasts with different requirements, with completely different thinking behind how code gets written. We have a lot of Swing code in our project, and when I look at it I simply don't see how something like XWork would fit in, or why it would be useful. What *is* useful is to allow actions to be called without a servlet environment, but more or less *only* for testing/debugging purposes. Executing actions as a response to asynchronous messages could work too. But that's about it. I do not believe that actions (except for maybe 1% of special cases) can be reused in so different spaces. I remain open to the *possibility* of it, but so far I just haven't seen it. So, given all of this, my resignation from XWork still holds. The requirements that have been voiced the last few days are not mine, and I don't think they're compatible with my goals, at least not without serious compromises that will only hurt the end result. The question then becomes: would it be useful to do *both* XWork and WebWork, but as separate projects with these different goals? /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 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 =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
Re: [OS-webwork] Reflection
Amen (great point abot JMS, btw)! This is _sandbox_, PLEASE everyone stop making things so dramatic. All I'm doing is putting things in there for us to discuss and toy with. Then we talk. That's the idea: Write, talk, write some more. Not write, talk, abandon project ;) -Pat - Original Message - From: Jason Carreira [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, January 12, 2003 11:04 AM Subject: RE: [OS-webwork] Reflection I'm not sure I see the disconnect here. What's so different about Xwork? Views can still be JSP / Velocity / XSLT which generates HTML. It's still a great framework for web app development. If the ThreadLocal thing is the only sticking point, then lets talk about that. I'm personally for the changes Patrick made, as I think it makes the framework much more flexible. For instance, you could queue actions using JMS with all of the context (the ActionInvocation, or whatever Patrick has named it) carried along. However, that said, if it's such a big deal that people are talking about forking the code base and splitting Xwork and Webwork, then I think we should roll it back and discuss. -Original Message- From: matt baldree [mailto:[EMAIL PROTECTED]] Sent: Sunday, January 12, 2003 10:18 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Reflection I think there are two directions here and I don't see any easy resolution at this stage. So, yes I think two projects make sense. My next question is Is there room for these two projects at OS? Does it make sense or will it be a distraction since they do have overlap? Should WW move back out on its own? -Matt - Original Message - From: Rickard Öberg [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, January 12, 2003 7:24 AM Subject: Re: [OS-webwork] Reflection Erik Beeson wrote: Rickard, as I understood, XWork was to break away from J2EE, hence removing web from the name. If new versions with strong web ties are going to remain, shouldn't they remain under the original WebWork name? That is something I wanted to gauge by my last couple of emails. I personally do not believe (at this point) that making the web part optional is going to work very well. I certainly don't believe that it is going to be feasible, or even a good idea, to make a framework that allows code to be written for both Swing and the web. They're different beasts with different requirements, with completely different thinking behind how code gets written. We have a lot of Swing code in our project, and when I look at it I simply don't see how something like XWork would fit in, or why it would be useful. What *is* useful is to allow actions to be called without a servlet environment, but more or less *only* for testing/debugging purposes. Executing actions as a response to asynchronous messages could work too. But that's about it. I do not believe that actions (except for maybe 1% of special cases) can be reused in so different spaces. I remain open to the *possibility* of it, but so far I just haven't seen it. So, given all of this, my resignation from XWork still holds. The requirements that have been voiced the last few days are not mine, and I don't think they're compatible with my goals, at least not without serious compromises that will only hurt the end result. The question then becomes: would it be useful to do *both* XWork and WebWork, but as separate projects with these different goals? /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 =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 --- 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 = Something 2 See! http://www.vasoftware.com ___
Re: [OS-webwork] Reflection
On Sunday, January 12, 2003, at 08:24 AM, Rickard Öberg wrote: So, given all of this, my resignation from XWork still holds. The requirements that have been voiced the last few days are not mine, and I don't think they're compatible with my goals, at least not without serious compromises that will only hurt the end result. The question then becomes: would it be useful to do *both* XWork and WebWork, but as separate projects with these different goals? Hmmm, That thought has occurred to me more than once in the last few days. I am certainly not feeling much love for the direction xwork is headed in. I'd bow out and not care or be interested, unfortunately I can't do that as I have a lot invested in webwork, and would rather use something that is maintained and suchlike. So why not have the xwork crowd go ahead and xwork, and maybe others could work on webwork 1.4/2.0? xwork need not care about backward compatibility or have web as its main focus. Webwork would be considerate to existing users and still focus on the web (while not ruling out non-web clients). Hani --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] 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 webwork:iterator 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; % table width=100% tr !-- start cell with webwork components -- ww:action name='CountriesList' id=countrieslist/ % start = System.currentTimeMillis(); % ui:select label='Country' name='country' list=@countrieslist/countries listKey='countryCode' listValue='description'/ % end = System.currentTimeMillis(); % !-- end cell with webwork components -- /tr /table p Execution Time=%= ((double)end - start) / 1000.0 % sec /p 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 --- 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 --- 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] Reflection
The multiple thread thing is simple/trivial to solve using AOP. I'm not sure this would cause any performance issue though. --- Jason Carreira [EMAIL PROTECTED] wrote: It's not that it's difficult to keep it Swing compatible and it's not a choice of loosing features. The new features, the biggest one being Interceptors, IMHO, are in no way involved in this. This is really a question of cleaning up some (IMO) ugliness in the original code that was put in to keep backward compatibility. Actions were originally spec'd to have a method, execute(), with no parameters. That was back when we had ServletAware, etc., and the context information would be made available to the Action before it was executed. When it was decided to get rid of these interfaces, to decouple Webwork from Servlets, it was decided to move to ActionContext, which uses a ThreadLocal to save the execution context for the Action in a way that is easily available, local to the current execution, and doesn't have to be passed as a parameter. Unfortunately, if you want Action preparation, execution, etc, to be able to be run from multiple threads, ThreadLocals are, at the very least, very difficult to use, and, at the worst, unworkable. Is this a huge deal? No, not really. Would it be nice to be able to do this the right way? Yes. But, if it is a requirement that old Actions not have to change their method signature and be able to get the params from the ActionContext ThreadLocal, then this is a limitation that can be documented and worked around. Just my $0.02 Jason -Original Message- From: Robert Carlens [mailto:[EMAIL PROTECTED]] Sent: Sunday, January 12, 2003 1:11 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Reflection I have been following this list for quite some time with great interest. I really like all the new ideas for XWork. I think it would be sad not to see those ideas become implemented only because it would be difficult to keep it Swing compatible. If an alternative is to break Webwork and XWork into two different projects I think it would be unfortunate, however, considering the alternative (miss out on all the great new functionality) I still think it would be worth it, but that's just my thinking for all it's worth. /Robert -Original Message- From: Rickard Öberg [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Sun, 12 Jan 2003 14:24:26 +0100 Subject: Re: [OS-webwork] Reflection Erik Beeson wrote: Rickard, as I understood, XWork was to break away from J2EE, hence removing web from the name. If new versions with strong web ties are going to remain, shouldn't they remain under the original WebWork name? That is something I wanted to gauge by my last couple of emails. I personally do not believe (at this point) that making the web part optional is going to work very well. I certainly don't believe that it is going to be feasible, or even a good idea, to make a framework that allows code to be written for both Swing and the web. They're different beasts with different requirements, with completely different thinking behind how code gets written. We have a lot of Swing code in our project, and when I look at it I simply don't see how something like XWork would fit in, or why it would be useful. What *is* useful is to allow actions to be called without a servlet environment, but more or less *only* for testing/debugging purposes. Executing actions as a response to asynchronous messages could work too. But that's about it. I do not believe that actions (except for maybe 1% of special cases) can be reused in so different spaces. I remain open to the *possibility* of it, but so far I just haven't seen it. So, given all of this, my resignation from XWork still holds. The requirements that have been voiced the last few days are not mine, and I don't think they're compatible with my goals, at least not without serious compromises that will only hurt the end result. The question then becomes: would it be useful to do *both* XWork and WebWork, but as separate projects with these different goals? /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 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 =omething 2 See! http://www.vasoftware.com
