DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14042.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
I have a problem with the deprecated ApplicationConfig class, and still
requiring it in the PlugIn interface.
It is not possible to create a PlugIn implementation without refering to
ApplicationConfig (even when using PlugInPatch, you have to implement
PlugIn). This gives deprecate warnings.
Some
I think it would make sense to put something like this into a
separate WAR.
It might then make sense to have a single convenience download,
along with the option to download each WAR separately
(documentation, exercize, example, gui).
Also, if helped with something like this, we could also
Personally, I'm finding that the user guide format is becoming a
pain to maintain. I'd like to start moving some material out into
their own HOWTO sections, especially anything that includes a
significant amount of code. Some of the sections I was looking at
include
4.2.1 = how to write an
Sounds like there are many benefits to using DynaForms but
is there any downside ?
For instance, not having explicit getters means using a generic
get method that has return type Object. This in turn means
having to use typecasts to cast from Object to some other type
The drawbacks of
The struts-blank.war at SourceForge is the 1.0 version of the
blank application for 1.1. So, the best answer would be blank.war
for 1.1 and the struts-blank.war for 1.0. =:0)
Of course, if you and Erik wanted to work on struts-xdoclet
through the SF site, just send me your SF ids =:0)
-Ted.
The intention was that Struts had to be mentioned on the page on
the other end of the link.
If this page is becoming problematic, and we want to drop the
whole thing, I wouldn't complain. (The day I did it, I said I
would live to regret it =:0)
-Ted.
11/24/2002 10:51:46 PM, David Graham
-Original Message-
From: Ted Husted [mailto:[EMAIL PROTECTED]]
IMHO, the best way to use XML is as a generator/decorator for
objects. One decoration might be to pass a script to a Java class
for processing, but framing conditions in a XML files seems to
step over the line to me.
My personal preference is to remove ApplicationConfig altogether since it
hasn't been in a release but other committers don't feel the same way. I
empathize with your situation but you need to educate your QA people that
they're being rediculous (easier said than done).
David
From:
-Original Message-
From: Nelson, Laird [mailto:[EMAIL PROTECTED]]
-Original Message-
From: Ted Husted [mailto:[EMAIL PROTECTED]]
IMHO, the best way to use XML is as a generator/decorator for
objects. One decoration might be to pass a script to a Java class
for
I think we should post theses rules on the consultants page:
1. This is for corporations only, not individual's resumes.
2. Struts must be mentioned on the page being linked to.
What do you think?
David
From: Ted Husted [EMAIL PROTECTED]
Reply-To: Struts Developers List [EMAIL
+1
I would think that anyone advertising themselves as a consultant would (at the
least) be in a position to accept 1099 gigs, and would therefore (but not
always) be Incorporated.
Also, I'm +1 for making everyone upload a picture of themselves chuggin on a
Jakarta-Struts beer ;)
--
James
Very interesting.
Since these appear to be 'competing technologies' I see you have chosen
Struts over barracuda. There was a long comparison on the enhydra site
which paints XMLC in a good light, but without a detailed investingation
doesn't mean much.
My questions are:
1) Are the
Acknowledged. I've finished writing what I was going to put into the
user guide, but I'll move that to a howto section and replace it with
a short paragraph in both the Model and View sections in the user
guide which will just refer to the howto section.
-Original Message-
From: Ted
Let me just emphasize the downsides that I mentioned already... using
DynaForms would mean that I would be hand-coding struts-config.xml and
validation.xml. By writing a ValidatorActionForm Java class for all my
forms I have to do neither now, and XDoclet is automatically generating
these
Can you create a small sample application to demonstrate how easy it is?
Create a project from the struts-example to do this.
I've done this a few times with other issues/concepts (jsp under web-inf, bundle
from the database, etc).
I'll host the download if you want, or we can get into the
Yup, no problem. In fact, its been my plan all along to get this
example posted online. The folks that have attended the Complete
Programmer symposiums where I've spoken and also the folks that attended
my ApacheCon presentation already have access to it (or could e-mail me
to get it). I've
On Mon, 25 Nov 2002, Andrew Hill wrote:
A DOM based rendering methodology might be more appropriate for this sort of
thing.
Those interested in DOM-based rendering, which you can then run through an
appropriate XSLT processing pipeline, should also take a look at STXX:
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14829.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
I thought I'd run this idea by the development team before entering it
into Bugzilla.
One of the items that is required with 508 compliance is a label value
for each form element:
For example:
label for=nameName:/label
input type=text id=name size=50 name=name /
More information at:
Just a question, who is Erik ? ;)
--- Ted Husted [EMAIL PROTECTED] a écrit : The struts-blank.war at SourceForge is
the 1.0
version of the
blank application for 1.1. So, the best answer would be blank.war
for 1.1 and the struts-blank.war for 1.0. =:0)
Of course, if you and Erik wanted
I think it's great to use label elements but I wouldn't use what you
proposed. My labels are typically in a separate table cell than the input
field and the tag wouldn't handle that. If we did add this support I would
be in favor of the labelKey attribute but not the label attribute. We
It would be good to provide some sort of automated support for this
component, but I don't see how we can possibly assume where the label
component will be placed. Yes, it could be used for prototypes, but I'd
rather not build a framework that people use to build throwaway code.
The annoying
Emmanuel Boudrant wrote:
Just a question, who is Erik ? ;)
I guess Ted is referring to me :)
Erik
http://erik.hatcher.net
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Oh yes ;)
So it's about Struts tools, how can we package a set of Struts tools for Java/XML
generation
(Struts-XDoclet, EasyStruts, Console).
Perhaps we need to create an API based on struts configuration classes
(org.apache.struts.config.*) for writing Struts XML/JSP/Java files. This API can be
XDoclet already ships with builtin struts-config.xml generation,
validatio.xml generation, and Struts form bean generation (from entity
beans, and maybe for value objects?).
I'm not sure what is needed to make the presentation of this stuff
better, but its all there for the taking and works
On Mon, 25 Nov 2002, Erik Hatcher wrote:
Date: Mon, 25 Nov 2002 14:11:12 -0500
From: Erik Hatcher [EMAIL PROTECTED]
Reply-To: Struts Developers List [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Subject: Re: blank.war vs. struts-blank.war [was: Re: Tools in Struts]
-Original Message-
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
I think a way to create label elements would be very useful. I just
don't think we should embed it in the existing UI element
tags (for the
reasons that others have articulated.
(I thought you tied labels
I don't see what advantage the html:label tag has over hand coding the
html. Looks like the same amount of work to me.
David
From: Craig R. McClanahan [EMAIL PROTECTED]
Reply-To: Struts Developers List [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Subject: Re: Enhancement
I agree, and does require more work, considering:
html:label for=name
bean:message key=prompt.username/
/html:label
Is more typing than:
label for=name
...
/label
Maybe something like this would make it more useful:
html:label key=prompt.username /
I was thinking of reducing the
Well for whatever worth this comment may have...
I think the last logo with the beer is the best
of the logos on the page
I've enjoyed the fact that when searching
monster and other it-job sites for struts
I'm presented with jobs requiring Auto Shop struts
experience.
Perhaps a logo that
Yes, it would create more confusion. It's better to present a consistent
view of the taglibs to users instead of using various non-standard names.
David
From: Matt Raible [EMAIL PROTECTED]
Reply-To: Struts Developers List [EMAIL PROTECTED]
To: 'Struts Developers List' [EMAIL PROTECTED]
Personally, I don't think we want to put ourselves into a position
where we have to start carding requests to be put on a link
page. If it's not a rule that a robot can enforce (like a link to
the Struts home page), then I would suggest that we just drop the
page entirely.
After all,
This may not have any effect on the implementation, but also note that
another legal form of the label component is to NOT specify a for
attribute, but assume that the nested content is the component the label
is for.
It looks like the only way adding this tag could be of any benefit is if
we
For the record, I'm with David. A beta is a beta. Any application
advanced enough to be using ApplicationConfig directly is advanced
enough to do a little renaming when moving from b2 to b3.
I support the commitment to provide backward compatability between
releases; but, IMHO, backward
This is eerily similar to my custom:label key=.../ tag which
generates field labels, along with an asterisk if its a required field
and a different style (currently red) if the field is in error.
This will be part of the app I post up this week too.
Erik
Matt Raible wrote:
I agree, and does
I suggested a previous logo back in July but there wasn't any feedback,
every body must have been on vacation.
Take a look at the original post it contains some very interesting links
to the types of the logo's I had in mind.
http://marc.theaimsgroup.com/?l=struts-userm=102779133515796w=3
-Rob
On Mon, 25 Nov 2002, David Graham wrote:
Date: Mon, 25 Nov 2002 12:25:29 -0700
From: David Graham [EMAIL PROTECTED]
Reply-To: Struts Developers List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: Enhancement Request - add label and labelKey to form elements
I don't see what
On Mon, 25 Nov 2002, Matt Raible wrote:
Date: Mon, 25 Nov 2002 12:40:27 -0700
From: Matt Raible [EMAIL PROTECTED]
Reply-To: Struts Developers List [EMAIL PROTECTED]
To: 'Struts Developers List' [EMAIL PROTECTED]
Subject: RE: Enhancement Request - add label and labelKey to form elements
I
On Mon, 25 Nov 2002, Ted Husted wrote:
Date: Mon, 25 Nov 2002 16:49:31 -0500
From: Ted Husted [EMAIL PROTECTED]
Reply-To: Struts Developers List [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Subject: Re: PlugIn, ApplicationConfig and Deprecated
For the record, I'm with
rleland 2002/11/25 18:33:07
Modified:src/share/org/apache/struts/action ActionServlet.java
PlugIn.java
src/share/org/apache/struts/tiles TilesPlugin.java
src/share/org/apache/struts/validator ValidatorPlugIn.java
Removed:
rleland 2002/11/25 18:37:40
Modified:src/share/org/apache/struts/tiles TilesPlugin.java
src/share/org/apache/struts/validator ValidatorPlugIn.java
Log:
Remoce PlugInPatch references.
Revision ChangesPath
1.13 +4 -5
rleland 2002/11/25 18:44:15
Modified:src/example/org/apache/struts/webapp/example/memory
MemoryDatabasePlugIn.java
Log:
Update example to use ModuleConfig
Revision ChangesPath
1.5 +7 -12
Craig R. McClanahan wrote:
Since we went to all the effort to change ApplicationConfig to
ModuleConfig in the first place, we should complete the task and banish it
from any non-deprecated APIs that we have. This whole change did make me
pretty squeamish :-), but a half-completed change
That being said, the JSTL libraries went pretty much towards
this approach (single-character prefixes where feasible), and
I'm currently leaning that way on JavaServer Faces as well.
IT makes sense to consider this.
So are you saying that I should go ahead and use this single-digit
As soon as you start using the single character prefix, we'll start getting
questions like, Is the h taglib the same as the html taglib?. If Struts
goes to single character prefixes, then you should too but I really don't
want to confuse new people with this. It's not rocket science but I
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14752.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
dgraham 2002/11/25 22:21:44
Modified:doc/resources consultants.xml
Log:
Added Openwide to consultants listing.
Revision ChangesPath
1.11 +1 -0 jakarta-struts/doc/resources/consultants.xml
Index: consultants.xml
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14829.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14730.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14693.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
51 matches
Mail list logo
