Re: [S2] Libraries in JDK 1.4 distribution
On Jan 16, 2008 6:28 AM, Niall Pemberton [EMAIL PROTECTED] wrote: On Jan 16, 2008 6:24 AM, Frank W. Zammetti [EMAIL PROTECTED] wrote: Martin Cooper wrote: That's a fair question, but I have an answer for it. Of course you do. If you didn't, I'd think you'd gone on vacation or something. ;-) :) So you're saying that if a non-committer thinks a release looks OK, a +1 says just that and means nothing more, Yes. whereas if a committer thinks it looks OK, they can't vote the same way unless they're committing to support it, and therefore cannot contribute to the binding vote count required for a release. Yes. But why would the non-committer vote in such an inconsistent way? Surely the appropriate thing to do would be to vote +0, which is what the committer would have to do in order to indicate that they thought the release looked OK but were not in a position to support it. No, because that would also imply that the non-binding +1 has the same implied willingness to support (because otherwise there would be no difference between 0 and +1), and I contend that *NO* non-binding vote *EVER* carries that implication, as a binding vote does. Binding and non-binding votes cannot be equated in any way other than the statement about the fitness of the release, otherwise there would be no reason to differentiate binding from non-binding votes in the first place. Any meaning above and beyond fitness of release is the sole pervue of the binding votes and voters. In any case, I'm going to sign out of this discussion now, as I have enough to do keeping up with my day job, and don't feel the need to further defend my right to vote +1 as I feel appropriate. That's cool Martin, I'm bowing out now too. You've made your position clear, and anyone can read it and make up their own mind about it. I'm glad you got the chance to defend your right, as you see it. For the record I agree with Martin and in my book votes-are-votes whoever they come from. +1 The binding/non-binding distinction is pretty much just for legal and anti-jerk reasons in my book. Shouldn't be used to divide the community. Really, when managing a release, i consider a non-binding -1 (from a non-jerk, of course) as much of a showstopper as a binding -1, why treat +1 differently? Doesn't seem like the Apache way to me. Niall Martin Cooper Frank - 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: [Dojo] Tooltips
You could ask if they'd be willing/able to change the license... On 3/16/07, Musachy Barroso [EMAIL PROTECTED] wrote: Yeah I liked that one, and compressed got to 7K, but it is GPL. musachy On 3/16/07, Antonio Petrelli [EMAIL PROTECTED] wrote: 2007/3/16, Nate Drake [EMAIL PROTECTED]: http://boxover.swazz.org/ Claims to be under 10k, but I'm not sure what the license is. I was curious and found this in their homepage: snip - BoxOver is free and distributed under the GNU license /snip GNU Licence what? GPL, LGPL? Either way, I think that cannot be used. Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Hey you! Would you help me to carry the stone? Pink Floyd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Project velocity-tools (in module velocity-tools) failed
VelocityTools is getting a Gump failure because we recently upgraded our Validator tool to use the org.struts.validator.Resources.getVarValue(Var,ServletContext,HttpServletRequest,boolean) method (to mirror the same change in JavascriptValidatorTag). The problem appears to be that the packaged-struts project in Gump (which we've been listing as a dependency) is an out of date JAR, and the struts project is a no-op. Is anyone in the Struts1 camp interested/able/willing to update Struts' presence in Gump? If not, i may try to take a stab at it, but it's been ages since i tried to build Struts myself, much less tell Gump how to do it. On 1/19/07, Velocity Gump dev@velocity.apache.org wrote: To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project velocity-tools has an issue affecting its community integration. This issue affects 3 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - portals-bridges-frameworks : Support for JSR168 compliant Portlet development - portals-bridges-velocity : Support for JSR168 compliant Portlet development - velocity-tools : VelocityTools project Full details are available at: http://vmgump.apache.org/gump/public/velocity-tools/velocity-tools/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on commons-beanutils exists, no need to add for property commons-beanutils.jar. -DEBUG- Dependency on commons-collections exists, no need to add for property commons-collections.jar. -DEBUG- Dependency on commons-digester exists, no need to add for property commons-digester.jar. -DEBUG- Dependency on commons-lang exists, no need to add for property commons-lang.jar. -DEBUG- Dependency on commons-logging exists, no need to add for property commons-logging.jar. -DEBUG- Dependency on commons-validator exists, no need to add for property commons-validator.jar. -DEBUG- Dependency on jakarta-oro exists, no need to add for property oro.jar. -DEBUG- Dependency on velocity-engine exists, no need to add for property velocity.jar. -DEBUG- Dependency on jakarta-servletapi-4 exists, no need to add for property servlet.jar. -DEBUG- Dependency on struts-sslext exists, no need to add for property sslext.jar. -DEBUG- Dependency on packaged-struts exists, no need to add for property struts-core.jar. -DEBUG- Dependency on packaged-struts exists, no need to add for property struts-taglib.jar. -DEBUG- Dependency on packaged-struts exists, no need to add for property struts-tiles.jar. -INFO- Failed with reason build failed -DEBUG- Extracted fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/velocity-tools/velocity-tools/gump_work/build_velocity-tools_velocity-tools.html Work Name: build_velocity-tools_velocity-tools (Type: Build) Work ended in a state of : Failed Elapsed: 9 secs Command Line: java -Djava.awt.headless=true org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dcommons-beanutils.jar=/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar -Doro.jar=/usr/local/gump/public/workspace/jakarta-oro/jakarta-oro-19012007.jar -Dstruts-core.jar=/usr/local/gump/packages/struts-1.2.9-lib/struts.jar -Dvelocity.jar=/usr/local/gump/public/workspace/velocity-engine/bin/velocity-19012007.jar -Dcommons-chain.jar=/usr/local/gump/public/workspace/jakarta-commons/chain/target/commons-chain-19012007.jar -Dservlet.jar=/usr/local/gump/public/workspace/jakarta-servletapi-4/lib/servlet.jar -Dskip.jar.loading=true -Dsslext.jar=/usr/local/gump/public/workspace/struts-sslext/web/WEB-INF/lib/sslext.jar -Dstruts-tiles.jar=/usr/local/gump/packages/struts-1.2.9-lib/struts.jar -Dcommons-lang.jar=/usr/local/gump/public/workspace/jakarta-commons/lang/commons-lang-19012007.jar -Dproject.version=19012007 -Dcommons-validator.jar=/usr/local/gump/public/workspace/jakarta-commons/validator/dist/commons-validator-19012007.jar -Dcommons-logging.jar=/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-19012007.jar -Dstruts-taglib.jar=/usr/local/gump/packages/struts-1.2.9-lib/struts.jar -Dcommons-collections.jar=/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-19012007.jar -Dcommons-digester.jar=/usr/local/gump/public/workspace/jakarta-commons/digester/dist/commons-digester.jar all [Working Directory: /usr/local/gump/public/workspace/velocity-tools] CLASSPATH:
Re: [VOTE] Tiles TLP
hey now, Tiles works well without JSP too. :) On 12/6/06, Greg Reddin [EMAIL PROTECTED] wrote: On Dec 4, 2006, at 7:34 AM, Ted Husted wrote: One note on the Resolution, some elder projects like Struts and Cocoon got away with the self-referential description, but if anyone has a slightly more detailed description of Tiles, it might save a round of revisions. I made a modification that includes this description: ...the JavaServer Pages template framework currently known as Apache Struts Tiles... Is that enough description or do you think I should add another WHERAS paragraph? 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: [VOTE] Tiles TLP
to be constructively critical, perhaps it would help to say that i think of it as a page composition and layout management framework. perhaps that language would be useful? On 12/6/06, Nathan Bubna [EMAIL PROTECTED] wrote: hey now, Tiles works well without JSP too. :) On 12/6/06, Greg Reddin [EMAIL PROTECTED] wrote: On Dec 4, 2006, at 7:34 AM, Ted Husted wrote: One note on the Resolution, some elder projects like Struts and Cocoon got away with the self-referential description, but if anyone has a slightly more detailed description of Tiles, it might save a round of revisions. I made a modification that includes this description: ...the JavaServer Pages template framework currently known as Apache Struts Tiles... Is that enough description or do you think I should add another WHERAS paragraph? 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: [VOTE] Tiles TLP
+1 On 12/2/06, David H. DeWolf [EMAIL PROTECTED] wrote: I'd like to begin the vote on the Tiles TLP Proposal [1] and Resolution [2]. [] +1 = Yes, let's ask the board to establish the Tiles TLP [] +0 = I'm in favor, to some extent. [] -0 = I'm not in favor but won't prevent it from happening. [] -1 = I'd rather see Tiles stay here or go somewhere else. [1] http://wiki.apache.org/struts/TilesTopLevel [2] http://wiki.apache.org/struts/TilesTlpResolution - 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: [tiles2] Tiles TLP and Dimensions incubation
in my continuing quest to redefine the concept of umbrella in Apache-land On 12/1/06, Martin Cooper [EMAIL PROTECTED] wrote: On 12/1/06, Antonio Petrelli [EMAIL PROTECTED] wrote: Craig McClanahan ha scritto: The Dimensions code is going to have to go through the Incubator -- even though its likely that this can go very quickly, there is no reason to mess up the progress of the Tiles TLP proposal by trying to do them together. Hi Craig, when I wrote at the same time I did not mean together. Since probably Dimensions will become a subproject of Tiles TLP I know this has been said by others before, but let me make it very clear: The ASF board does not like umbrella projects at all, and would most likely not approve Tiles as a TLP if it smelled of forthcoming sub-projects before it even got off the ground. actually, we were able to take Velocityto TLP with both existing subprojects and the smell of forthcoming ones. this was done with much clarification, restriction, and debate on what constitutes an acceptable subproject. the key difference is that Velocity will not be a bucket project such as Jakarta or db.apache.org that exists to group projects who share a conceptual space, but whose code and community are unconnected. instead, Velocity aims to be a true umbrella where all the Velocity subprojects (spokes of the umbrella) are truly sub-ordinate. this means their code and community are invested in the core Velocity template engine (the center pole) and do not function without it. the difference between bucket and umbrella is crucial to building a healthy, shared community. other significant differences are that non of the sub-projects get their own mailing list or svn permissions. that would fragment the community. The reason that some people do not want Tiles to live on as a sub-project within Struts is one of the same reasons that Shale went out on its own; sub-projects are a sign that a project is moving in the wrong direction; that is, in a direction that is not favoured by the ASF Board, and for good reasons. Struts has been moving, and continues to move, in a direction that eliminates the notion of sub-projects, the only exception being the two versions of the Struts framework itself. i really think this is throwing out the baby with the bathwater. just because the sub-project things has been done poorly, doesn't mean that it deserves to be eliminated. i would hope that the board's acceptance of Velocity and its subprojects as a TLP shows recognition that it can be done right. If Dimensions would ultimately be merged into Tiles, that is one thing, and that might be fine. If, however, you are thinking that Dimensions would live as a similar concept but separate framework to Tiles, but within the same TLP, that is quite another thing, and not something I would like to see, not to mention the ASF Board. agreed. conceptual association is totally insufficient grounds for shared community. So, in short, we should purge the notion of sub-projecs from our minds, whichever top-level project we are thinking of, and work on the basis that they should not exist. no thanks. -- Martin Cooper , I thought that probably it was appropriate to wait until it is estabilished. I read this: http://incubator.apache.org/incubation/Incubation_Policy.html#Sponsor snip A Sponsor SHALL be either: * the Board of the Apache Software Foundation; * a Top Level Project (TLP) within the Apache Software Foundation (where the TLP considers the Candidate to be a suitable sub-project); or * the Incubator PMC. /snip Antonio - 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: [tiles2] Tiles TLP and Dimensions incubation
On 12/1/06, Martin Cooper [EMAIL PROTECTED] wrote: On 12/1/06, Nathan Bubna [EMAIL PROTECTED] wrote: in my continuing quest to redefine the concept of umbrella in Apache-land On 12/1/06, Martin Cooper [EMAIL PROTECTED] wrote: On 12/1/06, Antonio Petrelli [EMAIL PROTECTED] wrote: Craig McClanahan ha scritto: The Dimensions code is going to have to go through the Incubator -- even though its likely that this can go very quickly, there is no reason to mess up the progress of the Tiles TLP proposal by trying to do them together. Hi Craig, when I wrote at the same time I did not mean together. Since probably Dimensions will become a subproject of Tiles TLP I know this has been said by others before, but let me make it very clear: The ASF board does not like umbrella projects at all, and would most likely not approve Tiles as a TLP if it smelled of forthcoming sub-projects before it even got off the ground. actually, we were able to take Velocityto TLP with both existing subprojects and the smell of forthcoming ones. this was done with much clarification, restriction, and debate on what constitutes an acceptable subproject. the key difference is that Velocity will not be a bucket project such as Jakarta or db.apache.org that exists to group projects who share a conceptual space, but whose code and community are unconnected. instead, Velocity aims to be a true umbrella where all the Velocity subprojects (spokes of the umbrella) are truly sub-ordinate. this means their code and community are invested in the core Velocity template engine (the center pole) and do not function without it. the difference between bucket and umbrella is crucial to building a healthy, shared community. other significant differences are that non of the sub-projects get their own mailing list or svn permissions. that would fragment the community. The reason that some people do not want Tiles to live on as a sub-project within Struts is one of the same reasons that Shale went out on its own; sub-projects are a sign that a project is moving in the wrong direction; that is, in a direction that is not favoured by the ASF Board, and for good reasons. Struts has been moving, and continues to move, in a direction that eliminates the notion of sub-projects, the only exception being the two versions of the Struts framework itself. i really think this is throwing out the baby with the bathwater. just because the sub-project things has been done poorly, doesn't mean that it deserves to be eliminated. i would hope that the board's acceptance of Velocity and its subprojects as a TLP shows recognition that it can be done right. If Dimensions would ultimately be merged into Tiles, that is one thing, and that might be fine. If, however, you are thinking that Dimensions would live as a similar concept but separate framework to Tiles, but within the same TLP, that is quite another thing, and not something I would like to see, not to mention the ASF Board. agreed. conceptual association is totally insufficient grounds for shared community. That's really the crux of what I was trying to say. Clearly, I didn't say it very well. ;-( excellent! so long as we do not plan to ban any and all subprojects from this Tiles TLP we're trying to create, i will be happy. but, if you'd like, feel free to join me in my quest and differentiate between conceptual bucket TLPs and code-connected umbrella TLPs. :) since we began the effort to extricate the Velocity umbrella from the Jakarta bucket, i've been making a concerted effort to refine the language here in hopes of changing how the ASF thinks about these issues. -- Martin Cooper So, in short, we should purge the notion of sub-projecs from our minds, whichever top-level project we are thinking of, and work on the basis that they should not exist. no thanks. -- Martin Cooper , I thought that probably it was appropriate to wait until it is estabilished. I read this: http://incubator.apache.org/incubation/Incubation_Policy.html#Sponsor snip A Sponsor SHALL be either: * the Board of the Apache Software Foundation; * a Top Level Project (TLP) within the Apache Software Foundation (where the TLP considers the Candidate to be a suitable sub-project); or * the Incubator PMC. /snip Antonio - 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: [PROPOSAL] Updated Tiles Graduation Proposal
I know i'm not really much involved with Tiles lately, but i'd just like to say that i think the idea of a topic-centered umbrella project is a bad idea and not especially likely to be favored by the ASF these days. IIRC, the discussions about forming a Jakarta Web Components group were not about forming a new subproject, but were part of Henri's vision for a flatter, component-centric Jakarta structure that had quasi-formal groupings (which could potentially even overlap) to conceptually organize the subprojects. It was definitely not planned that JWC would be a formal subproject containing sub-sub-projects. i don't have time to discuss this heavily atm, but i'll try to find links to the threads in question... On 11/28/06, Greg Reddin [EMAIL PROTECTED] wrote: Since we've failed to build consensus, I've published a versioned snapshot that will have to suffice for 2.0.2 and I will begin to drive the effort for TLP :( - it's not my preference but it will have to work. Hang on, slow down just a bit :-) Before we jump off the TLP cliff let's make sure we know all the options and have consensus from everybody involved. Here's the viable choices as I see them: 1) Jakarta Web Components Subproject - What components will make up this list? Who all needs to be involved in the discussion? 2) Apache Web Components TLP - What components will make up this list? Who needs to be involved in the discussion? What's the process to proceed? 3) Apache Tiles TLP - Seems we could do this here and now and submit a proposal to the board. Who else should we bring into the discussion? Options that have been discussed and rejected: 1) Struts subproject - Struts does not need to become an umbrella. 2) Jakarta Commons component - Tiles is more of a framework than most of the components under commons. Several people have voiced their objection to this approach. 3) Struts2 Tiles Plugin - Removes the standalone nature of Tiles. So... of the three viable options, let's discuss and decide where to go from here. 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: [PROPOSAL] Updated Tiles Graduation Proposal
here's one thread on Jakarta general http://www.mail-archive.com/general@jakarta.apache.org/msg12323.html On 11/28/06, Nathan Bubna [EMAIL PROTECTED] wrote: I know i'm not really much involved with Tiles lately, but i'd just like to say that i think the idea of a topic-centered umbrella project is a bad idea and not especially likely to be favored by the ASF these days. IIRC, the discussions about forming a Jakarta Web Components group were not about forming a new subproject, but were part of Henri's vision for a flatter, component-centric Jakarta structure that had quasi-formal groupings (which could potentially even overlap) to conceptually organize the subprojects. It was definitely not planned that JWC would be a formal subproject containing sub-sub-projects. i don't have time to discuss this heavily atm, but i'll try to find links to the threads in question... On 11/28/06, Greg Reddin [EMAIL PROTECTED] wrote: Since we've failed to build consensus, I've published a versioned snapshot that will have to suffice for 2.0.2 and I will begin to drive the effort for TLP :( - it's not my preference but it will have to work. Hang on, slow down just a bit :-) Before we jump off the TLP cliff let's make sure we know all the options and have consensus from everybody involved. Here's the viable choices as I see them: 1) Jakarta Web Components Subproject - What components will make up this list? Who all needs to be involved in the discussion? 2) Apache Web Components TLP - What components will make up this list? Who needs to be involved in the discussion? What's the process to proceed? 3) Apache Tiles TLP - Seems we could do this here and now and submit a proposal to the board. Who else should we bring into the discussion? Options that have been discussed and rejected: 1) Struts subproject - Struts does not need to become an umbrella. 2) Jakarta Commons component - Tiles is more of a framework than most of the components under commons. Several people have voiced their objection to this approach. 3) Struts2 Tiles Plugin - Removes the standalone nature of Tiles. So... of the three viable options, let's discuss and decide where to go from here. 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: [PROPOSAL] Updated Tiles Graduation Proposal
Sorry, should have put that in... i would suggest either A) Tiles as its own TLP: Apache Tiles B) Tiles as a Jakarta subproject: Jakarta Tiles if you do A, then keep your focus to Tiles. that doesn't mean you can't have other projects in a Tiles TLP; it just means they should be either built specifically for use with Tiles or else dependent on Tiles. if you do B, then Tiles should never have any subprojects of its own, but it can gather into a grouping or sub-community with other Jakarta subprojects. This is essentially what was proposed and discussed in the thread i sent. On 11/28/06, David H. DeWolf [EMAIL PROTECTED] wrote: Nathan Bubna wrote: I know i'm not really much involved with Tiles lately, but i'd just like to say that i think the idea of a topic-centered umbrella project is a bad idea and not especially likely to be favored by the ASF these days. Just curious, what do you suggest instead? - 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: [PROPOSAL] Updated Tiles Graduation Proposal
and another earlier one on this list: http://www.mail-archive.com/dev@struts.apache.org/msg20469.html (not sure that the mail archive got the full thread in this link) On 11/28/06, Nathan Bubna [EMAIL PROTECTED] wrote: here's one thread on Jakarta general http://www.mail-archive.com/general@jakarta.apache.org/msg12323.html On 11/28/06, Nathan Bubna [EMAIL PROTECTED] wrote: I know i'm not really much involved with Tiles lately, but i'd just like to say that i think the idea of a topic-centered umbrella project is a bad idea and not especially likely to be favored by the ASF these days. IIRC, the discussions about forming a Jakarta Web Components group were not about forming a new subproject, but were part of Henri's vision for a flatter, component-centric Jakarta structure that had quasi-formal groupings (which could potentially even overlap) to conceptually organize the subprojects. It was definitely not planned that JWC would be a formal subproject containing sub-sub-projects. i don't have time to discuss this heavily atm, but i'll try to find links to the threads in question... On 11/28/06, Greg Reddin [EMAIL PROTECTED] wrote: Since we've failed to build consensus, I've published a versioned snapshot that will have to suffice for 2.0.2 and I will begin to drive the effort for TLP :( - it's not my preference but it will have to work. Hang on, slow down just a bit :-) Before we jump off the TLP cliff let's make sure we know all the options and have consensus from everybody involved. Here's the viable choices as I see them: 1) Jakarta Web Components Subproject - What components will make up this list? Who all needs to be involved in the discussion? 2) Apache Web Components TLP - What components will make up this list? Who needs to be involved in the discussion? What's the process to proceed? 3) Apache Tiles TLP - Seems we could do this here and now and submit a proposal to the board. Who else should we bring into the discussion? Options that have been discussed and rejected: 1) Struts subproject - Struts does not need to become an umbrella. 2) Jakarta Commons component - Tiles is more of a framework than most of the components under commons. Several people have voiced their objection to this approach. 3) Struts2 Tiles Plugin - Removes the standalone nature of Tiles. So... of the three viable options, let's discuss and decide where to go from here. 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: Graduation Options (was Re: [PROPOSAL] Updated Tiles Graduation Proposal)
On 11/28/06, David H. DeWolf [EMAIL PROTECTED] wrote: ... Perhaps I'm looking at this too selfishly, but I'm thinking that if nothing else the teams can help each other with the infrastructure and burden of being a TLP. For example: - Moderating Mail Lists - Board Reports - Managing Jira - Community Oversight - etc. . . and the burden of all of these grows with the size of the community. true, it's not a linear curve, but i think the benefits of shared interest in a codebase are superior to those of size. It seems to me like those types of tasks can take a lot of development time away from a small team. I've heard of PMC Chairs that are consumed by all of this overhead and stop committing code. I don't ever want to get to that point and it seems possible considering the fact that there are only 3 of us - 2 that currently commit code. this is especially prone to happen when the scope of the PMC is too big. too much to oversee and keep track of. That said, I do think there's much more potential for commit overlap than you give credit. Simply having access to the repo of a sister project might spawn some interest. I know that I'd be apt to dive into FileUpload or WebParts if I had commit access. I've used both before but haven't contributed because the burden was too much for the benefit. it might, but i'd advise against counting on cvs access alone to spur involvment. At the same time, while I'm sure Dimensions or Scopes are great, I just don't have the need for them right now. And because of that, I'd be less apt to contribute. true, but those interested in dimensions or scopes (i'm assuming they're Tiles-dependent here) are much more apt to contribute to Tiles. and those who already know Tiles should be much more capable of jumping in on dimensions or scopes (being closely related projects) than they are on FileUpload. consider email: it should be easier and quicker for a Tiles committer to follow email about a closely related/dependent project than it is to follow emails about unrelated ones like FileUpload. lack of focus will cost all the developers time, not just the PMC chair. In other words, I don't think it's dependency that makes people contribute, I think it's weighing the benefit against the burden. If we lower the burden for key people, they may come to play. in both cases (Dimensions/Scopes vs FileUpload/WebParts) you are talking about lowering the burden equally from an infrastructure point of view, so that's a moot point. and the conceptual burden of contributing to a dependent project (Dimensions/Scopes) is already lower than that of an unrelated project (FileUpload). so, it's only the benefit side that is really in question here. as to that, investment in a project dependent on Tiles leads to investment in Tiles much more often than investment in FileUpload would. yes, in the other direction (starting with investment in Tiles, like you, and looking at Dimensions/Scopes), the benefit is highly personal and thus essentially arbitrary, but it still seems more likely (due to the lower conceptual burden). take the umbrella metaphor itself: umbrellas are much easier than tarpaulins to manage because they have a specific, central pole to which all the rest is firmly connected. likewise, putting Tiles, FileUpload, etc together in one project may have some benefits but is going to be hard to manage effectively and move forward together (Jakarta Commons and Jakarta itself are examples of this). - 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: [Struts1] STR-1183: creating a ViewUtils class
Yay!! On 11/23/06, Mark Bakker [EMAIL PROTECTED] wrote: I am interested to do some work on the Struts project. I have been investigating STR-1183 https://issues.apache.org/struts/browse/STR-1183 currently I started to create some code. In general I am creating a ViewUtils class in the struts-core, what is functional a copy of the TagUtils class in struts-taglib. This ViewUtils class will not use a PageContext in the signature. The interface of the TagUtils will not change and the TagUtils class will use the ViewUtils class where posible. Additional I will write unit tests for the ViewUtils class and will update the unit tests for the TagUtils class. If you guys have any idea's or remarks please let me know. - 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: JXP Template support?
If you don't want to learn anything new, why stop in the middle at JXP? Just use java itself. Then there's no new syntax (we'll ignore the fact that java syntax is still evolving...) and no new API (again ignoring the fact that those change too) that can often take longer to grok than a new syntax. Sarcasm, aside, lines 2 thru 5 of the example script at (http://jxp.sourceforge.net) are the new, non-java, not-quite-jsp syntax of JXP. Don't kid yourself. There is both new syntax and new API here. It may be minimal, but it's there. It has to be, otherwise, it's just an incomplete java interpreter with some new APIs built in. You might as well use something with more momentum and support, like Groovy. The syntax of template languages like Velocity or Freemarker is intentionally designed to be simple and quick to learn. Yeah, things like try-catch or synchronized blocks would probably involve a lot of complexity in such new template languages were they even possible, but there's good reasons for making such things difficult/impossible in a templating language. Also, the lack of an EL in JXP may simplify the syntax, but at the cost of a lot more keystrokes. There's a reason JSP, Velocity, Freemarker, and friends all have those. On 10/17/06, Mike B [EMAIL PROTECTED] wrote: Hi Guys, I am simply responding because we have been using JXP for about 7 months now.. We are currently using JXP for our web component templates. It has worked out fairly well. We actually started out using FreeMarker, but did not like the idea of learning a new syntax just for simple templating. Sure... its not that big of a deal, but what is the value add of learning additional syntax to do something you could do in Java (even easier). We also felt that JXP was easier to work with front to back. We were up and running in a couple of hours. Its nice to have the ability to write Java code in your templates. We never have much, but for the small sections that need it, it comes in handy. It would be great to see some others take interest in the project. I feel the over all benefits of having a popular and well supported template engine that has a JSP like syntax is a no-brainer. Some key reasons: - You get mainstream tool support for free. - You get a template engine with a familiar syntax - It makes for easy migration of JSP artifacts to templates (which are no longer bound to a JSP/Servlet container). Just some 3rd party thoughts. Cheers, Struts Action 2 / WW User - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=46468messageID=94261#94261 - 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: [tiles2] Tiles controllers (WAS: Re: [tiles2] Some words about proposed changes)
On 10/6/06, Antonio Petrelli [EMAIL PROTECTED] wrote: Greg Reddin ha scritto: Here's what I envision for the controller: I don't think it would really be used to change the destination of the response. I don't see the controller as being analogous to a Struts action even though it could be used in that way. If I wanted the controller to be used as a controller in the MVC sense of the word (IOW to select a destination) I'd want it to return something like actions do in Struts, WebWork, and JSF. I've always used the controller like a JSP tag. I use it to implement code that needs to reside in the view layer (or code that needs to be called from the view layer) and as a way to keep from writing scriptlet code in my JSPs. Uh I see, I think it's time to resurrect controllers (I think it's needed only in the TLD). Now what about their name? Possible names could be: * Controller for the class (or maybe TilesController) - controllerClass and controllerUrl for tag attributes * ViewPreparer (or TilesPreparer) for the class - preparerClass and preparerUrl and for the tag attribute (thanks Nathan!); * TilesPreprocessor - preprocessorClass, preprocessorUrl (this is what I suggest). How about TilePrep? It's shorter and can stand for either/both Preparer or Preprocessor. I think we should retain the controller for Tiles definitions (not sure about the insert tag). I have the same doubt, especially for controllerClass in tiles:insert: every time a new instance of that controller is created! Should we provide a caching mechanism, or remove the controllerClass at all? Ciao Antonio - 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: [tiles2] Some words about proposed changes
I think controllers should stay, but the name should be changed. Call them ViewPreparers or something... On 10/5/06, Greg Reddin [EMAIL PROTECTED] wrote: On Oct 5, 2006, at 9:53 AM, Antonio Petrelli wrote: * The controllers were added to allows stand alone use of tiles to be able to do some kind of computation associated to the tiles. When used with Struts, there is a redundancy (with the use of actions), but when used alone, the controller mechanism is very useful to separate view rendering from controller business The problem with Tiles controllers is that the controller is not able to choose between different destination pages. It misses an important part of a controller: the dispatcher. But using a normal url as a template (or tile :-) ) it can do both calling the model and dispatching. If you download the latest version from SVN, there is a test with a simple servlet that includes a (fixed for the moment) JSP page. And I think that including a Controller in a View layer technology is not a good idea. Here's what I envision for the controller: I don't think it would really be used to change the destination of the response. I don't see the controller as being analogous to a Struts action even though it could be used in that way. If I wanted the controller to be used as a controller in the MVC sense of the word (IOW to select a destination) I'd want it to return something like actions do in Struts, WebWork, and JSF. I've always used the controller like a JSP tag. I use it to implement code that needs to reside in the view layer (or code that needs to be called from the view layer) and as a way to keep from writing scriptlet code in my JSPs. It just so happens that the controller API gives you indirect access to the request and response objects so you could use them to include or forward or write directly to the response and all the other stuff you can do there. But I'd not recommend the controller be used in this way. I would use the controller to manipulate the TilesContext and the JSP contexts, but not to actually do anything with regards to changing the destination. In today's world if I was writing a Struts app with Tiles I would try to use JSTL, EL, custom tags, (or in JSF, action listeners, etc). to do things I did in the past with controllers. But I can still see circumstances where I might want a controller instead. Think about this: Tiles can be used for page composition outside of any MVC framework. In that sense it's kind of like a portlet container. (In fact I think that's how Cedric envisioned it before JSR-168 came about). So you can compose pages out of JSP fragments and populate each fragment with a controller that is executed before the fragment is processed and included. I actually have written a couple of small webapps that use Tiles in this way and see it as a powerful feature. I think we should retain the controller for Tiles definitions (not sure about the insert tag). I also think we should document the fact that you can get yourself into all kinds of trouble by making improper use of the request and response APIs from within the controller. Thoughts? 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: [s1] Commons-Lang
If i might jump in here... I whole-heartedly agree with Don. A couple years ago i would have argued against him on this quite vigorously. But after several more years of working close with both Struts (and VelocityStruts) which use commons-logging and Velocity itself (which takes Don's approach), i can say that Velocity's simple log interface has never caused me the headaches that commons-logging has (which were exacerbated by Tomcat's move to full dependence on commons-logging). I highly recommend you take Don's approach here. As for actually carrying that out, well ever since i came around to the position on this that i now have, i've been thinking that there still ought to be some commons version of what Velocity uses and Struts needs. The catch of course is that the code needs to be rather directly imported into the libraries that will use it and have its package names changed (a static linking of sorts), and i don't know how this would be automated or releases managed or anything of the sort. True, the code needed is not at all difficult or all that time consuming to write, but it seems to me there ought to be a way to develop it communally and share it in a way that can be easily (or better, automatically) internalized. Then we would not only save the work of rewriting it for each project, but also of learning the trivial differences in interfaces and configuration for each library out there. If anyone has ideas for how this might be done, i'd be happy to jump in and contribute Velocity's internal logging facility, as i've put much work into it in the last year or so. And of course, if a similar thing could be done for commons-lang type stuff, the same benefits would apply. Ideas anyone? On 8/21/06, Don Brown [EMAIL PROTECTED] wrote: Commons Logging is a great example of the problems these small third-party dependencies cause host applications :) In this case, yes, we need to log, however, as a library, the only messages the user will care about are those that are from the library as a whole. If the user needs to filter at a package level a library's log messages, that library has problems :) Therefore, all a library needs is a Log interface, a simple default implementation, and a factory to provide that implementation. The library, if it really wants, can provide a commons-logging, jdk logging, and/or log4j implementation, but I think that's really optional. The point is these classes should be in the libraries package system so that they don't conflict with any other application or application server dependencies. At some point, I plan to replace commons-logging in Struts 2 with a simple log framework. I can backport to Struts 1 if desired. Don On 8/21/06, Martin Cooper [EMAIL PROTECTED] wrote: On 8/21/06, Don Brown [EMAIL PROTECTED] wrote: I think we should keep s2's dependencies down to an absolute minimum. If you are writing an application, the more you reuse third-party libraries the better, however, if you are writing a framework and/or library, ideally, you should have none. The main reason libraries should have as few deps as possible is it imposes undue restrictions on the application using the library. For example, say Struts 2 started using commons-lang 2.1, but the application wanted to move to 3.0. They'd have to wait until Struts 2 moved to 3.0, but then all the apps using 2.1 would be forced to upgrade. IMO, the ideal library has no dependencies, and I include commons-logging in the forbidden list. Any library of any consequence needs to log errors and exceptions. We can't dictate to our users which logging package they use, and we need to provide for unified logging throughout an application. Given those constraints, how do you propose that we handle logging if we don't depend on something like Commons Logging? -- Martin Cooper Don Paul Benedict wrote: Because Struts does alot of Spring manipulation on URIs, would it make sense to add Commons Lang as a dependency? This way we don't have homegrown string parsing done everytime. Thoughts for s2 too? - Do you Yahoo!? Next-gen email? Have it all with the all-new Yahoo! Mail Beta. - 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: Whose log is this anyway? (was Re: [s1] Commons-Lang)
Very cool. That looks like what i was looking for. Thanks :) On 8/22/06, Bob Lee [EMAIL PROTECTED] wrote: On 8/22/06, Ted Husted [EMAIL PROTECTED] wrote: Say, wasn't there a mention of some package that renamed packages dynamically or something? That's the real issue. Two versions of the same package name on the same classpath. jarjar In the case of logging though, we should just use java.util.logging. If you still want to use log4j, why not write a j.u.logging Handler which logs to log4j? Do we really need an API to decouple us from an API which decouples us from a logging implementation, or is one level of indirection sufficient? This is why everyone makes fun of clogging. Bob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Whose log is this anyway? (was Re: [s1] Commons-Lang)
+1 I really like what Seam is doing. As soon as Velocity moves to
jdk5, you can bet we'll be doing much the same.
And yeah, it really only takes a few simple classes to have a much
nicer interface than j.u.logging. For Velocity, we basically have
two classes (Log and LogManager) and an interface (LogChute), then the
rest are all just very simple LogChute implementations to j.u.logging,
clogging and such. Adding the ability to use varargs to streamline
things as Seam and Stripes are doing would definitely make it
worthwhile to implement this, IMHO.
On 8/22/06, Don Brown [EMAIL PROTECTED] wrote:
I think a couple extra classes is worth switching from this:
public Order createOrder(User user, Product product, int quantity) {
if ( log.isLoggable(Level.FINE) ) {
log.fine(Creating new order for user: + user.username() +
product: + product.name()
+ quantity: + quantity);
}
return new Order(user, product, quantity);
}
to this:
public Order createOrder(User user, Product product, int quantity) {
log.debug(Creating new order for user: #0 product: #1 quantity: #2,
user.username(), product.name(), quantity);
return new Order(user, product, quantity);
}
Considering how often we log things, I think the cleanup is huge and a
few classes are definitely worth the price.
Don
Bob Lee wrote:
On 8/22/06, Don Brown [EMAIL PROTECTED] wrote:
Well, for one, we only really need one logging instance for the whole
library. Second, and admittedly this is subjective, the
java.util.logging API is a horribly designed, obtuse API. I'd rather
see us write a small, clean API along the lines of Seam's logging class
that utilizes varargs to reduce the need for isDebugEnabled().
I agree that j.u.logging is a PoS, but it's ubiquitous, and for our
purposes, it workds fine. We may only need one logger for the whole
framework, but it's just as easy to create a logger per class, and you
can
still configure them all at once. I'd rather fix j.u.logging than
build yet
another API.
Bob
-
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: Whose log is this anyway? (was Re: [s1] Commons-Lang)
On 8/22/06, Martin Cooper [EMAIL PROTECTED] wrote:
On 8/22/06, Tim Fennell [EMAIL PROTECTED] wrote:
On Aug 22, 2006, at 5:11 PM, Martin Cooper wrote:
if (isDebugLoggingEnabled()) {
log.debug(And the answer is: + expensiveMethodCallHere());
}
I don't know about you, but I'm very thankful for that guard when
debug
logging is disabled (e.g. in production). Without it, I'm going to
make that
expensive method call even if logging is disabled - and then just
throw away
the result after doing nothing in log.debug. Even a lowly toString
() call,
frequently used in debug logging, can get expensive, so it's not
like this
is a corner case.
-1 on getting rid of guards.
I agree that in rare cases you might want to be able to do this
still. But in the vastly more common 2nd case you cite (the
expensive toString() call), that's entirely the point of this. Log
methods take Object.../Object[] and only toString the objects in the
array if the appropriate log level is enabled.
No, I don't think you're getting what I'm saying. I'm not talking about
internal toString() calls, I'm talking about something like:
log.debug(And the answer is: + myBigObject.toString());
That toString() method is going to be invoked before the log.debug method is
ever called, so the cost is sunk even if debug logging is disabled.
Now, I get the point that I should probably have used a parameterised string
and passed in myBigObject, letting the log method to the toString() call,
but people are so used to doing things like the above that it will still
happen.
True. Also true is that the same people are also used to wrapping
such calls in isDebugEnabled() which i don't think anyone wants to
abolish. They just want a shorthand to be available. Besides, we are
still talking about the internal logging facility for Struts2 (and
potentially directly tied derivate libraries), not something
application developers are supposed to be using, right?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Tag prefixes
If you need multi-line bodies, then you are best off sticking to
directives for now. If you don't need or want line breaks in your
body, then a tool will be fine.
The helpful thing in Velocity 1.5 is that you can have multi-line
string literals, interpolated strings, method calls, and directive
calls. So you could do:
$tool.body(
This is a $adjective body.
It has two lines.
)
with tool, where before you'd have had to do
$tool.body(This is a $adjective body.${br}It has two lines.)
Where the value of $br is a line break character.
Of course, we have yet to release Velocity 1.5 though it is extremely
stable and much superior to 1.4, because some of us (occasionally
including myself) are rather determined to knock off a few more old,
obscure bugs first, but haven't made the time to do it. All the new
features are done though, so there shouldn't be any more API changes.
On 7/19/06, Patrick Lightbody [EMAIL PROTECTED] wrote:
Nathan,
I don't think tools will work for us for now because of the body tag
requirements. Perhaps Velocity 1.5 will help?
-
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=37739messageID=74500#74500
-
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] Tag prefixes
On 7/18/06, Don Brown [EMAIL PROTECTED] wrote: Nathan Bubna wrote: (it's been awhile since I've been one myself --- Ahh, those were the days!), but the _ is a shift key. If we were going to use a separator in the vmname, we might want to try the hyphen (-). Then, all three would have separators, even if different separators :) From the VTL reference, it looks like only [ a..z, A..Z ][ a..z, A..Z, 0..9, -, _ ] are valid,. * http://jakarta.apache.org/velocity/docs/vtl-reference-guide.html My general feel is that #surl is fine, but if you really want a separation, you should use a hyphen, not an underscore. Of course, if i were doing this myself i might design some/many of these as tools instead. so $s.url(...) instead of #surl(...). No biggie though. Hmm...what would be involved if we did turn it into a tool? Are there any advantages/disadvantages over how we do it now? Once we get Velocity 1.5 out, tools will probably be the easiest development path for most things. Prior to 1.5's better \n handling directives are easiest for anything that needs/wants/uses a body. In general, tools are the best thing for stuff that is not Velocity-related. In other words, if the function in question doesn't need access to the AST and such, use a tool. Then you have much more flexibility and room for syntactic sugar. And as it stands now, looks like s- is winning. +1 Don :) -T. - 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: [s2] Tag prefixes
On 7/18/06, Ted Husted [EMAIL PROTECTED] wrote: On 7/18/06, Nathan Bubna [EMAIL PROTECTED] wrote: My general feel is that #surl is fine, but if you really want a separation, you should use a hyphen, not an underscore. Of course, if i were doing this myself i might design some/many of these as tools instead. so $s.url(...) instead of #surl(...). No biggie though. Bringing the Velocity tools on board sounds interesting. If not for 2.0.0, then maybe for 2.0.1, if you were up to doing the work, Nathan. I might be up for it. I'm keeping an eye on what you're all up to. I doubt i'll have time for the next 3+ months (newborn baby and working hard on a Spring MVC project for the boss), but i'm very interested in where WebWork/Struts2 is headed. I see good things here. Oh, and you don't necessarily need to bring VelocityTools on board to use tools. When i say Use A Tool i just mean use a handy, well-focused java object with a VTL-friendly interface that's automatically placed in the context for every page. :) Velocity Tools is just a collection of such objects and one convenient way to automatically add them to the context. If our particular tools aren't useful and/or you have an easier way to add them to your context with your framework, then you don't need VelocityTools. -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: [s2] Tag prefixes
On 7/18/06, Ted Husted [EMAIL PROTECTED] wrote: On 7/18/06, Don Brown [EMAIL PROTECTED] wrote: What about using s_ for velocity, then s: for the rest? From what Toby said, I think FreeMarker uses a ., as in @s.url ... / I'd like to hear from a Velocity person on this but i like lurking! ;-) (it's been awhile since I've been one myself --- Ahh, those were the days!), but the _ is a shift key. If we were going to use a separator in the vmname, we might want to try the hyphen (-). Then, all three would have separators, even if different separators :) From the VTL reference, it looks like only [ a..z, A..Z ][ a..z, A..Z, 0..9, -, _ ] are valid,. * http://jakarta.apache.org/velocity/docs/vtl-reference-guide.html My general feel is that #surl is fine, but if you really want a separation, you should use a hyphen, not an underscore. Of course, if i were doing this myself i might design some/many of these as tools instead. so $s.url(...) instead of #surl(...). No biggie though. :) -T. - 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: [Standalone Tiles] Changing the Semantics of the InsertTag
I like the idea. I've always felt tiles was more complicated than necessary. Simplify it. Antonio's question is a good one. The lookup order needs to be well documented and a type=definition|attribute attribute would probably need to be available to override the standard lookup procedure. On 6/13/06, Greg Reddin [EMAIL PROTECTED] wrote: Ticket SB-21 [1] seeks to simplify the Tiles taglib API. First, it's a given that this will break backwards compatibility. You can't reduce an API without breaking compatibility. But as long as we're seeing this version of Tiles as a rework, I don't think it's a problem. Also, I don't think it's a difficult thing to fix in existing applications. No functionality will be removed, but redundant hooks to the same functionality will be removed. Finally, I think this will be one of the greatest improvements to the usability of Tiles. I'm currently working on a patch to implement this. Of the attributes that are currently supported by InsertTag, I believe the following are redundant: 1) attribute, definition, name could all be resolved to name. 2) component, page, and template could all be resolved to template. In addition the name attribute can be interpreted as either a pointer to a Tiles definition or attribute or an URL, which essentially makes it equivalent to page and template. I propose that we reduce all these meanings down to the name attribute. IOW, name can be a definition name or an attribute name. I suspect this is how Tiles is being used in 90% of applications anyway. I know that's how I use it. Further, I propose that we reduce all the URL-based attributes to the template attribute. So if you want to directly insert a page you must use the template attribute. The net result is that you can use the insert tag in the following ways: tiles:insert name=someName/ - to insert a Tiles definition or attribute. tiles:insert template=/somepage.jsp/ - to insert a URL. I'm not really sure what the use of the beanName and beanProperty values are, so if someone wants to enlighten me on that, I'd appreciate it. Finally, I personally don't see the use for including a controllerClass or controllerUrl in the insert tag. IMO, if you want to do something like that you should use the definition tag instead. I still intend to completely support attributes defined in the tag body as such: tiles:insert name=someDefinition tiles:put name=someAttribute value=someValue/ /tiles:insert And the other attributes like flush, ignore, and role will continue to function as always. Have I left out any major uses of the insert tag? Does this change remove any functionality that anyone is currently relying on? Thanks, Greg [1] http://issues.apache.org/struts/browse/SB-21 - 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: Proposal for change
On 4/25/06, Frank W. Zammetti [EMAIL PROTECTED] wrote: On Tue, April 25, 2006 6:45 am, Ted Husted said: snip/ From an ASF perspective, the community is not everyone who subscribes to the mailing list and downloads the product. The community is the set of individuals who contribute to the project, both by making helpful posts to the mailing list *and* by contributing useful code and documentation. Downloads don't make the product possible. Contributions make the product possible. Our customers are the contributors, who pay for the product with posts and patches. I guess this is one way that I've never quite got it, as Craig says :) I view the community as being larger than just those contributing. While I have no problem affording something more to those that contribute, I think those simply using the product have a stake in it. They can of course choose to ignore that stake, but they can exercise interest if they wish. For me, the community would be anyone who has an active interest in how the project develops. Those that contribute in some way deserve a louder voice and a bigger say in things, but I don't think contributing is the only criteria for being in the community. But that is my interpretation, I realize it doesn't jive with the ASF interpretation :) it feels like this is really the lynchpin of all this. your understanding of the Struts community is not the ASF's. your understanding of what the community is appears to be the driving principle behind your proposal. so this proposal contains an implicit subtraction of the current definition of community to replace it with a broader one. like it or not, when you widen the scope, you are subtracting an intentional limitation set by the ASF. i know, it seems like a fairly simple and nice proposal to make it the standard practice to let all interested parties weigh in on committer nominations, but as you are probably discovering by the responses, there is a significant ideological shift involved. community is critical to the ASF; changing that from them that do the work to all who are interested in the work is no small thing. committer status is fundamentally two things: a formal recognition that the person is among them that do the work (which should already be obvious) and a labor saving device (so the other committers don't have to deal with the person's patches). so as i see it, nominations and votes ought to be a largely superfluous formality, and the opinion of those interested in shaping the development of the project but not among them that do the work is irrelevant politics (the unfortunately common penalty for popular projects like Struts). Over the years, I think there have been exactly two committer nominations here that failed, and both times the failed nominees had not submitted a single patch. i.e. it was not at all obvious that those two were among them that do the work. Question: does submitting a patch have to mean having the patch accepted? At first glance, the obvious answer is yes, but I'm not so sure it's really the obvious answer... if someone has submitted a number of patches that were not committed for reasons other than purely technical (i.e., the patch will break X), should those patches be considered? snip/ forgive me for being blunt, but this is nonsense. who wants a committer whose work breaks X? those patches aren't part of the work of the project. that's a bummer for the submitter, but this is not about effort or desire or concern or anything other form of interest in a project. it's about merit. if you don't have it, then you are s.o.l. Oh, and if you do have it but insist on changing this to be more about interest than merit (i.e. you don't get it), then you should not be the least surprised when you find a lot of resistance. :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposal for change
On 4/25/06, Frank W. Zammetti [EMAIL PROTECTED] wrote: On Tue, April 25, 2006 3:10 pm, Martin Cooper said: This is where I'm not sure I agree... why can you only have a stake in the code, or in the community even, if you are a committer? And certainly the community is often touted as the most important part of any ASF project... it's just that community in that context means the committers only, which is where I disagree with the Apache Way I guess. No, that's not correct. The community is, as you put it earlier, anyone who has an active interest in how the project develops. So you actually agree with the Apache Way. ;-) If your saying that the community is not only composed of committers, PMC members, etc., then yes, I do agree :) and of course, i sent me email before reading these because the thread is moving so fast. ugh, defining words can be such a pain. :) for the record, when i use community == them that do the work in my email, i am referring to those who make the decisions. this is pretty much the committers and contributors (note again that contributors != patch submitters). of course, there is the broader sense of community that includes those who have an interest in the development of a project, but in the Apache Way, their opinions are not binding. oh, and i realized that calling them irrelevant politics was totally wrong since the decision making community does care about the opinions of the broader interested-in-development community and even the user community. committers and contributors are not at all immune to ego-stroking and the politics that accompany it. instead of irrelevant politics, i ought to have just said politics. ;-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposal for change
On 4/25/06, Frank W. Zammetti [EMAIL PROTECTED] wrote: On Tue, April 25, 2006 3:42 pm, Nathan Bubna said: Question: does submitting a patch have to mean having the patch accepted? At first glance, the obvious answer is yes, but I'm not so sure it's really the obvious answer... if someone has submitted a number of patches that were not committed for reasons other than purely technical (i.e., the patch will break X), should those patches be considered? snip/ forgive me for being blunt, but this is nonsense. who wants a committer whose work breaks X? those patches aren't part of the work of the project. that's a bummer for the submitter, but this is not about effort or desire or concern or anything other form of interest in a project. it's about merit. if you don't have it, then you are s.o.l. Oh, and if you do have it but insist on changing this to be more about interest than merit (i.e. you don't get it), then you should not be the least surprised when you find a lot of resistance. :) I think you may have misunderstood... someone who's code breaks X SHOULD NOT be considered. I didn't say otherwise :) As for interest vs. merit, I don't at all disagree... merit is what counts. My only point would be that what constitutes merit may not be, or maybe should not be, as simple as how many accepted patches has this person put forward. Ted hinted at that with his commented about the Wiki being considered. I agree that code trumps all else, as it should be, but should that be the *only* consideration? no, not just code; documentation is great too! and personally, the only parts of wiki contributions that ought to be considered are those that become part of the official release/distribution. those are the wiki-submitted patches that have been accepted. Well, in any case, you raise a good point about the proposal maybe being more of a paradigm shift than I thought. I may have miscalculated that. You also raise some other fair points above I think about being a fundamental change in what community is. I sincerely thank everyone that commented, I appreciate you taking the time out of your busy schedules to at least consider the proposal. I won't push it any further, being heard and considered is all I could have expected. thanks for stirring the pot! it's a healthy thing. :) Frank - 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: Standalone Tiles as TLP
On 4/23/06, Martin Cooper [EMAIL PROTECTED] wrote: On 4/23/06, Don Brown [EMAIL PROTECTED] wrote: I would think it would be Tiles' responsibility to support deployment with Struts. In that view, Tiles would be its own project, yet part of it would depend on struts-action.jar to provide the Struts hooks. In the same way, they would provide Struts Action 2 hooks, if necessary. This is a tough one - for me, at least. Should an independent Tiles have glue code for Struts, or should it be Struts' responsibility to provide the glue? If we look at Velocity, the glue is over there, but we've also talked about it coming here. If we look at Validator, the glue is here. If we look at Chain, the servlet and portlet glue is over there. My preference, at least at this time, would be for the Struts / Tiles glue to stay here. That will help Standalone Tiles stand on its own feet, and especially help with the notion that it's now independent of Struts. Any perception - real or otherwise - that Tiles is tied to Struts will be detrimental to Tiles as an independent library. +1 Let's keep the Struts-Tiles code and Tiles-Velocity type code out of stand-alone tiles for the moment. I think a better time for moving those over would be once Tiles is established and released as an independent Jakarta Web Component. -- Martin Cooper Don Wendy Smoak wrote: On 4/23/06, Don Brown [EMAIL PROTECTED] wrote: Agreed. Would it be possible to do this by JavaOne? Moving Tiles isn't a huge deal, but it would make the new directions of Struts easier to explain to users. What happens to Struts Tiles, then? I'm not sure I understand why we're holding Struts Tiles out of the Struts Action distribution. Won't there always be a struts-tiles.jar of some kind, whether it's the current one with all the code, or a much lighter version that works with Standalone Tiles? -- Wendy - 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: Standalone Tiles as TLP
On 4/22/06, Martin Cooper [EMAIL PROTECTED] wrote: On 4/21/06, Greg Reddin [EMAIL PROTECTED] wrote: On Apr 21, 2006, at 7:56 AM, Ted Husted wrote: IMHO, once Standalone Tiles is ready for a release, we should migrate the component to a top-level ASF project. When we started this process, the original intent was to decompose Tiles here, test it in Action and Shale, and then move it out when it was ready to stand on its own. I agree with your points about Tiles not being an application framework, etc. My only concern about making it a TLP is developer support. Granted, this could be an issue no matter where Tiles lives. But there are not throngs of people jumping in to help with the refactoring efforts. I wonder if there are enough people interested in developing Tiles to support its own TLP. I have these same concerns. That is why my preference would be for Tiles to stay here until Jakarta Web Components (nee Jakarta Silk) gets off the ground, and then move there, where it can share a general purpose web-focussed community and mindshare. +1 I think that would be a great community for Tiles to join. -- Martin Cooper 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: Standalone Tiles as TLP
On 4/21/06, Ted Husted [EMAIL PROTECTED] wrote: Lately, we've gotten into the habit of talking about Standalone Tiles as if it were already an Apache Struts subproject. As far as I remember, there has never been a vote to that effect, and the only proposal on the wiki positions Tiles as a top-level project, once it is ready to stand on its own. * http://wiki.apache.org/struts/TilesTopLevel IMHO, once Standalone Tiles is ready for a release, we should migrate the component to a top-level ASF project. When we started this process, the original intent was to decompose Tiles here, test it in Action and Shale, and then move it out when it was ready to stand on its own. If anything will make Apache Struts an umbrella, it would be keeping Tiles here, rather than proposing it as a top-level project. Standalone Tiles is *not* an application framework. Tiles is a *component that can be used by any web application, just like Validator and BeanUtils and everything else we extracted into standalone versions. Of course, another alternative would be to propose Tiles as Commons component or Jakarta subproject. Albeit, I feel that Tiles falls somewhere between a component and a framework, and that Tiles is rich enough to warrant its own top-level project. Thoughts? Do we need to be discussing this now? I kinda feel like this should wait until Tiles is ready to stand alone. If there is sufficient interest/support from developers, then i don't see any problem with having Tiles be a top level project. But to be honest, i don't think we have that at this, or if we do, then it is a surprise to me. And i'll point the finger at myself on that one too. The time i have available for open source work is very limited lately and Velocity is my priority there. I'd like to jump in and help with Tiles, but the time isn't there. Right now, it is easier for me to envision Tiles staying on as a Struts subproject. As for jumping over to Jakarta, that wouldn't bother me, but i'm not sure i understand why. Just because it's not a full framework on the level of Struts 1.x, Shale, and SAF 2? That's not a reason that motivates me a lot. -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: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
On 3/20/06, Frank W. Zammetti [EMAIL PROTECTED] wrote: Craig McClanahan wrote: For Shale, at least, I would *not* advocate eliminating separate JAR files. There are optional features of Shale that themselves have their own dependencies, and it would be a burden on all Shale users if everything was combined into one JAR file. As Ted mentioned earlier in some thread, this is a lesson that we in the Struts community can learn from what Spring is doing. Two use cases in the Shale world: * Shale Remoting -- a completely standalone JAR file that does not depend on anything else in Shale, but is useful for component authors and app developers doing AJAX style development. 40k and zero dependencies, versus 140k (for shale-core.jar) and a bunch of dependencies. * Tiger Extensions -- optional layer on top of Shale that utilizes JDK 1.5annotations to reduce or eliminate configuration files. Including this stuff in a core Shale JAR file would require *all* users to be based on JDK 1.5. In the Struts 1.x world, the same kind of argument applies to struts-el.jar(only needed if you are on a JSP 2.0 platform) and struts-faces.jar (only needed if you are using JSF components in a Struts based application). That all makes perfect sense, thanks Craig. You know, I was looking at the Struts front page a few minutes ago, specifically the Extensions, which are the seven dwarfs IIRC. The one that sticks out for me as a problem, if that's the right word, is the JSP Taglib. there have been VelocityStruts users eager for the Struts tags to be separated from the core for a long time. there's plenty of people using Struts without the tags. I think it's fair to say that the majority of Struts developers consider the Struts tags to be intrinsically part of the Struts Action Framework (SAF). Except for me who rarely uses them! :) The analogy I would use us the component kit you use in a JSF app... *can* you build a JSF app with no component kit at all? I would guess yes... but how many people *would* ever do that? I would guess very few. I think the same is true of the Struts tags. I think everything else, Tiles, Flow, EL, etc., really do seem to me to be true extensions, and as such it makes sense for them to develop on their own, be packaged on their own, and be downloaded separately as needed. My only concern there is simply to document well what version(s) of a given extension can be used with a given version of SAF. I think this information should always be front and center and easy to find quickly. But, the JSP Taglib, that one I think really does make more sense to go along with the core itself. I'm not saying it can't be its own JAR... that's just a matter of the final build artifact. I'd probably opt to include it in the Struts JAR, but that's really a minor point IMO. What is more important is that I think the taglib should share the same version number, release cycle, etc., as the core, and in fact should just simply BE part of the core. I guess I'm saying I would propose amending Don's proposal to only apply to the Struts taglibs :) Craig Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - 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: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
On 3/20/06, Frank W. Zammetti [EMAIL PROTECTED] wrote: Nathan Bubna wrote: there have been VelocityStruts users eager for the Struts tags to be separated from the core for a long time. there's plenty of people using Struts without the tags. I didn't know that, thanks for pointing it out. Do the tags being there hinder those users in any way though? Assuming not, and assuming my belief that more Struts developers *DO* use the tags than don't (which may not be true!) then I'm not sure it matters, and I would still suggest the tags should be part of the core. Not directly. But in so far as extras can hinder releases and sap development effort from the core, they do hinder the users. In general, one of the reasons i liked seeing the Struts extras pulled out of the core was the hope that bugs and slow development in such non-essential parts of Struts would no longer be a hinderance to fresh Struts core releases. It's a tough trade-off though, i admit. Either risk dependency confusion and frustration or else risk having good code be held back by extras that only a portion of the userbase is interested in. Personally, i prefer a little extra dependency complexity (and that preference even predates the usefulness of Maven and Ivy for such things) to the stifling of release frequency and freedom. Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - 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: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
On 3/20/06, Paul Benedict [EMAIL PROTECTED] wrote: I do see benefit in having the struts-taglibs (and actions) being their own release because there are some very minor enhancements that don't really require a new action framework release. For instance, Struts 1.2.5 added the errorStyle and errorStyleClass attributes, which probably could have been released faster if they were separate. This is the same situation for the struts-actions library which doesn't need a framework upgrade to add new functionality. However, the biggest downside of separate releases, as I see it, will be the confusion in the separate versioning of the libraries. Someone might be asking one day, Does taglibs-1.3.11 go with struts-action-1.3.4 or struts-action-1.3.6? It is really going to be difficult to eyeball which version library depends on which version library of another. Did I get this wrong? Isn't this how the independent libraies will be released at different schedules? compatibility is not that difficult to maintain in reality. for project developers there are just 3 simple rules to follow: - no point release (1.3.1 to 1.3.2) should ever break a working, outward facing API - all minor versions (1.3.x to 1.4.x) should deprecate working, outward facing APIs before removing (release foo in 1.3.x, deprecate in 1.4.x, and remove no sooner than 1.5.x, if at all). - all major versions (1.x.x to 2.x.x) are free to break or change whatever they wish. assuming developers respect these well-established patterns, then users worried about compatibility and dependencies and unwilling to track all project changes, there are only three simple rules: - point release versions that go GA are always safe to upgrade - watch for deprecations when upgrading minor version numbers - expect things to break with a major version upgrade and all of that can be done without any documentation apart from the version numbers themselves. throw in notice of deprecations in changelogs, and simple instructions about the latest versions (struts-taglibs 1.6.x depends on struts-action-core 1.4.x) and what's the big deal? also, by separating out the various extra components, you make the development and maintenance of entirely new components (e.g. VelocityStruts) easier, because some former internal APIs are now the external APIs of the core compenents. since those are now outward facing, compatibility and stability of the core is more rigorously maintained. so for those not under the Struts umbrella, life becomes better. :) If so, an alternative would be to re-tag all libraries and release them under one distribution version. If struts-taglibs go through 5 quick releases, that's also 5 quick releases of Struts too. heh. who ever heard of a quick Struts release? now you're just talking nonsense. ;-) but seriously, this is totally unrealistic. the different projects will overlap in their various states of readiness/buginess and the next GA release of any of it must wait until all of it is ready. Paul __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - 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: Tough Questions on Struts and Webwork Integration
On 11/29/05, Niall Pemberton [EMAIL PROTECTED] wrote: On 11/29/05, Don Brown [EMAIL PROTECTED] wrote: First, we bring in the WebWork 2.2 code which forms the Struts Ti core. Then, we develop a Struts compatibility layer. Along the way, if we see anything from Struts Action 1.x that should also go into Struts Ti core, we can add it. Honestly, I don't really see anything of Struts Action 1.x that isn't done better in WebWork, so yes, I still think it is a merger, but being this is targetted for Struts Action 2.0, I think it is appropriate to be such a large rewrite. Even if we wrote Struts Action 2.0 from scratch, I doubt we'd see much from Struts Action 1.x we'd want to carry over. Its probably a great plan to switch to WebWork 2.2 but I still don't see how you can say its a merger if no Struts code is involved - merger in terms of community, but not software. i would say the merging of communities and effort is far and away the important part. that's certainly the interesting part to me. i can't imagine any sane way to do a code merger apart from the proposed compatibility layer. so the community/effort merging has been my understanding from the get-go. And as with WebWork 1.x and as we've been saying from the beginning, Struts Action 1.x will continue to be developed and supported, so I wouldn't even call that a deprecation. If its agreed we move to WebWork 2.2 for Struts 2.0 then why would we continue developing Struts 1.x? I wouldn't want to, it would be a waste of time - would you anticipate doing any/much Struts 1.x development in this scenario? But again, that is my 2c which may not reflect the opinions of the Struts PMC as a whole. Don Niall Pemberton wrote: On 11/29/05, Don Brown [EMAIL PROTECTED] wrote: snip 3) A users has invested his or her hard-earned cash in `WebWork' in Action book. Will contents of this tome still be relevant in Struts? Absolutely, since Struts Ti == WebWork 2.2, with some package name changes. /snip snip 5) What architectural components are going to be replaced in Struts ? ( And conversely in Webwork?) This is a tough question because we haven't started on the Struts compatibility layer so I can't tell you what we can support from Struts. WebWork will be imported as is, so I don't see anything replaced there initially, however, we might decide to remove some deprecations. I can tell you it is my personal goal for the Struts compatibility layer to support to some extent Struts Actions, ActionForms, Validator, and Tiles at least. /snip I thought the proposal was to merge Struts and WebWork - from this and what : Jason Carreira said on TSS the actual proposal is that Struts Action/Classic is dumped and a migration path for Struts users to WebWork 2.2 be provided? If this is the case then rather than calling this a proposed merger wouldn't it be clearer to say that the proposal is to deprecate Struts in favour of WebWork? Niall Don - 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: [PROPOSAL] Merger with WebWork
interesting. and promising! i'll keep on eye on this. webwork has long had better velocity integration that struts. this proposed merger might either obviate the need for VelocityStruts integration in VelocityTools or else provide an opportune time to shift some of that code over to the StrutsWork community. :) if i haven't already noticed it happening, feel free to ping [EMAIL PROTECTED] if/when you work on merging WebWork's Velocity support. i'd be happy to help with that. On 11/25/05, Ted Husted [EMAIL PROTECTED] wrote: Presented by: Don Brown, Ted Husted, Jason Carreira, and Patrick Lightbody Between the Clarity hubbub [1] and the Java Web Alignment brouhaha [2], it came up that WebWork would like to merge with another framework. Ted and Don followed up with the two core WebWork developers, Patrick Lightbody and Jason Carreira. As it turns out, they are very interested in merging WebWork with Struts. An archive of our discussions is available as a Quick Topic thread [3]. As some of you know, the underlying idea behind Ti was to use WebWork as the core of Struts Action Framework 2.x. Conceptually, WebWork and Struts 1.x are very similar. We've often said, without embarrassment, that WebWork does many things better than Struts 1.x. Meanwhile, WebWork has the ability to provide a layer of almost full backwards-compatibility for Struts 1.x, and we have already demonstrated we can integrate Beehive's (very cool) Page Flow with WebWork. PROPOSAL: Bring WebWork into Struts through Struts Ti We would to amend the Struts Ti sandbox proposal to provide for merging WebWork 2.2 into our codebase. The WebWork merger would be Ti phase 1. Much of the work now proposed for Ti would become phase 2. * Ti phase 1 = WebWork 2.2 + Struts 1.x compatibility library and migration tools * Ti phase 2 = phase 1 + Commons Chain integration + Beehive's Page Flow + simplified annotations + quick development mode When the Ti phase 1 has coalesced and is providing a high degree of Struts 1.x compatibility, our intention would be to propose Ti as a Struts Action Framework 2.x candidate. Until that time, we would continue to consider Ti a next generation proposal and, pending a decison by the PMC, avoid attaching the 2.x label to Ti. When BeeHive Page Flow matures, it may be proposed to be merged with Struts Ti as phase 2. That work could also be positioned as a new subproject depending on where the PMC feels it would be better suited. As we work on Struts Ti, we would also expect that work would continue on Struts Action 1.x, perhaps including feature changes that would bring the codebases even closer together. To get started, we could bring the WebWork codebase into the Foundation through the Incubator. As part of the proposal to the Incubator, we could elect Patrick and Jason as committers, so that they could help us get Ti ready for an acceptance vote. There is also a Confluence space [4] setup to manage documents relating to the proposal. -- Don Brown, Ted Husted, Jason Carreira, and Patrick Lightbody. [1] Clarity - http://opensource2.atlassian.com/confluence/oss/display/WAG/Clarity [2] Java Web Alignment Group - http://opensource2.atlassian.com/confluence/oss/display/WAG/Home [3] Quick Topic Thread - http://www.quicktopic.com/33/H/KBfrHFUehSj/p16.1#QTmsg4 [4] Confluence space - http://opensource.atlassian.com/confluence/oss/x/kQY - 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]
VelocityTools 1.2 final released
The Jakarta Velocity team is pleased to announce the availability of Velocity Tools 1.2. This release offers numerous useful new generic and VelocityView tools, compatibility with Struts 1.2.x, and several bug fixes. For a complete list of changes, see the change log. VelocityTools is available in either binary or source form from the Velocity downloads page: http://jakarta.apache.org/site/downloads/downloads_velocity.cgi VelocityTools: http://jakarta.apache.org/velocity/tools/ Change Log: http://jakarta.apache.org/velocity/tools/changes.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: View helpers a.k.a. inverted views
On 10/13/05, Don Brown [EMAIL PROTECTED] wrote: This reminds me of the old push vs pull MVC architecture back in 2000/2001. The core decision is would you rather _push_ objects into a context in your action class, then let the view use them to generate the page, or, while processing your JSP, _pull_ the data into it by calling methods, processes, etc. In those days, the question was whether to use the push technique used by frameworks like Barracuda or pull with powerful JSP tags. Today, this seems to still be a big issue. Only now, the push proponents would be HTML template technologies like Tapestry, Wicket, and Clay. Technologies like JSF and JSP, even velocity seem to be able to be used either way. Looks like Stripes takes the pull position. Agreed. it is still a big question. and yes, velocity does support either. Which is better? I don't know if you can determine that for all situations. Push models work better to separate the designer from the developer, and generally produce views that are more maintainable. Pull can be easier to grasp for the developer and generally minimizes code. I don't quite agree. :) I think pull and push are pretty evenly effective maintainability and in separating the developer and the designer. They just do so in different ways. Pull allows developers to give designers a very consistent (and consistently available) interface with much less effort and lower probability of error. This lowers designer requests for X in page Y (more maintenance ability is passed to the designer). Push, on the other hand, limits the designer to just what the developer considers necessary for a page. As parameters change or errors appear, the developer is more responsible and the design aspects are typically simpler. So, yes, your decision should be made situationally, but i wouldn't call it a choice between maintainability and simplicity without specifying whether you're referring to a designer or developer perspective. :) By the way, if i can take this opportunity to do so, VelocityStruts is in need of some upgrades for the Struts 1.2 and/or 1.3 series. I've not been free to use Struts in my paid work and volunteer time has been scarce, so i'm not up to speed on the newer versions. If anyone is interested in helping out, that would much appreciated. :) I hope to see this discussion have a resurgence as I think it does well to capture two core approaches to web development. For more reading: http://jakarta.apache.org/turbine/further-reading/pullmodel.html Don On 10/13/05, Michael Jouravlev [EMAIL PROTECTED] wrote: I came across a discussion about view helpers, started by Tim Fennel, author of Stripes. He advocates the inverted model for displaying views, when view helper action is called from JSP if needed, instead of forwarding to JSP page from action, like it works in Struts now. With his approach, it is possible to navigate directly to JSP. On the one hand, this is a step backward, since I used to consider a JSP page as a mere view, and I prefer to navigate to web resource instead of navigating to a concrete view. On the other hand, using JSP directly from browser allows to employ jsp:include without forwarding. Currently I create embedded JSP controls by including Struts action into a JSP page. The action forwards to JSP file to render a fragment. Servlet engines do not like forwarding, and closes output stream immediately after returning from forwarded fragment, so the rest of the parent page is not rendered. Using JSP directly solves the problem, because no forwarding needed. What about creating a tag that will allow to define a certain bean as a view helper, and to automatically call something like processView() on it, and return a string mapping, which could be used to select a subview. Several subviews can be defined on one JSP page, and be selected via tag or a scriptlet. Michael J. - 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: View helpers a.k.a. inverted views
I totally agree, and I think most advocates of pull model design would as well. Note that Turbine (home to the doc that Don referenced) supports and encourages using action classes for actions (requests to do something) and pull tools (aka view helpers) for presentation of data (requests to view something). On 10/13/05, Tim Fennell [EMAIL PROTECTED] wrote: I feel like I should jump in and clear up my position here since the Stripes position is essentially what I wrote in a blog entry ;) Stripes very happily supports both the push and pull ways of doing this (and Jason pointed out to me earlier, that WebWork has similar functionality but I won't speak for their preferences) Often times I end up having a page that is read only. The application I'm developing now is a fairly complex app to facilitate DNA re-sequencing. We have lots and lots of domain objects, and lots of search/detail pages. These are the kinds of pages that I think are perfect candidates for the pull model. They are a very clearly defined view with a clear responsibility. There's no real decision making logic, it's all go pull this data and display it to the user. By using view helpers, all our search and detail pages are easy to embed in other pages. I find having pre-actions for this both awkward and unnecessary. But that doesn't mean that I think every page should eschew pre-actions in favor of view helpers. It seems to me anywhere that I'm making complex decisions about which view to render, or may have different data to render into the view, a pre-action is more appropriate. And I'm always in favor of actions to process events from the user when the request is to *do* something, not just *view* something. I think (and maybe I'm wrong) that the Struts community tends to use pre-actions for almost everything. Admittedly Tiles allows you to use use a pre-action per view fragment, but I'm not sure how many people make use of that over pre-actions. I was just trying to point out that my preference is for view helpers in situations where all you are doing is trying to load a page that requires some data in order to display, and that I don't think it's bad to have an application with some direct-to-jsp navigation, and some through-action navigation. My 2c. -t On Oct 13, 2005, at 1:51 PM, Don Brown wrote: This reminds me of the old push vs pull MVC architecture back in 2000/2001. The core decision is would you rather _push_ objects into a context in your action class, then let the view use them to generate the page, or, while processing your JSP, _pull_ the data into it by calling methods, processes, etc. In those days, the question was whether to use the push technique used by frameworks like Barracuda or pull with powerful JSP tags. Today, this seems to still be a big issue. Only now, the push proponents would be HTML template technologies like Tapestry, Wicket, and Clay. Technologies like JSF and JSP, even velocity seem to be able to be used either way. Looks like Stripes takes the pull position. Which is better? I don't know if you can determine that for all situations. Push models work better to separate the designer from the developer, and generally produce views that are more maintainable. Pull can be easier to grasp for the developer and generally minimizes code. I hope to see this discussion have a resurgence as I think it does well to capture two core approaches to web development. For more reading: http://jakarta.apache.org/turbine/further-reading/pullmodel.html Don On 10/13/05, Michael Jouravlev [EMAIL PROTECTED] wrote: I came across a discussion about view helpers, started by Tim Fennel, author of Stripes. He advocates the inverted model for displaying views, when view helper action is called from JSP if needed, instead of forwarding to JSP page from action, like it works in Struts now. With his approach, it is possible to navigate directly to JSP. On the one hand, this is a step backward, since I used to consider a JSP page as a mere view, and I prefer to navigate to web resource instead of navigating to a concrete view. On the other hand, using JSP directly from browser allows to employ jsp:include without forwarding. Currently I create embedded JSP controls by including Struts action into a JSP page. The action forwards to JSP file to render a fragment. Servlet engines do not like forwarding, and closes output stream immediately after returning from forwarded fragment, so the rest of the parent page is not rendered. Using JSP directly solves the problem, because no forwarding needed. What about creating a tag that will allow to define a certain bean as a view helper, and to automatically call something like processView() on it, and return a string mapping, which could be used to select a subview. Several subviews can be defined on one JSP page,
Re: View helpers a.k.a. inverted views
On 10/13/05, Ted Husted [EMAIL PROTECTED] wrote: On 10/13/05, Nathan Bubna [EMAIL PROTECTED] wrote: By the way, if i can take this opportunity to do so, VelocityStruts is in need of some upgrades for the Struts 1.2 and/or 1.3 series. I've not been free to use Struts in my paid work and volunteer time has been scarce, so i'm not up to speed on the newer versions. If anyone is interested in helping out, that would much appreciated. :) For Struts 1.3, I wouldn't trying to make the VelocityStruts tools obsolete :) ? The idea with this 1.3 agenda item * ViewContext - A Commons Chain Context that implements the combined VelocityStruts logical API (same signatures). is to eliminate the need for tags to wander all over the contexts looking for this and that. Instead, it will all be in a single object in request scope. (Which in turn might access other objects in session or application scope.) Accessing Struts components directly would be deprecated, and support removed in a later release. Access through the ViewContext would be cannonical, and tag libs support Struts would need to upgrade. sounds good. but i'm not sure i follow totally... has this been done? or is it just planned? really, i'm not up to speed on Struts 1.3 at all. Since VelocityStruts has already solved this problem :), I'd like to adopt and adapt that code so that it is part of the Core framework. just want to be sure i understand here... are you wanting to bring Velocity(Tools) integration code over to the Core or merely the code we use to access Struts resources? granted, the two aren't clearly delineated in VelocityStruts, but in general the integration-ish code is in the actual tool classes and exists to put a Velocity(Tools) friendly API on Struts resources. the StrutsUtils class is largely where we access struts resources (and i believe it originated in code from you. :) The big implementation question would be whether to use several objects, as Velocity Struts does, or just roll them back into one. yep. that's a big one. we break them up because it seems conceptually clearer and simpler to have $link, $text, $errors, and such than to have the extra layer of $struts.link, $struts.text, and so on. but this may not matter so much if you are presenting an API to tag (or tool) developers rather than page designers. also, a big advantage of splitting ours up is that we are then able to have the StrutsLinkTool extend VelocityView's LinkTool and thus leverage that code, and we can also offer the SecureLinkTool as an optional drop in replacement for the StrutsLinkTool. of course, on the latter, i suppose you could combine them all and make the https/http option be a matter of tool config rather than tool choice. -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: Ant or Maven (Pick one please)
On Wed, 23 Feb 2005 14:05:12 -0600, Joe Germuska [EMAIL PROTECTED] wrote: At 2:53 PM -0500 2/23/05, Frank W. Zammetti wrote: An unsolicited outside comment... If your intention is to continue to allow the general Struts user community to still be able to build Struts, I would suggest against Maven. Maven strikes me as considerably more complex and intimidating than does Ant, even if that complexity might be justifiable because Maven is more powerful. I think there is a higher barrier to entry with Maven, and Ant is I think a more common and well-understood tool by most developers. If this isn't so much a concern though, i.e., if you intend that for the most part only those interested in actively developing Struts should be building it from source, than by all means go with Maven. It would however be unfortunate if the seemingly simple choice of a build tool discouraged contributions. I'm not saying this would be the case going with Maven, but I *would* be less concerned about this with Ant. Have you used Maven? I understand that it has a lot of features (perhaps too many) and that it can be a bit slow off the mark, but you never have to modify a single file? I have seen few if any Ant-based projects which didn't require at least a bit of tweaking to a local build.properties file; on the other hand, most Maven projects just work if you have Maven installed. I agree that we don't want to hamper usage by the general community; however, I feel that -- specifically with Struts -- we never had a particularly easy to use Ant build. agreed. i remember the first time i tried to get struts building locally. it was a pain to get all the dependencies set up, even though i was familiar with ant. maven may still be unfamiliar to many developers (myself included), but that alone is a poor reason to not use it. once upon a time, ant was unfamiliar to me too. :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Extracting taglibs
You can indeed use Velocity+Tiles: http://jakarta.apache.org/velocity/tools/javadoc/org/apache/velocity/tools/struts/TilesTool.html Also, while ya'll are pulling out the taglibs (hooray!!), i would like to just mention that there are some things in the TagUtils class that are useful to other view technologies like Velocity. in the midst of all this reshuffling, i would suggest at least considering keeping/moving some such things into a more generic ViewUtils type class. of course, i've not been working on Struts projects lately and have forgotten specifically what functions i'm thinking of and haven't time to look into it or offer patches; i just thought i'd put the idea out there. and btw, congrats on all the great work happening w/Struts right now. i'm looking forward to when i've got a chance to play around with some of these things. Nathan Bubna On Tue, 21 Dec 2004 18:29:43 -0800, Don Brown [EMAIL PROTECTED] wrote: It has been discussed, I believe, to separate Tiles from Struts, but no one seemed to know where it would go. jakarta-commons doesn't want taglibs, and for some reason I don't remember, the taglibs project wasn't accepted. It would be kinda funny, though, since Tiles used to be its own project that was assimilated into Struts when Struts was trying to divest iteself of code into commons. I mentioned the separation of Tiles from their taglibs as I thought I heard somewhere of Velocity being able to use Tiles. I could be wrong though. Don Eddie Bush wrote: Actually, I'd tend to agree with that. It makes more sense than separating Tiles and the Tiles taglibs - don't think you'd use the former without the latter. Maybe ... but I don't. On Tue, 21 Dec 2004 20:35:53 -0500, Deadman, Hal [EMAIL PROTECTED] wrote: Haven't look into this much but it would seem better to have a completely separate tiles sub-project that struts core would use. Don't JSF and Spring currently use tiles and have to include struts.jar when all they really want is tiles? -Original Message- From: Don Brown [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 21, 2004 7:51 PM To: Struts Developers List Subject: Extracting taglibs My basic assumption in approaching taglibs extraction into its own subproject is it can reference Struts classes, but Struts classes shouldn't reference it. If that is correct, here are the changes I see happening to extract taglibs: 1. Move o.a.s.taglib out into its own subproject src tree 2. Remove methods in RequestUtils that delegate to TagUtils. They are marked as deprecated anyways and explicitly say they will be removed after 1.2. 3. Move properties in o.a.s.taglib.html.Constants that are referred to in Struts core code into o.a.s.Globals. (cancel and token keys) 4. Move o.a.s.taglib.tiles to o.a.s.tiles.taglib This one I'm not sure about. Should/can tiles be used w/o its jsp taglibs? If not, then it should stay in core w/ tiles. Otherwise, it could be moved out too. That should be it, as far as I can tell. taglibs are already pretty well isolated from the rest of Struts which will make the extraction pretty straightforward. I'd like to get this done before Christmas (25th) if there are no objections. Don - 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: PATCH: html:cancel tag. Made a javascript version for submitting
Michael Rasmussen said: I think I would go the other way with this. In my perfect struts world there would be no struts tags at all. +1 Struts would have no clue as to what you were using as the presentation layer. (JSP, Swing, WML) ... or Velocity :) Put them in jakarta-taglibs and leave struts as a controller. Just my .02 ... or just make the struts taglibs an optional package developed as a struts sub-project. Nathan Bubna [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
