Re: OGNL performance detrimental to Struts 2
I'm not sure I'd worry about it. Howard's post said it only made 1ms difference. Bob On 12/12/06, dice <[EMAIL PROTECTED]> wrote: The custom OGNLValueStack made little difference. AFAIK, the majority of the OGNL calls are dealing with the tag parameters in the tag templates which are not simple java properties. It's a pity. I was looking forward to using Struts 2 on our next major project but much like JSF it is too risky from a performance perspective. Back to Struts 1 ... *sigh* Bob Lee wrote: > > We noticed the same thing. Maybe we should replace it with JSP-EL? (I > don't > have time to rewrite OGNL myself.) > > In the mean time, we wrote a custom version of OgnlValueStack. > -- View this message in context: http://www.nabble.com/OGNL-performance-detrimental-to-Struts-2-tf2804655.html#a7847866 Sent from the Struts - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OGNL performance detrimental to Struts 2
The custom OGNLValueStack made little difference. AFAIK, the majority of the OGNL calls are dealing with the tag parameters in the tag templates which are not simple java properties. It's a pity. I was looking forward to using Struts 2 on our next major project but much like JSF it is too risky from a performance perspective. Back to Struts 1 ... *sigh* Bob Lee wrote: > > We noticed the same thing. Maybe we should replace it with JSP-EL? (I > don't > have time to rewrite OGNL myself.) > > In the mean time, we wrote a custom version of OgnlValueStack. > -- View this message in context: http://www.nabble.com/OGNL-performance-detrimental-to-Struts-2-tf2804655.html#a7847866 Sent from the Struts - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OGNL performance detrimental to Struts 2
Would you guys be "morally offended" if I lifted this code? (or potentially did, need to see how amenable the two are first, but it shouldn't be too hard) I mean, I know licensing is blah blah and all , but you know...Maybe it's not "right". Bob Lee wrote: > > > In the mean time, we wrote a custom version of OgnlValueStack (pasted > below) > which optimizes and uses reflection for normal Java expressions; it's an > order of magnitude faster. I think it's 100% compatible (we haven't > noticed > any problems). > > -- View this message in context: http://www.nabble.com/OGNL-performance-detrimental-to-Struts-2-tf2804655.html#a7847251 Sent from the Struts - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven build & release changes
The new struts-master pom has the following distribution management section: struts-staging Apache Struts Staging Repository scp://people.apache.org/www/people.apache.org/builds/struts/m2-staging-repository ... This means that if the version number does not end in -SNAPSHOT, the artifacts will be deployed to http://people.apache.org/builds/struts/m2-staging-repository. (Previously, we were staging releases in the snapshot repository.) I've updated both 'how to build' wiki pages with a new profile to put in your settings.xml file: struts-staging struts-staging http://people.apache.org/builds/struts/m2-staging-repository false true If you need Maven to download artifacts from the staging repository, use -Pstruts-staging on the command line to enable this profile. This isn't something you'd want to have enabled all the time. Both s1 and s2 are pointed at the same staging repo, so we'll have to coordinate releases or switch to a different place for one of them. Somehow I don't think it will be a problem... Over in Maven-land things are moving closer to having release staging and acceptance/promotion as part of the standard Maven release process. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tiles 2 jdk
Please continue to ask these questions on the mailing lists so that everyone can benefit from the answers. . . Stone, Sam wrote: Before I go through the trouble of building this and portlet and wahtever else I might need - will it all compile with JDK 1.4? I've been using an older snapshot jar with WebSphere 5 (JDK 1.4.2) and I need to either: No, by default they will not. However, you should be able to utilize the maven retrotranslator goal - which will make 1.5 code and back-port it. a) get a new build working from the current source code OR ? I'm not sure I understand. Are you looking for the retrotranslator jar to be published as a snapshot? b) get the last source code that does work with JDK 1.4 We are not directly supporting 1.4. Sam -Original Message- From: David H. DeWolf on behalf of David H. DeWolf Sent: Tue 12/12/2006 6:25 PM To: Struts Developers List Subject: Re: Where is Latest tiles-test-2.0-SNAPSHOT.war??? Yes, tiles2 will be based off of 1.5. My guess would be that this change was made about 4 weeks ago. . .when it's released, we'll provide a retro-translator version. David Stone, Sam wrote: > Thanks. Did this change from jdk 1.4 to 1.5 in the last few weeks? > > Sam > > > -Original Message- > From: David H. DeWolf [mailto:[EMAIL PROTECTED] On Behalf Of David H. > DeWolf > Sent: Tuesday, December 12, 2006 10:45 AM > To: Struts Developers List > Subject: Re: Where is Latest tiles-test-2.0-SNAPSHOT.war??? > > The most recent 'stable' snapshot is: > > 2.0-r480013-SNAPSHOT > > and is in the snapshot repo: > > http://people.apache.org/repo/m2-snapshot-repository/ > > If you need consistency, this one won't be changed underneath you. > > > David > > > Stone, Sam wrote: >> Where is latest downloadable tiles-test war file? >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[s2] Needs a new XWork snapshot
Struts 2 won't build against the XWork snapshot that is available in the repository: [INFO] Surefire report directory: e:\svn\struts\current\struts2\core\target\sure fire-reports org.apache.maven.surefire.booter.SurefireExecutionException: com/opensymphony/xw ork2/TestNGXWorkTestCase; nested exception is java.lang.NoClassDefFoundError: co m/opensymphony/xwork2/TestNGXWorkTestCase java.lang.NoClassDefFoundError: com/opensymphony/xwork2/TestNGXWorkTestCase S2 builds fine if I first build the latest xwork locally. Can someone please deploy a new xwork snapshot (or check on the process that's supposed to be doing it) ? Thanks, Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (WW-1166) AJAX submit button with action parameter does not submit with action in the query parameters in Firefox 1.5
On 12/12/06, john book (JIRA) <[EMAIL PROTECTED]> wrote: [ http://issues.apache.org/struts/browse/WW-1166?page=comments#action_39073 ] john book commented on WW-1166: I've reported both of these to Jeff and [EMAIL PROTECTED] His last request was to leave them in JIRA until he can investigate, so please don't delete the comments. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: referencing spring beans from struts.xml
In Tapestry, you use the "spring:" prefix notation (all lowercase) to refer to Spring beans. David Durham wrote: Dave Newton wrote: From: David Durham [mailto:[EMAIL PROTECTED] I kind of stumbled over the spring "glue" for struts, rereading the wiki page a few times before the struts.xml action _class_ needs to reference the bean name attribute from spring's configuration. Just thinking about it a little more, that seems a bit esoteric. Would it be better to have the class attribute be specified as "spring::bean" or "spring:bean", something like that? You can turn off the autowiring if you don't like how it works or configure the actions explicitly (I think...) I didn't find it particularly esoteric that if you have an id and setter that match that it injects it for you, but that's just me :) I don't think my first message was clear, and perhaps the problem is that I really only have a cursory understanding of Struts 2, but my thinking is that if a configuration file in a Java framework has an attribute named "class," then that refers to a Java classname, e.g., com.dave.MyClass. And, indeed in struts.xml, the class usually does. but in the spring integration it's: This is great. It works great, SFAIK. I'm saying that perhaps that shoul be: or something like that to kind of indicate to a developer, "Hey, this isn't a standard java class name." -DAve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: referencing spring beans from struts.xml
Though, one thing I really like about the current implementation, which I think Ted alluded to, is the ability to not only support different implementations but allow them to be easily swapped. If I have a service facade which is implemented by two swappable but different implementations, in the current scheme, one could be glued together with spring and the other with another IoC container without having to duplicate the action config. David David Durham wrote: Ted Husted wrote: On 12/12/06, Don Brown <[EMAIL PROTECTED]> wrote: > > > or something like that to kind of indicate to a developer, "Hey, this > isn't a standard java class name." > Good point. I like this idea more because it would allow us to use multiple object factories simultaneously. You know, you should make an object factory that parses prefixes to delegate to the proper object factory... :) If all of my Actions are being injected, then a prefix adds no information. It's just six more characters to type (and possibliy mistype) in each and every attriibute. We'd just be saying "smurf smurf smurf" :) The added information is, perhaps, clarity, though you make a strong argument for possible dubiousness on that point. My original thinking about this was "this took way to long to figure out, maybe this doc should have it as a bulleted item." Then, I thought "wait, the action configiruation isn't explicit about this element." Anyway, if clarity is not an issue, determinacy certainly is, because name-space collisions are possible. Maybe solved by an order property like: objectFactoryOrder = spring, new Or does this already exist? -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where is Latest tiles-test-2.0-SNAPSHOT.war???
Yes, tiles2 will be based off of 1.5. My guess would be that this change was made about 4 weeks ago. . .when it's released, we'll provide a retro-translator version. David Stone, Sam wrote: Thanks. Did this change from jdk 1.4 to 1.5 in the last few weeks? Sam -Original Message- From: David H. DeWolf [mailto:[EMAIL PROTECTED] On Behalf Of David H. DeWolf Sent: Tuesday, December 12, 2006 10:45 AM To: Struts Developers List Subject: Re: Where is Latest tiles-test-2.0-SNAPSHOT.war??? The most recent 'stable' snapshot is: 2.0-r480013-SNAPSHOT and is in the snapshot repo: http://people.apache.org/repo/m2-snapshot-repository/ If you need consistency, this one won't be changed underneath you. David Stone, Sam wrote: Where is latest downloadable tiles-test war file? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Where is Latest tiles-test-2.0-SNAPSHOT.war???
Thanks. Did this change from jdk 1.4 to 1.5 in the last few weeks? Sam -Original Message- From: David H. DeWolf [mailto:[EMAIL PROTECTED] On Behalf Of David H. DeWolf Sent: Tuesday, December 12, 2006 10:45 AM To: Struts Developers List Subject: Re: Where is Latest tiles-test-2.0-SNAPSHOT.war??? The most recent 'stable' snapshot is: 2.0-r480013-SNAPSHOT and is in the snapshot repo: http://people.apache.org/repo/m2-snapshot-repository/ If you need consistency, this one won't be changed underneath you. David Stone, Sam wrote: > Where is latest downloadable tiles-test war file? > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Where is Latest tiles-test-2.0-SNAPSHOT.war???
Thanks much. Did this change from jdk_1.4 to 1.5 in the last few weeks? Sam -Original Message- From: Greg Reddin [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 12, 2006 9:56 AM To: Struts Developers List Subject: Re: Where is Latest tiles-test-2.0-SNAPSHOT.war??? On Dec 12, 2006, at 8:42 AM, Stone, Sam wrote: > Where is latest downloadable tiles-test war file? This page tells you how to get it: http://struts.apache.org/struts-sandbox/tiles/index.html Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: referencing spring beans from struts.xml
Ted Husted wrote: On 12/12/06, Don Brown <[EMAIL PROTECTED]> wrote: > > > or something like that to kind of indicate to a developer, "Hey, this > isn't a standard java class name." > Good point. I like this idea more because it would allow us to use multiple object factories simultaneously. You know, you should make an object factory that parses prefixes to delegate to the proper object factory... :) If all of my Actions are being injected, then a prefix adds no information. It's just six more characters to type (and possibliy mistype) in each and every attriibute. We'd just be saying "smurf smurf smurf" :) The added information is, perhaps, clarity, though you make a strong argument for possible dubiousness on that point. My original thinking about this was "this took way to long to figure out, maybe this doc should have it as a bulleted item." Then, I thought "wait, the action configiruation isn't explicit about this element." Anyway, if clarity is not an issue, determinacy certainly is, because name-space collisions are possible. Maybe solved by an order property like: objectFactoryOrder = spring, new Or does this already exist? -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Additional UI tags
That really is the crux of my question, does this belong in struts proper, as a 'plug-in' module, or as a complete separate project? My understanding from the ww forums is that the table tag is there, but no one was really supporting it. (And briefly looking at it, I was not real impressed with it) I was planning to check it out, and see if some integration with Dojo was possible, and add an example to showcase, after 2.0.2. My issue with the DisplayTag is that is doesn't integrate as nicely with the ftl-backed UI tags--along with the fact that you can't break out the individual pieces. (There are screens where I only need paging, but it's not a table, or it's a table with subheading that DisplayTag doesn't support) You are right, I was thinking about table pagination, but there are other scenarios where it would be helpful. Follow Ted's advise and add it to a jira ticket, it won't hurt anyway :) musachy I plan on doing that as soon as I get the CLA back from our legal person. I checked with the CTO and he didn't have an issue with it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Additional UI tags
A plugin for enhanced tags, like treeview, seems reasonable, leaving the core tags to concentrate on cases with direct HTML 4 corrollaries, but that's something we could sort out for the next GA series. -Ted. On 12/12/06, Tom Schneider <[EMAIL PROTECTED]> wrote: > Don Brown wrote: >> The question is do we want to create one Struts tag library that does >> everything, or focus on tags that require close ties with our >> framework? While I like the idea of providing more features and tags >> to our users, I wonder if within Struts is the best place to host it... >> That really is the crux of my question, does this belong in struts proper, as a 'plug-in' module, or as a complete separate project? My understanding from the ww forums is that the table tag is there, but no one was really supporting it. (And briefly looking at it, I was not real impressed with it) My issue with the DisplayTag is that is doesn't integrate as nicely with the ftl-backed UI tags--along with the fact that you can't break out the individual pieces. (There are screens where I only need paging, but it's not a table, or it's a table with subheading that DisplayTag doesn't support) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: referencing spring beans from struts.xml
On 12/12/06, Don Brown <[EMAIL PROTECTED]> wrote: > > > or something like that to kind of indicate to a developer, "Hey, this > isn't a standard java class name." > Good point. I like this idea more because it would allow us to use multiple object factories simultaneously. You know, you should make an object factory that parses prefixes to delegate to the proper object factory... :) As it stands, I believe the code could access multiple factories without syntactic sugar. If the class attribute is not in the catalog, then the system will instantiate it as a class reference. If more object factories were in play, each could be checked in turn, and finally the usual object factory, "new", would be tried. My concern would be that a prefix would have us starting to add more red tape again. A casual passerby might not realize at first that the application is injecting classes from Spring, but the developers working on the code certainly do. It's not a trivial design decision. If all of my Actions are being injected, then a prefix adds no information. It's just six more characters to type (and possibliy mistype) in each and every attriibute. We'd just be saying "smurf smurf smurf" :) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Additional UI tags
Tom Schneider wrote: Musachy Barroso wrote: We also have a table tag, which I have never seen and I don't know if it works. On that same thought, DisplayTag has a lot of stuff which would be pointless to duplicate. But I could say the same thing about the ajax tags anyway... musachy Don Brown wrote: The question is do we want to create one Struts tag library that does everything, or focus on tags that require close ties with our framework? While I like the idea of providing more features and tags to our users, I wonder if within Struts is the best place to host it... That really is the crux of my question, does this belong in struts proper, as a 'plug-in' module, or as a complete separate project? My understanding from the ww forums is that the table tag is there, but no one was really supporting it. (And briefly looking at it, I was not real impressed with it) I was planning to check it out, and see if some integration with Dojo was possible, and add an example to showcase, after 2.0.2. My issue with the DisplayTag is that is doesn't integrate as nicely with the ftl-backed UI tags--along with the fact that you can't break out the individual pieces. (There are screens where I only need paging, but it's not a table, or it's a table with subheading that DisplayTag doesn't support) You are right, I was thinking about table pagination, but there are other scenarios where it would be helpful. Follow Ted's advise and add it to a jira ticket, it won't hurt anyway :) musachy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Additional UI tags
Musachy Barroso wrote: We also have a table tag, which I have never seen and I don't know if it works. On that same thought, DisplayTag has a lot of stuff which would be pointless to duplicate. But I could say the same thing about the ajax tags anyway... musachy Don Brown wrote: The question is do we want to create one Struts tag library that does everything, or focus on tags that require close ties with our framework? While I like the idea of providing more features and tags to our users, I wonder if within Struts is the best place to host it... That really is the crux of my question, does this belong in struts proper, as a 'plug-in' module, or as a complete separate project? My understanding from the ww forums is that the table tag is there, but no one was really supporting it. (And briefly looking at it, I was not real impressed with it) My issue with the DisplayTag is that is doesn't integrate as nicely with the ftl-backed UI tags--along with the fact that you can't break out the individual pieces. (There are screens where I only need paging, but it's not a table, or it's a table with subheading that DisplayTag doesn't support) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Additional UI tags
From: Musachy Barroso [mailto:[EMAIL PROTECTED] > The tree tag is not working right now, I looked at it a few weeks ago > and I got it to work with some changes (small changes, but I forgot > already which ones). Oh, really? Hrm; I'm using it and it's fine (not sure which version that particular project is using though :/ Don't know about the DnD support though; haven't gotten that far. Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Additional UI tags
The tree tag is not working right now, I looked at it a few weeks ago and I got it to work with some changes (small changes, but I forgot already which ones). musachy Dave Newton wrote: From: Don Brown [mailto:[EMAIL PROTECTED] The question is do we want to create one Struts tag library that does everything, or focus on tags that require close ties with our framework? While I like the idea of providing more features and tags to our users, I wonder if within Struts is the best place to host it... Along this line I'm already a bit concerned about the Dojo integration; I am about to tackle some tree widget tasks that I know how to do with straight Dojo (drag-and-drop etc.) that I don't know (yet; it may be trivial, I just don't know) how to handle within the S2 wrapper tags. Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Additional UI tags
From: Don Brown [mailto:[EMAIL PROTECTED] > The question is do we want to create one Struts tag library that does > everything, or focus on tags that require close ties with our > framework? While I like the idea of providing more features and tags > to our users, I wonder if within Struts is the best place to host > it... Along this line I'm already a bit concerned about the Dojo integration; I am about to tackle some tree widget tasks that I know how to do with straight Dojo (drag-and-drop etc.) that I don't know (yet; it may be trivial, I just don't know) how to handle within the S2 wrapper tags. Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: referencing spring beans from struts.xml
From: David Durham [mailto:[EMAIL PROTECTED] > I don't think my first message was clear, and perhaps the problem is > that I really only have a cursory understanding of Struts 2, but my > thinking is that if a configuration file in a Java framework has an > attribute named "class," then that refers to a Java classname, e.g., > com.dave.MyClass. And, indeed in struts.xml, the class usually does. Gotcha. I was thinking about the id/getter application context autowiring; my bad. Don's followup makes a good point, although I might have chosen "SpringId" as the prefix :) Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Additional UI tags
We also have a table tag, which I have never seen and I don't know if it works. On that same thought, DisplayTag has a lot of stuff which would be pointless to duplicate. But I could say the same thing about the ajax tags anyway... musachy Don Brown wrote: The question is do we want to create one Struts tag library that does everything, or focus on tags that require close ties with our framework? While I like the idea of providing more features and tags to our users, I wonder if within Struts is the best place to host it... Don Ted Husted wrote: I know I've implemented paging a dozen different ways, and reducing to a tag of our own sounds like a good idea. Ditto with sorted tables. If you wanted to contribute the tags, the thing to do would be to file a CLA and open a JIRA ticket with the code attached,. * http://apache.org/licenses/#clas -Ted. On 12/10/06, Tom Schneider <[EMAIL PROTECTED]> wrote: Hello, I've been working with webwork since June. My company migrated from a home-grown webframework to webwork and it has been a very good experience. I'm excited to see how struts2 can improve on an already top-notch framework. In the process of integrating webwork with our software, I implemented several UI tags that probably could be used on other projects. I wanted to get a feel for whether there was a desire to add these tags to the core struts project. Although there are other open source tags that implement this functionality, we leverage the template based nature of the UI tags very heavily and wanted tags that allowed us this type of customization. Pager - the pager tag is used to display a small pager display to allow pagination navigation. (e.g. << < 1 to 6 of 30 > >>) This is used on almost all the pages where we have lists of data. SortColumn - the sort column tag displays the column name, the current sort direction and is hyperlinked so that the sort direction/selected sort column can be changed (e.g. Name ^ or Name v) So, my question is: Is there any interest in adding these kinds of tags to the core struts tag library, or should these be separate? I would think there would be enough other projects out there that would need these types of tags to warrant it, however, I've been doing only database apps for the last 2 years, so my perspective may be skewed a bit. Thanks, Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Additional UI tags
The question is do we want to create one Struts tag library that does everything, or focus on tags that require close ties with our framework? While I like the idea of providing more features and tags to our users, I wonder if within Struts is the best place to host it... Don Ted Husted wrote: I know I've implemented paging a dozen different ways, and reducing to a tag of our own sounds like a good idea. Ditto with sorted tables. If you wanted to contribute the tags, the thing to do would be to file a CLA and open a JIRA ticket with the code attached,. * http://apache.org/licenses/#clas -Ted. On 12/10/06, Tom Schneider <[EMAIL PROTECTED]> wrote: Hello, I've been working with webwork since June. My company migrated from a home-grown webframework to webwork and it has been a very good experience. I'm excited to see how struts2 can improve on an already top-notch framework. In the process of integrating webwork with our software, I implemented several UI tags that probably could be used on other projects. I wanted to get a feel for whether there was a desire to add these tags to the core struts project. Although there are other open source tags that implement this functionality, we leverage the template based nature of the UI tags very heavily and wanted tags that allowed us this type of customization. Pager - the pager tag is used to display a small pager display to allow pagination navigation. (e.g. << < 1 to 6 of 30 > >>) This is used on almost all the pages where we have lists of data. SortColumn - the sort column tag displays the column name, the current sort direction and is hyperlinked so that the sort direction/selected sort column can be changed (e.g. Name ^ or Name v) So, my question is: Is there any interest in adding these kinds of tags to the core struts tag library, or should these be separate? I would think there would be enough other projects out there that would need these types of tags to warrant it, however, I've been doing only database apps for the last 2 years, so my perspective may be skewed a bit. Thanks, Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: referencing spring beans from struts.xml
David Durham wrote: I don't think my first message was clear, and perhaps the problem is that I really only have a cursory understanding of Struts 2, but my thinking is that if a configuration file in a Java framework has an attribute named "class," then that refers to a Java classname, e.g., com.dave.MyClass. And, indeed in struts.xml, the class usually does. but in the spring integration it's: This is great. It works great, SFAIK. I'm saying that perhaps that shoul be: or something like that to kind of indicate to a developer, "Hey, this isn't a standard java class name." Good point. I like this idea more because it would allow us to use multiple object factories simultaneously. You know, you should make an object factory that parses prefixes to delegate to the proper object factory... :) Don -DAve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: referencing spring beans from struts.xml
Dave Newton wrote: From: David Durham [mailto:[EMAIL PROTECTED] I kind of stumbled over the spring "glue" for struts, rereading the wiki page a few times before the struts.xml action _class_ needs to reference the bean name attribute from spring's configuration. Just thinking about it a little more, that seems a bit esoteric. Would it be better to have the class attribute be specified as "spring::bean" or "spring:bean", something like that? You can turn off the autowiring if you don't like how it works or configure the actions explicitly (I think...) I didn't find it particularly esoteric that if you have an id and setter that match that it injects it for you, but that's just me :) I don't think my first message was clear, and perhaps the problem is that I really only have a cursory understanding of Struts 2, but my thinking is that if a configuration file in a Java framework has an attribute named "class," then that refers to a Java classname, e.g., com.dave.MyClass. And, indeed in struts.xml, the class usually does. but in the spring integration it's: This is great. It works great, SFAIK. I'm saying that perhaps that shoul be: or something like that to kind of indicate to a developer, "Hey, this isn't a standard java class name." -DAve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: referencing spring beans from struts.xml
> From: David Durham [mailto:[EMAIL PROTECTED] > I kind of stumbled over the spring "glue" for struts, rereading the > wiki page a few times before the struts.xml action _class_ needs to > reference the bean name attribute from spring's configuration. Just > thinking about it a little more, that seems a bit esoteric. Would it > be better to have the class attribute be specified as "spring::bean" > or "spring:bean", something like that? You can turn off the autowiring if you don't like how it works or configure the actions explicitly (I think...) I didn't find it particularly esoteric that if you have an id and setter that match that it injects it for you, but that's just me :) Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
referencing spring beans from struts.xml
I kind of stumbled over the spring "glue" for struts, rereading the wiki page a few times before the struts.xml action _class_ needs to reference the bean name attribute from spring's configuration. Just thinking about it a little more, that seems a bit esoteric. Would it be better to have the class attribute be specified as "spring::bean" or "spring:bean", something like that? -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Struts 2.0.2 Build - ON HOLD
I attached WW-1554_2.patch (use this one instead of the previous ones) to WW-1554, a parameter was missing in notifyTopics. It has a fix to hangman ajax, which now works. There is an image attached to the ticket that needs to be added to showcase. regards musachy Musachy Barroso wrote: I'm trying to get hangman to work. musachy Ted Husted wrote: OK, we're getting closer, but there's still a few issues to resolve, if 2.0.2 is going to be a step forward. * Apply patch for Dojo topic notification (WW-1554) * Apply patch for DatePicker (WW-1555) * Fix XSLT Result (WW-1550) * Move Continuations support to an experimental plugin (WW-1548) * Fix other new showcase problems (WW-1538) ** Prefix example ** MessageStoreInterceptor Example ** Hangman Ajax example I've a users group meeting tonight, and two events at school tomorrow, so it will be Thursday before I can look at any of these myself. If anyone wants to jump in, feel free. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where is Latest tiles-test-2.0-SNAPSHOT.war???
The most recent 'stable' snapshot is: 2.0-r480013-SNAPSHOT and is in the snapshot repo: http://people.apache.org/repo/m2-snapshot-repository/ If you need consistency, this one won't be changed underneath you. David Stone, Sam wrote: Where is latest downloadable tiles-test war file? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Struts 2.0.2 Build - ON HOLD
I'm trying to get hangman to work. musachy Ted Husted wrote: OK, we're getting closer, but there's still a few issues to resolve, if 2.0.2 is going to be a step forward. * Apply patch for Dojo topic notification (WW-1554) * Apply patch for DatePicker (WW-1555) * Fix XSLT Result (WW-1550) * Move Continuations support to an experimental plugin (WW-1548) * Fix other new showcase problems (WW-1538) ** Prefix example ** MessageStoreInterceptor Example ** Hangman Ajax example I've a users group meeting tonight, and two events at school tomorrow, so it will be Thursday before I can look at any of these myself. If anyone wants to jump in, feel free. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where is Latest tiles-test-2.0-SNAPSHOT.war???
On Dec 12, 2006, at 8:42 AM, Stone, Sam wrote: Where is latest downloadable tiles-test war file? This page tells you how to get it: http://struts.apache.org/struts-sandbox/tiles/index.html Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Where is Latest tiles-test-2.0-SNAPSHOT.war???
Where is latest downloadable tiles-test war file? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Additional UI tags
I know I've implemented paging a dozen different ways, and reducing to a tag of our own sounds like a good idea. Ditto with sorted tables. If you wanted to contribute the tags, the thing to do would be to file a CLA and open a JIRA ticket with the code attached,. * http://apache.org/licenses/#clas -Ted. On 12/10/06, Tom Schneider <[EMAIL PROTECTED]> wrote: Hello, I've been working with webwork since June. My company migrated from a home-grown webframework to webwork and it has been a very good experience. I'm excited to see how struts2 can improve on an already top-notch framework. In the process of integrating webwork with our software, I implemented several UI tags that probably could be used on other projects. I wanted to get a feel for whether there was a desire to add these tags to the core struts project. Although there are other open source tags that implement this functionality, we leverage the template based nature of the UI tags very heavily and wanted tags that allowed us this type of customization. Pager - the pager tag is used to display a small pager display to allow pagination navigation. (e.g. << < 1 to 6 of 30 > >>) This is used on almost all the pages where we have lists of data. SortColumn - the sort column tag displays the column name, the current sort direction and is hyperlinked so that the sort direction/selected sort column can be changed (e.g. Name ^ or Name v) So, my question is: Is there any interest in adding these kinds of tags to the core struts tag library, or should these be separate? I would think there would be enough other projects out there that would need these types of tags to warrant it, however, I've been doing only database apps for the last 2 years, so my perspective may be skewed a bit. Thanks, Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- HTH, Ted. * http://www.husted.com/struts/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Struts 2.0.2 Build - ON HOLD
OK, we're getting closer, but there's still a few issues to resolve, if 2.0.2 is going to be a step forward. * Apply patch for Dojo topic notification (WW-1554) * Apply patch for DatePicker (WW-1555) * Fix XSLT Result (WW-1550) * Move Continuations support to an experimental plugin (WW-1548) * Fix other new showcase problems (WW-1538) ** Prefix example ** MessageStoreInterceptor Example ** Hangman Ajax example I've a users group meeting tonight, and two events at school tomorrow, so it will be Thursday before I can look at any of these myself. If anyone wants to jump in, feel free. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OGNL performance detrimental to Struts 2
On 12/12/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: On 12/11/06, dice <[EMAIL PROTECTED]> wrote: > By my own benchmarking I am finding Struts 2 somewhere between 5-10 times > slower than Struts 1 in JSP rendering. JProfiler is telling me OGNL is the > bottleneck. There's a similar thread on the webwork dev list: http://forums.opensymphony.com/thread.jspa?threadID=52734&messageID=106274 I found that in my own own application, the problem was indeed related to OGNL, but mostly for the form tags (things go very well when using simple tags like iterator and property, but you lose everything as soon as the first form/inputfield/select tags enter the game. It was Don who actually pointed me to MVEL. Before, I tried to take a quick stab at bytecode enhancements for OGNL, but lack of experience with the OGNL architecture and ASM interfered with my plans. It also seems my initial performance results about MVEL being 2x slower than OGNL in interpreted mode were misplaced (well, I couldn't get the compilation mode to work), so Chris Brock (its author) kindly sent me some better constructs, which I'll be testing this week. -- Wendy Cheers, Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- iDTV System Engineer "Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." - John F. Woods - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
