DO NOT REPLY [Bug 4095] New: - html:select should take default value from the property.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4095

html:select should take default value from the property.

   Summary: html:select should take default value from the property.
   Product: Struts
   Version: 1.0 Final
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Custom Tags
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


If the 'value' attribute of a select tag is not set, but the 'property' is, then
the 'value' should default to the current value of the property. In other words
the default option should be the current value of the associated property,
unless an alternate value is specified.

Re: [PROPOSAL] XMLMessageResources

[James Holmes]

Looks good.  In fact I myself had an interest in
writing just this functionality and have just been too
busy with the Console to take on any "Core"
development work.

-james


--- [EMAIL PROTECTED] wrote:
> The Struts 1.1 TODO list contains the following
> item:
> 
> "XmlMessageResources. Implementation of
> MessageResources and
> MessageResourcesFactory that loads message keys and
> strings from one or more
> XML resources or files."
> 
> I have an implementation of this which I would like
> to contribute to Struts.
> The implementation is a drop-in replacement for the
> existing
> PropertyMessageResources. In fact, it is derived
> from it, and so shares the
> same file naming scheme for locale-specific
> messages.
> 
> Here's a simple example of what an XML message file
> would look like:
> 
> -- begin example --
> 
> 
> 
>   You
> must enter a
> username
>   You
> must enter a
> password
>key="validation.password.match">Confirmation
> password does not
> match
> 
> -- end example --
> 
> The first line of the example provides a hint as to
> why I did not attempt to
> incorporate messages for more than one locale into a
> single XML file.
> Messages for different locales may well be specified
> using different
> character encodings. In addition, maintaining the
> messages from each locale
> in a different XML file avoids loading locales
> unnecessarily.
> 
> To use this implementation, all that is required is
> to specify the 'factory'
> init-param in your web.xml file, and to make sure
> that the 'application'
> init-param refers to an XML resource.
> 
> What do people think about incorporating this into
> the Struts 1.1 code base?
> 
> --
> Martin Cooper
> 
> 
> 
> 


__
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com

SV: [PROPOSAL] XMLMessageResources

[Mikkel Bruun]

I agree, looks like a usuable feature...

:: 
  Mikkel Bruun
  Senior IT Developer
  [EMAIL PROTECTED]
  Direct: +45 32 88 22 73

  Valtech A/S
  Kanonbaadsvej 10
  DK-1437 Copenhagen
  Tel  +45 32 88 20 00
  Fax +45 32 88 20 20



> -Oprindelig meddelelse-
> Fra: James Holmes [mailto:[EMAIL PROTECTED]]
> Sendt: 11 October 2001 12:47
> Til: [EMAIL PROTECTED]
> Emne: Re: [PROPOSAL] XMLMessageResources
> 
> 
> Looks good.  In fact I myself had an interest in
> writing just this functionality and have just been too
> busy with the Console to take on any "Core"
> development work.
> 
> -james
> 
> 
> --- [EMAIL PROTECTED] wrote:
> > The Struts 1.1 TODO list contains the following
> > item:
> > 
> > "XmlMessageResources. Implementation of
> > MessageResources and
> > MessageResourcesFactory that loads message keys and
> > strings from one or more
> > XML resources or files."
> > 
> > I have an implementation of this which I would like
> > to contribute to Struts.
> > The implementation is a drop-in replacement for the
> > existing
> > PropertyMessageResources. In fact, it is derived
> > from it, and so shares the
> > same file naming scheme for locale-specific
> > messages.
> > 
> > Here's a simple example of what an XML message file
> > would look like:
> > 
> > -- begin example --
> > 
> > 
> > 
> >   You
> > must enter a
> > username
> >   You
> > must enter a
> > password
> >> key="validation.password.match">Confirmation
> > password does not
> > match
> > 
> > -- end example --
> > 
> > The first line of the example provides a hint as to
> > why I did not attempt to
> > incorporate messages for more than one locale into a
> > single XML file.
> > Messages for different locales may well be specified
> > using different
> > character encodings. In addition, maintaining the
> > messages from each locale
> > in a different XML file avoids loading locales
> > unnecessarily.
> > 
> > To use this implementation, all that is required is
> > to specify the 'factory'
> > init-param in your web.xml file, and to make sure
> > that the 'application'
> > init-param refers to an XML resource.
> > 
> > What do people think about incorporating this into
> > the Struts 1.1 code base?
> > 
> > --
> > Martin Cooper
> > 
> > 
> > 
> > 
> 
> 
> __
> Do You Yahoo!?
> Make a great connection at Yahoo! Personals.
> http://personals.yahoo.com
> 

RE: [PROPOSAL] XMLMessageResources

[Young, Wayne]

Title: RE: [PROPOSAL] XMLMessageResources





What are some benefits of using XMLMessageResources over standard property files?


Wayne Young




-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 11, 2001 1:08 AM
To: [EMAIL PROTECTED]
Subject: [PROPOSAL] XMLMessageResources



The Struts 1.1 TODO list contains the following item:


"XmlMessageResources. Implementation of MessageResources and
MessageResourcesFactory that loads message keys and strings from one or more
XML resources or files."


I have an implementation of this which I would like to contribute to Struts.
The implementation is a drop-in replacement for the existing
PropertyMessageResources. In fact, it is derived from it, and so shares the
same file naming scheme for locale-specific messages.


Here's a simple example of what an XML message file would look like:


-- begin example --




  You must enter a
username
  You must enter a
password
  Confirmation password does not
match

-- end example --


The first line of the example provides a hint as to why I did not attempt to
incorporate messages for more than one locale into a single XML file.
Messages for different locales may well be specified using different
character encodings. In addition, maintaining the messages from each locale
in a different XML file avoids loading locales unnecessarily.


To use this implementation, all that is required is to specify the 'factory'
init-param in your web.xml file, and to make sure that the 'application'
init-param refers to an XML resource.


What do people think about incorporating this into the Struts 1.1 code base?


--
Martin Cooper

Re: new feature

[c tang]

Maybe I have not clearly stated my case.
Let me give you an example, hope that will help.

A Bean defines a method called findWhere which
calls a ejb bean and return a Collection of 
objects.  In current implementation, There is no way
to use taglib to get hold of the collection of object
in a jsp page other than usng ugly scriptlet.  Does
that go against what taglib is all about?

ct

--- [EMAIL PROTECTED] wrote:
> -1.
> 
> If someone wants to code their *beans* this way,
> they should code/generate 
> a BeanInfo to go with it, IMHO.
> 
> --
> dIon Gillard, Multitask Consulting
> Work:  http://www.multitask.com.au
> JavaNews: http://www.multitask.com.au/JavaNews
> - Forwarded by dIon Gillard/Multitask
> Consulting/AU on 11/10/2001 02:44 PM -Re: new
> feature
> 
> -1
> 
> Looking to call a method besides get*() runs
> contrary to the JavaBean
> specification. Struts should stick to the book.
> 
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel +1 716 737-3463
> -- http://www.husted.com/about/struts/
> 
> 
> c tang wrote:
> >
> > Hi there,
> >
> > I'd like a new feature being added to Nested
> > References of bean tag.  Currently it can read
> from
> > property with getter method.  It would be nice if
> it
> > can read from a pure method too.
> >
> > For example,
> > currently
> > property="foo.bar"
> > is translated into the equivalent the Java
> expression:
> > getFoo().getBar()
> >
> > I propose that if getBar() is not available,
> > property="foo.bar"
> > is translated into the equivalent the Java
> expression:
> > getFoo().bar()
> >
> > This is a feature in webobject, which allows
> access to
> > an object without have to define an attribute.
> >
> > ct
> >
> 


__
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com

RE: [PROPOSAL] XMLMessageResources

[Curt Hagenlocher]

Young, Wayne  writes:

> What are some benefits of using XMLMessageResources over standard
> property files?

Improved buzzword-compliance?

--
Curt Hagenlocher
[EMAIL PROTECTED]

DO NOT REPLY [Bug 4108] New: - Dyslexic typo

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4108

Dyslexic typo

   Summary: Dyslexic typo
   Product: Struts
   Version: 1.0 Final
  Platform: PC
   URL: http://jakarta.apache.org/struts/userGuide/resources.htm
l
OS/Version: Windows NT/2K
Status: NEW
  Severity: Minor
  Priority: Other
 Component: Documentation
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


On the page http://jakarta.apache.org/struts/userGuide/resources.html, the 
second header reads 'Contributor Tabligs' where it should read 'Contributor 
Taglibs' (notice the swapped 'b' and 'g' in the second word).

RE: [PROPOSAL] XMLMessageResources

[SCHACHTER,MICHAEL (HP-NewJersey,ex2)]

Martin,

In the jakarta-commons-sandbox, there's a folder
called "resources" containing Struts MessageResources
and some other classes that I was working on, but had
to put off for a while.

It seemed before that MessageResources were being
factored out of Struts and into jakarta-commons, and if this
is still the case (Craig?), I can free up some time now
to finish off the remaining code and maybe go 1.0 with 
it, along with your XmlMessageResources class.  Do you
have committer access to the sandbox?



-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 11, 2001 2:08 AM
To: [EMAIL PROTECTED]
Subject: [PROPOSAL] XMLMessageResources


The Struts 1.1 TODO list contains the following item:

"XmlMessageResources. Implementation of MessageResources and
MessageResourcesFactory that loads message keys and strings from one or more
XML resources or files."

I have an implementation of this which I would like to contribute to Struts.
The implementation is a drop-in replacement for the existing
PropertyMessageResources. In fact, it is derived from it, and so shares the
same file naming scheme for locale-specific messages.

Here's a simple example of what an XML message file would look like:

-- begin example --



  You must enter a
username
  You must enter a
password
  Confirmation password does not
match

-- end example --

The first line of the example provides a hint as to why I did not attempt to
incorporate messages for more than one locale into a single XML file.
Messages for different locales may well be specified using different
character encodings. In addition, maintaining the messages from each locale
in a different XML file avoids loading locales unnecessarily.

To use this implementation, all that is required is to specify the 'factory'
init-param in your web.xml file, and to make sure that the 'application'
init-param refers to an XML resource.

What do people think about incorporating this into the Struts 1.1 code base?

--
Martin Cooper

cvs commit: jakarta-struts/src/share/org/apache/struts/upload BufferedMultipartInputStream.java MultipartIterator.java

[mschachter]

mschachter01/10/11 09:28:17

  Modified:src/share/org/apache/struts/upload
BufferedMultipartInputStream.java
MultipartIterator.java
  Log:
   - port from 1.0 branch to address bugs #3702, #3828, and #2683
  
  Revision  ChangesPath
  1.6   +7 -4  
jakarta-struts/src/share/org/apache/struts/upload/BufferedMultipartInputStream.java
  
  Index: BufferedMultipartInputStream.java
  ===
  RCS file: 
/home/cvs/jakarta-struts/src/share/org/apache/struts/upload/BufferedMultipartInputStream.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- BufferedMultipartInputStream.java 2001/09/24 16:41:37 1.5
  +++ BufferedMultipartInputStream.java 2001/10/11 16:28:17 1.6
  @@ -218,13 +218,16 @@
   
   int read = read();
   ByteArrayOutputStream baos = new ByteArrayOutputStream();
  -while (read != -1) {
  -if (read == '\n') {
  -return baos.toByteArray();
  -}
  +
  + // return null if there are no more bytes to read
  +if( -1 == read )
  +return null;
  +
  +while ((read != -1) && (read != '\n')) {
   baos.write(read);
   read = read();
   }
  +
   return baos.toByteArray();
   }
   
  
  
  
  1.18  +95 -90
jakarta-struts/src/share/org/apache/struts/upload/MultipartIterator.java
  
  Index: MultipartIterator.java
  ===
  RCS file: 
/home/cvs/jakarta-struts/src/share/org/apache/struts/upload/MultipartIterator.java,v
  retrieving revision 1.17
  retrieving revision 1.18
  diff -u -r1.17 -r1.18
  --- MultipartIterator.java2001/09/24 16:41:37 1.17
  +++ MultipartIterator.java2001/10/11 16:28:17 1.18
  @@ -21,7 +21,7 @@
* 
*  MultipartIterator iterator = new MultipartIterator(request);
*  MultipartElement element;
  - * 
  + *
*  while ((element = iterator.getNextElement()) != null) {
*   //do something with element
*  }
  @@ -31,64 +31,64 @@
* @author Mike Schachter
*/
   public class MultipartIterator {
  -
  +
   /**
* The maximum size in bytes of the buffer used to read lines [4K]
*/
   public static int MAX_LINE_SIZE = 4096;
  -
  +
   /**
* The request instance for this class
*/
   protected HttpServletRequest request;
  -
  +
   /**
* The input stream instance for this class
*/
   protected BufferedMultipartInputStream inputStream;
  -
  +
   /**
* The boundary for this multipart request
*/
   protected String boundary;
  -
  +
   /**
* The byte array representing the boundary for this multipart request
*/
   protected byte[] boundaryBytes;
  -
  +
   /**
* Whether or not the input stream is finished
*/
   protected boolean contentRead = false;
  -
  +
   /**
* The maximum file size in bytes allowed. Ignored if -1
*/
   protected long maxSize = -1;
  -
  +
   /**
* The total bytes read from this request
*/
   protected long totalLength = 0;
  -
  +
   /**
* The content length of this request
*/
   protected int contentLength;
  -
  +
   /**
* The size in bytes written to the filesystem at a time [20K]
*/
   protected int diskBufferSize = 2 * 10240;
  -
  +
   /**
* The amount of data read from a request at a time.
* This also represents the maximum size in bytes of
* a line read from the request [4KB]
*/
   protected int bufferSize = 4096;
  -
  +
   /**
* The temporary directory to store files
*/
  @@ -97,13 +97,13 @@
   /**
* Constructs a MultipartIterator with a default buffer size and no file size
* limit
  - * 
  + *
* @param request The multipart request to iterate
*/
   public MultipartIterator(HttpServletRequest request) throws ServletException{
   this(request, -1);
   }
  -
  +
   /**
* Constructs a MultipartIterator with the specified buffer size and
* no file size limit
  @@ -112,10 +112,10 @@
* @param bufferSize The size in bytes that should be read from the input
*   stream at a times
*/
  -public MultipartIterator(HttpServletRequest request, int bufferSize) throws 
ServletException {
  +public MultipartIterator(HttpServletRequest request, int bufferSize) throws 
ServletException {
  this (request, bufferSize, -1);
   }
  -
  +
   /**
* Constructs a MultipartIterator with the specified buffer size and
* the specified file size limit in byt

Re: new feature

[Craig R. McClanahan]

On Thu, 11 Oct 2001, c tang wrote:

> Date: Thu, 11 Oct 2001 06:21:57 -0700 (PDT)
> From: c tang <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: Re: new feature
>
> Maybe I have not clearly stated my case.
> Let me give you an example, hope that will help.
>
> A Bean defines a method called findWhere which
> calls a ejb bean and return a Collection of
> objects.  In current implementation, There is no way
> to use taglib to get hold of the collection of object
> in a jsp page other than usng ugly scriptlet.  Does
> that go against what taglib is all about?
>

To accomplish your goal without any changes to the current code, you have
three choices:

* Change the name of the findWhere() method to getWhere() so that
  it conforms to the JavaBeans design patterns.

* Add a BeanInfo class (see the JavaBeans specification for more
  information) that tells the JDK that your "where" method's
  property getter is named "findWhere" instead of "getWhere".

* Add property getter methods that conform to the standard JavaBeans
  design patterns in addition to (or instead of) your findWhere method.

> ct
>

Craig


> --- [EMAIL PROTECTED] wrote:
> > -1.
> >
> > If someone wants to code their *beans* this way,
> > they should code/generate
> > a BeanInfo to go with it, IMHO.
> >
> > --
> > dIon Gillard, Multitask Consulting
> > Work:  http://www.multitask.com.au
> > JavaNews: http://www.multitask.com.au/JavaNews
> > - Forwarded by dIon Gillard/Multitask
> > Consulting/AU on 11/10/2001 02:44 PM -Re: new
> > feature
> >
> > -1
> >
> > Looking to call a method besides get*() runs
> > contrary to the JavaBean
> > specification. Struts should stick to the book.
> >
> > -- Ted Husted, Husted dot Com, Fairport NY USA.
> > -- Custom Software ~ Technical Services.
> > -- Tel +1 716 737-3463
> > -- http://www.husted.com/about/struts/
> >
> >
> > c tang wrote:
> > >
> > > Hi there,
> > >
> > > I'd like a new feature being added to Nested
> > > References of bean tag.  Currently it can read
> > from
> > > property with getter method.  It would be nice if
> > it
> > > can read from a pure method too.
> > >
> > > For example,
> > > currently
> > > property="foo.bar"
> > > is translated into the equivalent the Java
> > expression:
> > > getFoo().getBar()
> > >
> > > I propose that if getBar() is not available,
> > > property="foo.bar"
> > > is translated into the equivalent the Java
> > expression:
> > > getFoo().bar()
> > >
> > > This is a feature in webobject, which allows
> > access to
> > > an object without have to define an attribute.
> > >
> > > ct
> > >
> >
>
>
> __
> Do You Yahoo!?
> Make a great connection at Yahoo! Personals.
> http://personals.yahoo.com
>

RE: [PROPOSAL] XMLMessageResources

[Craig R. McClanahan]

On Thu, 11 Oct 2001, SCHACHTER,MICHAEL (HP-NewJersey,ex2) wrote:

> Date: Thu, 11 Oct 2001 12:12:15 -0400
> From: "SCHACHTER,MICHAEL (HP-NewJersey,ex2)" <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
> Subject: RE: [PROPOSAL] XMLMessageResources
>
> Martin,
>
> In the jakarta-commons-sandbox, there's a folder
> called "resources" containing Struts MessageResources
> and some other classes that I was working on, but had
> to put off for a while.
>

Yep.

> It seemed before that MessageResources were being
> factored out of Struts and into jakarta-commons, and if this
> is still the case (Craig?), I can free up some time now
> to finish off the remaining code and maybe go 1.0 with
> it, along with your XmlMessageResources class.  Do you
> have committer access to the sandbox?
>
>

I would like to see this finished, so we can migrate Struts 1.1 to it.
Any Jakarta committer (on any project) can have write access to the
jakarta-commons-sandbox repository -- let me know if you have any problems
with this.

Craig

>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, October 11, 2001 2:08 AM
> To: [EMAIL PROTECTED]
> Subject: [PROPOSAL] XMLMessageResources
>
>
> The Struts 1.1 TODO list contains the following item:
>
> "XmlMessageResources. Implementation of MessageResources and
> MessageResourcesFactory that loads message keys and strings from one or more
> XML resources or files."
>
> I have an implementation of this which I would like to contribute to Struts.
> The implementation is a drop-in replacement for the existing
> PropertyMessageResources. In fact, it is derived from it, and so shares the
> same file naming scheme for locale-specific messages.
>
> Here's a simple example of what an XML message file would look like:
>
> -- begin example --
> 
>
> 
>   You must enter a
> username
>   You must enter a
> password
>   Confirmation password does not
> match
> 
> -- end example --
>
> The first line of the example provides a hint as to why I did not attempt to
> incorporate messages for more than one locale into a single XML file.
> Messages for different locales may well be specified using different
> character encodings. In addition, maintaining the messages from each locale
> in a different XML file avoids loading locales unnecessarily.
>
> To use this implementation, all that is required is to specify the 'factory'
> init-param in your web.xml file, and to make sure that the 'application'
> init-param refers to an XML resource.
>
> What do people think about incorporating this into the Struts 1.1 code base?
>
> --
> Martin Cooper
>
>
>

RE: [PROPOSAL] XMLMessageResources

[martin . cooper]

Ah. Thanks for letting me know. I guess I was on hiatus when that happened 
in Commons. ;-) I'd better go take a look at what's there. I'm a Commons 
committer also, so I should be able to commit to the sandbox.

--
Martin Cooper


At 09:12 AM 10/11/01, SCHACHTER,MICHAEL (HP-NewJersey,ex2) wrote:
>Martin,
>
>In the jakarta-commons-sandbox, there's a folder
>called "resources" containing Struts MessageResources
>and some other classes that I was working on, but had
>to put off for a while.
>
>It seemed before that MessageResources were being
>factored out of Struts and into jakarta-commons, and if this
>is still the case (Craig?), I can free up some time now
>to finish off the remaining code and maybe go 1.0 with
>it, along with your XmlMessageResources class.  Do you
>have committer access to the sandbox?
>
>
>
>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, October 11, 2001 2:08 AM
>To: [EMAIL PROTECTED]
>Subject: [PROPOSAL] XMLMessageResources
>
>
>The Struts 1.1 TODO list contains the following item:
>
>"XmlMessageResources. Implementation of MessageResources and
>MessageResourcesFactory that loads message keys and strings from one or more
>XML resources or files."
>
>I have an implementation of this which I would like to contribute to Struts.
>The implementation is a drop-in replacement for the existing
>PropertyMessageResources. In fact, it is derived from it, and so shares the
>same file naming scheme for locale-specific messages.
>
>Here's a simple example of what an XML message file would look like:
>
>-- begin example --
>
>
>
>   You must enter a
>username
>   You must enter a
>password
>   Confirmation password does not
>match
>
>-- end example --
>
>The first line of the example provides a hint as to why I did not attempt to
>incorporate messages for more than one locale into a single XML file.
>Messages for different locales may well be specified using different
>character encodings. In addition, maintaining the messages from each locale
>in a different XML file avoids loading locales unnecessarily.
>
>To use this implementation, all that is required is to specify the 'factory'
>init-param in your web.xml file, and to make sure that the 'application'
>init-param refers to an XML resource.
>
>What do people think about incorporating this into the Struts 1.1 code base?
>
>--
>Martin Cooper

RE: [PROPOSAL] XMLMessageResources

[martin . cooper]

In my opinion, one of the biggest benefits is that you can do all sorts of 
things with standard XML tools. For example, the message resources could be 
used as input to XSLT for various things, or as output from it.

One idea I had in mind was translation tools. Imagine if you started with a 
"master"  document like this:


   
 validation.username.required
 login page
 Displayed when no user name is entered on login 
page
 You must enter a username
   
   [...]


This file can be sent to a translation service where an appropriate 
XML-based tool can lead the translator through the messages and let them 
provide translations for the text. The final XML message resources can be 
generated from the message master using XSLT.

Even better, the translated messages can be used as input to an incremental 
translation process. When version 2 of the application comes out, the 
translation tool can use the message master and the message resource to 
identify which messages have modified text, and which new messages need to 
be translated, avoiding the lengthy (and expensive) process of 
re-translating the entire application.

Granted, all this could be done using property resources too. However, it 
seems to me that using XML will provide a more flexible approach, given the 
many XML tools available, where the message resources can be both the input 
and the output.

--
Martin Cooper


At 05:32 AM 10/11/01, Young, Wayne wrote:

>What are some benefits of using XMLMessageResources over standard property 
>files?
>
>Wayne Young
>
>
>-Original Message-
>From: [EMAIL PROTECTED] 
>[mailto:[EMAIL PROTECTED]]
>Sent: Thursday, October 11, 2001 1:08 AM
>To: [EMAIL PROTECTED]
>Subject: [PROPOSAL] XMLMessageResources
>
>The Struts 1.1 TODO list contains the following item:
>
>"XmlMessageResources. Implementation of MessageResources and
>MessageResourcesFactory that loads message keys and strings from one or more
>XML resources or files."
>
>I have an implementation of this which I would like to contribute to Struts.
>The implementation is a drop-in replacement for the existing
>PropertyMessageResources. In fact, it is derived from it, and so shares the
>same file naming scheme for locale-specific messages.
>
>Here's a simple example of what an XML message file would look like:
>
>-- begin example --
>
>
>
>   You must enter a
>username
>   You must enter a
>password
>   Confirmation password does not
>match
>
>-- end example --
>
>The first line of the example provides a hint as to why I did not attempt to
>incorporate messages for more than one locale into a single XML file.
>Messages for different locales may well be specified using different
>character encodings. In addition, maintaining the messages from each locale
>in a different XML file avoids loading locales unnecessarily.
>
>To use this implementation, all that is required is to specify the 'factory'
>init-param in your web.xml file, and to make sure that the 'application'
>init-param refers to an XML resource.
>
>What do people think about incorporating this into the Struts 1.1 code base?
>
>--
>Martin Cooper
>

RE: [PROPOSAL] XMLMessageResources

[Craig R. McClanahan]

On Thu, 11 Oct 2001 [EMAIL PROTECTED] wrote:

>
> Ah. Thanks for letting me know. I guess I was on hiatus when that happened
> in Commons. ;-) I'd better go take a look at what's there. I'm a Commons
> committer also, so I should be able to commit to the sandbox.
>

You are, and you can.  :-)

> --
> Martin Cooper
>

Craig

Re: new feature

[c tang]

--- "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote:
> 
> 
> On Thu, 11 Oct 2001, c tang wrote:
> 
> > Date: Thu, 11 Oct 2001 06:21:57 -0700 (PDT)
> > From: c tang <[EMAIL PROTECTED]>
> > Reply-To: [EMAIL PROTECTED]
> > To: [EMAIL PROTECTED]
> > Subject: Re: new feature
> >
> > Maybe I have not clearly stated my case.
> > Let me give you an example, hope that will help.
> >
> > A Bean defines a method called findWhere which
> > calls a ejb bean and return a Collection of
> > objects.  In current implementation, There is no
> way
> > to use taglib to get hold of the collection of
> object
> > in a jsp page other than usng ugly scriptlet. 
> Does
> > that go against what taglib is all about?
> >
> 
> To accomplish your goal without any changes to the
> current code, you have
> three choices:
> 
> * Change the name of the findWhere() method to
> getWhere() so that
>   it conforms to the JavaBeans design patterns.
> 
> * Add a BeanInfo class (see the JavaBeans
> specification for more
>   information) that tells the JDK that your "where"
> method's
>   property getter is named "findWhere" instead of
> "getWhere".
> 
> * Add property getter methods that conform to the
> standard JavaBeans
>   design patterns in addition to (or instead of)
> your findWhere method.
> 
> > ct
> >
> 
> Craig
> 

Yes, it will work if you tried to access objects in
your own code.

A lot of time, you uses a third party classes that 
you cannot change their interface.  I imagines that
a wrapper class may be created.  But in my opinion,
it is overkilled for a small task like this.

ct

> > --- [EMAIL PROTECTED] wrote:
> > > -1.
> > >
> > > If someone wants to code their *beans* this way,
> > > they should code/generate
> > > a BeanInfo to go with it, IMHO.
> > >
> > > --
> > > dIon Gillard, Multitask Consulting
> > > Work:  http://www.multitask.com.au
> > > JavaNews: http://www.multitask.com.au/JavaNews
> > > - Forwarded by dIon Gillard/Multitask
> > > Consulting/AU on 11/10/2001 02:44 PM -Re:
> new
> > > feature
> > >
> > > -1
> > >
> > > Looking to call a method besides get*() runs
> > > contrary to the JavaBean
> > > specification. Struts should stick to the book.
> > >
> > > -- Ted Husted, Husted dot Com, Fairport NY USA.
> > > -- Custom Software ~ Technical Services.
> > > -- Tel +1 716 737-3463
> > > -- http://www.husted.com/about/struts/
> > >
> > >
> > > c tang wrote:
> > > >
> > > > Hi there,
> > > >
> > > > I'd like a new feature being added to Nested
> > > > References of bean tag.  Currently it can read
> > > from
> > > > property with getter method.  It would be nice
> if
> > > it
> > > > can read from a pure method too.
> > > >
> > > > For example,
> > > > currently
> > > > property="foo.bar"
> > > > is translated into the equivalent the Java
> > > expression:
> > > > getFoo().getBar()
> > > >
> > > > I propose that if getBar() is not available,
> > > > property="foo.bar"
> > > > is translated into the equivalent the Java
> > > expression:
> > > > getFoo().bar()
> > > >
> > > > This is a feature in webobject, which allows
> > > access to
> > > > an object without have to define an attribute.
> > > >
> > > > ct
> > > >
> > >
> >
> >
> > __
> > Do You Yahoo!?
> > Make a great connection at Yahoo! Personals.
> > http://personals.yahoo.com
> >
> 


__
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com

RE: new feature

[Tim Moore]

Maybe a new tag that just uses introspection to call a named method on a
bean wouldn't be a bad idea...

-- 
Tim Moore / Blackboard Inc. / Software Engineer
1899 L Street, NW/ 5th Floor / Washington, DC 20036
Phone 202-463-4860 ext. 258 / Fax 202-463-4863


> -Original Message-
> From: c tang [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, October 11, 2001 5:17 PM
> To: [EMAIL PROTECTED]
> Subject: Re: new feature
> 
> 
> 
> --- "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote:
> > 
> > 
> > On Thu, 11 Oct 2001, c tang wrote:
> > 
> > > Date: Thu, 11 Oct 2001 06:21:57 -0700 (PDT)
> > > From: c tang <[EMAIL PROTECTED]>
> > > Reply-To: [EMAIL PROTECTED]
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: new feature
> > >
> > > Maybe I have not clearly stated my case.
> > > Let me give you an example, hope that will help.
> > >
> > > A Bean defines a method called findWhere which
> > > calls a ejb bean and return a Collection of
> > > objects.  In current implementation, There is no
> > way
> > > to use taglib to get hold of the collection of
> > object
> > > in a jsp page other than usng ugly scriptlet. 
> > Does
> > > that go against what taglib is all about?
> > >
> > 
> > To accomplish your goal without any changes to the
> > current code, you have
> > three choices:
> > 
> > * Change the name of the findWhere() method to
> > getWhere() so that
> >   it conforms to the JavaBeans design patterns.
> > 
> > * Add a BeanInfo class (see the JavaBeans
> > specification for more
> >   information) that tells the JDK that your "where"
> > method's
> >   property getter is named "findWhere" instead of
> > "getWhere".
> > 
> > * Add property getter methods that conform to the
> > standard JavaBeans
> >   design patterns in addition to (or instead of)
> > your findWhere method.
> > 
> > > ct
> > >
> > 
> > Craig
> > 
> 
> Yes, it will work if you tried to access objects in
> your own code.
> 
> A lot of time, you uses a third party classes that 
> you cannot change their interface.  I imagines that
> a wrapper class may be created.  But in my opinion,
> it is overkilled for a small task like this.
> 
> ct
> 
> > > --- [EMAIL PROTECTED] wrote:
> > > > -1.
> > > >
> > > > If someone wants to code their *beans* this way,
> > > > they should code/generate
> > > > a BeanInfo to go with it, IMHO.
> > > >
> > > > --
> > > > dIon Gillard, Multitask Consulting
> > > > Work:  http://www.multitask.com.au
> > > > JavaNews: http://www.multitask.com.au/JavaNews
> > > > - Forwarded by dIon Gillard/Multitask
> > > > Consulting/AU on 11/10/2001 02:44 PM -Re:
> > new
> > > > feature
> > > >
> > > > -1
> > > >
> > > > Looking to call a method besides get*() runs
> > > > contrary to the JavaBean
> > > > specification. Struts should stick to the book.
> > > >
> > > > -- Ted Husted, Husted dot Com, Fairport NY USA.
> > > > -- Custom Software ~ Technical Services.
> > > > -- Tel +1 716 737-3463
> > > > -- http://www.husted.com/about/struts/
> > > >
> > > >
> > > > c tang wrote:
> > > > >
> > > > > Hi there,
> > > > >
> > > > > I'd like a new feature being added to Nested
> > > > > References of bean tag.  Currently it can read
> > > > from
> > > > > property with getter method.  It would be nice
> > if
> > > > it
> > > > > can read from a pure method too.
> > > > >
> > > > > For example,
> > > > > currently
> > > > > property="foo.bar"
> > > > > is translated into the equivalent the Java
> > > > expression:
> > > > > getFoo().getBar()
> > > > >
> > > > > I propose that if getBar() is not available,
> > > > > property="foo.bar"
> > > > > is translated into the equivalent the Java
> > > > expression:
> > > > > getFoo().bar()
> > > > >
> > > > > This is a feature in webobject, which allows
> > > > access to
> > > > > an object without have to define an attribute.
> > > > >
> > > > > ct
> > > > >
> > > >
> > >
> > >
> > > __
> > > Do You Yahoo!?
> > > Make a great connection at Yahoo! Personals.
> > > http://personals.yahoo.com
> > >
> > 
> 
> 
> __
> Do You Yahoo!?
> Make a great connection at Yahoo! Personals.
> http://personals.yahoo.com
> 

Please unsubcsribe me

[Gujral, Irvind]

Title: Please unsubcsribe me






Please unsubscribe me



-Original Message-
From: Tim Moore [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 11, 2001 2:57 PM
To: [EMAIL PROTECTED]
Subject: RE: new feature



Maybe a new tag that just uses introspection to call a named method on a
bean wouldn't be a bad idea...


-- 
Tim Moore / Blackboard Inc. / Software Engineer
1899 L Street, NW/ 5th Floor / Washington, DC 20036
Phone 202-463-4860 ext. 258 / Fax 202-463-4863



> -Original Message-
> From: c tang [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, October 11, 2001 5:17 PM
> To: [EMAIL PROTECTED]
> Subject: Re: new feature
> 
> 
> 
> --- "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote:
> > 
> > 
> > On Thu, 11 Oct 2001, c tang wrote:
> > 
> > > Date: Thu, 11 Oct 2001 06:21:57 -0700 (PDT)
> > > From: c tang <[EMAIL PROTECTED]>
> > > Reply-To: [EMAIL PROTECTED]
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: new feature
> > >
> > > Maybe I have not clearly stated my case.
> > > Let me give you an example, hope that will help.
> > >
> > > A Bean defines a method called findWhere which
> > > calls a ejb bean and return a Collection of
> > > objects.  In current implementation, There is no
> > way
> > > to use taglib to get hold of the collection of
> > object
> > > in a jsp page other than usng ugly scriptlet. 
> > Does
> > > that go against what taglib is all about?
> > >
> > 
> > To accomplish your goal without any changes to the
> > current code, you have
> > three choices:
> > 
> > * Change the name of the findWhere() method to
> > getWhere() so that
> >   it conforms to the JavaBeans design patterns.
> > 
> > * Add a BeanInfo class (see the JavaBeans
> > specification for more
> >   information) that tells the JDK that your "where"
> > method's
> >   property getter is named "findWhere" instead of
> > "getWhere".
> > 
> > * Add property getter methods that conform to the
> > standard JavaBeans
> >   design patterns in addition to (or instead of)
> > your findWhere method.
> > 
> > > ct
> > >
> > 
> > Craig
> > 
> 
> Yes, it will work if you tried to access objects in
> your own code.
> 
> A lot of time, you uses a third party classes that 
> you cannot change their interface.  I imagines that
> a wrapper class may be created.  But in my opinion,
> it is overkilled for a small task like this.
> 
> ct
> 
> > > --- [EMAIL PROTECTED] wrote:
> > > > -1.
> > > >
> > > > If someone wants to code their *beans* this way,
> > > > they should code/generate
> > > > a BeanInfo to go with it, IMHO.
> > > >
> > > > --
> > > > dIon Gillard, Multitask Consulting
> > > > Work:  http://www.multitask.com.au
> > > > JavaNews: http://www.multitask.com.au/JavaNews
> > > > - Forwarded by dIon Gillard/Multitask
> > > > Consulting/AU on 11/10/2001 02:44 PM -Re:
> > new
> > > > feature
> > > >
> > > > -1
> > > >
> > > > Looking to call a method besides get*() runs
> > > > contrary to the JavaBean
> > > > specification. Struts should stick to the book.
> > > >
> > > > -- Ted Husted, Husted dot Com, Fairport NY USA.
> > > > -- Custom Software ~ Technical Services.
> > > > -- Tel +1 716 737-3463
> > > > -- http://www.husted.com/about/struts/
> > > >
> > > >
> > > > c tang wrote:
> > > > >
> > > > > Hi there,
> > > > >
> > > > > I'd like a new feature being added to Nested
> > > > > References of bean tag.  Currently it can read
> > > > from
> > > > > property with getter method.  It would be nice
> > if
> > > > it
> > > > > can read from a pure method too.
> > > > >
> > > > > For example,
> > > > > currently
> > > > > property="foo.bar"
> > > > > is translated into the equivalent the Java
> > > > expression:
> > > > > getFoo().getBar()
> > > > >
> > > > > I propose that if getBar() is not available,
> > > > > property="foo.bar"
> > > > > is translated into the equivalent the Java
> > > > expression:
> > > > > getFoo().bar()
> > > > >
> > > > > This is a feature in webobject, which allows
> > > > access to
> > > > > an object without have to define an attribute.
> > > > >
> > > > > ct
> > > > >
> > > >
> > >
> > >
> > > __
> > > Do You Yahoo!?
> > > Make a great connection at Yahoo! Personals.
> > > http://personals.yahoo.com
> > >
> > 
> 
> 
> __
> Do You Yahoo!?
> Make a great connection at Yahoo! Personals.
> http://personals.yahoo.com
> 

cvs commit: jakarta-struts/web/example tour.htm

[craigmcc]

craigmcc01/10/11 19:03:15

  Modified:web/example Tag: STRUTS_1_0_BRANCH tour.htm
  Log:
  Fix typos in the Walking Tour.
  
  Submitted by: Ed Burns <[EMAIL PROTECTED]>
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.5.2.2   +3 -3  jakarta-struts/web/example/tour.htm
  
  Index: tour.htm
  ===
  RCS file: /home/cvs/jakarta-struts/web/example/tour.htm,v
  retrieving revision 1.5.2.1
  retrieving revision 1.5.2.2
  diff -u -r1.5.2.1 -r1.5.2.2
  --- tour.htm  2001/08/07 18:29:31 1.5.2.1
  +++ tour.htm  2001/10/12 02:03:15 1.5.2.2
  @@ -231,19 +231,19 @@
   Before passing the request to LogonAction, the ActionServlet looks for the
   LogonForm bean. If it finds it, the ActionServlet updates the bean by matching
   properties named in the HTTP request with properties named in the form bean. If
  -it doesn't find the bean, ActionServlet creates it, so ActionLogon can assume
  +it doesn't find the bean, ActionServlet creates it, so LogonAction can assume
   that it already exists.
   When called by the ActionServlet, LogonAction retrieves the username and
   password from the LogonForm bean. (If just created, the bean will return default
   values.)
  -In the example, LoginAction then checks with the DatabaseServlet to see if
  +In the example, LogonAction then checks with the DatabaseServlet to see if
   the logon matches a registered user. If the logon doesn't match, LogonAction
   adds a message key to an error list. At the end of the routine, if the error
   list is not empty, LogonAction adds a User bean to the session context, and forwards
   control to its input form (login.jsp).
   
   Note that direct access to the DatabaseServlet should really be handled by a
  -business-logic bean, and NOT by LoginAction. To quote the example's author
  +business-logic bean, and NOT by LogonAction. To quote the example's author
   "This should be considered a bug in the example." 
   
   If there are no errors, LogonAction places a user bean into the
  
  
  

cvs commit: jakarta-struts/web/example tour.htm

[craigmcc]

craigmcc01/10/11 19:03:47

  Modified:web/example tour.htm
  Log:
  Port fix to typos.
  Submitted by: Ed Burns <[EMAIL PROTECTED]>
  
  Revision  ChangesPath
  1.7   +3 -3  jakarta-struts/web/example/tour.htm
  
  Index: tour.htm
  ===
  RCS file: /home/cvs/jakarta-struts/web/example/tour.htm,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- tour.htm  2001/08/07 18:28:35 1.6
  +++ tour.htm  2001/10/12 02:03:47 1.7
  @@ -231,19 +231,19 @@
   Before passing the request to LogonAction, the ActionServlet looks for the
   LogonForm bean. If it finds it, the ActionServlet updates the bean by matching
   properties named in the HTTP request with properties named in the form bean. If
  -it doesn't find the bean, ActionServlet creates it, so ActionLogon can assume
  +it doesn't find the bean, ActionServlet creates it, so LogonAction can assume
   that it already exists.
   When called by the ActionServlet, LogonAction retrieves the username and
   password from the LogonForm bean. (If just created, the bean will return default
   values.)
  -In the example, LoginAction then checks with the DatabaseServlet to see if
  +In the example, LogonAction then checks with the DatabaseServlet to see if
   the logon matches a registered user. If the logon doesn't match, LogonAction
   adds a message key to an error list. At the end of the routine, if the error
   list is not empty, LogonAction adds a User bean to the session context, and forwards
   control to its input form (login.jsp).
   
   Note that direct access to the DatabaseServlet should really be handled by a
  -business-logic bean, and NOT by LoginAction. To quote the example's author
  +business-logic bean, and NOT by LogonAction. To quote the example's author
   "This should be considered a bug in the example." 
   
   If there are no errors, LogonAction places a user bean into the