You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Jim Richards <gr...@cyber4.org> on 2001/02/11 07:12:00 UTC
Old questions that die hard
I've been out of the Struts loop for a few weeks (or months, or years based on
Internet time) and I am impressed that almost everything is ready for a 1.0
release, which means Craig's comments below still stand, re: Multipage forms
and forms built dynamically. The other thing I haven't found reference to yet is
client side validation (but I also haven't looked that hard either)
I'll have to start digging deep again.
Craig wrote:
>My thinking on multi-page forms is definitely not totally finished yet, but my
>operating assumption has been that you'd have separate actions for each page, so
>you could therefore direct errors back to the individual pages. The logical
>"grouping" of the actions could happen by subclassing a common base class that
>represented the shared logic. You would declare the same form bean for all of
>these actions, and you'd store this bean in session scope. (As a side benefit,
>you can also use "next" and "previous" logical forward names directly, without
>having to calculate which page you are on in sequence, and then know what the
>next and previous logical names are.)
>
>It is still messy, because the validation method (at least) needs to know what
>fields came from what pages, and there is no convenient way to communicate that
>information so that it only needs to be specified once. I think that a final
>solution to this is probably going to need to wait for a 1.1 time frame, when we
>can figure out how to deal with it cleanly. I believe that the current approach
>works quite well for single page forms (with the outstanding issue of people
>that want to deal with dynamic sets of properties, rather than fixed ones, which
>will need to be a separate extension if we decide to support it).
--
Mary had a crypto key
she kept it in escrow
and everything that Mary said
the Feds were sure to know.
Re: Old questions that die hard
Posted by Jim Richards <gr...@cyber4.org>.
Ted Husted wrote:
> Jim Richards wrote:
> >The other thing I haven't found reference to yet is
> >client side validation (but I also haven't looked that hard either)
>
> It's on the 1.1 TODO list.
>
> And, of course, we're glad that you've checked in again!
I did notice that you had your name down for the client
side validation. I'd be interested in your thoughts, and
ideas because this is something I've done a lot of
recently (not in Struts/JSP though) ...
Please unsubscribe adeniji@computer.org
Posted by Kenny Adeniji <ke...@yahoo.com>.
Please unsubscribe adeniji@computer.org
--- Ted Husted <ne...@husted.com> wrote:
> My initial thoughts were to look at what some of the
> advanced HTML
> authoring tools, like FrontPage and Dreamweaver do
> with this. Craig
> mentioned to me that the client-side validations
> should be coordinated
> with any new work on server-side validations.
>
> Obviously, some standard "domain type" validations
> would be very useful,
> corresponding to Java or SQL types. These might be
> the sorts of things
> we could easily add as properties, and would fit in
> with any IDE
> integration projects.
>
> These could then be braced server-side with hardcore
> regex validations,
> along with any business logic checking.
>
> Of course, late-model Javascript also supports regex
> ...
>
> Jim Richards wrote:
> >>The other thing I haven't found reference to yet
> is
> >>client side validation (but I also haven't looked
> that hard either)
>
> > I did notice that you had your name down for the
> client
> > side validation. I'd be interested in your
> thoughts, and
> > ideas because this is something I've done a lot of
> > recently (not in Struts/JSP though) ...
>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel 716 425-0252; Fax 716 223-2506.
> -- http://www.husted.com/about/struts/
>
>
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35
a year! http://personal.mail.yahoo.com/
Re: can we remove this user from the list ?
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Done.
Craig
Maya Muchnik wrote:
> Every time, when I am sending an email I am getting this message (maybe others
> too):
>
> Subject:
> Mail User is Out of Storage Space
> Date:
> .....
> From:
> mail@murlmail.com
>
> Can we remove this user ? Maybe he is not there anymore.
can we remove this user from the list ?
Posted by Maya Muchnik <mm...@pumatech.com>.
Every time, when I am sending an email I am getting this message (maybe others
too):
Subject:
Mail User is Out of Storage Space
Date:
.....
From:
mail@murlmail.com
Can we remove this user ? Maybe he is not there anymore.
Re: Old questions that die hard
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Maya Muchnik wrote:
> Thank you, David.
> I have tested struts-example with disabled JavaScript on Netscape. It is still
> working!!!
> Maya
>
The only JavaScript code in the Struts example is the attempt to set input focus
on the first field on each form. In this case, the lack of JavaScript is pretty
innocuous. For more complex user interfaces, JavaScript might be required (by the
app) to be turned on.
Craig
Re: Old questions that die hard
Posted by Maya Muchnik <mm...@pumatech.com>.
Thank you, David.
I have tested struts-example with disabled JavaScript on Netscape. It is still
working!!!
Maya
"Verratti, David" wrote:
> Hi Maya:
>
> In Netscape 4.7: Choose Edit-->Preferences-->Advanced, unselect enable
> Javascript
>
> Don't think you can in IE, means you can rely on Javascript if you know your
> users are all IE..
>
> see ya
> Dave
>
> -----Original Message-----
> From: mmuchnik [mailto:mmuchnik]On Behalf Of Maya Muchnik
> Sent: 13 February 2001 22:13
> To: struts-user@jakarta.apache.org
> Subject: Re: Old questions that die hard
>
> David,
>
> Could you, please, email, how to disable JavaScript in Netscape and / or IE.
>
> thanks,
>
> Maya
>
> "Verratti, David" wrote:
>
> > Basic rule - don't count on client for anything other than basic html
> unless
> > you can control the client environment. It's not just ancient browser
> > support, fairly modern browsers (ie Netscape, which I assume would be the
> > default browser for all non-Windows clients) allow users to disable
> > Javascript.
> >
> > see ya
> > Dave
> >
> > -----Original Message-----
> > From: Andrew Collins [mailto:andrewrcollins@yahoo.com]
> > Sent: 13 February 2001 20:18
> > To: struts-user@jakarta.apache.org
> > Subject: Re: Old questions that die hard
> >
> > > Of course, late-model Javascript also supports regex ...
> >
> > Perhaps you mean "newer versions of JavaScript"...
> >
> > (I'm a stickler sometimes, a weissenheimer the remainder.)
> >
> > Is there good cause to support ancient browsers?
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Get personalized email addresses from Yahoo! Mail - only $35
> > a year! http://personal.mail.yahoo.com/
RE: Old questions that die hard
Posted by "Verratti, David" <dv...@silverstream.com>.
Hi Maya:
In Netscape 4.7: Choose Edit-->Preferences-->Advanced, unselect enable
Javascript
Don't think you can in IE, means you can rely on Javascript if you know your
users are all IE..
see ya
Dave
-----Original Message-----
From: mmuchnik [mailto:mmuchnik]On Behalf Of Maya Muchnik
Sent: 13 February 2001 22:13
To: struts-user@jakarta.apache.org
Subject: Re: Old questions that die hard
David,
Could you, please, email, how to disable JavaScript in Netscape and / or IE.
thanks,
Maya
"Verratti, David" wrote:
> Basic rule - don't count on client for anything other than basic html
unless
> you can control the client environment. It's not just ancient browser
> support, fairly modern browsers (ie Netscape, which I assume would be the
> default browser for all non-Windows clients) allow users to disable
> Javascript.
>
> see ya
> Dave
>
> -----Original Message-----
> From: Andrew Collins [mailto:andrewrcollins@yahoo.com]
> Sent: 13 February 2001 20:18
> To: struts-user@jakarta.apache.org
> Subject: Re: Old questions that die hard
>
> > Of course, late-model Javascript also supports regex ...
>
> Perhaps you mean "newer versions of JavaScript"...
>
> (I'm a stickler sometimes, a weissenheimer the remainder.)
>
> Is there good cause to support ancient browsers?
>
> __________________________________________________
> Do You Yahoo!?
> Get personalized email addresses from Yahoo! Mail - only $35
> a year! http://personal.mail.yahoo.com/
Re: Old questions that die hard
Posted by Maya Muchnik <mm...@pumatech.com>.
David,
Could you, please, email, how to disable JavaScript in Netscape and / or IE.
thanks,
Maya
"Verratti, David" wrote:
> Basic rule - don't count on client for anything other than basic html unless
> you can control the client environment. It's not just ancient browser
> support, fairly modern browsers (ie Netscape, which I assume would be the
> default browser for all non-Windows clients) allow users to disable
> Javascript.
>
> see ya
> Dave
>
> -----Original Message-----
> From: Andrew Collins [mailto:andrewrcollins@yahoo.com]
> Sent: 13 February 2001 20:18
> To: struts-user@jakarta.apache.org
> Subject: Re: Old questions that die hard
>
> > Of course, late-model Javascript also supports regex ...
>
> Perhaps you mean "newer versions of JavaScript"...
>
> (I'm a stickler sometimes, a weissenheimer the remainder.)
>
> Is there good cause to support ancient browsers?
>
> __________________________________________________
> Do You Yahoo!?
> Get personalized email addresses from Yahoo! Mail - only $35
> a year! http://personal.mail.yahoo.com/
RE: Old questions that die hard
Posted by "Verratti, David" <dv...@silverstream.com>.
Basic rule - don't count on client for anything other than basic html unless
you can control the client environment. It's not just ancient browser
support, fairly modern browsers (ie Netscape, which I assume would be the
default browser for all non-Windows clients) allow users to disable
Javascript.
see ya
Dave
-----Original Message-----
From: Andrew Collins [mailto:andrewrcollins@yahoo.com]
Sent: 13 February 2001 20:18
To: struts-user@jakarta.apache.org
Subject: Re: Old questions that die hard
> Of course, late-model Javascript also supports regex ...
Perhaps you mean "newer versions of JavaScript"...
(I'm a stickler sometimes, a weissenheimer the remainder.)
Is there good cause to support ancient browsers?
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35
a year! http://personal.mail.yahoo.com/
Re: Old questions that die hard
Posted by Andrew Collins <an...@yahoo.com>.
> Of course, late-model Javascript also supports regex ...
Perhaps you mean "newer versions of JavaScript"...
(I'm a stickler sometimes, a weissenheimer the remainder.)
Is there good cause to support ancient browsers?
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35
a year! http://personal.mail.yahoo.com/
RE: Client-side validation (Old questions that die hard)
Posted by Neal Kaiser <ne...@makeastore.com>.
Dave,
One functionality that might be nice for the validation you are working on:
The ability to say that a field is required IF a certain form parameter
exists.
Something like:
<logic:equal name="registrationForm" property="role"
scope="request" value="Admin">
<field property="addr"
displayname="registrationForm.addr.displayname"
required="true"/>
</logic:equal>
So, the property "addr" is validated ONLY if the
registrationForm.role="Admin"
That's probably not the best syntax, but I think you get what I mean.
Thanks, Neal
> -----Original Message-----
> From: David Winterfeldt [mailto:dwinterfeldt@yahoo.com]
> Sent: Thursday, February 15, 2001 12:06 PM
> To: struts-user@jakarta.apache.org
> Subject: Re: Client-side validation (Old questions that die hard)
>
>
> I actually had some built-in expressions for testing,
> but then I pulled it out for simplicity. I had some
> basic things like phone numbers and such hard coded in
> and checking for a date (leap year, etc.), but I
> thought it might be better to wait and think about it
> a little more so someone could plug in their own date
> validation function if they wanted to.
>
> Although I assume you're talking about primitives,
> String, and Date which would cover a lot forms. I
> hadn't really thought about that, but it is a good
> idea. I could add a type attribute to the field
> element (ex: type="int"). I was hoping that before I
> did too much more on it that if it looked like a good
> start it could be used and/or modified for the struts
> validation in 1.1. I would be interested in being
> involved in working on the validation framework. So I
> thought it would be a good idea to hear about ideas
> and what the validation framework should do before I
> did more work. As the validation starts expanding, it
> may be a lot of work to keep the client side
> javascript in sync with it. Although if everything is
> kept clean enough that you call a method to do
> something there could be an equivalent Javascript
> method (as long as it doesn't hit a database or server
> side resource).
>
> It would also be nice to have basic expressions like
> this value should be an int and when that is confirmed
> be able to check if it is in a range.
>
> Ted, do you have an opinion on how locale should be
> handled if validation rules are kept in an xml file?
> Should there be a separate file for each locale like
> resource files or an attribute in the xml file. I
> could make a 'form set' element and it could have a
> locale attribute. You could then group forms in a
> locale and even set one group as a default. I was
> also thinking about making validation resource class
> like MessageResource and putting that in application
> scope instead of a Hashtable. To keep the validation
> in line with struts, it would be important to be able
> to specify different validation rules for different
> countries.
>
>
> David
>
> --- Ted Husted <ne...@husted.com> wrote:
> > David Winterfeldt wrote:
> > > I posted the code and a example war at. Ted, if
> > you
> > > want to, you can add this to the list of struts
> > > sites/resources you have.
> >
> > I've added this to my list at <
> > http://husted.com/about/struts >, along
> > with Craig T's very kewl presentation.
> >
> > If this keeps up, we're going to need an
> > announcement list just to keep
> > up with the new Struts resources!
> >
> > I'm hip deep (down from neck deep) in the
> > Dreamweaver UltraDev tutorials
> > right now, but as soon that's done, I'm back to
> > refining validation
> > for my working application -- which would now mean
> > taking your Validator
> > for a spin!
> >
> > What I really like about this at first glance is the
> > XML configuration.
> > This plays well into integrating this both with
> > Struts and with visual
> > environments, like UltraDev.
> >
> > Have you thought about offering built-in expressions
> > for standard Java
> > and SQL types?
> >
> > -- Ted Husted, Husted dot Com, Fairport NY USA.
> > -- Custom Software ~ Technical Services.
> > -- Tel 716 425-0252; Fax 716 223-2506.
> > -- http://www.husted.com/about/struts/
>
>
> __________________________________________________
> Do You Yahoo!?
> Get personalized email addresses from Yahoo! Mail - only $35
> a year! http://personal.mail.yahoo.com/
>
Re: Client-side validation (Old questions that die hard)
Posted by David Winterfeldt <dw...@yahoo.com>.
I actually had some built-in expressions for testing,
but then I pulled it out for simplicity. I had some
basic things like phone numbers and such hard coded in
and checking for a date (leap year, etc.), but I
thought it might be better to wait and think about it
a little more so someone could plug in their own date
validation function if they wanted to.
Although I assume you're talking about primitives,
String, and Date which would cover a lot forms. I
hadn't really thought about that, but it is a good
idea. I could add a type attribute to the field
element (ex: type="int"). I was hoping that before I
did too much more on it that if it looked like a good
start it could be used and/or modified for the struts
validation in 1.1. I would be interested in being
involved in working on the validation framework. So I
thought it would be a good idea to hear about ideas
and what the validation framework should do before I
did more work. As the validation starts expanding, it
may be a lot of work to keep the client side
javascript in sync with it. Although if everything is
kept clean enough that you call a method to do
something there could be an equivalent Javascript
method (as long as it doesn't hit a database or server
side resource).
It would also be nice to have basic expressions like
this value should be an int and when that is confirmed
be able to check if it is in a range.
Ted, do you have an opinion on how locale should be
handled if validation rules are kept in an xml file?
Should there be a separate file for each locale like
resource files or an attribute in the xml file. I
could make a 'form set' element and it could have a
locale attribute. You could then group forms in a
locale and even set one group as a default. I was
also thinking about making validation resource class
like MessageResource and putting that in application
scope instead of a Hashtable. To keep the validation
in line with struts, it would be important to be able
to specify different validation rules for different
countries.
David
--- Ted Husted <ne...@husted.com> wrote:
> David Winterfeldt wrote:
> > I posted the code and a example war at. Ted, if
> you
> > want to, you can add this to the list of struts
> > sites/resources you have.
>
> I've added this to my list at <
> http://husted.com/about/struts >, along
> with Craig T's very kewl presentation.
>
> If this keeps up, we're going to need an
> announcement list just to keep
> up with the new Struts resources!
>
> I'm hip deep (down from neck deep) in the
> Dreamweaver UltraDev tutorials
> right now, but as soon that's done, I'm back to
> refining validation
> for my working application -- which would now mean
> taking your Validator
> for a spin!
>
> What I really like about this at first glance is the
> XML configuration.
> This plays well into integrating this both with
> Struts and with visual
> environments, like UltraDev.
>
> Have you thought about offering built-in expressions
> for standard Java
> and SQL types?
>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel 716 425-0252; Fax 716 223-2506.
> -- http://www.husted.com/about/struts/
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35
a year! http://personal.mail.yahoo.com/
Re: Client-side validation (Old questions that die hard)
Posted by Ted Husted <ne...@husted.com>.
David Winterfeldt wrote:
> I posted the code and a example war at. Ted, if you
> want to, you can add this to the list of struts
> sites/resources you have.
I've added this to my list at < http://husted.com/about/struts >, along
with Craig T's very kewl presentation.
If this keeps up, we're going to need an announcement list just to keep
up with the new Struts resources!
I'm hip deep (down from neck deep) in the Dreamweaver UltraDev tutorials
right now, but as soon that's done, I'm back to refining validation
for my working application -- which would now mean taking your Validator
for a spin!
What I really like about this at first glance is the XML configuration.
This plays well into integrating this both with Struts and with visual
environments, like UltraDev.
Have you thought about offering built-in expressions for standard Java
and SQL types?
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 425-0252; Fax 716 223-2506.
-- http://www.husted.com/about/struts/
Re: Old questions that die hard
Posted by David Winterfeldt <dw...@yahoo.com>.
I added basic client side javascript validation that
matches the server side validation. Validation rules
are stored in an xml file.
I thought that if the form had a locale attribute that
would take care of i18n or there could be separate
files like the property resource files.
I was also thinking about how open the validation
framework should be. If it could be configured a
little like some Ant tasks, you could define a method
to perform validation and what validation need to
finish before others proceed like the Ant depends
attribute.
<name="required"
class="org.apache.struts.Validation"
property="validateRequired"/>
<name="regexp"
class="org.apache.struts.Validation"
property="validateRegexp"
depends="required"/>
<field property="firstName"
validations="required,regexp"
mask="^\w+$" />
I thought of this because I'm checking for all
required fields before continuing to check the regular
expressions. Anyway, it's late. I hope that part
made sense.
I posted the code and a example war at. Ted, if you
want to, you can add this to the list of struts
sites/resources you have. Is this something along the
lines you were thinking of? Let me know what you
think of Ted.
http://home.earthlink.net/~dwinterfeldt
David Winterfeldt
--- Ted Husted <ne...@husted.com> wrote:
> My initial thoughts were to look at what some of the
> advanced HTML
> authoring tools, like FrontPage and Dreamweaver do
> with this. Craig
> mentioned to me that the client-side validations
> should be coordinated
> with any new work on server-side validations.
>
> Obviously, some standard "domain type" validations
> would be very useful,
> corresponding to Java or SQL types. These might be
> the sorts of things
> we could easily add as properties, and would fit in
> with any IDE
> integration projects.
>
> These could then be braced server-side with hardcore
> regex validations,
> along with any business logic checking.
>
> Of course, late-model Javascript also supports regex
> ...
>
> Jim Richards wrote:
> >>The other thing I haven't found reference to yet
> is
> >>client side validation (but I also haven't looked
> that hard either)
>
> > I did notice that you had your name down for the
> client
> > side validation. I'd be interested in your
> thoughts, and
> > ideas because this is something I've done a lot of
> > recently (not in Struts/JSP though) ...
>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel 716 425-0252; Fax 716 223-2506.
> -- http://www.husted.com/about/struts/
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35
a year! http://personal.mail.yahoo.com/
Re: Proper way to 'forward' dynamically
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Dennis wrote:
> I haven't been able to find a question regarding this particular
> circumstance, so hopefully this isn't in an FAQ somewhere!
>
> In my Action subclass, rather than returning the results of
> mapping.findForward(...) I need to forward to a page determined at runtime.
> What is the *proper* way to forward to xxx.jsp? Should I construct an
> ActionForward? (tried that unsuccessfully).
>
When I need this, I just create a new ActionForward dynamically:
String path = ... create context-relative path to new page ...
return (new ActionForward(path));
The path you calculate must be context relative and start with a slash, exactly
like the "path" attributes to your standard <forward> elements.
>
> Thanks for any help,
>
> Dennis
Craig
Proper way to 'forward' dynamically
Posted by Dennis <de...@iswsolutions.com>.
I haven't been able to find a question regarding this particular
circumstance, so hopefully this isn't in an FAQ somewhere!
In my Action subclass, rather than returning the results of
mapping.findForward(...) I need to forward to a page determined at runtime.
What is the *proper* way to forward to xxx.jsp? Should I construct an
ActionForward? (tried that unsuccessfully).
Thanks for any help,
Dennis
Re: Old questions that die hard
Posted by Ted Husted <ne...@husted.com>.
My initial thoughts were to look at what some of the advanced HTML
authoring tools, like FrontPage and Dreamweaver do with this. Craig
mentioned to me that the client-side validations should be coordinated
with any new work on server-side validations.
Obviously, some standard "domain type" validations would be very useful,
corresponding to Java or SQL types. These might be the sorts of things
we could easily add as properties, and would fit in with any IDE
integration projects.
These could then be braced server-side with hardcore regex validations,
along with any business logic checking.
Of course, late-model Javascript also supports regex ...
Jim Richards wrote:
>>The other thing I haven't found reference to yet is
>>client side validation (but I also haven't looked that hard either)
> I did notice that you had your name down for the client
> side validation. I'd be interested in your thoughts, and
> ideas because this is something I've done a lot of
> recently (not in Struts/JSP though) ...
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 425-0252; Fax 716 223-2506.
-- http://www.husted.com/about/struts/
Re: Old questions that die hard
Posted by Jim Richards <gr...@cyber4.org>.
Ted Husted wrote:
> Jim Richards wrote:
> >The other thing I haven't found reference to yet is
> >client side validation (but I also haven't looked that hard either)
>
> It's on the 1.1 TODO list.
>
> And, of course, we're glad that you've checked in again!
I did notice that you had your name down for the client
side validation. I'd be interested in your thoughts, and
ideas because this is something I've done a lot of
recently (not in Struts/JSP though) ...
Re: Old questions that die hard
Posted by Ted Husted <ne...@husted.com>.
Jim Richards wrote:
>The other thing I haven't found reference to yet is
>client side validation (but I also haven't looked that hard either)
It's on the 1.1 TODO list.
And, of course, we're glad that you've checked in again!