[S2] Mess with WW-1942
Hi all! I closed the WW-1942 because the remaining failing test case was not related to Java 6 and/or Windows, so I closed it and opened a new one. https://issues.apache.org/struts/browse/WW-2291 I have to apologize Don (Brown) since I closed this issue, and I assigned him the new issue, but it was the only way to clean the ambiguity in the description of the issue and the real facts. Sorry Don! Ciao Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Pre-Assigning Tickets (was Re: [S2] Mess with WW-1942)
As a rule, I would suggest that we avoid assigning tickets to ourselves or to each other, or even to ourselves, until we have actually, that minute, started work on the ticket. In an open volunteer environment, pre-assigning tickets undermines volunteerism and and promotes bottlenecking. Pre-assigning tickets undermines volunteerism in two ways. First, it discourages other volunteers from stepping up and working on the ticket themselves. Second, it implies that the volunteer is not a volunteer, but is now compelled to work on this ticket. Unfortunately, we all have competing responsibilities to which the ASF takes a back seat, and it's hard to guarantee when we will be able to do something, if we are not doing it right now. The volunteerism problems then tend to create a bottleneck. Other people shy away because it's been pre-assigned, and, often, the pre-assignee can't work on it now because of competing responsibilities. A key concept is that everyone on the PMC is jointly and severally responsible for the code. We are all entitled, and encourged, to work on any aspect of the codebase. We don't use the maintainer module, and if one us can't work on something, then another one of us should step up and take care of business. -Ted. On Nov 4, 2007 6:01 AM, Antonio Petrelli [EMAIL PROTECTED] wrote: Hi all! I closed the WW-1942 because the remaining failing test case was not related to Java 6 and/or Windows, so I closed it and opened a new one. https://issues.apache.org/struts/browse/WW-2291 I have to apologize Don (Brown) since I closed this issue, and I assigned him the new issue, but it was the only way to clean the ambiguity in the description of the issue and the real facts. Sorry Don! Ciao Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- HTH, Ted http://www.husted.com/ted/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Pre-Assigning Tickets (was Re: [S2] Mess with WW-1942)
2007/11/4, Ted Husted [EMAIL PROTECTED]: As a rule, I would suggest that we avoid assigning tickets to ourselves or to each other, or even to ourselves, until we have actually, that minute, started work on the ticket. In an open volunteer environment, pre-assigning tickets undermines volunteerism and and promotes bottlenecking. Pre-assigning tickets undermines volunteerism in two ways. First, it discourages other volunteers from stepping up and working on the ticket themselves. Second, it implies that the volunteer is not a volunteer, but is now compelled to work on this ticket. Unfortunately, we all have competing responsibilities to which the ASF takes a back seat, and it's hard to guarantee when we will be able to do something, if we are not doing it right now. The volunteerism problems then tend to create a bottleneck. Other people shy away because it's been pre-assigned, and, often, the pre-assignee can't work on it now because of competing responsibilities. A key concept is that everyone on the PMC is jointly and severally responsible for the code. We are all entitled, and encourged, to work on any aspect of the codebase. We don't use the maintainer module, and if one us can't work on something, then another one of us should step up and take care of business. Ted, I didn't want to pre-assign tickets to anyone, only assign the ticket to Don, who was assigned in the previous ticket. Anyway I noticed that Don took the previous ticket a long ago (24 May), so now I remove the assignment. Sorry Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Messing around with parameters
On Nov 1, 2007 4:10 PM, Brian Pontarelli [EMAIL PROTECTED] wrote: s:hidden name=[EMAIL PROTECTED] value=EUR/ s:textfield key=child.allowance/ c:hidden name=[EMAIL PROTECTED] value=MM/dd// s:textfield key=subscription.expireDate/ Is the use case that these facts are embedded in the page, but not known to the server-side system? So, since the Action doesn't already know the format is MM/dd/, it needs to be told? True to some degree. You still have the issue that some of the parameters don't map to properties of the JavaBean. If you did this: s:hidden name=user.allowance.currencyCode value=USD/ s:textfield key=user.allowance.amount/ You would need to specify that the currencyCode should be excluded, If all this is going to be placed into a map of attributes anyway, could we just have a map of attributes? c:hidden name=attributes[subscription_expireDate_format] value=MM/dd// s:textfield key=subscription.expireDate/ I don't know if this is the right syntax or not, or even if we have a syntax for adding entries to a map property. If we don't, then I'm thinking that we should solve that general use case, which should address this specific use case. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[S2] Message Resources ExpressionConfigurationSupport
I'm looking at https://issues.apache.org/struts/browse/WW-809 which would let us load message resources by designating a package with a wildcard character, like this * webwork.custom.i18n.resources=ApplicationResources, actions/* in which case all the .properties files in the actions package would be added to the configuration. One aspect of this idea is that it might let us multiple resource files, even when there is not a corresponding Action. The lack of an Action came up in the extended CodeBehind thread, since we might have a page that doesn't have it's own Action. There are other features to the patch, like optional recursion support (which might also play nice with CodeBehind). My questions are * Does this sound like a good idea to everyone? * Is this a XWork level patch or something we should apply here? * If we apply it here, is it big enough for a CLA? -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[S2] Taglib Exercises Appilcation and ShowCase Expectations
Following up on https://issues.apache.org/struts/browse/WW-771, and dealing with Tag QA generally, I wonder if we should have a taglib exercises application that provides a simple visual test suite against the tags, as we do for Struts 1. My concern is that it would start to overlap with what we are doing with the ShowCase. Which begs the question: What are we doing with the ShowCase? I'm not sure if it is suppose to be a Demo, a Cookbook, a set of Test Cases, or all of the above. Right now it is definitely all of the above, but is that what we want it to be? And if it is what we want to it be, do we want to separate it into different segments to clarify what each case is suppose to be doing? In any event, I would like to start a new ShowCase instance for 2.1 and port everything over, case-by-case, making sure each case meets our expectations. But the first question would be: What are our expectations? -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Taglib Exercises Appilcation and ShowCase Expectations
The junit tests actually have a pretty good set of functional, black box tests for the tags, although there are holes. Therefore, I don't think showing every single tag for the purposes of testing is necessary. Kudos for taking up showcase cleanup banner. Don On 11/4/07, Ted Husted [EMAIL PROTECTED] wrote: Following up on https://issues.apache.org/struts/browse/WW-771, and dealing with Tag QA generally, I wonder if we should have a taglib exercises application that provides a simple visual test suite against the tags, as we do for Struts 1. My concern is that it would start to overlap with what we are doing with the ShowCase. Which begs the question: What are we doing with the ShowCase? I'm not sure if it is suppose to be a Demo, a Cookbook, a set of Test Cases, or all of the above. Right now it is definitely all of the above, but is that what we want it to be? And if it is what we want to it be, do we want to separate it into different segments to clarify what each case is suppose to be doing? In any event, I would like to start a new ShowCase instance for 2.1 and port everything over, case-by-case, making sure each case meets our expectations. But the first question would be: What are our expectations? -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] Taglib Exercises Appilcation and ShowCase Expectations
Except that I'd have to learn to write them :) On Nov 4, 2007 7:51 AM, Don Brown [EMAIL PROTECTED] wrote: The junit tests actually have a pretty good set of functional, black box tests for the tags, although there are holes. Therefore, I don't think showing every single tag for the purposes of testing is necessary. Kudos for taking up showcase cleanup banner. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Taglib Exercises Appilcation and ShowCase Expectations
I'm not sure it is practical for a junit test to test all the variations of the tags. Just setting up the expected output would be very tedious. I like the idea of having a taglib showcase to test all the tags--I looked at showcase the other day to see if it had this and it didn't. Also, being able to switch themes on the fly would be a good thing. Even in a taglib showcase, we couldn't possibly test every single tag variation, however, it would be a nice sanity check above the level of test case to verify we didn't totally mess something up. (That's always my fear with the ftl templates) Ted Husted wrote: Except that I'd have to learn to write them :) On Nov 4, 2007 7:51 AM, Don Brown [EMAIL PROTECTED] wrote: The junit tests actually have a pretty good set of functional, black box tests for the tags, although there are holes. Therefore, I don't think showing every single tag for the purposes of testing is necessary. Kudos for taking up showcase cleanup banner. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[s2] Roadmap for the core taglib
Speaking of the core taglib, what ARE we going to do with it. There's been talk of moving them to a separate plugin, reimplementing them in a java, etc. It would be nice to know from a roadmap prespective about where the core taglib is headed--I have several plugins that would be affected by it. At a minimum, if we're going to keep the ftl template at all, then I would recommend we bring in tabletags. (At least the paging and sorting tags) Looking at the downloads page for tabletags, there have been over 7000 downloads over the last year. That seems significant to me. The table tag itself probably needs a little TLC at the moment, but I think the other tags are pretty solid. I'm also open to looking at other tags that should be brought in--again this is contingent on what we decide to do with them pesky tags. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Roadmap for the core taglib
On Nov 4, 2007 9:33 AM, Tom Schneider [EMAIL PROTECTED] wrote: Speaking of the core taglib, what ARE we going to do with it. There's been talk of moving them to a separate plugin, reimplementing them in a java, etc. It would be nice to know from a roadmap prespective about where the core taglib is headed--I have several plugins that would be affected by it. My understanding is that we would like to move the existing tags to a plugin, and create a standard bundle that would include the tag-plugin, the code-behind plugin, and the core as a single JAR. The code-behind plugin will subsume the zero-config and annotations code, as well as the SmartURls plugin. * [s2] Should tags be their own plugin? * [S2] Plugins gone wild! One place to document decisions like this is the STATUS.txt file under SVN. * http://svn.apache.org/viewvc/struts/current/STATUS.txt?view=markup In terms of the longer-term roadmap, work is being done on a JSP 2 taglib that won't use the templating system at all. Don's also been doing some preliminary refactoring in XWork so that the expression language can be made pluggable, meaning we would also be able to plugin something else instead of OGNL. -Ted. At a minimum, if we're going to keep the ftl template at all, then I would recommend we bring in tabletags. (At least the paging and sorting tags) Looking at the downloads page for tabletags, there have been over 7000 downloads over the last year. That seems significant to me. The table tag itself probably needs a little TLC at the moment, but I think the other tags are pretty solid. I'm also open to looking at other tags that should be brought in--again this is contingent on what we decide to do with them pesky tags. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- HTH, Ted http://www.husted.com/ted/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Roadmap for the core taglib
Ted Husted wrote: Don's also been doing some preliminary refactoring in XWork so that the expression language can be made pluggable, meaning we would also be able to plugin something else instead of OGNL. -Ted. You mean like JUEL? http://cwiki.apache.org/confluence/display/S2PLUGINS/JUEL+plugin :) Thanks for the info Ted, that helps me out. So looking down the road we might have: xml configuration or codebehind; new java taglib or current templating taglib; freemarker, velocity or JSP; OGNL, MVEL, or JUEL. I'm all for choice, but trying to support all those combinations might be challenging. I can just imagine the posts on the user list: Um.. I'm using Struts 2 with the code behind and rest plugin and the java taglib in velocity with MVEL and my page doesn't display I'm not saying we shouldn't persue these endeavors, but I think it's helpful to consider things from a new user perspective and decide if we're going to support every combination of technology. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[s2] JUEL plugin (was Roadmap for the core taglib)
Whoa, where did that one come from? I was just begging for such a plugin yesterday on #struts from Richard Burton, who is working on an MVEL one. I could see Struts 3 == new taglib + JUEL + robust rest and codebehind. As for the problem of so many combinations of plugins, I'm all for the proliferation of plugins, but do think we need to not ship with two plugins that solve the same problem. For example, it would be confusing to ship with two codebehind plugins or two expression language plugins, especially since the latter could require its own taglib. The distribution we ship as official Struts 2 should stay coherent and focused. Don On 11/5/07, Tom Schneider [EMAIL PROTECTED] wrote: Ted Husted wrote: Don's also been doing some preliminary refactoring in XWork so that the expression language can be made pluggable, meaning we would also be able to plugin something else instead of OGNL. -Ted. You mean like JUEL? http://cwiki.apache.org/confluence/display/S2PLUGINS/JUEL+plugin :) Thanks for the info Ted, that helps me out. So looking down the road we might have: xml configuration or codebehind; new java taglib or current templating taglib; freemarker, velocity or JSP; OGNL, MVEL, or JUEL. I'm all for choice, but trying to support all those combinations might be challenging. I can just imagine the posts on the user list: Um.. I'm using Struts 2 with the code behind and rest plugin and the java taglib in velocity with MVEL and my page doesn't display I'm not saying we shouldn't persue these endeavors, but I think it's helpful to consider things from a new user perspective and decide if we're going to support every combination of technology. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] JUEL plugin (was Roadmap for the core taglib)
Isn't that what Ted wanted? A new plug-in a day for 60 days. :) I have one lined up for tomorrow. Tom Don Brown wrote: Whoa, where did that one come from? I was just begging for such a plugin yesterday on #struts from Richard Burton, who is working on an MVEL one. I could see Struts 3 == new taglib + JUEL + robust rest and codebehind. As for the problem of so many combinations of plugins, I'm all for the proliferation of plugins, but do think we need to not ship with two plugins that solve the same problem. For example, it would be confusing to ship with two codebehind plugins or two expression language plugins, especially since the latter could require its own taglib. The distribution we ship as official Struts 2 should stay coherent and focused. Do - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Roadmap for the core taglib
The key point is that we don't have to demonstrate all the flexibility in the examples that we post at the site. People who don't know what choices to make, will look at our examples, and just follow those. As to the examples we post, I would like to pick a stack that we can all support, and use it to write best practices examples. For example, I'm not a fan of JSP, but I do agree that we should use JSP, because that's what everyone understands and can at least maintain. And, if when we post FreeMarker or Velocity examples, we should label them as alternatives. (Even though I personally prefer Velocity.) And now that we have the JPA, I would also like to use it to power the MailReader, and other examples, and maybe work on some Eclipse tools to make it all quite painless. Right now, everyone knows that JPA/Hibernate, Spring, and Struts/JSP is the defacto industry standard stack, and that's what we should use in our examples. As to the rest of it, there's a saying in ASF circles: Let Darwin Decide. No one here is compelled to support anything. If no one knows the answer to a question, then the question doesn't get answered. Likewise, if something doesn't work as well as it might, and no one submits a patch, it doesn't get maintained. In the end, what gets supported and maintained will be a function of what each volunteer chooses to support and maintain. It's also important to recognize that the flexibility is being born out of actual need. OGNL is scary, and the templating system is ongoing source of performance complaints. If we were making decisions based on support effort, then these are the first two things that should go. -Ted. On Nov 4, 2007 3:02 PM, Tom Schneider [EMAIL PROTECTED] wrote: Ted Husted wrote: Don's also been doing some preliminary refactoring in XWork so that the expression language can be made pluggable, meaning we would also be able to plugin something else instead of OGNL. -Ted. You mean like JUEL? http://cwiki.apache.org/confluence/display/S2PLUGINS/JUEL+plugin :) Thanks for the info Ted, that helps me out. So looking down the road we might have: xml configuration or codebehind; new java taglib or current templating taglib; freemarker, velocity or JSP; OGNL, MVEL, or JUEL. I'm all for choice, but trying to support all those combinations might be challenging. I can just imagine the posts on the user list: Um.. I'm using Struts 2 with the code behind and rest plugin and the java taglib in velocity with MVEL and my page doesn't display I'm not saying we shouldn't persue these endeavors, but I think it's helpful to consider things from a new user perspective and decide if we're going to support every combination of technology. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Roadmap for the core taglib
Even though I argued for it initially, I'm still not 100% sure we want to pull out the tags. Not only is it more confusing to users, but it makes tag extension harder, since plugins can't provide plugin points to other plugins. That means we'd have to keep the majority of the tag infrastructure in core, which gains us little, IMO. One reason to pull them out is it better facilitates new EL's. With how the tags work right now, they depend on the OGNL EL from a syntax perspective mostly as the API dependency has been abstracted. If you created a JUEL plugin, for example, you'd probably want to rewrite most of the tags to better take advantage of deferred expressions. Anyways, I'm not saying there aren't solutions, just that we need to think about it some more. At this point, I'm not sure the potential cost outweights the benefits. Don On 11/5/07, Ted Husted [EMAIL PROTECTED] wrote: On Nov 4, 2007 9:33 AM, Tom Schneider [EMAIL PROTECTED] wrote: Speaking of the core taglib, what ARE we going to do with it. There's been talk of moving them to a separate plugin, reimplementing them in a java, etc. It would be nice to know from a roadmap prespective about where the core taglib is headed--I have several plugins that would be affected by it. My understanding is that we would like to move the existing tags to a plugin, and create a standard bundle that would include the tag-plugin, the code-behind plugin, and the core as a single JAR. The code-behind plugin will subsume the zero-config and annotations code, as well as the SmartURls plugin. * [s2] Should tags be their own plugin? * [S2] Plugins gone wild! One place to document decisions like this is the STATUS.txt file under SVN. * http://svn.apache.org/viewvc/struts/current/STATUS.txt?view=markup In terms of the longer-term roadmap, work is being done on a JSP 2 taglib that won't use the templating system at all. Don's also been doing some preliminary refactoring in XWork so that the expression language can be made pluggable, meaning we would also be able to plugin something else instead of OGNL. -Ted. At a minimum, if we're going to keep the ftl template at all, then I would recommend we bring in tabletags. (At least the paging and sorting tags) Looking at the downloads page for tabletags, there have been over 7000 downloads over the last year. That seems significant to me. The table tag itself probably needs a little TLC at the moment, but I think the other tags are pretty solid. I'm also open to looking at other tags that should be brought in--again this is contingent on what we decide to do with them pesky tags. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- HTH, Ted http://www.husted.com/ted/blog/ - 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] JUEL plugin (was Roadmap for the core taglib)
On Nov 4, 2007 2:58 PM, Don Brown [EMAIL PROTECTED] wrote: As for the problem of so many combinations of plugins, I'm all for the proliferation of plugins, but do think we need to not ship with two plugins that solve the same problem. I believe Struts already ships multiple plugins that solve the same problem. The View and the File Upload problems each have multiple plugins. I think the whole point is choice, and I don't see any problem with shipping that choice as part of Struts. Ted has also championed a one-stop, getting started file that would contain a single solution to each of the problems (with the exception of the view), which I think takes care of the problem of confusing new users. But that's just one, non-committer's, opinion. (*Chris*) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
