martinc 01/11/01 21:31:58
Modified:doc installation-1.0.xml installation.xml
Added: doc installation-jetty.xml
Log:
- Added installation instructions for Jetty.
- Corrected taglib references from struts-form to struts-html.
- Miscellaneous corrections to the
+ p
+For every lt;form-beangt; tag in your
codestruts-config.xml/code
+file, you must have a corresponding Java class. The same
holds true for
+each lt;action-mappinggt; tag.
+ /p
+
Is this accurate? What something like:
action
Are 3702 and 3828 resolved now?
Or are they being held open pending the unit test?
[EMAIL PROTECTED] wrote:
mschachter01/10/11 09:28:17
Modified:src/share/org/apache/struts/upload
BufferedMultipartInputStream.java
cedric 01/11/02 02:45:30
Modified:doc struts-template.xml
Log:
Update put documentation : put can have a body as content
Revision ChangesPath
1.3 +3 -0 jakarta-struts/doc/struts-template.xml
Index: struts-template.xml
I think this is a great idea. That would make Struts much more easily
extensible and you wouldn't even really have to look at the Struts code
much to extend it. Perhaps it could be done such that services could be
registered to be invoked at certain points during the process method,
say before
Hello Bill,
Take a look to the contrib directory in struts project. It contains
ServiceManager subproject. Half year ago I start to work under it,
prepare initial version and post it to the community. Last month I try
to refactor my old code, and improve core functions.
I am ready to listen all
Take a look at how Barracuda event handling works. I think it allows most
of this type of handling to be done quite elegantly. The web site is
http://barracuda.enhydra.org
The code is open source, and could be used either directly, or as a library
if the licenses are compatible. Otherwise, it
cedric 01/11/02 08:50:05
Modified:contrib/tiles/src/share/org/apache/struts/tiles/xmlDefinition
XmlAttribute.java
contrib/tiles/web/doc/WEB-INF tutorialDefinitions.xml
struts-config.xml
Right now, some of these things are being addressed by two initiatives.
This is not to say these are the only possible solutions, simply what
people have already started. I personally think both solutions are quite
good, and any help anyone can offer would be appreciated.
First, there is Oleg's
Andrej Sobkowski wrote:
- The form bean itself is a special data holder and shouldn't be aware of
how its data is validated. Do you agree?
I'm not sure that I do. I like to think of the ActionForm as a firewall.
If it has passes the intial validation, then I know it is safe to use,
and can
Ted,
thanks for your answer.
I understand your idea of initial validation. And I also agree with
Generally, objects should have dominion over their own data. But in the
case of the validation process, IMHO the bean is the data used by a
potentially external validation process (and not
Hi. Wanting to change the descriptions for the indexed tags in the docs to make
things a little clearer. Propose the following:
for tags which inherit from BaseInputTag:
Valid only inside of logic:iterate tag.
If true, the name of the html tag will be
Unsubsribe me!!
-Original Message-
From: David Winterfeldt [mailto:[EMAIL PROTECTED]]
Sent: Friday, November 02, 2001 2:17 PM
To: Struts Developers List
Subject: RE: Validator design considerations
--- Sobkowski, Andrej [EMAIL PROTECTED]
wrote:
Ted,
thanks for your answer.
I
read the bottom of your email!
Gujral, Irvind [EMAIL PROTECTED] on 11/02/2001
03:23:50 PM
Please respond to Struts Developers List
[EMAIL PROTECTED]
To: 'Struts Developers List'
[EMAIL PROTECTED]
cc:(bcc: David Hay/Lex/Lexmark)
Subject: Unsubscribe me
Unsubsribe
The problem of getting the validation information is really a problem of
where one gets meta-data from. Some meta-data depends on context, and some
is fixed, and that is really the indicator for where it should be put.
Another piece of meta-data is the human readable title for the attribute.
Sobkowski, Andrej wrote:
What if the
validation on the same bean is different depending on the app context? It
wouldn't be clean (for lack of better word) to consider both validations
inside the bean itself (validate())... hence the advantage of having
separate validation processes on the
I actually built out a very similar framework back in my ATG days.
Greate minds stink alike
Not so sure how much logic you want to put into the XML. I would rather
have Form validators that have access to a slew of page validation rules.
One possiblity is
MyFormValidator extends
Event handling has come up several times, but no one's put any code on
the table yet :-(
If we were ever to do anything about event handling, or generic
validators, I'd love to see something that was compatible with
Barracuda. They are doing some nice work over there.
Meanwhile, the workflow
Group,
I have read these comments on validators with interest. Experience
tells me that most (99.9%+) validations can be performed with a
validator, an error id, the value, and the value's container. Of course
the container could be a struts form, but it would be nice if it could
be a
Ya know, you're right. When I read the original proposed change, it seemed
to make sense, but I guess I was thinking only of the common case where the
'type' attribute is used. It's not true when either 'forward' or 'include'
are used.
Now that I think about it, technically, the previous
20 matches
Mail list logo
