snip/
I guess I have to reiterate what others have said earlier today: how do
you deal with handling or enforcing composition order? I.e. are you
implicitly assuming/requiring that the various elements in the chain are
orthogonal with respect to changes in the input/output stream or
changes in
I think that the just released commons-net 1.0 has taken over from
jakarta-oro.
-Original Message-
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 25, 2003 10:00 AM
To: [EMAIL PROTECTED]
Subject: Dependent Packages in Struts 1.1
snip/
jakarta-oro
red-face victim=me /
-Original Message-
From: Martin Cooper [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 25, 2003 11:01 AM
To: [EMAIL PROTECTED]
Subject: Re: Dependent Packages in Struts 1.1
No. Jakarta ORO is a text processing package that Validator
uses for its regular
For the humor impaired: that is a total Friday comment, and not meant
seriously!
-Original Message-
From: Byrne, Steven
Sent: Friday, February 07, 2003 4:04 PM
To: Struts Developers List
Subject: RE: Bug 16685
I like this -- 10% content lines; 90% self serving sig lines
These kinds of things should definitely be in the roadmap document, both
as a declarative statement of agreement amongst the developers, as well
as an expectation setting mechanism for the rest of the struts
community.
-Original Message-
From: David Graham [mailto:[EMAIL PROTECTED]]
Ted makes a good point, but it's only valid IF people are looking that
closely at the bug list and taking the time to make the proper
inferences about the intentions of the developer team.
Isn't it much better to make those intentions plain by directly stating
them in the roadmap document? Like
Yep -- your guess is correct. I'm surprised that it isn't in the 4.x
spec; I suspect that it was supplanted by an equivalent CSS option. I
*think* it is documented in the HTML 3.2 spec. All browsers I know of
support it. Basically the browser shows the lowsrc image first (or
only) so something
I have to disagree. It's perfectly legitimate for a single checkbox to
have a value that's not one of on, yes or true.
That's legit HTML. Struts currently (seemingly needlessly) prevents
that usage by only having an annointed set of values, and forcing users
to use those. I think Franco is
Whatever the decision, once it's made it should go into the roadmap
document just so there's a record of it
-Original Message-
From: Eddie Bush [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 22, 2002 12:17 PM
To: Struts Developers List
Subject: Re: HTML, XML, XHTML and
of the roadmap so we'd have
something to patch :0)
http://jakarta.apache.org/struts/status.html
-Ted.
10/16/2002 4:42:10 PM, Byrne, Steven [EMAIL PROTECTED] wrote:
Definitely a big part of what 1.1 is all about is
integrating Tiles and
Validator into the main Struts distribution
]
Sent: Thursday, October 17, 2002 11:29 AM
To: Struts Developers List
Subject: Re: Tiles Refactorings for 1.1 compatability
Byrne, Steven wrote:
Here's the draft roadmap that I wrote up.
Struts 1.2 January 2003 [duration: 2 months? ]
* tiles JSTL aware
? What
Oh -- sorry -- that was just a serving suggestion for strut-dev to
kind of indicate what time frame 1.2 might come out in and what the
development duration might be.
Remember, the impetus for doing the roadmap in the first place was about
figuring out the urgency of including some particular
Byrne, Steven wrote:
Here's the draft roadmap that I wrote up.
Struts 1.1
* Servlet 2.2 / JSP 1.1 based
* tiles validator first class citizens
* tiles module aware
* validator module aware
* Struts-el tag lib at contrib status
* [need help here] ??? factored out into jakarta
Sounds like the aye's have it: modules is the term.
-Original Message-
From: Ted Husted [mailto:husted;apache.org]
Sent: Thursday, October 17, 2002 3:14 AM
To: Struts Developers List
Subject: Re: Terminology: modules versus sub-apps
+1 for modules.
If the documentation
Definitely a big part of what 1.1 is all about is integrating Tiles and
Validator into the main Struts distribution. Pulling them back into
pseudo-contrib status would not be a good thing.
Has anyone estimated the level of effort to make each of them be sub-app
aware? I imagine it's
I would think that before Ted or anyone can answer the question of
whether to wait until 1.2, a clear roadmap of near term future releases,
including features and functionality lists for each release, be
published. Right now, saying that it's ok to wait until 1.2 is pretty
much meaningless
I developed a system that handles the need for having multiple
components of a Struts application (Struts, Tiles, Validator, etc)
partitioned in a modular fashion, so that independent groups could work
on their component parts without having to worry about what other groups
were doing, and yet
What are people's feelings about supporting Servlet 2.2 in post 1.1? Is
it time that we can say in 1.2 and beyond that servlet 2.3 is required?
I was thinking about the roadmap, and realizing that while a Struts
version that was JSF aware was probably a ways off, a version with JSTL
I think it would be best if we reserved the term modules for the
future; in almost all respects, the Struts apps that are referenced by
some path off the context root are really little web applications
themselves, hence the term sub apps [I don't care if it has a hyphen
or not] is more
Nothing a simple global search replace couldn't handle, right? I
understand your point. However, this notation hasn't been in use for
very long, and won't be *that* distruptive if it's changed (or even less
so if it's just noted in passing somewhere, although personally I'd
prefer to do the
Well, yeah, you actually might want to make a branch for just that
reason:
CVS gives you the ability to produce diffs between versions. Assuming
Eddie was empowered create such a branch (OT!), then he could check in
his changes to that branch. He, or others (since its a visible branch),
could
Karen,
This the type of question that should be asked on struts-user. The
struts-dev mailing list is for people working on the implementation of
Struts itself.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 03, 2002 12:52 PM
To:
I think the behavior of whether to terminate field level checking on the
first field failure should be controllable. For my company's
application, it is important to show all the failures for a given field,
so the user knows that not only is the field required, but it's a
telephone number field
I think as much as we would like to think that new users trying out
Struts will understand what the term beta means, I believe reality is
that there will be a lot of negative impressions formed by having what's
very likely to be the first webapp that newbies will try out fail on
them. It gives
I think I have discovered a probelm with the recently added validator
DTDs: they seem to allow only a single msg and arg 0-3 element according
to the content model; I think this is not correct.
My understanding is that there can be several msg, and arg[n] elements
which are matched up with the
Take those DTDs with a hefty grain of salt. I think it would be *FAR*
better to derive them by looking at the digester code and the associated
attribute sets. If it would be of help, I can do this by the end of
this week.
Steve
-Original Message-
From: James Holmes [mailto:[EMAIL
26 matches
Mail list logo
