You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Mike Haberman <mi...@ncsa.uiuc.edu> on 2001/03/09 17:47:11 UTC
PROPOSAL: form verification
Hello All,
I started to look at intake's solution to do input verification
and it looks great. However, I would like to propose an
alternative/joint solution. My goal is to integrate this solution
with intake and to give people a framwork/base to allow them to use
their own form verification techniques if they want to do things
differently.
From all the different solutions that people propose to do form
verification, the one thing they all have in common is that some class
gets called to verify the input. (eg. SomeClass.isValid(input)).
A majority of these classes could be reused, (e.g. EmailAddressVerifier,
USPhoneNumberVerifier, USDateVerifier, NonEmptyVerifier, etc). This is
the base set that Turbine provides.
I would like to start collecting these classes so that turbine (and
non-turbine applications can use them as well.
Now the only hook into turbine is the following:
change the database.dtd
-----------------------
add one extra attribute to the column:
verificationClass CDATA #IMPLIED
change Column.java
----------------
get/set Methods for verficationClass
change BasePeer.java
--------------------
Add the Methods
getInputVerifier(String columnName)
setInputVerifier(String columnName, String className)
change Peer.vm
--------------
to make use of it all during Peer generation
Here's the benefit of all this
-----------------------------
Intake can make use of the popular input verification classes that
already exist. As can your home brewed form verification methods.
We provide the base classes, you decide on policy and mechanism.
If you decide to use intake, great; otherwise you still have a
base to work from to do your own form verification.
Application writers can put the InputVerifier in the context so that
template writers could do client side verification.(i.e javascript)
It's very painless (takes no time) for someone to add input verification
to their application: They use the SAME app-schmea.xml file and just
add the class name to the relevant column.
On the development side you just do:
InputVerifier verify = BasePeer.getInputVerifier(BasePeer.Name)
if ( verify.isValid(input)) {
}
// here's the interface for an InputVerifier
public boolean isValid(String input);
public void checkInput(String value) throws FormInputException;
public String getErrorMessage(String input);
public String getJavaScript();
public String getExpectedFormat();
I'll be happy to add the functionality. I've been using it for awhile
for a variety of projects (turbine and non-turbine stuff). And now
I won't have to swap in my own database.dtd, torque templates, and
Column.java for my turbine projects.
Let me know!
thanks,
mike
--
-------------------------------------------------
I am Vinz, Vinz Clortho. Keymaster of Gozer,
Volguus Zildrohar, Lord of the Sebouillia.
Are you the Gatekeeper?
-------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: PROPOSAL: form verification
Posted by John McNally <jm...@collab.net>.
1. Whether to (a)integrate the form validation into the schema.xml file
or (b)create a separate specification.
(a) has the advantage that allows the elimination of duplication of
entries, for example a size="255" specification for a column can be
interpreted as a requirement that maxLength="255" on the verification
end, where in (b)the length is specified in two places.
One of the main reasons I have chosen (b) is that it allows a form
validation service to be built that integrates nicely with the om/peer
model but would be easier to use with other OR mapping such as container
managed EJB. I also think it would be useful to have some details
relevant to validation be configurable in xml, for example a valid date
range. I was thinking it might make a single specification overly
complex.
It would probably be a good idea to include transformation from one to
another, to make things easier. Or if no one besides me sees an
advantage to two files, we could combine them. I really do not want to
do the work towards this, however. I would like to develop the xml in
parallel with torque until the feature set (available verifications) is
nailed down better.
2. It is my intention that many verification classes be available. As
the input from Neeme Praks and
Leandro Rodrigo Saad Cruz and now you have made it clear this is
desirable. I have a question on
> verification, the one thing they all have in common is that some class
> gets called to verify the input. (eg. SomeClass.isValid(input)).
> A majority of these classes could be reused, (e.g. EmailAddressVerifier,
> USPhoneNumberVerifier, USDateVerifier, NonEmptyVerifier, etc). This is
> the base set that Turbine provides.
How does your system deal with the requirement to have both USDate and
NonEmpty. I brings up a point Leandro had about verification between
fields. I have chosen a specification of fields that may not make such
verification possible, but I am confident it can be worked out. For
example a password verification field, this field probably does not have
persistence, where does this fit with your model? I think something
like can be worked in with field attributes or a specific field type
(verifier class).
I like your idea of the javascript method and it goes along with an idea
that I had for future improvement of a hook into a help system. Please
try to think about how your ideas might fit into the intake service.
One of the goals of intake was to simplify the process of providing
re-entry in a form for invalid input in line with the pull model. I
still haven't gotten to the point of being able to display this result,
but I think I have much of what is needed.
Another objective was to eliminate the overhead of ValueParser's
setProperties. I originally started using torque to generate classes
using setters/getters directly, but have scaled back a bit in the hope
that the service will be easier to implement and develop with the
possibility of adding back the torque optimization at a later stage and
as possibly something that is added to the build process later in the
development cycle. As it currently stands the service uses the xml
specification to cache some of reflection result up front and also a
reusable pool of input classes so that the introspection is not
something that is being done per request. It is probably possible to
front load the entire introspection process, though I have not done so
as of yet. The reusable pool is ripped off from the pool service, but
is modified to pool the partially initialized variations. (I have not
implemented the Recyclable interface yet, but of course it is needed in
this context)
All this is available in the services.intake package, please consider
the torque implementation to be old for the moment. The service is not
functional and currently without even much javadoc, I will improve the
javadoc at least minimally within the next day or so (I should be doing
it now, but I worked on this about 20 hours yesterday and it has taken
me close to 2 hours just to write this one email). Anyone who wishes to
work on functionality is extremely welcome, but as Jon said let's try to
get a killer service instead of a lot of different ways to accomplish
it.
John McNally
Mike Haberman wrote:
>
> Hello All,
>
> I started to look at intake's solution to do input verification
> and it looks great. However, I would like to propose an
> alternative/joint solution. My goal is to integrate this solution
> with intake and to give people a framwork/base to allow them to use
> their own form verification techniques if they want to do things
> differently.
>
> From all the different solutions that people propose to do form
> verification, the one thing they all have in common is that some class
> gets called to verify the input. (eg. SomeClass.isValid(input)).
> A majority of these classes could be reused, (e.g. EmailAddressVerifier,
> USPhoneNumberVerifier, USDateVerifier, NonEmptyVerifier, etc). This is
> the base set that Turbine provides.
>
> I would like to start collecting these classes so that turbine (and
> non-turbine applications can use them as well.
>
> Now the only hook into turbine is the following:
>
> change the database.dtd
> -----------------------
> add one extra attribute to the column:
> verificationClass CDATA #IMPLIED
>
> change Column.java
> ----------------
> get/set Methods for verficationClass
>
> change BasePeer.java
> --------------------
> Add the Methods
> getInputVerifier(String columnName)
> setInputVerifier(String columnName, String className)
>
> change Peer.vm
> --------------
> to make use of it all during Peer generation
>
> Here's the benefit of all this
> -----------------------------
> Intake can make use of the popular input verification classes that
> already exist. As can your home brewed form verification methods.
> We provide the base classes, you decide on policy and mechanism.
> If you decide to use intake, great; otherwise you still have a
> base to work from to do your own form verification.
>
> Application writers can put the InputVerifier in the context so that
> template writers could do client side verification.(i.e javascript)
>
> It's very painless (takes no time) for someone to add input verification
> to their application: They use the SAME app-schmea.xml file and just
> add the class name to the relevant column.
>
> On the development side you just do:
>
> InputVerifier verify = BasePeer.getInputVerifier(BasePeer.Name)
> if ( verify.isValid(input)) {
> }
>
> // here's the interface for an InputVerifier
> public boolean isValid(String input);
> public void checkInput(String value) throws FormInputException;
> public String getErrorMessage(String input);
> public String getJavaScript();
> public String getExpectedFormat();
>
> I'll be happy to add the functionality. I've been using it for awhile
> for a variety of projects (turbine and non-turbine stuff). And now
> I won't have to swap in my own database.dtd, torque templates, and
> Column.java for my turbine projects.
>
> Let me know!
>
> thanks,
>
> mike
>
> --
> -------------------------------------------------
> I am Vinz, Vinz Clortho. Keymaster of Gozer,
> Volguus Zildrohar, Lord of the Sebouillia.
> Are you the Gatekeeper?
> -------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: PROPOSAL: form verification
Posted by Jon Stevens <jo...@latchkey.com>.
on 3/9/01 8:47 AM, "Mike Haberman" <mi...@ncsa.uiuc.edu> wrote:
> I'll be happy to add the functionality. I've been using it for awhile
> for a variety of projects (turbine and non-turbine stuff). And now
> I won't have to swap in my own database.dtd, torque templates, and
> Column.java for my turbine projects.
>
>
> Let me know!
I think John is the deciding factor on this, but I'm all for the ability to
plug in different systems and making it easy to do so.
Comments: I do wish that we work together on this stuff to come up with one
really great solution instead of a bazillion half done (or fully done)
solutions. Mostly because people tend to want to just pick one solution and
go with it and having to choose from a ton of different options can be
confusing. I think that is partly why over time this group has been
migrating to Velocity as a single solution. It is cool to support a ton of
template tools, but when it comes down to it...we just want one that works.
thanks,
-jon
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org