formproc-developer

RE: [FormProc-developer] RE: Validation by type

[Anthony E. <me...@an...>]

What gave you the idea that FormProc is a lightweight validation framework?
FormProc is in fact it is a form processing framework.  Part of form
processing, in my opinion, is to make it easier to store the form data in an
object, hence the auto population facilities provided by FormProc.  I
consider it part of the core functionality of FormProc.

Does anyone else have an opinion on this?  Do you like or dislike the way
FormProc auto populates objects?  Not that I am going to change it or
anything.  :-)

-Anthony

> -----Original Message-----
> From: Nick Bauman [mailto:ni...@co...]
> Sent: Wednesday, January 23, 2002 10:37 AM
> To: me...@an...
> Subject: RE: [FormProc-developer] RE: Validation by type
>
>
> Anthony,
>
> > widget and the FormElement class.  My reason for this is that the
> > FormElement does more than just validation - it also maps the form
> > field to a write method on a target object.  Thus having a single
>
> Howcome your framework has object population in addition to data
> validation? I mean isn't the population out of the context of a
> lightweight validation framework? It's like having a water pipe that does
> a loop-de-loop. It's pretty neat lookin', but it's having a
> strange effect
> on design, don't you think?
>
> I mean correct me: I'm not you and I'd be convinced if you could make a
> case for the coupling. Think of me as being too dumb to understand and I
> need to be enlightened. :)
>
> --
> Nick Bauman
> Java Programmer.
> Available Cheap.
> Minneapolis area.
> Will commute interstate.
> Resume: http://www.cortexity.com/resume.html
>

[FormProc-developer] Object Population and Validation (was: Validation by type)

[Nick B. <ni...@co...>]

I understand. That's great, I think it's a good idea. I was making an 
assumption that these are 2 different goals that s/b decoupled. It is, 
however, not wrong to couple them.

Thinking aloud: 

For myself, and maybe I need some religion on this one, but I personally 
don't like frameworks that make me change my objects to fit them better, 
or have to make discriptors of my objects that are external to them which 
make it possible for a framework to use them. For me to accept this, I'm 
going to take a long hard look before leaping. This is why I like the idea 
of decoupling the data validation from the object population. Maybe I want 
to plug in my own object population strategy? For this a peer interface is 
all that's needed. (If you've guessed that I dislike CORBA for this reason 
you're partially right, but only in particular when everyone is speaking 
Java, but that's another argument) 

Also, Anthony, the object population portion has taken root in your 
design. Is that a good thing? Maybe it is, but it makes me think. 

> What gave you the idea that FormProc is a lightweight validation
> framework? FormProc is in fact it is a form processing framework.  Part
> of form processing, in my opinion, is to make it easier to store the
> form data in an object, hence the auto population facilities provided
> by FormProc.  I consider it part of the core functionality of FormProc.
> 
> Does anyone else have an opinion on this?  Do you like or dislike the
> way FormProc auto populates objects?  Not that I am going to change it
> or anything.  :-)
> 
> -Anthony
> 
>> -----Original Message-----
>> From: Nick Bauman [mailto:ni...@co...]
>> Sent: Wednesday, January 23, 2002 10:37 AM
>> To: me...@an...
>> Subject: RE: [FormProc-developer] RE: Validation by type
>>
>>
>> Anthony,
>>
>> > widget and the FormElement class.  My reason for this is that the
>> > FormElement does more than just validation - it also maps the form
>> > field to a write method on a target object.  Thus having a single
>>
>> Howcome your framework has object population in addition to data
>> validation? I mean isn't the population out of the context of a
>> lightweight validation framework? It's like having a water pipe that
>> does a loop-de-loop. It's pretty neat lookin', but it's having a
>> strange effect
>> on design, don't you think?
>>
>> I mean correct me: I'm not you and I'd be convinced if you could make
>> a case for the coupling. Think of me as being too dumb to understand
>> and I need to be enlightened. :)

-- 
Nick Bauman 
Java Programmer. 
Available Cheap. 
Minneapolis area.
Will commute interstate.
Resume: http://www.cortexity.com/resume.html

RE: [FormProc-developer] Object Population and Validation (was: Validation by type)

[Anthony E. <me...@an...>]

Comments inline.

> -----Original Message-----
> From: for...@li... 
> [mailto:for...@li...] On 
> Behalf Of Nick Bauman
> Sent: Wednesday, January 23, 2002 11:37 AM
> To: for...@li...
> Subject: [FormProc-developer] Object Population and 
> Validation (was: Validation by type)
> 
> 
> I understand. That's great, I think it's a good idea. I was making an 
> assumption that these are 2 different goals that s/b 
> decoupled. It is, 
> however, not wrong to couple them.

Good, glad we agree. :-)

> 
> Thinking aloud: 
> 
> For myself, and maybe I need some religion on this one, but I 
> personally 
> don't like frameworks that make me change my objects to fit 
> them better, 
> or have to make discriptors of my objects that are external 
> to them which 
> make it possible for a framework to use them. 

The good news is that you don't have to change your objects to work with
FormProc.  The data population is not required.  You do not have to
specify write methods and if a setXXX() method is not found then that
field will be skipped (validation will still occur though).

> For me to 
> accept this, I'm 
> going to take a long hard look before leaping. This is why I 
> like the idea 
> of decoupling the data validation from the object population. 
> Maybe I want 
> to plug in my own object population strategy? 

Being able to plug in an object population strategy is not a bad idea.
If you ever find that you do need to do this then let me know and I will
work on making the population part of FormProc pluggable.  One thing to
note is that FormProc attempts to follow the JavaBeans standards when
populating objects since it is the accepted standard for working with
unknown components at runtime.

> For this a peer 
> interface is 
> all that's needed. (If you've guessed that I dislike CORBA 
> for this reason 
> you're partially right, but only in particular when everyone 
> is speaking 
> Java, but that's another argument) 
> 
> Also, Anthony, the object population portion has taken root in your 
> design. Is that a good thing? Maybe it is, but it makes me think. 

I wouldn't say that it has taken root, rather it is the most common way
that people think about forms (AFAICT).  Even if FormProc was not
designed to populate objects I would still maintain the one-to-one
relationship between form widgets and FormElements in FormProc.

-Anthony

RE: [FormProc-developer] Object Population and Validation (was: Validation by type)

[Nick B. <ni...@co...>]

Anthony Wrote:

> Comments inline.
> 
>> -----Original Message-----
>> From: for...@li... 
>> [mailto:for...@li...] On 
>> Behalf Of Nick Bauman
>> Sent: Wednesday, January 23, 2002 11:37 AM
>> To: for...@li...
>> Subject: [FormProc-developer] Object Population and 
>> Validation (was: Validation by type)
>> 
>> 
>> I understand. That's great, I think it's a good idea. I was making an 
>> assumption that these are 2 different goals that s/b 
>> decoupled. It is, 
>> however, not wrong to couple them.
> 
> Good, glad we agree. :-)
> 
>> 
>> Thinking aloud: 
>> 
>> For myself, and maybe I need some religion on this one, but I 
>> personally 
>> don't like frameworks that make me change my objects to fit 
>> them better, 
>> or have to make discriptors of my objects that are external 
>> to them which 
>> make it possible for a framework to use them. 
> 
> The good news is that you don't have to change your objects to work
> with FormProc.  The data population is not required.  You do not have
> to specify write methods and if a setXXX() method is not found then
> that field will be skipped (validation will still occur though).

Perfect.
 
>> For me to 
>> accept this, I'm 
>> going to take a long hard look before leaping. This is why I 
>> like the idea 
>> of decoupling the data validation from the object population. 
>> Maybe I want 
>> to plug in my own object population strategy? 
> 
> Being able to plug in an object population strategy is not a bad idea.
> If you ever find that you do need to do this then let me know and I
> will work on making the population part of FormProc pluggable.  One
> thing to note is that FormProc attempts to follow the JavaBeans
> standards when populating objects since it is the accepted standard for
> working with unknown components at runtime.

Sure, JavaBeans is what I assumed. Principle of Least Astonishment.
 
>> For this a peer 
>> interface is 
>> all that's needed. (If you've guessed that I dislike CORBA 
>> for this reason 
>> you're partially right, but only in particular when everyone 
>> is speaking 
>> Java, but that's another argument) 
>> 
>> Also, Anthony, the object population portion has taken root in your 
>> design. Is that a good thing? Maybe it is, but it makes me think. 
> 
> I wouldn't say that it has taken root, rather it is the most common way
> that people think about forms (AFAICT).  Even if FormProc was not
> designed to populate objects I would still maintain the one-to-one
> relationship between form widgets and FormElements in FormProc.

I was being too obtuse by the phrase "taken root", my fault. Specifically, 
and not to belabor the point, I was implying "the subsystem of object 
population is influencing the (potentially unrelated) data validation 
subsystem". And there's nothing wrong with that, it's just something to 
consider. :-)

> -Anthony
> 

-- 
Nick Bauman 
- A Fella That Thinks FormProc is awesome

RE: [FormProc-developer] Object Population and Validation (was: Validation by type)

[Anthony E. <me...@an...>]

> >>
> >> Also, Anthony, the object population portion has taken root in your
> >> design. Is that a good thing? Maybe it is, but it makes me think.
> >
> > I wouldn't say that it has taken root, rather it is the most common way
> > that people think about forms (AFAICT).  Even if FormProc was not
> > designed to populate objects I would still maintain the one-to-one
> > relationship between form widgets and FormElements in FormProc.
>
> I was being too obtuse by the phrase "taken root", my fault.
> Specifically,
> and not to belabor the point, I was implying "the subsystem of object
> population is influencing the (potentially unrelated) data validation
> subsystem". And there's nothing wrong with that, it's just something to
> consider. :-)

Duly noted.  If it ever becomes a problem (for you or other FormProc users)
then we can re-address it then.

-Anthony