You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Jason van Zyl <jv...@apache.org> on 2001/05/15 23:02:40 UTC
Re: cvs commit:
jakarta-turbine/src/java/org/apache/turbine/torque/engine/database/model
Column.java
mikeh@apache.org wrote:
>
> mikeh 01/05/15 09:53:40
>
> Modified: src/java/org/apache/turbine/torque/engine/database/model
> Column.java
> Log:
> added the necessary set/get for inputValidator
>
I don't think validation should be made part of the database model.
Validation has nothing to do a column in the database, you have
to validate a piece of information that is entered at the application
level.
How about moving the validation hooks to intake?
--
jvz.
Jason van Zyl
jvanzyl@apache.org
http://jakarta.apache.org/velocity
http://jakarta.apache.org/turbine
http://jakarta.apache.org/commons
http://tambora.zenplex.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-turbine/src/java/org/apache/turbine/torque/engine/database/model Column.java
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Jason van Zyl <jv...@apache.org> writes:
> I'm sorry I didn't pay attention when you brought this up the first
> time,
> but I really don't think binding the validation into the peers is really
> a good idea.
I have to agree with Jason's comment. If this is should go anywhere,
it should live in the business objects' setXxx() methods. It is also
seems rather unnecessary w/ Intake, but could be used for an
additional level of validation (which defaults to turned off).
Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: cvs commit:
jakarta-turbine/src/java/org/apache/turbine/torque/engine/database/model
Column.java
Posted by Jason van Zyl <jv...@apache.org>.
Mike Haberman wrote:
>
> On Tue, May 15, 2001 at 05:02:40PM -0400, Jason van Zyl wrote:
> > I don't think validation should be made part of the database model.
> > Validation has nothing to do a column in the database, you have
> > to validate a piece of information that is entered at the application
> > level.
>
> I think the line of application input validation and database input
> validation is a gray one. Saying not null, default, unique are a form
> of pushing input validation to the database server. Column.java
> is being used simply as the glue to get the data from the dtd into
> the Peer.
I don't think it's gray. I don't remember the vote but if the vote
was to happen again it would definitely be -1. You design an application
from the user's perspective and the information entered must be valid
in order for other user's in the system to use that information in
an effective manner.
If Bob is entering product information and as the designer of the
application
you decide that the product name must be unique so that information is
not stored in multiple places. This is because you want the data for
that product to have some integrity. This has nothing to do the
persistence layer. That you can enforce this at the database level
is irrelevant. You can use it as a catchall in the event that you
didn't properly trap the invalid data at the application but I don't
really think this is a form a application form validation.
It is most likely that people will use a database, but what if people
are writing simple apps where the data is stored in flat files, or
we create a Turbine app that is a front-end for modify LDAP entries?
How would we validate LDAP entries using what you have committed.
To me forms and validation are completely separate and it's not
a gray area at all.
> The whole idea is to provide a lightweight mechanism so that users
> can plug in their own form of doing input validation.
> Once you say
> <column name="email" .. inputValidator="org.apache...EmailValidator" />
>
> You can then do the following:
> iv = peer.getInputValidator(EMAIL);
> if (iv.checkInput(input) {
> }
> else {
> }
Again, what if I want to validate something in a form that is not
destined for a column in a database?
> Also, if you have a form that doesn't map 1-1 with Peers, you can
> use the InputValidators directly e.g.
I want to validate a login name against an Windows2000 server. What
does that have to do with peers?
> HashMap map ..
> map.put("email", new EmailValidator());
> map.put("name", new NotEmptyValidor());
> ..
> util.checkInput(map, parameterParser);
>
> That tool is yet to be committed. But it will also do
> util.checkInput(peer, parameterParser);
> where it will cycle through the pp checking the input against the peer
> validators.
>
> thanks for the input, I'm not totally against not
> using database/model/*. But I need some way to make the association.
I'm a very strong -1 for tying the validation into the peer system.
I think we can come up with a better model using what intake has
started.
Use simple field definitions, any form is composed of a set of simple
fields
that are mediated. The mediator contains all the form specific
validation
code so that there is no coupling between the actual field objects.
The mediator can then use the validator stuff you've made. The mediator
could dynamically load a validators objects that implement Validator so
that the mediator/validation object coupling is low between fields and
there validators.
John/Jon had the idea of placing a form description in it's own XML
file.
I think this would be good as it separates the application designers job
from the database designer (maybe one in the same in most cases). The
app
should be designed first and then these XML files describing forms and
possibly
work flow could be passed through a tool to help make the database
schema.
I don't know exactly how this would work.
I understand that you want to keep everything in one XML file, but I
don't
think it's appropriate to cram all the application's information in
there.
Struts has a nice model I think, maybe we could steal some of there
ideas.
I'm sorry I didn't pay attention when you brought this up the first
time,
but I really don't think binding the validation into the peers is really
a good idea.
--
jvz.
Jason van Zyl
jvanzyl@apache.org
http://jakarta.apache.org/velocity
http://jakarta.apache.org/turbine
http://jakarta.apache.org/commons
http://tambora.zenplex.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-turbine/src/java/org/apache/turbine/torque/engine/database/model Column.java
Posted by Mike Haberman <mi...@ncsa.uiuc.edu>.
On Tue, May 15, 2001 at 05:02:40PM -0400, Jason van Zyl wrote:
> I don't think validation should be made part of the database model.
> Validation has nothing to do a column in the database, you have
> to validate a piece of information that is entered at the application
> level.
I think the line of application input validation and database input
validation is a gray one. Saying not null, default, unique are a form
of pushing input validation to the database server. Column.java
is being used simply as the glue to get the data from the dtd into
the Peer.
The whole idea is to provide a lightweight mechanism so that users
can plug in their own form of doing input validation.
Once you say
<column name="email" .. inputValidator="org.apache...EmailValidator" />
You can then do the following:
iv = peer.getInputValidator(EMAIL);
if (iv.checkInput(input) {
}
else {
}
Also, if you have a form that doesn't map 1-1 with Peers, you can
use the InputValidators directly e.g.
HashMap map ..
map.put("email", new EmailValidator());
map.put("name", new NotEmptyValidor());
..
util.checkInput(map, parameterParser);
That tool is yet to be committed. But it will also do
util.checkInput(peer, parameterParser);
where it will cycle through the pp checking the input against the peer
validators.
thanks for the input, I'm not totally against not
using database/model/*. But I need some way to make the association.
mike
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org