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
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.
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
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,
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
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
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
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
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,
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
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
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?
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
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 ==
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
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
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
17 matches
Mail list logo
