format Attribute

[Volker Krebs]

Hello,

I wanted to use the new  format mechanism,
I specified my format strings in the message resources.
So far so good ... everything was fine, but when I changed the
user locale with Action.setLocale() nothing happend for
FLOAT_FORMAT_KEY.
The Problem is in
org.apache.struts.taglib.bean.WriteTag.formatValue(...)
after line 318.
Please watch my comment.

if (formatStr == null) {
   format = NumberFormat.getInstance(locale);
} else {
   try {
 //Here we don't use the user locale but the JVM default locale.
 format = new DecimalFormat(formatStr);
   } catch (IllegalArgumentException _e) {
 JspException e = new
   JspException(messages.getMessage("write.format", formatStr));
 RequestUtils.saveException(pageContext, e);
 throw e;
   }
}

I changed it to this, and it did work well.

if (formatStr == null) {
   format = NumberFormat.getInstance(locale);
} else {
   try {
 //here we use the user locale
 NumberFormat f = NumberFormat.getNumberInstance(locale);
 if (f instanceof DecimalFormat) {
   ((DecimalFormat) f).applyPattern(formatStr);
   format = f;
  } else {
format = new DecimalFormat(formatStr);
  }
   } catch (IllegalArgumentException _e) {
 JspException e = new
   JspException(messages.getMessage("write.format", formatStr));
 RequestUtils.saveException(pageContext, e);
 throw e;
   }
}

Is this a Bug ??
Or am I missunderstanding something ?

Volker


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Well-formed HTML support in struts 1.01+ !!

[Morten M. Christensen]

At our company we have been using struts 1.0 since the release and very 
glad for it... Until recently, where we have shocked by the discovery 
that structs 1.0 breaks all out attempts at produce well-formed HTML!

Our situation is that we now need to output well-formed HTML (we will 
probably use XHTML), in order to do easy post processing in XSL/Java for 
various nice things like automated GUI testing (all extremely important 
and requires well-formed HTML / XHTML).

At first we have tried to close all our struts tags (ex.  - 
note the space needed for some old browsers) but to no avail. Struts 
just ignores our attempts at closing the tags.

What can we do now? I would not like to either drop struts or drop our 
automated tests as well as other critial things that depends on 
well-formed HTML. I would therefore request that the struts developers 
find some way of at least minimal support for generating well formed 
HTML (and please do not suggest simply using TIDY or something like that 
- it does not work ; at least for us it does not).

BTW: From searching the web I saw another posting about this from a 
"Matt Raible" (?), mentioning briefly some uncommitted code that could 
solve this (where, how ?). Would that be possible to just include that 
in 1.0.1 (it would need to be official so that we can count on it for 
the future).

Sincerely,
Morten Christensen,
AArhus, Denmark


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-struts/doc struts-bean.xml

[oalexeev]

oalexeev01/12/12 06:10:03

  Modified:doc  struts-bean.xml
  Log:
  Insert additional description of format attribute and formatting logic in bean:write 
tag.
  
  Revision  ChangesPath
  1.8   +14 -5 jakarta-struts/doc/struts-bean.xml
  
  Index: struts-bean.xml
  ===
  RCS file: /home/cvs/jakarta-struts/doc/struts-bean.xml,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- struts-bean.xml   2001/12/06 18:08:40 1.7
  +++ struts-bean.xml   2001/12/12 14:10:03 1.8
  @@ -895,10 +895,20 @@
   empty
   
   Retrieve the value of the specified bean property, and render it to the
  -current JspWriter as a String.  If there is a PropertyEditor configured
  -for the property value's class, the getAsText() method will
  -be called.  Otherwise, the usual toString() conversions
  -will be applied.
  +current JspWriter as a String by the ways:
  + 
  + If format attribute exists then value will be formatted on 
base of format 
  + string from format attribute and default system locale.
  + If in resources exists format string for value data type (view 
format
  + attribute description) then value will be formatted on base of format string
  + from resources. Resources bundle and target locale can be specified with
  + bundle and locale attributes. If nothing specified 
then
  + default resource bundle and current user locale will be used.
  + If there is a PropertyEditor configured for the property value's class, 
the 
  + getAsText() method will be called.
  + Otherwise, the usual toString() conversions will be 
applied.
  + 
  + 
   
   If a problem occurs while retrieving the specified bean property, a
   request time exception will be thrown.
  @@ -1002,7 +1012,6 @@
  java.sql.Time
  
 
  -  If nothing found, then toString() method for target object will be 
called.
 Default format strings in resources can be written as - 
   
   org.apache.struts.taglib.bean.format.int=##
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-struts/src/share/org/apache/struts/taglib/bean WriteTag.java

[oalexeev]

oalexeev01/12/12 06:11:30

  Modified:src/share/org/apache/struts/taglib/bean WriteTag.java
  Log:
  Change formatting logic for numeric values according a letter from
  Volker Krebs <[EMAIL PROTECTED]>  (Abas Software AG)
  
  Revision  ChangesPath
  1.14  +12 -5 
jakarta-struts/src/share/org/apache/struts/taglib/bean/WriteTag.java
  
  Index: WriteTag.java
  ===
  RCS file: 
/home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/bean/WriteTag.java,v
  retrieving revision 1.13
  retrieving revision 1.14
  diff -u -r1.13 -r1.14
  --- WriteTag.java 2001/12/06 17:59:34 1.13
  +++ WriteTag.java 2001/12/12 14:11:30 1.14
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/bean/WriteTag.java,v 1.13 
2001/12/06 17:59:34 oalexeev Exp $
  - * $Revision: 1.13 $
  - * $Date: 2001/12/06 17:59:34 $
  + * $Header: 
/home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/bean/WriteTag.java,v 1.14 
2001/12/12 14:11:30 oalexeev Exp $
  + * $Revision: 1.14 $
  + * $Date: 2001/12/12 14:11:30 $
*
* 
*
  @@ -89,7 +89,7 @@
* output stream, optionally filtering characters that are sensitive in HTML.
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.13 $ $Date: 2001/12/06 17:59:34 $
  + * @version $Revision: 1.14 $ $Date: 2001/12/12 14:11:30 $
*/
   
   public class WriteTag extends TagSupport {
  @@ -301,6 +301,7 @@
   if ( value instanceof java.lang.String ) {
   return (String)value;
   } else if ( value instanceof Number ) {
  +boolean formatStrFromResources = false;
   if( formatStr==null ) {
   if( ( value instanceof Byte )||
   ( value instanceof Short )   ||
  @@ -314,12 +315,18 @@
( value instanceof BigDecimal ) )
   formatStr = RequestUtils.message(pageContext, 
this.bundle,
 this.localeKey, FLOAT_FORMAT_KEY );
  +if( formatStr!=null ) 
  +formatStrFromResources = true;
   }
   if( formatStr==null )
   format = NumberFormat.getInstance( locale );
   else {
   try {
  -format = new DecimalFormat( formatStr );
  +format = NumberFormat.getNumberInstance( locale );
  +if( formatStrFromResources ) 
  +( ( DecimalFormat ) format 
).applyLocalizedPattern( formatStr );
  +else
  +( ( DecimalFormat ) format ).applyPattern( 
formatStr );
   } catch( IllegalArgumentException _e ) {
   JspException e = new 
JspException(messages.getMessage("write.format", formatStr));
   RequestUtils.saveException(pageContext, e);
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: format Attribute

[Volker Krebs]

Volker Krebs wrote:

> Hello,
> 
> I wanted to use the new  format mechanism,
> I specified my format strings in the message resources.
> So far so good ... everything was fine, but when I changed the
> user locale with Action.setLocale() nothing happend for
> FLOAT_FORMAT_KEY.
> The Problem is in
> org.apache.struts.taglib.bean.WriteTag.formatValue(...)
> after line 318.

Ok thanks for fixing that, I found somethig else,
if we have a java.util.Date a toString is printed.

} else if ((value instanceof java.sql.Date) ||
  value instanceof java.util.Date) { //check also for util.Date
   formatStr = RequestUtils.message(pageContext, this.bundle,
   this.localeKey, DATE_FORMAT_KEY);
}

You also have to check if the type is java.util.Date and
use the DATE_FORMAT_KEY for this type.

thanks

Volker


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: role based actions

[Phase Communcations]

The ldap portion is under development. It will be a bit. My code is a struts
centric security at this point. I am experimenting with extending it to
support ldap. I can still show you the code for the security if you would
like.

Brandon Goodin
Phase Web and Multimedia
P (406) 862-2245
F (406) 862-0354
[EMAIL PROTECTED]
http://www.phase.ws


-Original Message-
From: Dr. BaTien Duong [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, December 11, 2001 5:53 PM
To: Struts Developers List
Subject: Re: role based actions


Brandon:

I am interested in your code as we are working on Struts, ldap, and Java
single SignOn technology.

[EMAIL PROTECTED]

- Original Message -
From: "Phase Communcations" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Tuesday, December 11, 2001 4:43 PM
Subject: RE: role based actions


> One last thing. When a security check happens and the user is forwarded to
> the login. Their desired destination is stored and once their security is
> verified they are forwarded on to that page.
>
> -Original Message-
> From: Phase Communcations [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, December 11, 2001 4:40 PM
> To: Struts Developers List
> Subject: RE: role based actions
>
>
> In my code I extended the action class (not the action servlet) and
required
> that group access be established on a per extended action class basis.
>
> Defined within my struts-config file in my action class definitions I use
an
> extra attribute(s):
>
> 
>
> There is a security check within the extended action class that uses an
> extended ActionMapping to retrieve the "group" property and checks it
> against the users information (in a database). If the user belongs to the
> proper group or one of the groups defined then it allows them access to
that
> action/area with their assigned role and permissions. If the security
check
> fails, they are routed to a login page.
>
> The other thing that it does is it stores role and permission information
in
> a bean so that security information can be used to define the view as
well.
>
> I opted out of the container managed security because I was working under
> Tomcat 3.2.3 and am trying to create a more independent security model.
This
> model also works well for me because I use the command line url format for
> mapping to my action classes and none of my views are available but
through
> action classes (except index.jsp).
>
> I would be happy to share my code if anyone is interested. I think it is
> flexible enough that it could be incorporated into an ldap system. I have
> been confeing with a colleague who is working on struts interacting with
> ldap for security and profile management.
>
> Anyways if you like the idea of security being managed from the action
class
> and don't expose your views but through action mappings. This might be a
> good solution
>
> Brandon Goodin
> Phase Web and Multimedia
> P (406) 862-2245
> F (406) 862-0354
> [EMAIL PROTECTED]
> http://www.phase.ws
>
>
> -Original Message-
> From: craigmcc@localhost [mailto:craigmcc@localhost]On Behalf Of Craig
> R. McClanahan
> Sent: Tuesday, December 11, 2001 10:16 AM
> To: Struts Developers List
> Subject: Re: role based actions
>
>
>
>
> On Tue, 11 Dec 2001 [EMAIL PROTECTED] wrote:
>
> > Date: Tue, 11 Dec 2001 10:27:52 -0500
> > From: [EMAIL PROTECTED]
> > Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Subject: role based actions
> >
> >
> > I am a struts "newbie" so I apologize in advance if this topic has
already
> > beaten to death...
> >
> >  ~~~
> >
> > I noticed role-based actions on the pending tasks list.
>
> Adding this (and a few of the other recent enhancements) to Struts 1.1 is
> definitely on *my* list.  I will have some time to do so between Christmas
> and New Years.
>
> Craig McClanahan
>
> >
> > Can anyone comment on the status and scope of this effort? (link was a
> dead
> > end)
> >
> > The description points to role being driven by security, seems the role
> will
> > be detected and then dispatches to the proper action? points to assoc'd
> form
> > through config?
> >
> > Is this intended to be used for personalization to the extent where a
> person
> > of one role gets a different view, can user customize their view?
> >
> > Does this provide a place holder for that kind of functionality v. any
> > particular "built in" functionality?
> >
> > Thanks, sorry if the questions were a little obtuse.
> >
> > -Rick Vaillancourt
> >
> >
> > --
> > To unsubscribe, e-mail:
> 
> > For additional commands, e-mail:
> 
> >
> >
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>
>
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>
>
>
>
> --
> To unsubscribe, e-mail:

> For

RE: role based actions

[Taylor Cowan]

Struts is a J2EE add on, thus it should only be aware of J2EE concepts like
"roles".
J2EE provides security through the app server, and the concrete security
scheme may be ldap, jdbc, or other means.  Struts doesn't need security, it
just makes use of J2EE security.  I was just looking over Tomcat and it can
be configured to use LDAP.  Most other app servers should provide that as
well.

If you really do need to implement your own security, it would be better to
add this at the app server level, not struts.

Taylor

-Original Message-
From: Phase Communcations [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, December 12, 2001 9:54 AM
To: Struts Developers List
Subject: RE: role based actions


The ldap portion is under development. It will be a bit. My code is a struts
centric security at this point. I am experimenting with extending it to
support ldap. I can still show you the code for the security if you would
like.

Brandon Goodin
Phase Web and Multimedia
P (406) 862-2245
F (406) 862-0354
[EMAIL PROTECTED]
http://www.phase.ws


-Original Message-
From: Dr. BaTien Duong [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, December 11, 2001 5:53 PM
To: Struts Developers List
Subject: Re: role based actions


Brandon:

I am interested in your code as we are working on Struts, ldap, and Java
single SignOn technology.

[EMAIL PROTECTED]

- Original Message -
From: "Phase Communcations" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Tuesday, December 11, 2001 4:43 PM
Subject: RE: role based actions


> One last thing. When a security check happens and the user is forwarded to
> the login. Their desired destination is stored and once their security is
> verified they are forwarded on to that page.
>
> -Original Message-
> From: Phase Communcations [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, December 11, 2001 4:40 PM
> To: Struts Developers List
> Subject: RE: role based actions
>
>
> In my code I extended the action class (not the action servlet) and
required
> that group access be established on a per extended action class basis.
>
> Defined within my struts-config file in my action class definitions I use
an
> extra attribute(s):
>
> 
>
> There is a security check within the extended action class that uses an
> extended ActionMapping to retrieve the "group" property and checks it
> against the users information (in a database). If the user belongs to the
> proper group or one of the groups defined then it allows them access to
that
> action/area with their assigned role and permissions. If the security
check
> fails, they are routed to a login page.
>
> The other thing that it does is it stores role and permission information
in
> a bean so that security information can be used to define the view as
well.
>
> I opted out of the container managed security because I was working under
> Tomcat 3.2.3 and am trying to create a more independent security model.
This
> model also works well for me because I use the command line url format for
> mapping to my action classes and none of my views are available but
through
> action classes (except index.jsp).
>
> I would be happy to share my code if anyone is interested. I think it is
> flexible enough that it could be incorporated into an ldap system. I have
> been confeing with a colleague who is working on struts interacting with
> ldap for security and profile management.
>
> Anyways if you like the idea of security being managed from the action
class
> and don't expose your views but through action mappings. This might be a
> good solution
>
> Brandon Goodin
> Phase Web and Multimedia
> P (406) 862-2245
> F (406) 862-0354
> [EMAIL PROTECTED]
> http://www.phase.ws
>
>
> -Original Message-
> From: craigmcc@localhost [mailto:craigmcc@localhost]On Behalf Of Craig
> R. McClanahan
> Sent: Tuesday, December 11, 2001 10:16 AM
> To: Struts Developers List
> Subject: Re: role based actions
>
>
>
>
> On Tue, 11 Dec 2001 [EMAIL PROTECTED] wrote:
>
> > Date: Tue, 11 Dec 2001 10:27:52 -0500
> > From: [EMAIL PROTECTED]
> > Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Subject: role based actions
> >
> >
> > I am a struts "newbie" so I apologize in advance if this topic has
already
> > beaten to death...
> >
> >  ~~~
> >
> > I noticed role-based actions on the pending tasks list.
>
> Adding this (and a few of the other recent enhancements) to Struts 1.1 is
> definitely on *my* list.  I will have some time to do so between Christmas
> and New Years.
>
> Craig McClanahan
>
> >
> > Can anyone comment on the status and scope of this effort? (link was a
> dead
> > end)
> >
> > The description points to role being driven by security, seems the role
> will
> > be detected and then dispatches to the proper action? points to assoc'd
> form
> > through config?
> >
> > Is this intended to be used for personalization to the extent where a
> person
> > of one role gets a different view, ca

RE: role based actions

[Phase Communcations]

That's good advice. Thanks. I currently am "required" to run Tomcat 3.2.3 so
I decided to go the "hack path" and include my security in struts and hide
all my views(jsp) behind command style urls (no *.do). Yet my code is
flexible enough to take advantage of the container managed security when I
move up to tomcat 4.0 (servlet 2.3/jsp 1.2). Thanks for your direction.

Brandon Goodin
Phase Web and Multimedia
P (406) 862-2245
F (406) 862-0354
[EMAIL PROTECTED]
http://www.phase.ws


-Original Message-
From: Taylor Cowan [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, December 12, 2001 7:18 AM
To: Struts Developers List
Subject: RE: role based actions


Struts is a J2EE add on, thus it should only be aware of J2EE concepts like
"roles".
J2EE provides security through the app server, and the concrete security
scheme may be ldap, jdbc, or other means.  Struts doesn't need security, it
just makes use of J2EE security.  I was just looking over Tomcat and it can
be configured to use LDAP.  Most other app servers should provide that as
well.

If you really do need to implement your own security, it would be better to
add this at the app server level, not struts.

Taylor

-Original Message-
From: Phase Communcations [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, December 12, 2001 9:54 AM
To: Struts Developers List
Subject: RE: role based actions


The ldap portion is under development. It will be a bit. My code is a struts
centric security at this point. I am experimenting with extending it to
support ldap. I can still show you the code for the security if you would
like.

Brandon Goodin
Phase Web and Multimedia
P (406) 862-2245
F (406) 862-0354
[EMAIL PROTECTED]
http://www.phase.ws


-Original Message-
From: Dr. BaTien Duong [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, December 11, 2001 5:53 PM
To: Struts Developers List
Subject: Re: role based actions


Brandon:

I am interested in your code as we are working on Struts, ldap, and Java
single SignOn technology.

[EMAIL PROTECTED]

- Original Message -
From: "Phase Communcations" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Tuesday, December 11, 2001 4:43 PM
Subject: RE: role based actions


> One last thing. When a security check happens and the user is forwarded to
> the login. Their desired destination is stored and once their security is
> verified they are forwarded on to that page.
>
> -Original Message-
> From: Phase Communcations [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, December 11, 2001 4:40 PM
> To: Struts Developers List
> Subject: RE: role based actions
>
>
> In my code I extended the action class (not the action servlet) and
required
> that group access be established on a per extended action class basis.
>
> Defined within my struts-config file in my action class definitions I use
an
> extra attribute(s):
>
> 
>
> There is a security check within the extended action class that uses an
> extended ActionMapping to retrieve the "group" property and checks it
> against the users information (in a database). If the user belongs to the
> proper group or one of the groups defined then it allows them access to
that
> action/area with their assigned role and permissions. If the security
check
> fails, they are routed to a login page.
>
> The other thing that it does is it stores role and permission information
in
> a bean so that security information can be used to define the view as
well.
>
> I opted out of the container managed security because I was working under
> Tomcat 3.2.3 and am trying to create a more independent security model.
This
> model also works well for me because I use the command line url format for
> mapping to my action classes and none of my views are available but
through
> action classes (except index.jsp).
>
> I would be happy to share my code if anyone is interested. I think it is
> flexible enough that it could be incorporated into an ldap system. I have
> been confeing with a colleague who is working on struts interacting with
> ldap for security and profile management.
>
> Anyways if you like the idea of security being managed from the action
class
> and don't expose your views but through action mappings. This might be a
> good solution
>
> Brandon Goodin
> Phase Web and Multimedia
> P (406) 862-2245
> F (406) 862-0354
> [EMAIL PROTECTED]
> http://www.phase.ws
>
>
> -Original Message-
> From: craigmcc@localhost [mailto:craigmcc@localhost]On Behalf Of Craig
> R. McClanahan
> Sent: Tuesday, December 11, 2001 10:16 AM
> To: Struts Developers List
> Subject: Re: role based actions
>
>
>
>
> On Tue, 11 Dec 2001 [EMAIL PROTECTED] wrote:
>
> > Date: Tue, 11 Dec 2001 10:27:52 -0500
> > From: [EMAIL PROTECTED]
> > Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Subject: role based actions
> >
> >
> > I am a struts "newbie" so I apologize in advance if this topic has
already
> > beaten to death...
> >
> >  ~~~
> >
> > I n

Re[2]: format Attribute

[Oleg V Alexeev]

Hello Volker,

Here is one problem... java.util.Date can hold date-time values. So if
formatting process always take java.util.Date values to format as Date
then time part of value always will be unaccessable.

I agree with you - java.util.Date values must be converted as Date
values too. But how do we switch between Date, Time and Date-Time
values?

I view one way to solve such problem - add formatKey attribute to hold
key to retrieve format string from resources.

Wednesday, December 12, 2001, 5:23:37 PM, you wrote:

VK> Volker Krebs wrote:

>> Hello,
>> 
>> I wanted to use the new  format mechanism,
>> I specified my format strings in the message resources.
>> So far so good ... everything was fine, but when I changed the
>> user locale with Action.setLocale() nothing happend for
>> FLOAT_FORMAT_KEY.
>> The Problem is in
>> org.apache.struts.taglib.bean.WriteTag.formatValue(...)
>> after line 318.

VK> Ok thanks for fixing that, I found somethig else,
VK> if we have a java.util.Date a toString is printed.

VK> } else if ((value instanceof java.sql.Date) ||
VK>   value instanceof java.util.Date) { //check also for util.Date
VK>formatStr = RequestUtils.message(pageContext, this.bundle,
VK>this.localeKey, DATE_FORMAT_KEY);
VK> }

VK> You also have to check if the type is java.util.Date and
VK> use the DATE_FORMAT_KEY for this type.

VK> thanks

VK> Volker


VK> --
VK> To unsubscribe, e-mail:   
VK> For additional commands, e-mail: 



-- 
Best regards,
 Olegmailto:[EMAIL PROTECTED]



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-struts/src/share/org/apache/struts/taglib/bean WriteTag.java

[oalexeev]

oalexeev01/12/12 08:11:00

  Modified:src/share/org/apache/struts/taglib/bean WriteTag.java
  Log:
  Remove default formatting code for numbers - pass it to the toString() method. Fixed 
by letter from -
  Deadman, Hal <[EMAIL PROTECTED]>
  
  Revision  ChangesPath
  1.15  +5 -7  
jakarta-struts/src/share/org/apache/struts/taglib/bean/WriteTag.java
  
  Index: WriteTag.java
  ===
  RCS file: 
/home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/bean/WriteTag.java,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- WriteTag.java 2001/12/12 14:11:30 1.14
  +++ WriteTag.java 2001/12/12 16:11:00 1.15
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/bean/WriteTag.java,v 1.14 
2001/12/12 14:11:30 oalexeev Exp $
  - * $Revision: 1.14 $
  - * $Date: 2001/12/12 14:11:30 $
  + * $Header: 
/home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/bean/WriteTag.java,v 1.15 
2001/12/12 16:11:00 oalexeev Exp $
  + * $Revision: 1.15 $
  + * $Date: 2001/12/12 16:11:00 $
*
* 
*
  @@ -89,7 +89,7 @@
* output stream, optionally filtering characters that are sensitive in HTML.
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.14 $ $Date: 2001/12/12 14:11:30 $
  + * @version $Revision: 1.15 $ $Date: 2001/12/12 16:11:00 $
*/
   
   public class WriteTag extends TagSupport {
  @@ -318,9 +318,7 @@
   if( formatStr!=null ) 
   formatStrFromResources = true;
   }
  -if( formatStr==null )
  -format = NumberFormat.getInstance( locale );
  -else {
  +if( formatStr!=null ) {
   try {
   format = NumberFormat.getNumberInstance( locale );
   if( formatStrFromResources ) 
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Well-formed HTML support in struts 1.01+ !!

[Craig R. McClanahan]

On Wed, 12 Dec 2001, Morten M. Christensen wrote:

> Date: Wed, 12 Dec 2001 12:28:57 +0100
> From: Morten M. Christensen <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Well-formed HTML support in struts 1.01+ !!
>
> At our company we have been using struts 1.0 since the release and very
> glad for it... Until recently, where we have shocked by the discovery
> that structs 1.0 breaks all out attempts at produce well-formed HTML!
>

Well-formed HTML and well-formed XHTML (which is really just an
application of XML) are two different things.

> Our situation is that we now need to output well-formed HTML (we will
> probably use XHTML), in order to do easy post processing in XSL/Java for
> various nice things like automated GUI testing (all extremely important
> and requires well-formed HTML / XHTML).
>

All of the Struts tags in 1.0 generate well-formed HTML tags, in
accordance with the W3C HTML Specification.

For XHTML, some recent work has been done in the HEAD branch (and
therefore available through the nightly builds) to give you the option to
create well-formed XHTML instead.  Simply do the following:


  ...


and the rendered tags will all be compatible with XML syntax, as XHTML
requires.


> At first we have tried to close all our struts tags (ex.  -
> note the space needed for some old browsers) but to no avail. Struts
> just ignores our attempts at closing the tags.

This doesn't work because a Struts tag is really a JSP custom action call.
The actual HTML that is rendered is created by the tag itself.

>
> What can we do now? I would not like to either drop struts or drop our
> automated tests as well as other critial things that depends on
> well-formed HTML. I would therefore request that the struts developers
> find some way of at least minimal support for generating well formed
> HTML (and please do not suggest simply using TIDY or something like that
> - it does not work ; at least for us it does not).
>
> BTW: From searching the web I saw another posting about this from a
> "Matt Raible" (?), mentioning briefly some uncommitted code that could
> solve this (where, how ?). Would that be possible to just include that
> in 1.0.1 (it would need to be official so that we can count on it for
> the future).
>

See above.

> Sincerely,
> Morten Christensen,
> AArhus, Denmark
>


Craig



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 5395] New: - ActionContext class

[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=5395

ActionContext class

   Summary: ActionContext class
   Product: Struts
   Version: Nightly Build
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Controller
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Draft source code for a new action class, ActionContext. This is a helper object 
to expose the Struts shared resource which are be stored in the application, 
session, or request contexts, as appropriate. An instance should be created for 
each request processed. The  methods which return resources from
the request or session contexts are not thread-safe. Provided for use by other 
servlets in the application so they can easily access the Struts shared resource 
The resources are stored under attributes in the application, session, or 
request contexts. The ActionContext methods simply return the resource from 
under the context and key used by the Struts. 

This is being tested in conjunction with a Velocity servlet. The ActionContext 
is introduced into the VelocityContext as a object named get. This then lets the 
velocity template designers to chant:

$!get.message("index.title")

where a JSP would use 

mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: 

DO NOT REPLY [Bug 5395] - ActionContext class

[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=5395

ActionContext class





--- Additional Comments From [EMAIL PROTECTED]  2001-12-12 13:03 ---
Created an attachment (id=891)
ActionContext source code

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Freetext attribute for all tags...

[Colin Sharples]

One last comment on this - have a look at the following sites:

http://www.anybrowser.org/campaign/

http://www.webstandards.org/upgrade/

which present two other sides to the story:

1) by using browser-specific code you actively discriminate against those
who have no option but to use something other than NS or IE (e.g. blind
people who need a text-based browser).

2) the recent versions of most browsers, including the big 2, support all
the relevant standards anyway, so there's simply no need to be
browser-specific.

That's reality for ya...

Regards

Colin M Sharples
I/T Architect
IBM Global Services New Zealand

email: [EMAIL PROTECTED]
phone: 64-4-5769853
mobile: 64-21-402085
fax: 64-4-5765616




   
  
Arron Bates
  

onkey.com> cc: 
  
   Subject: Re: Freetext attribute for all 
tags...   
12/12/2001 11:29   
  
Please respond 
  
to "Struts 
  
Developers List"   
  
   
  
   
  



It's all reality. Standards and non-compliant realities alike.

Take the new DOM scripting model... NS copied IE in the
getElementById()... why... because it's truly sweet. But it's not in the
spec. It's an example where the spec is not as good as the
implementation. W3C are recommendations, and should be treaded as such.
I truly feel supporting them only to the limits of their definition is
as bad in a "reality" sense as letting everything through flood-gate
style (Like an NS4 layer tag. There's a standard for ya :).

It's also a chicken and the egg situation. Specs are more of a snapshot
of the here, now and has been. Someone has to break the new ground and
implement something for the idea to be had and the need created. Like
the NS4 layer tag.


But, a committer has already said no, so everything else as they say is
"pissing in the wind".
(It's good to remind people the rules of the system, thanks Ted.)


With that, I'm going to get back to my day job.
:)

Arron.


Ted Husted wrote:

>Jon Wall wrote:
>
>>Do you want Struts to be a framework for building just
>>mass-market web sites (portals, ecommerce, etc)??
>>
>
>It's my personal feeling that we are providing the tag extensions as a
>convenience, and that they are ancilliary to the actual framework. I
>think this will become more evident as other presentation systems, like
>Velocity, come to support Struts.
>
>With the rise of Jakarta Taglibs and the JSPTL, there are fewer and
>fewer reasons for us to host our own tag extensions. Something that is
>forefront in my mind right now, is that we should continue to stay the
>course on the extensions during this transitional period.
>
>As it stands, any tag you might want to use can easily be created using
>bean:write or html:write, and the best thing to do might be for us
>(meaning me) to better document those techniques.
>
>And, as it stands, there is nothing to prevent people from using their
>own tag extensions with Struts. I think as team we encourage that idea
>whenever we can. If someone wanted to create and maintain their a set of
>tag extensions, that supported non-standard attributes, we'd be happy to
>link to those from the Resource page. But someone else will have to
>accept that burden.
>
>-- Ted Husted, Husted dot Com, Fairport NY USA.
>-- Custom Software ~ Technical Services.
>-- Tel +1 716 737-3463
>-- http://www.husted.com/struts/
>
>--
>To unsubscribe, e-mail:   <
mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: <
mailto:[EMAIL PROTECTED]>
>



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

JSR 159?

[Allen]

Hi,

I was just looking over JSR 159 (http://jcp.org/jsr/detail/159.jsp) and
was wondering if this will have any impact on Struts (it is still a ways
off, but I thought I would ask).

Specifically, I thought that this MAY be related (but, maybe I am
reading too much into it):
 "JPCs will not obsolete the existing J2EE
component models - JSPs, Servlets and EJBs.
  These models will continue to be the basic
building blocks of J2EE applications. The JPC
  component model will provide a mechanism
for layering a process level abstraction over these
  components. In effect, it will be a way to
aggregate a combination of JSPs, Servlets and EJBs
  to form a process level component. This
means that JPC will introduce a minimum of new
  programming concepts and will focus
primarily on the 'binding' of a process definition to its
  implementation as J2EE components."

Allen


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: JSR 159?

[Craig R. McClanahan]

On Wed, 12 Dec 2001, Allen wrote:

> Date: Wed, 12 Dec 2001 17:14:12 -0500
> From: Allen <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Dev <[EMAIL PROTECTED]>
> Subject: JSR 159?
>
> Hi,
>
> I was just looking over JSR 159 (http://jcp.org/jsr/detail/159.jsp) and
> was wondering if this will have any impact on Struts (it is still a ways
> off, but I thought I would ask).
>

It's likely to be more in the "workflow" space than in Struts
particularly, although it could possibly provide Struts developers a way
to compose their Actions out of existing EJBs.

Craig


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Freetext attribute for all tags...

[Arron Bates]

(I do apologise for this post. It should stop. But for some reason I 
just can't handle misrepresentation of trying to get markup to work in 
the largest amount of browsers possible (both those inside and outside 
the spec). So, if you don't want to hear a rant in reply to a rant, read 
another email...)


Actually Colin,

Both your points are misplaced, and you're trying to become a champion 
of "correctness" and I find it arrogant and ignorant that you're trying 
to publish that the need to create a page that works on *more* browsers 
is "incorrect".

As for your points...

1) I don't discriminate. In fact... this is all about going the extra 
step to make sure I *don't* discriminate. And that includes older 
browsers. You're talking in terms of *only* using non-standard 
attributes, where in reality they're actually used along side. If a 
browser doesn't support them, their presence doesn't effect them. So 
"marginwidth" works great in IE & NS6, but NS4 will ignore it. I use 
also "leftmargin" & "rightmargin" in the same tag and NS4 will use them 
and IE & NS6 will ignore them. Result, a page that works in all 4+ 
browsers, and discriminates nobody.

2) It's not about being "browser-specific". As above, it's about 
including specific attributes amongst standard ones. Not "just using the 
specific ones".


So considering all this... the pages I markup work on more browsers than 
the ones you do, because I'm not bound by the spec. This means... I have 
a potentially larger user base. Take this little piece of information to 
a potential client/employer... What's reality?...

I am so over this conversation.


Arron.

* Does a bandwagon go faster if it's painted red?...


Colin Sharples wrote:

>One last comment on this - have a look at the following sites:
>
>http://www.anybrowser.org/campaign/
>
>http://www.webstandards.org/upgrade/
>
>which present two other sides to the story:
>
>1) by using browser-specific code you actively discriminate against those
>who have no option but to use something other than NS or IE (e.g. blind
>people who need a text-based browser).
>
>2) the recent versions of most browsers, including the big 2, support all
>the relevant standards anyway, so there's simply no need to be
>browser-specific.
>
>That's reality for ya...
>
>Regards
>
>Colin M Sharples
>I/T Architect
>IBM Global Services New Zealand
>
>email: [EMAIL PROTECTED]
>phone: 64-4-5769853
>mobile: 64-21-402085
>fax: 64-4-5765616
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Documentation

[David Morris]

Developers,

I appreciate all of the hard work you have done to produce Struts,
which has saved me hundreds of hours. Twice now I have used an
unsupported, but documented tag feature only to discover that the
feature is only supported in the nightly builds. Is there some way that
this could be indicated in the documentation -- something like
implemented in 1.01? This would be like the JavaDoc that comes with
Sun's JDKs. I would find it very useful and from the user mailing list,
I think others have run into this. 

I am willing to help get this added, but I don't have a clue how to do
it. If it helps, I could add a bug (is this a bug?) when I encounter
this.

Thanks,

David Morris 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Freetext attribute for all tags...

[Colin Sharples]

LOL :-) Gotta love that Parthian shot...

I agree it's pointless going on, so we should agree to disagree. However,
I'd like to point out that the web sites I referred to in my previous post
do not necessarily reflect my point of view - and indeed they are probably
contradictory to each other. I felt they were relevant to the debate,
though.

Anyway, 'nuff distractions, back to the real work...

Regards

Colin M Sharples
I/T Architect
IBM Global Services New Zealand

email: [EMAIL PROTECTED]
phone: 64-4-5769853
mobile: 64-21-402085
fax: 64-4-5765616




   
  
Arron Bates
  

onkey.com> cc: 
  
   Subject: Re: Freetext attribute for all 
tags...   
13/12/2001 13:03   
  
Please respond 
  
to "Struts 
  
Developers List"   
  
   
  
   
  



(I do apologise for this post. It should stop. But for some reason I
just can't handle misrepresentation of trying to get markup to work in
the largest amount of browsers possible (both those inside and outside
the spec). So, if you don't want to hear a rant in reply to a rant, read
another email...)


Actually Colin,

Both your points are misplaced, and you're trying to become a champion
of "correctness" and I find it arrogant and ignorant that you're trying
to publish that the need to create a page that works on *more* browsers
is "incorrect".

As for your points...

1) I don't discriminate. In fact... this is all about going the extra
step to make sure I *don't* discriminate. And that includes older
browsers. You're talking in terms of *only* using non-standard
attributes, where in reality they're actually used along side. If a
browser doesn't support them, their presence doesn't effect them. So
"marginwidth" works great in IE & NS6, but NS4 will ignore it. I use
also "leftmargin" & "rightmargin" in the same tag and NS4 will use them
and IE & NS6 will ignore them. Result, a page that works in all 4+
browsers, and discriminates nobody.

2) It's not about being "browser-specific". As above, it's about
including specific attributes amongst standard ones. Not "just using the
specific ones".


So considering all this... the pages I markup work on more browsers than
the ones you do, because I'm not bound by the spec. This means... I have
a potentially larger user base. Take this little piece of information to
a potential client/employer... What's reality?...

I am so over this conversation.


Arron.

* Does a bandwagon go faster if it's painted red?...


Colin Sharples wrote:

>One last comment on this - have a look at the following sites:
>
>http://www.anybrowser.org/campaign/
>
>http://www.webstandards.org/upgrade/
>
>which present two other sides to the story:
>
>1) by using browser-specific code you actively discriminate against those
>who have no option but to use something other than NS or IE (e.g. blind
>people who need a text-based browser).
>
>2) the recent versions of most browsers, including the big 2, support all
>the relevant standards anyway, so there's simply no need to be
>browser-specific.
>
>That's reality for ya...
>
>Regards
>
>Colin M Sharples
>I/T Architect
>IBM Global Services New Zealand
>
>email: [EMAIL PROTECTED]
>phone: 64-4-5769853
>mobile: 64-21-402085
>fax: 64-4-5765616
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

form initialization

[Jon Burford]

Greetings!

I have a dynamic form which needs to be initialized from the database.  If I put code 
to initialize the attributes in the default constructor of the form bean, all this 
happens with no problems - the form is displayed with the proper values.  My problem 
is that the form bean needs some of the request parameters from the calling jsp page 
in order to properly initialize its fields.  What is the preferred way of form bean 
initialization and how can it access request parameters at initialization time?  I 
used a couple hidden form fields which the jsp page initialized to the corresponding 
request parameters, but this does not take effect until AFTER the constructor is 
called.  Any help would be much appreciated.

TIA!
Jon

Re: form initialization

[Arron Bates]

The only way which I've done such a thing is with a bean nested one 
level inside another.

The constructor is called on the root bean, and have getters and setters 
there waiting to handle the parameters that you're passing from your 
form. In your action, call another method which will then build the 
nested bean with everything which you need from the database. From then 
in, reference properties in the internal bean via nested properties.

So the sequence happens like this

1) Form is submitted with parameters needed to load the bean.
2) The constructor is called in the root bean and an empty root bean is 
made.
3) Struts servlet will populate properties with your init parameters.
4) In your action, call a method like "initInternalBean()" or something.
5) Inside this method, access the properties which were set by the form, 
and build an internal bean to what you need..
6) If you have a simple getter method to access the bean you can get to 
the properties you need via nested properties which you can use 
thereafter in your JSP's etc.
eg.  "internalBean.beanProperty"

Is this enough to get across what I'm trying to say?...
I can provide a simple code snippet if it's not.
If you're worried about managing nested objects in your JSP's I can 
help there too. ;)


Arron.

Jon Burford wrote:

>Greetings!
>
>I have a dynamic form which needs to be initialized from the database.  If I put code 
>to initialize the attributes in the default constructor of the form bean, all this 
>happens with no problems - the form is displayed with the proper values.  My problem 
>is that the form bean needs some of the request parameters from the calling jsp page 
>in order to properly initialize its fields.  What is the preferred way of form bean 
>initialization and how can it access request parameters at initialization time?  I 
>used a couple hidden form fields which the jsp page initialized to the corresponding 
>request parameters, but this does not take effect until AFTER the constructor is 
>called.  Any help would be much appreciated.
>
>TIA!
>Jon
>
>



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: form initialization

[Craig R. McClanahan]

On Wed, 12 Dec 2001, Jon Burford wrote:

> Date: Wed, 12 Dec 2001 20:40:34 -0800
> From: Jon Burford <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: form initialization
>
> Greetings!
>
> I have a dynamic form which needs to be initialized from the database.
> If I put code to initialize the attributes in the default constructor
> of the form bean, all this happens with no problems - the form is
> displayed with the proper values.  My problem is that the form bean
> needs some of the request parameters from the calling jsp page in
> order to properly initialize its fields.  What is the preferred way of
> form bean initialization and how can it access request parameters at
> initialization time?  I used a couple hidden form fields which the jsp
> page initialized to the corresponding request parameters, but this
> does not take effect until AFTER the constructor is called.  Any help
> would be much appreciated.
>

This type of question is really more suited for the STRUTS-USER list.

The design pattern I prefer is exemplified in the Struts Example
application -- use an Action to set up the form bean *before* the form is
displayed.

In the example app, note how an "Edit Subscription" transaction is
handled:

* The "/editSubscription" action is called to pre-fill the
  SubscriptionForm bean and place it in request scope.  If you
  need values from the request that triggered this, they are
  accessible to the Action and it can call setters as needed.

* This action forwards to "subscription.jsp" which shows the
  pre-filled-out form.

* The submit goes to the "/saveSubscription" action which
  updates the database (assuming successful validation).

> TIA!
> Jon
>
>

Craig McClanahan



--
To unsubscribe, e-mail:   
For additional commands, e-mail: