You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by GR...@intellicare.com on 2005/08/08 21:46:28 UTC
[OT]Terrific intro to JSF
Hi all:
i know it isn't Friday yet.. ;) but .. in case you have been looking for a
nice and clear introduction to JSF, look no further. Here it is:
http://www-128.ibm.com/developerworks/java/library/j-jsf1/
I have only just completed the first article - and can't wait to get to
the next three! - but the first article is just *fantastic*. It's
articles like these which make Java almost too much fun..:)
Geeta
Re: [OT]Terrific intro to JSF
Posted by Craig McClanahan <cr...@gmail.com>.
On 8/10/05, Daniel Perry <d....@netcase.co.uk> wrote:
> My reasoning behind all this stuff, is i HATE all these xml config files.
> Or more accurately, I like xml config files, but I hate moving between X
> different xml files. It might suit IDEs, but it aint right for humans!
> You've got a jsp page with <html:text> - why cant i put validation, type
> (for dynamic bean handling), etc there, rather than looking at various
> different xml files.
>
If you hate hand editing XML files, why do it? That's what tool are
for ... and this applies to Struts just as much as it does to JSF.
IDEs can deal with this, but they are not required -- go get Faces
Console or Struts Console from jamesholmes.com and "be done" with
editing XML files yourself. You can use these gadgets either
standalone or as plugins to your favorite IDE.
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Trim all fields before validation
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Sounds good. I certainly understand the jitters, my organization is
very much like that as well (in fact, I had to sneak some JWP code in
too, disguised as part of the app itself!) Just wanted to know if there
was a problem with it that I could have done something about. As always
though, I very much appreciate any feedback, so if you do have any
suggestions down the road, I'll be here :)
Frank
Dilip Ladhani wrote:
> I am going to try that out in our new application Frank. The "trim"
> issue was with our older app, which is the big sustaining force (cash
> cow) for our company, and I wasn't able to push through the new jar and
> web.xml changes there, as people are nervous whenever I suggest anything
> major there.
>
> I do like the JWP concept, and will try it out in our new app and let
> you know of any shortcommings I find. Thanks for your help and your work
> in making it available.
>
> Dilip
>
>
>> From: "Frank W. Zammetti" <fz...@omnytex.com>
>> Reply-To: fzlists@omnytex.com
>> To: Struts Users Mailing List <us...@struts.apache.org>
>> Subject: Re: Trim all fields before validation
>> Date: Thu, 01 Sep 2005 14:57:36 -0400
>>
>> The ParameterMungerFilter in JWP didn't do the trick for you? I'd
>> love to know what shortcomings you found so that I can work to improve
>> it :)
>>
>> Frank
>>
>> Dilip Ladhani wrote:
>>
>>> I am not a fan of javascript, I know, I can use this, but I have
>>> always had browser compatibility issues with javascript. I still use
>>> javascript, when absolutely necessary, but I prefer to avoid it.
>>>
>>> As far as "required" goes, that probably won't work because I could
>>> have a string like " test " which would pass the "required
>>> test, wouldn't it? unless I misunderstood what you are suggesting.
>>>
>>> I did try a generic loop as per Joe's suggestion and that worked
>>> pretty well. Here is a what I did.
>>>
>>> java.util.Map map = thisForm.getMap();
>>> java.util.Iterator it = map.keySet().iterator();
>>> while(it.hasNext()){
>>> String key = (String) it.next();
>>> Object obj = map.get(key);
>>> if (obj instanceof String){
>>> obj = ((String) obj).trim();
>>> }
>>> else if(obj instanceof String[]){
>>> String[] temp = (String[]) obj;
>>> for(int i=0;i<temp.length; i++){
>>> temp[i] = temp[i].trim();
>>> }
>>> obj = temp;
>>> }
>>> map.put(key, obj);
>>> }
>>>
>>>
>>>> From: Kishore Senji <ki...@gmail.com>
>>>> Reply-To: "Struts Users Mailing List" <us...@struts.apache.org>
>>>> To: Struts Users Mailing List <us...@struts.apache.org>
>>>> Subject: Re: Trim all fields before validation
>>>> Date: Thu, 1 Sep 2005 09:40:42 -0700
>>>>
>>>> Wouldn't this be easier, without mucking with the form, to let this be
>>>> handled by the validator itself. For any field validation you would
>>>> just
>>>> have to have the "requires" validation before you do any other
>>>> validation,
>>>> and that way you would take care of empty strings or as Joe said you
>>>> could
>>>> do this in javascript as well pretty easily.
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: user-help@struts.apache.org
>>>
>>>
>>>
>>>
>>>
>>
>> --
>> Frank W. Zammetti
>> Founder and Chief Software Architect
>> Omnytex Technologies
>> http://www.omnytex.com
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>
>
>
>
>
>
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Trim all fields before validation
Posted by Dilip Ladhani <di...@hotmail.com>.
I am going to try that out in our new application Frank. The "trim" issue
was with our older app, which is the big sustaining force (cash cow) for our
company, and I wasn't able to push through the new jar and web.xml changes
there, as people are nervous whenever I suggest anything major there.
I do like the JWP concept, and will try it out in our new app and let you
know of any shortcommings I find. Thanks for your help and your work in
making it available.
Dilip
>From: "Frank W. Zammetti" <fz...@omnytex.com>
>Reply-To: fzlists@omnytex.com
>To: Struts Users Mailing List <us...@struts.apache.org>
>Subject: Re: Trim all fields before validation
>Date: Thu, 01 Sep 2005 14:57:36 -0400
>
>The ParameterMungerFilter in JWP didn't do the trick for you? I'd love to
>know what shortcomings you found so that I can work to improve it :)
>
>Frank
>
>Dilip Ladhani wrote:
>>I am not a fan of javascript, I know, I can use this, but I have always
>>had browser compatibility issues with javascript. I still use javascript,
>>when absolutely necessary, but I prefer to avoid it.
>>
>>As far as "required" goes, that probably won't work because I could have a
>>string like " test " which would pass the "required test, wouldn't
>>it? unless I misunderstood what you are suggesting.
>>
>>I did try a generic loop as per Joe's suggestion and that worked pretty
>>well. Here is a what I did.
>>
>>java.util.Map map = thisForm.getMap();
>>java.util.Iterator it = map.keySet().iterator();
>>while(it.hasNext()){
>> String key = (String) it.next();
>> Object obj = map.get(key);
>> if (obj instanceof String){
>> obj = ((String) obj).trim();
>> }
>> else if(obj instanceof String[]){
>> String[] temp = (String[]) obj;
>> for(int i=0;i<temp.length; i++){
>> temp[i] = temp[i].trim();
>> }
>> obj = temp;
>> }
>>map.put(key, obj);
>>}
>>
>>
>>>From: Kishore Senji <ki...@gmail.com>
>>>Reply-To: "Struts Users Mailing List" <us...@struts.apache.org>
>>>To: Struts Users Mailing List <us...@struts.apache.org>
>>>Subject: Re: Trim all fields before validation
>>>Date: Thu, 1 Sep 2005 09:40:42 -0700
>>>
>>>Wouldn't this be easier, without mucking with the form, to let this be
>>>handled by the validator itself. For any field validation you would just
>>>have to have the "requires" validation before you do any other
>>>validation,
>>>and that way you would take care of empty strings or as Joe said you
>>>could
>>>do this in javascript as well pretty easily.
>>
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>>
>>
>>
>
>--
>Frank W. Zammetti
>Founder and Chief Software Architect
>Omnytex Technologies
>http://www.omnytex.com
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>For additional commands, e-mail: user-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Trim all fields before validation
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
The ParameterMungerFilter in JWP didn't do the trick for you? I'd love
to know what shortcomings you found so that I can work to improve it :)
Frank
Dilip Ladhani wrote:
> I am not a fan of javascript, I know, I can use this, but I have always
> had browser compatibility issues with javascript. I still use
> javascript, when absolutely necessary, but I prefer to avoid it.
>
> As far as "required" goes, that probably won't work because I could have
> a string like " test " which would pass the "required test,
> wouldn't it? unless I misunderstood what you are suggesting.
>
> I did try a generic loop as per Joe's suggestion and that worked pretty
> well. Here is a what I did.
>
> java.util.Map map = thisForm.getMap();
> java.util.Iterator it = map.keySet().iterator();
> while(it.hasNext()){
> String key = (String) it.next();
> Object obj = map.get(key);
> if (obj instanceof String){
> obj = ((String) obj).trim();
> }
> else if(obj instanceof String[]){
> String[] temp = (String[]) obj;
> for(int i=0;i<temp.length; i++){
> temp[i] = temp[i].trim();
> }
> obj = temp;
> }
> map.put(key, obj);
> }
>
>
>> From: Kishore Senji <ki...@gmail.com>
>> Reply-To: "Struts Users Mailing List" <us...@struts.apache.org>
>> To: Struts Users Mailing List <us...@struts.apache.org>
>> Subject: Re: Trim all fields before validation
>> Date: Thu, 1 Sep 2005 09:40:42 -0700
>>
>> Wouldn't this be easier, without mucking with the form, to let this be
>> handled by the validator itself. For any field validation you would just
>> have to have the "requires" validation before you do any other
>> validation,
>> and that way you would take care of empty strings or as Joe said you
>> could
>> do this in javascript as well pretty easily.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
>
>
>
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Trim all fields before validation
Posted by Dilip Ladhani <di...@hotmail.com>.
I am not a fan of javascript, I know, I can use this, but I have always had
browser compatibility issues with javascript. I still use javascript, when
absolutely necessary, but I prefer to avoid it.
As far as "required" goes, that probably won't work because I could have a
string like " test " which would pass the "required test, wouldn't it?
unless I misunderstood what you are suggesting.
I did try a generic loop as per Joe's suggestion and that worked pretty
well. Here is a what I did.
java.util.Map map = thisForm.getMap();
java.util.Iterator it = map.keySet().iterator();
while(it.hasNext()){
String key = (String) it.next();
Object obj = map.get(key);
if (obj instanceof String){
obj = ((String) obj).trim();
}
else if(obj instanceof String[]){
String[] temp = (String[]) obj;
for(int i=0;i<temp.length; i++){
temp[i] = temp[i].trim();
}
obj = temp;
}
map.put(key, obj);
}
>From: Kishore Senji <ki...@gmail.com>
>Reply-To: "Struts Users Mailing List" <us...@struts.apache.org>
>To: Struts Users Mailing List <us...@struts.apache.org>
>Subject: Re: Trim all fields before validation
>Date: Thu, 1 Sep 2005 09:40:42 -0700
>
>Wouldn't this be easier, without mucking with the form, to let this be
>handled by the validator itself. For any field validation you would just
>have to have the "requires" validation before you do any other validation,
>and that way you would take care of empty strings or as Joe said you could
>do this in javascript as well pretty easily.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Trim all fields before validation
Posted by Kishore Senji <ki...@gmail.com>.
Wouldn't this be easier, without mucking with the form, to let this be
handled by the validator itself. For any field validation you would just
have to have the "requires" validation before you do any other validation,
and that way you would take care of empty strings or as Joe said you could
do this in javascript as well pretty easily.
Re: Trim all fields before validation
Posted by Dilip Ladhani <di...@hotmail.com>.
Thanks Ed, I will give this a shot
>From: Ed Griebel <ed...@gmail.com>
>Reply-To: "Struts Users Mailing List" <us...@struts.apache.org>
>To: Struts Users Mailing List <us...@struts.apache.org>
>Subject: Re: Trim all fields before validation
>Date: Wed, 31 Aug 2005 16:13:56 -0400
>
>I just checked the Struts source code, and getMap() returns a
>reference to the internal hash map, so changes to items in the map
>will be reflected in the form bean.
>
>-ed
>
>On 8/31/05, Dilip Ladhani <di...@hotmail.com> wrote:
> > That's correct Ed, but there is no way to set it back, unless I modify
>the
> > code, right?
> >
> >
> > >From: Ed Griebel <ed...@gmail.com>
> > >Reply-To: "Struts Users Mailing List" <us...@struts.apache.org>
> > >To: Struts Users Mailing List <us...@struts.apache.org>
> > >Subject: Re: Trim all fields before validation
> > >Date: Wed, 31 Aug 2005 15:48:30 -0400
> > >
> > >If you don't want to write javascript to do it, Frank's suggestion
> > >looks like your best bet, but I've only looked at the Javadoc not the
> > >code behind it.
> > >
> > >If you want to brute-force it, you can certainly get the map out of a
> > >DynaForm easily enough:
> > >Map values = (DynaValidatorActionForm form).getMap();
> > >
> > >-ed
> > >
> > >On 8/31/05, Dilip Ladhani <di...@hotmail.com> wrote:
> > > > I still need to look at Frank's suggestion. Thanks for your
>suggestions
> > > > Frank and Joe.
> > > >
> > > > So Joe, you would trim all the fields using javascript right? I
> > >understand
> > > > your suggestion. I was hoping that just before I call validate in my
> > >action,
> > > > I could write a generic loop to loop around the keyset (I suppose
>this
> > >is
> > > > not exposed by DynaValidatorActionForm, like it would be for say a
> > >Hahmap)
> > > > and trim all the Strings on the form. But I am not sure how I can
>get
> > >the
> > > > keyset.
> > > >
> > > > Javascript can always work and I do use javascript, but always as a
>last
> > > > resort.
> > > >
> > > > All ideas are welcome.
> > > >
> > > > >From: Joe Germuska <Jo...@Germuska.com>
> > > > >To: "Dilip Ladhani" <di...@hotmail.com>,
>user@struts.apache.org
> > > > >Subject: Re: Trim all fields before validation
> > > > >Date: Wed, 31 Aug 2005 13:58:50 -0500
> > > > >
> > > > >At 2:49 PM -0400 8/31/05, Dilip Ladhani wrote:
> > > > >>Hello all,
> > > > >>
> > > > >>I was searching for the best way to do this.
> > > > >>
> > > > >>I want all the fields on my form to be trimmed before they are
>sent
> > >for
> > > > >>validation (I call validate from my action class). What's the best
>way
> > >to
> > > > >>do this if I have DynaValidatorActionForm?
> > > > >
> > > > >Personally, I'd make this part of an onsubmit handler in the page.
> > > > >
> > > > >You can't really intervene in the form population process on the
>Struts
> > > > >side right now (although arguably that's something which should be
> > >exposed
> > > > >for user customization better).
> > > > >
> > > > >I suppose maybe you could extend DynaValidatorActionForm and try to
> > > > >intervene in how it handles property setting, but it's pretty
>abstract,
> > >so
> > > > >that may be a big challenge.
> > > > >
> > > > >And, of course, you could sacrifice your dynaforms and implement
>your
> > >own
> > > > >form bean classes which trim any non-null string value which is
> > >applied.
> > > > >
> > > > >Joe
> > > > >
> > > > >--
> > > > >Joe Germuska Joe@Germuska.com http://blog.germuska.com
> > > > >"Narrow minds are weapons made for mass destruction" -The Ex
> > > >
> > > >
> > > >
> > > >
>---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > > > For additional commands, e-mail: user-help@struts.apache.org
> > > >
> > > >
> > >
> > >---------------------------------------------------------------------
> > >To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > >For additional commands, e-mail: user-help@struts.apache.org
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
> >
> >
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>For additional commands, e-mail: user-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Trim all fields before validation
Posted by Ed Griebel <ed...@gmail.com>.
I just checked the Struts source code, and getMap() returns a
reference to the internal hash map, so changes to items in the map
will be reflected in the form bean.
-ed
On 8/31/05, Dilip Ladhani <di...@hotmail.com> wrote:
> That's correct Ed, but there is no way to set it back, unless I modify the
> code, right?
>
>
> >From: Ed Griebel <ed...@gmail.com>
> >Reply-To: "Struts Users Mailing List" <us...@struts.apache.org>
> >To: Struts Users Mailing List <us...@struts.apache.org>
> >Subject: Re: Trim all fields before validation
> >Date: Wed, 31 Aug 2005 15:48:30 -0400
> >
> >If you don't want to write javascript to do it, Frank's suggestion
> >looks like your best bet, but I've only looked at the Javadoc not the
> >code behind it.
> >
> >If you want to brute-force it, you can certainly get the map out of a
> >DynaForm easily enough:
> >Map values = (DynaValidatorActionForm form).getMap();
> >
> >-ed
> >
> >On 8/31/05, Dilip Ladhani <di...@hotmail.com> wrote:
> > > I still need to look at Frank's suggestion. Thanks for your suggestions
> > > Frank and Joe.
> > >
> > > So Joe, you would trim all the fields using javascript right? I
> >understand
> > > your suggestion. I was hoping that just before I call validate in my
> >action,
> > > I could write a generic loop to loop around the keyset (I suppose this
> >is
> > > not exposed by DynaValidatorActionForm, like it would be for say a
> >Hahmap)
> > > and trim all the Strings on the form. But I am not sure how I can get
> >the
> > > keyset.
> > >
> > > Javascript can always work and I do use javascript, but always as a last
> > > resort.
> > >
> > > All ideas are welcome.
> > >
> > > >From: Joe Germuska <Jo...@Germuska.com>
> > > >To: "Dilip Ladhani" <di...@hotmail.com>, user@struts.apache.org
> > > >Subject: Re: Trim all fields before validation
> > > >Date: Wed, 31 Aug 2005 13:58:50 -0500
> > > >
> > > >At 2:49 PM -0400 8/31/05, Dilip Ladhani wrote:
> > > >>Hello all,
> > > >>
> > > >>I was searching for the best way to do this.
> > > >>
> > > >>I want all the fields on my form to be trimmed before they are sent
> >for
> > > >>validation (I call validate from my action class). What's the best way
> >to
> > > >>do this if I have DynaValidatorActionForm?
> > > >
> > > >Personally, I'd make this part of an onsubmit handler in the page.
> > > >
> > > >You can't really intervene in the form population process on the Struts
> > > >side right now (although arguably that's something which should be
> >exposed
> > > >for user customization better).
> > > >
> > > >I suppose maybe you could extend DynaValidatorActionForm and try to
> > > >intervene in how it handles property setting, but it's pretty abstract,
> >so
> > > >that may be a big challenge.
> > > >
> > > >And, of course, you could sacrifice your dynaforms and implement your
> >own
> > > >form bean classes which trim any non-null string value which is
> >applied.
> > > >
> > > >Joe
> > > >
> > > >--
> > > >Joe Germuska Joe@Germuska.com http://blog.germuska.com
> > > >"Narrow minds are weapons made for mass destruction" -The Ex
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > > For additional commands, e-mail: user-help@struts.apache.org
> > >
> > >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> >For additional commands, e-mail: user-help@struts.apache.org
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Trim all fields before validation
Posted by Dilip Ladhani <di...@hotmail.com>.
That's correct Ed, but there is no way to set it back, unless I modify the
code, right?
>From: Ed Griebel <ed...@gmail.com>
>Reply-To: "Struts Users Mailing List" <us...@struts.apache.org>
>To: Struts Users Mailing List <us...@struts.apache.org>
>Subject: Re: Trim all fields before validation
>Date: Wed, 31 Aug 2005 15:48:30 -0400
>
>If you don't want to write javascript to do it, Frank's suggestion
>looks like your best bet, but I've only looked at the Javadoc not the
>code behind it.
>
>If you want to brute-force it, you can certainly get the map out of a
>DynaForm easily enough:
>Map values = (DynaValidatorActionForm form).getMap();
>
>-ed
>
>On 8/31/05, Dilip Ladhani <di...@hotmail.com> wrote:
> > I still need to look at Frank's suggestion. Thanks for your suggestions
> > Frank and Joe.
> >
> > So Joe, you would trim all the fields using javascript right? I
>understand
> > your suggestion. I was hoping that just before I call validate in my
>action,
> > I could write a generic loop to loop around the keyset (I suppose this
>is
> > not exposed by DynaValidatorActionForm, like it would be for say a
>Hahmap)
> > and trim all the Strings on the form. But I am not sure how I can get
>the
> > keyset.
> >
> > Javascript can always work and I do use javascript, but always as a last
> > resort.
> >
> > All ideas are welcome.
> >
> > >From: Joe Germuska <Jo...@Germuska.com>
> > >To: "Dilip Ladhani" <di...@hotmail.com>, user@struts.apache.org
> > >Subject: Re: Trim all fields before validation
> > >Date: Wed, 31 Aug 2005 13:58:50 -0500
> > >
> > >At 2:49 PM -0400 8/31/05, Dilip Ladhani wrote:
> > >>Hello all,
> > >>
> > >>I was searching for the best way to do this.
> > >>
> > >>I want all the fields on my form to be trimmed before they are sent
>for
> > >>validation (I call validate from my action class). What's the best way
>to
> > >>do this if I have DynaValidatorActionForm?
> > >
> > >Personally, I'd make this part of an onsubmit handler in the page.
> > >
> > >You can't really intervene in the form population process on the Struts
> > >side right now (although arguably that's something which should be
>exposed
> > >for user customization better).
> > >
> > >I suppose maybe you could extend DynaValidatorActionForm and try to
> > >intervene in how it handles property setting, but it's pretty abstract,
>so
> > >that may be a big challenge.
> > >
> > >And, of course, you could sacrifice your dynaforms and implement your
>own
> > >form bean classes which trim any non-null string value which is
>applied.
> > >
> > >Joe
> > >
> > >--
> > >Joe Germuska Joe@Germuska.com http://blog.germuska.com
> > >"Narrow minds are weapons made for mass destruction" -The Ex
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
> >
> >
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>For additional commands, e-mail: user-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Trim all fields before validation
Posted by Ed Griebel <ed...@gmail.com>.
If you don't want to write javascript to do it, Frank's suggestion
looks like your best bet, but I've only looked at the Javadoc not the
code behind it.
If you want to brute-force it, you can certainly get the map out of a
DynaForm easily enough:
Map values = (DynaValidatorActionForm form).getMap();
-ed
On 8/31/05, Dilip Ladhani <di...@hotmail.com> wrote:
> I still need to look at Frank's suggestion. Thanks for your suggestions
> Frank and Joe.
>
> So Joe, you would trim all the fields using javascript right? I understand
> your suggestion. I was hoping that just before I call validate in my action,
> I could write a generic loop to loop around the keyset (I suppose this is
> not exposed by DynaValidatorActionForm, like it would be for say a Hahmap)
> and trim all the Strings on the form. But I am not sure how I can get the
> keyset.
>
> Javascript can always work and I do use javascript, but always as a last
> resort.
>
> All ideas are welcome.
>
> >From: Joe Germuska <Jo...@Germuska.com>
> >To: "Dilip Ladhani" <di...@hotmail.com>, user@struts.apache.org
> >Subject: Re: Trim all fields before validation
> >Date: Wed, 31 Aug 2005 13:58:50 -0500
> >
> >At 2:49 PM -0400 8/31/05, Dilip Ladhani wrote:
> >>Hello all,
> >>
> >>I was searching for the best way to do this.
> >>
> >>I want all the fields on my form to be trimmed before they are sent for
> >>validation (I call validate from my action class). What's the best way to
> >>do this if I have DynaValidatorActionForm?
> >
> >Personally, I'd make this part of an onsubmit handler in the page.
> >
> >You can't really intervene in the form population process on the Struts
> >side right now (although arguably that's something which should be exposed
> >for user customization better).
> >
> >I suppose maybe you could extend DynaValidatorActionForm and try to
> >intervene in how it handles property setting, but it's pretty abstract, so
> >that may be a big challenge.
> >
> >And, of course, you could sacrifice your dynaforms and implement your own
> >form bean classes which trim any non-null string value which is applied.
> >
> >Joe
> >
> >--
> >Joe Germuska Joe@Germuska.com http://blog.germuska.com
> >"Narrow minds are weapons made for mass destruction" -The Ex
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Trim all fields before validation
Posted by Joe Germuska <Jo...@Germuska.com>.
At 9:43 AM +1000 9/2/05, amos@amos.mailshell.com wrote:
>On Wed, 2005-08-31 at 13:58 -0500, Joe Germuska wrote:
>> You can't really intervene in the form population process on the
>> Struts side right now (although arguably that's something which
>> should be exposed for user customization better).
>
>We already have a BaseProcessor class which extends
>TilesRequestProcessor. I added the following code there and it
>seems to work: Is there something I'm missing?
...
not if it works! One could argue that you're not really intervening
but duplicating, and that your solution only works as long as you
never use non-dyna forms -- but if that works for you, good.
I've also tended to mentally block out solutions based around
subclassing RequestProcessor because so much of my Struts time in the
last year has been around trying to solve problems with subclassing
it -- but as you point out, even if there are a few problems, there
is still some decent exposure of extension points.
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Trim all fields before validation
Posted by am...@amos.mailshell.com.
On Wed, 2005-08-31 at 13:58 -0500, Joe Germuska wrote:
> You can't really intervene in the form population process on the
> Struts side right now (although arguably that's something which
> should be exposed for user customization better).
We already have a BaseProcessor class which extends
TilesRequestProcessor. I added the following code there and it
seems to work:
protected void processPopulate(HttpServletRequest httpServletRequest,
HttpServletResponse httpServletResponse, ActionForm actionForm,
ActionMapping actionMapping) throws ServletException
{
super.processPopulate(httpServletRequest, httpServletResponse,
actionForm, actionMapping);
if (actionForm instanceof DynaActionForm)
{
DynaActionForm dynaActionForm = (DynaActionForm)actionForm;
for (Iterator<Map.Entry> iterator =
dynaActionForm.getMap().entrySet().iterator();
iterator.hasNext();)
{
Map.Entry entry = iterator.next();
if (entry.getValue() instanceof String)
dynaActionForm.set((String)entry.getKey(),
((String)entry.getValue()).trim());
}
}
}
Is there something I'm missing?
Thanks,
--Amos
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Trim all fields before validation
Posted by Dilip Ladhani <di...@hotmail.com>.
I still need to look at Frank's suggestion. Thanks for your suggestions
Frank and Joe.
So Joe, you would trim all the fields using javascript right? I understand
your suggestion. I was hoping that just before I call validate in my action,
I could write a generic loop to loop around the keyset (I suppose this is
not exposed by DynaValidatorActionForm, like it would be for say a Hahmap)
and trim all the Strings on the form. But I am not sure how I can get the
keyset.
Javascript can always work and I do use javascript, but always as a last
resort.
All ideas are welcome.
>From: Joe Germuska <Jo...@Germuska.com>
>To: "Dilip Ladhani" <di...@hotmail.com>, user@struts.apache.org
>Subject: Re: Trim all fields before validation
>Date: Wed, 31 Aug 2005 13:58:50 -0500
>
>At 2:49 PM -0400 8/31/05, Dilip Ladhani wrote:
>>Hello all,
>>
>>I was searching for the best way to do this.
>>
>>I want all the fields on my form to be trimmed before they are sent for
>>validation (I call validate from my action class). What's the best way to
>>do this if I have DynaValidatorActionForm?
>
>Personally, I'd make this part of an onsubmit handler in the page.
>
>You can't really intervene in the form population process on the Struts
>side right now (although arguably that's something which should be exposed
>for user customization better).
>
>I suppose maybe you could extend DynaValidatorActionForm and try to
>intervene in how it handles property setting, but it's pretty abstract, so
>that may be a big challenge.
>
>And, of course, you could sacrifice your dynaforms and implement your own
>form bean classes which trim any non-null string value which is applied.
>
>Joe
>
>--
>Joe Germuska Joe@Germuska.com http://blog.germuska.com
>"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Trim all fields before validation
Posted by Joe Germuska <Jo...@Germuska.com>.
At 2:49 PM -0400 8/31/05, Dilip Ladhani wrote:
>Hello all,
>
>I was searching for the best way to do this.
>
>I want all the fields on my form to be trimmed before they are sent
>for validation (I call validate from my action class). What's the
>best way to do this if I have DynaValidatorActionForm?
Personally, I'd make this part of an onsubmit handler in the page.
You can't really intervene in the form population process on the
Struts side right now (although arguably that's something which
should be exposed for user customization better).
I suppose maybe you could extend DynaValidatorActionForm and try to
intervene in how it handles property setting, but it's pretty
abstract, so that may be a big challenge.
And, of course, you could sacrifice your dynaforms and implement your
own form bean classes which trim any non-null string value which is
applied.
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Trim all fields before validation
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Take a peek at the ParameterMunger filter in Java Web Parts:
http://javawebparts.sourceforge.net/javadocs/javawebparts/filter/ParameterMungerFilter.html
This will do what you want I think. If you decide to use it and have
any suggestions, they are always welcome :)
Frank
Dilip Ladhani wrote:
> Hello all,
>
> I was searching for the best way to do this.
>
> I want all the fields on my form to be trimmed before they are sent for
> validation (I call validate from my action class). What's the best way
> to do this if I have DynaValidatorActionForm?
>
> thanks,
> Dilip
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
>
>
>
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Trim all fields before validation
Posted by Dilip Ladhani <di...@hotmail.com>.
Hello all,
I was searching for the best way to do this.
I want all the fields on my form to be trimmed before they are sent for
validation (I call validate from my action class). What's the best way to do
this if I have DynaValidatorActionForm?
thanks,
Dilip
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT]Terrific intro to JSF
Posted by Laurie Harper <la...@holoweb.net>.
Craig McClanahan wrote:
> For validations, using one configuration file versus two isn't really
> different in terms of functionality being supported -- and in one
> respect (using different validation rules with the same form under
> different circumstances) it might actually reduce flexibility. Some
> will consider it more user friendly, however.
Good point; I tend to tie validation to form beans by form name which
eliminates that flexibility anyway but I can see how it may be useful.
There are tangible benefits to keeping all the configuration about a given
'foo' as close to 'foo' as possible, but not sufficient to sacrifice
functionality.
> Handling conversions with smarter proxies seems like it might be more
> valuable -- although the existing conversion framework supported by
> BeanUtils isn't really up to the task (it's focused on one way
> String->Object instead of two way conversions needed for both input
> and output). But that only gives you the "component-like"
> capabilities of very simple components. An overall component API
> does a lot more for you than just eliminate form beans. This is just
> the characteristic most obvious to someone familiar with Struts.
Yeah, absolutely; I saw this as an incremental enhancement to Struts'
functionality rather than as a way to turn Struts into a 'poor man's
component framework' ;-) And it's a separate concern to the validation
thing above; just an enhancement of the capabilities today's dyna forms
offer which could an optional, additional feature.
I guess I should go re-read the Struts Ti thread in case this idea's
already in there ;-)
L.
--
Laurie, Open Source advocate, Java geek and novice blogger:
http://www.holoweb.net/laurie
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT]Terrific intro to JSF
Posted by Craig McClanahan <cr...@gmail.com>.
On 8/9/05, Laurie Harper <la...@holoweb.net> wrote:
> Craig McClanahan wrote:
> > On 8/9/05, Daniel Perry <d....@netcase.co.uk> wrote:
> >
> >>>-----Original Message-----
> >>>From: Craig McClanahan [mailto:craigmcc@gmail.com]
> >>>PS: It's pretty straightforward to build turbo versions of the Struts
> >>>HTML tags that have many of the same features described above. But
> >>>that doesn't begin to touch the behavior at input time, where the
> >>>component itself deals with details like converters, and completely
> >>>eliminates the need for a form bean.
> >>
> >>Now it's funny... i was thinking about this the other day.
> >>
> >>Why not add to the struts html tags to take validation information? And
> >>while you're at it, why not add typing like type="date" or type="int" or
> >>type="string" to text fields.
> >
> >
> > Interesting idea. Let's do a bit of mental exploration of what
> > actually happens to see how practical it is. When does a Struts
> > custom tag actually execute? Only when the page is being rendered, as
> > the various HTML elements get produced. Now, when does (server side)
> > validation need to happen? On the subsequent form submit (the actual
> > call to invoke the server side validator is one of the things that
> > RequestProcessor does).
> >
> > Hmm ..... there's no "tag" there to do the validation for me ....
> > maybe I need a component model to encapsulate both the rendering and
> > the validating behavior ... wonder where I can find one of those? :-)
>
> Interestingly, when I read Daniel's post I thought he was advocating adding
> validation metadata to the form bean declaration and using dynamic proxies
> to generate the beans -- like enhanced Dyna forms. You'd eliminate the need
> for a separate validation.xml and, by making the proxy beans smarter so
> they could wrap an existing form bean or typed DTO and handle the
> string/type conversions in the proxy, you'd get a long way to automating a
> lot of the glue code. Sounded like a good idea to me... :-)
>
> Do your comments change if you look at the idea from that direction?
For validations, using one configuration file versus two isn't really
different in terms of functionality being supported -- and in one
respect (using different validation rules with the same form under
different circumstances) it might actually reduce flexibility. Some
will consider it more user friendly, however.
Handling conversions with smarter proxies seems like it might be more
valuable -- although the existing conversion framework supported by
BeanUtils isn't really up to the task (it's focused on one way
String->Object instead of two way conversions needed for both input
and output). But that only gives you the "component-like"
capabilities of very simple components. An overall component API
does a lot more for you than just eliminate form beans. This is just
the characteristic most obvious to someone familiar with Struts.
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT]Terrific intro to JSF
Posted by Laurie Harper <la...@holoweb.net>.
Craig McClanahan wrote:
> On 8/9/05, Daniel Perry <d....@netcase.co.uk> wrote:
>
>>>-----Original Message-----
>>>From: Craig McClanahan [mailto:craigmcc@gmail.com]
>>>PS: It's pretty straightforward to build turbo versions of the Struts
>>>HTML tags that have many of the same features described above. But
>>>that doesn't begin to touch the behavior at input time, where the
>>>component itself deals with details like converters, and completely
>>>eliminates the need for a form bean.
>>
>>Now it's funny... i was thinking about this the other day.
>>
>>Why not add to the struts html tags to take validation information? And
>>while you're at it, why not add typing like type="date" or type="int" or
>>type="string" to text fields.
>
>
> Interesting idea. Let's do a bit of mental exploration of what
> actually happens to see how practical it is. When does a Struts
> custom tag actually execute? Only when the page is being rendered, as
> the various HTML elements get produced. Now, when does (server side)
> validation need to happen? On the subsequent form submit (the actual
> call to invoke the server side validator is one of the things that
> RequestProcessor does).
>
> Hmm ..... there's no "tag" there to do the validation for me ....
> maybe I need a component model to encapsulate both the rendering and
> the validating behavior ... wonder where I can find one of those? :-)
Interestingly, when I read Daniel's post I thought he was advocating adding
validation metadata to the form bean declaration and using dynamic proxies
to generate the beans -- like enhanced Dyna forms. You'd eliminate the need
for a separate validation.xml and, by making the proxy beans smarter so
they could wrap an existing form bean or typed DTO and handle the
string/type conversions in the proxy, you'd get a long way to automating a
lot of the glue code. Sounded like a good idea to me... :-)
Do your comments change if you look at the idea from that direction?
L.
>>Then you eliminate actionforms as all the validation info is in the form,
>>and can be automcatically done for you, and then use can use dynamic proxies
>>to provide properly typed javabeans as output from a form, and use the
>>models DTOs to put data into forms!
>
>
> You just described the most common design pattern for using JSF :-).
>
>
>>Daniel.
>>
>>
>
>
> Craig
--
Laurie, Open Source advocate, Java geek and novice blogger:
http://www.holoweb.net/laurie
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: {Spam?} RE: [OT]Terrific intro to JSF
Posted by GR...@intellicare.com.
Daniel:
"Daniel Perry" <d....@netcase.co.uk> wrote on 08/10/2005 05:39:49 AM:
> My reasoning behind all this stuff, is i HATE all these xml config
files.
> Or more accurately, I like xml config files, but I hate moving between X
> different xml files. It might suit IDEs, but it aint right for humans!
> You've got a jsp page with <html:text> - why cant i put validation, type
> (for dynamic bean handling), etc there, rather than looking at various
> different xml files.
XDcolet hasn't been integrated with JSF yet (
http://www.evolutionnext.com/blog/2004/11/13/1100372027000.html)
but once it is, who knows, maybe we'll probably never touch a config file
again..:)
> > >
> > > Then you eliminate actionforms as all the validation info is in
> > the form,
> > > and can be automcatically done for you, and then use can use
> > dynamic proxies
> > > to provide properly typed javabeans as output from a form, and use
the
> > > models DTOs to put data into forms!
> >
> > You just described the most common design pattern for using JSF :-).
>
> One of these days i will find some time to look at jsf/shale properly.
Been
> saying that for quite a while, just never got round to it!
>
> Daniel.
Geeta
RE: [OT]Terrific intro to JSF
Posted by Daniel Perry <d....@netcase.co.uk>.
> Interesting idea. Let's do a bit of mental exploration of what
> actually happens to see how practical it is. When does a Struts
> custom tag actually execute? Only when the page is being rendered, as
> the various HTML elements get produced. Now, when does (server side)
> validation need to happen? On the subsequent form submit (the actual
> call to invoke the server side validator is one of the things that
> RequestProcessor does).
>
> Hmm ..... there's no "tag" there to do the validation for me ....
> maybe I need a component model to encapsulate both the rendering and
> the validating behavior ... wonder where I can find one of those? :-)
Thought of that. Then i thought... why not just stick the validationion
requirements into the session when you render the tags, then they'd
magically be there when you need to validate it! You also know what
properties need to be provided by the proxy bean.
There's one more bonus of this - it wouldnt break backwards compatibility,
which seems to be a requirement for struts development :(
My reasoning behind all this stuff, is i HATE all these xml config files.
Or more accurately, I like xml config files, but I hate moving between X
different xml files. It might suit IDEs, but it aint right for humans!
You've got a jsp page with <html:text> - why cant i put validation, type
(for dynamic bean handling), etc there, rather than looking at various
different xml files.
>
> >
> > Then you eliminate actionforms as all the validation info is in
> the form,
> > and can be automcatically done for you, and then use can use
> dynamic proxies
> > to provide properly typed javabeans as output from a form, and use the
> > models DTOs to put data into forms!
>
> You just described the most common design pattern for using JSF :-).
One of these days i will find some time to look at jsf/shale properly. Been
saying that for quite a while, just never got round to it!
Daniel.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT]Terrific intro to JSF
Posted by Craig McClanahan <cr...@gmail.com>.
On 8/9/05, Daniel Perry <d....@netcase.co.uk> wrote:
> > -----Original Message-----
> > From: Craig McClanahan [mailto:craigmcc@gmail.com]
> > PS: It's pretty straightforward to build turbo versions of the Struts
> > HTML tags that have many of the same features described above. But
> > that doesn't begin to touch the behavior at input time, where the
> > component itself deals with details like converters, and completely
> > eliminates the need for a form bean.
>
> Now it's funny... i was thinking about this the other day.
>
> Why not add to the struts html tags to take validation information? And
> while you're at it, why not add typing like type="date" or type="int" or
> type="string" to text fields.
Interesting idea. Let's do a bit of mental exploration of what
actually happens to see how practical it is. When does a Struts
custom tag actually execute? Only when the page is being rendered, as
the various HTML elements get produced. Now, when does (server side)
validation need to happen? On the subsequent form submit (the actual
call to invoke the server side validator is one of the things that
RequestProcessor does).
Hmm ..... there's no "tag" there to do the validation for me ....
maybe I need a component model to encapsulate both the rendering and
the validating behavior ... wonder where I can find one of those? :-)
>
> Then you eliminate actionforms as all the validation info is in the form,
> and can be automcatically done for you, and then use can use dynamic proxies
> to provide properly typed javabeans as output from a form, and use the
> models DTOs to put data into forms!
You just described the most common design pattern for using JSF :-).
>
> Daniel.
>
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: [OT]Terrific intro to JSF
Posted by Daniel Perry <d....@netcase.co.uk>.
> -----Original Message-----
> From: Craig McClanahan [mailto:craigmcc@gmail.com]
> PS: It's pretty straightforward to build turbo versions of the Struts
> HTML tags that have many of the same features described above. But
> that doesn't begin to touch the behavior at input time, where the
> component itself deals with details like converters, and completely
> eliminates the need for a form bean.
Now it's funny... i was thinking about this the other day.
Why not add to the struts html tags to take validation information? And
while you're at it, why not add typing like type="date" or type="int" or
type="string" to text fields.
Then you eliminate actionforms as all the validation info is in the form,
and can be automcatically done for you, and then use can use dynamic proxies
to provide properly typed javabeans as output from a form, and use the
models DTOs to put data into forms!
Daniel.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT]Terrific intro to JSF
Posted by Craig McClanahan <cr...@gmail.com>.
On 8/8/05, Frank W. Zammetti <fz...@omnytex.com> wrote:
> That is a good article, thanks for pointing it out Geeta!
>
> Ironically, I remember very well, that calculator example is the exact
> same one I saw more than two years ago at a Java user's group meeting...
> it must get the point across well :) I remember they showed all sorts
> of state diagrams and expanded on it a bit, which made JSF seem very
> overwhelming... this article does the exact opposite, which is a
> pleasent change as far as I'm concerned.
>
> I hope this isn't seen as thread-jacking, but I think it's a relevant
> question and I'm hoping Craig or someone very much in-tune with JSF can
> answer this...
>
And you were so ***good*** about the Maven thread! :-) :-) :-)
> I know you can apply styles to the various JSF controls... my question
> is, to what extent can you do so?
>
There's no global answer that applies to all components ... see below
for some sceanrios.
> Taking something like the panelGrid from this example... what if I
> wanted to have the messages directly below the textboxes in a small red
> font and the buttons to the right? What if I wanted to apply a
> background image to the textbox to give it an inner bevel appearance?
> Would this all be possible within the confines of JSP, and more
> importantly, would it be a very difficult exercise?
Regarding stylability, the JSF standard components basically adopted a
common convention from the Struts tags, in that they all sport a
"styleClass" and a "style" attribute. The former is essentially a
passthrough to the HTML "class" attribute (you can't use that directly
in JSP because of the way JavaBeans property names work ... getClass()
is inherited from java.lang.Object so you can't have a JSP attribute
named "class"). In a similar way, the "style" attribute value, if
specified, is passed through directly.
As a result, the standard JSF components have a minimum level of
styleability equivalent to corresponding Struts tags. Some of them go
a little further, however:
* The "footerClass" attribute lets you specify the overall style class to add
to a panel footer (HtmlDataTable, HtmlGridPanel)
* The "headerClass" attribute lets you specify the overall style class to add
to a panel header (HtmlDataTable, HtmlGridPanel)
* The "columnClasses" attribute lets you specify the overall style class to
use on each individual column (HtmlDataTable)
* The "rowClasses" attribute lets you specify the overall style class to
use on each individual row (HtmlDataTable). In particular, this lets you
do things like even/odd row striping very easily.
In all of the above cases, you have to explicitly specify style
classes on all the components you want them to apply to. An
additional (and/or alternative ... it is not mutually exclusive)
strategy is for a component library to render explicit stye class
names by default -- the new components in Sun Java Studio Creator 2 EA
do this, for example. This allows you to abstract the actual
appearance stuff related to, say, a Data Table component into a
stylesheet ... and then provide a separate mechanism to select which
stylesheet to use at runtime. In Creator, this notion is called
"theming".
To your specific example, it's definitely possible to do all of this,
even if you are using only the standard JSF components. However,
you'll find it easier to use components that do the grunt work for
you. Just as an example of what's possible, the Label component (in
Creator 2 EA) is used to create a component label associated with an
input field. Out of the box, this component:
* Includes a "level" property that takes a 1/2/3 value to determine
how "important" this label is. This translates into different style
class names being emitted at runtime, without the page author having to
know things like style class names.
* Has a "for" attribute that contains the id of the input component this
field is associated with. This supports three interesting features:
- Emits the appropriate HTML for creating accessible applications,
so that a screen reader can understand what prompts go with
what fields.
- If the field corresponding to this label has its "required"
property set to true,
emit a theme specific icon (by default an "*" character) next to the label.
- If the field corresponding to this label has its "valid" property
set to false
(because a validation rule failed), display the label text in
(say) red instead
of the default color (typically black).
All of this is possible with CSS support at the level of Struts tags
(or the JSF standard components), but it is definitely tedious. Much
nicer is knowing I can simply drag a label component onto the design
surface and click-drag the corresponding input field to establish the
linkage (err, for those of you not using Creator, that means "type in
a couple of JSP custom tags and remember to set the 'for' attribute
correctly" :-), and know that all the dynamic stuff just works.
>
> Frank
>
Craig
PS: It's pretty straightforward to build turbo versions of the Struts
HTML tags that have many of the same features described above. But
that doesn't begin to touch the behavior at input time, where the
component itself deals with details like converters, and completely
eliminates the need for a form bean.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT]Terrific intro to JSF
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
That is a good article, thanks for pointing it out Geeta!
Ironically, I remember very well, that calculator example is the exact
same one I saw more than two years ago at a Java user's group meeting...
it must get the point across well :) I remember they showed all sorts
of state diagrams and expanded on it a bit, which made JSF seem very
overwhelming... this article does the exact opposite, which is a
pleasent change as far as I'm concerned.
I hope this isn't seen as thread-jacking, but I think it's a relevant
question and I'm hoping Craig or someone very much in-tune with JSF can
answer this...
I know you can apply styles to the various JSF controls... my question
is, to what extent can you do so?
Taking something like the panelGrid from this example... what if I
wanted to have the messages directly below the textboxes in a small red
font and the buttons to the right? What if I wanted to apply a
background image to the textbox to give it an inner bevel appearance?
Would this all be possible within the confines of JSP, and more
importantly, would it be a very difficult exercise?
Frank
GRamani@intellicare.com wrote:
> Hi all:
>
> i know it isn't Friday yet.. ;) but .. in case you have been looking for a
> nice and clear introduction to JSF, look no further. Here it is:
>
> http://www-128.ibm.com/developerworks/java/library/j-jsf1/
>
> I have only just completed the first article - and can't wait to get to
> the next three! - but the first article is just *fantastic*. It's
> articles like these which make Java almost too much fun..:)
>
> Geeta
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: {Spam?} Re: [OT]Terrific intro to JSF
Posted by GR...@intellicare.com.
well, yes.. I guess maybe my note seems to suggest otherwise..?
well, I am right now about half way through the second one and it's still
holding up to its initial promise..:)
Geeta
"C.F. Scheidecker Antunes" <na...@antunes.eti.br>
08/09/2005 02:18 PM
Please respond to
"Struts Users Mailing List" <us...@struts.apache.org>
To
Struts Users Mailing List <us...@struts.apache.org>
cc
Subject
{Spam?} Re: [OT]Terrific intro to JSF
Well. It seems that all articles were written already.
http://www-128.ibm.com/developerworks/views/java/libraryview.jsp?search_by=nonbelievers:
GRamani@intellicare.com wrote:
>Hi all:
>
>i know it isn't Friday yet.. ;) but .. in case you have been looking for
a
>nice and clear introduction to JSF, look no further. Here it is:
>
>http://www-128.ibm.com/developerworks/java/library/j-jsf1/
>
>I have only just completed the first article - and can't wait to get to
>the next three! - but the first article is just *fantastic*. It's
>articles like these which make Java almost too much fun..:)
>
>Geeta
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
CONFIDENTIALITY NOTICE:This email is intended solely for the person or
entity to which it is addressed and may contain confidential and/or
protected health information. Any duplication, dissemination, action
taken in reliance upon, or other use of this information by persons or
entities other than the intended recipient is prohibited and may violate
applicable laws. If this email has been received in error, please notify
the sender and delete the information from your system. The views
expressed in this email are those of the sender and may not necessarily
represent the views of IntelliCare.
Re: [OT]Terrific intro to JSF
Posted by "C.F. Scheidecker Antunes" <na...@antunes.eti.br>.
Well. It seems that all articles were written already.
http://www-128.ibm.com/developerworks/views/java/libraryview.jsp?search_by=nonbelievers:
GRamani@intellicare.com wrote:
>Hi all:
>
>i know it isn't Friday yet.. ;) but .. in case you have been looking for a
>nice and clear introduction to JSF, look no further. Here it is:
>
>http://www-128.ibm.com/developerworks/java/library/j-jsf1/
>
>I have only just completed the first article - and can't wait to get to
>the next three! - but the first article is just *fantastic*. It's
>articles like these which make Java almost too much fun..:)
>
>Geeta
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org