formproc-developer — Developer interests

RE: [FormProc-developer] multi-validator

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

I just realized after I sent this message out that the
FormValidatorGroup is in version 0.5 which is unreleased at this time.
Therefore this feature is only in the CVS repository.  I am going to
release 0.5 soon - I want to put in JD's patch for using relative file
names first.

-Anthony

> -----Original Message-----
> From: for...@li... 
> [mailto:for...@li...] On 
> Behalf Of Anthony Eden
> Sent: Monday, January 07, 2002 5:16 PM
> To: FormProc Developer List
> Subject: RE: [FormProc-developer] multi-validator
> 
> 
> FormProc doesn't support multiple validators for an element 
> in the manner which you have shown below.  To use multiple 
> validators you should use a FormValidatorGroup.  A 
> FormValidatorGroup can hold any number of FormValidators.  
> And since the FormValidatorGroup is a FormValidator itself 
> you can nest form validators.
> 
> The type mapping for the FormValidatorGroup is specified in 
> the formproc.xml file.  I have used the word "group" in the 
> example below.
> 
> Thus the proper configuration would be:
> 
> <formproc:element name="age">
>   <formproc:validator type="group">
>     <formproc:validator type="rule">
>       <rule>org.formproc.example.IsIntRule</rule>
>       <formproc:error lang="en">Valid age must be 
> integer.</formproc:error>
>     </formproc:validator>
>  		
>     <formproc:validator type="expression">
>       <pattern>^(2[0-9])$</pattern>
>       <formproc:error lang="en">Valid age must be between 
> 20-29.</formproc:error>
>     </formproc:validator>
> 
>   </formproc:validator>   
> 
>   <formproc:message lang="en">Valid age required.</formproc:message>
>  
> </formproc:element>
> 
> 
> If you are still having problems then please mention which 
> version of FormProc you are using in any future messages.
> 
> Sincerely,
> Anthony Eden
> 
> 
> > -----Original Message-----
> > From: for...@li...
> > [mailto:for...@li...] On 
> > Behalf Of INFO II
> > Sent: Monday, January 07, 2002 1:01 PM
> > To: for...@li...
> > Subject: [FormProc-developer] multi-validator
> > 
> > 
> > Hi,
> > 
> > Just a little question regarding "multi-validator" for
> > a specific element.  Why my example doesn't work?
> > 
> > Here I want to validate first if the "age" is an
> > integer, after I would like to validate the range of
> > value (20-29).  I know if I use only the regexp it's
> > enough to do the job, but to do the test of
> > "multi-validator", I have tried this.
> > 
> > =======================================================
> > 
> > <formproc:element name="age">
> >   <formproc:validator type="rule">
> >     <rule>org.formproc.example.IsIntRule</rule>
> >     <formproc:error lang="en">Valid age must be
> > integer.</formproc:error>
> >   </formproc:validator>
> > 		
> >   <formproc:validator type="expression">
> >     <pattern>^(2[0-9])$</pattern>
> >     <formproc:error lang="en">Valid age must be
> > between 20-29.</formproc:error>
> >   </formproc:validator>
> >   
> >   <formproc:message lang="en">Valid age required.   
> > </formproc:message>
> > 
> > </formproc:element>
> > 
> > 
> > 
> > Each validator have been tested separatly and works
> > fine.  But together, only the first is tested.
> > 
> > 
> > Thanks.
> > 
> > __________________________________________________
> > Do You Yahoo!?
> > Send FREE video emails in Yahoo! Mail!
> > http://promo.yahoo.com/videomail/
> > 
> > 
> > _______________________________________________
> > FormProc-developer mailing list
> > For...@li...
> > https://lists.sourceforge.net/lists/listinfo/formproc-developer
> > 
> 
> 
> _______________________________________________
> FormProc-developer mailing list
> For...@li...
> https://lists.sourceforge.net/lists/listinfo/formproc-developer
> 

RE: [FormProc-developer] multi-validator

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

FormProc doesn't support multiple validators for an element in the
manner which you have shown below.  To use multiple validators you
should use a FormValidatorGroup.  A FormValidatorGroup can hold any
number of FormValidators.  And since the FormValidatorGroup is a
FormValidator itself you can nest form validators.

The type mapping for the FormValidatorGroup is specified in the
formproc.xml file.  I have used the word "group" in the example below.

Thus the proper configuration would be:

<formproc:element name="age">
  <formproc:validator type="group">
    <formproc:validator type="rule">
      <rule>org.formproc.example.IsIntRule</rule>
      <formproc:error lang="en">Valid age must be
integer.</formproc:error>
    </formproc:validator>
 		
    <formproc:validator type="expression">
      <pattern>^(2[0-9])$</pattern>
      <formproc:error lang="en">Valid age must be between
20-29.</formproc:error>
    </formproc:validator>

  </formproc:validator>   

  <formproc:message lang="en">Valid age required.</formproc:message>
 
</formproc:element>


If you are still having problems then please mention which version of
FormProc you are using in any future messages.

Sincerely,
Anthony Eden


> -----Original Message-----
> From: for...@li... 
> [mailto:for...@li...] On 
> Behalf Of INFO II
> Sent: Monday, January 07, 2002 1:01 PM
> To: for...@li...
> Subject: [FormProc-developer] multi-validator
> 
> 
> Hi,
> 
> Just a little question regarding "multi-validator" for
> a specific element.  Why my example doesn't work?
> 
> Here I want to validate first if the "age" is an
> integer, after I would like to validate the range of
> value (20-29).  I know if I use only the regexp it's
> enough to do the job, but to do the test of 
> "multi-validator", I have tried this.
> 
> =======================================================
> 
> <formproc:element name="age">
>   <formproc:validator type="rule">
>     <rule>org.formproc.example.IsIntRule</rule>
>     <formproc:error lang="en">Valid age must be 
> integer.</formproc:error>
>   </formproc:validator>
> 		
>   <formproc:validator type="expression">
>     <pattern>^(2[0-9])$</pattern>
>     <formproc:error lang="en">Valid age must be
> between 20-29.</formproc:error>
>   </formproc:validator>
>   
>   <formproc:message lang="en">Valid age required.   
> </formproc:message>
> 
> </formproc:element>
> 
> 
> 
> Each validator have been tested separatly and works
> fine.  But together, only the first is tested. 
> 
> 
> Thanks.
> 
> __________________________________________________
> Do You Yahoo!?
> Send FREE video emails in Yahoo! Mail! 
> http://promo.yahoo.com/videomail/
> 
> 
> _______________________________________________
> FormProc-developer mailing list 
> For...@li...
> https://lists.sourceforge.net/lists/listinfo/formproc-developer
> 

[FormProc-developer] multi-validator

[INFO II <in...@ya...>]

Hi,

Just a little question regarding "multi-validator" for
a specific element.  Why my example doesn't work?

Here I want to validate first if the "age" is an
integer, after I would like to validate the range of
value (20-29).  I know if I use only the regexp it's
enough to do the job, but to do the test of 
"multi-validator", I have tried this.

=======================================================

<formproc:element name="age">
  <formproc:validator type="rule">
    <rule>org.formproc.example.IsIntRule</rule>
    <formproc:error lang="en">Valid age must be
integer.</formproc:error>
  </formproc:validator>
		
  <formproc:validator type="expression">
    <pattern>^(2[0-9])$</pattern>
    <formproc:error lang="en">Valid age must be
between 20-29.</formproc:error>
  </formproc:validator>
  
  <formproc:message lang="en">Valid age required.   
</formproc:message>

</formproc:element>



Each validator have been tested separatly and works
fine.  But together, only the first is tested. 


Thanks.

__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/

[FormProc-developer] Relative paths

[JD E. <jd...@sa...>]

 Hi every body,

 I just added a little bit of code to the file org.formproc.FormManager.java
from the version 0.4

 With this code you can specify a 'file' name  (relative to the
formproc.xml's localization) in the form definition instead  the full
'path'.

 The form definition in formproc.xml will change from:

<formproc:form name="test"
loader="com.anthonyeden.lib.resource.FileResourceLoader"
              path="C:\classes\FormProc\example\example-form.xml"
monitor="true"/>


to:

 <formproc:form name="test"
loader="com.anthonyeden.lib.resource.FileResourceLoader"
               file="example-form.xml" monitor="true"/>


Attached are the diff and the full file.


Best regards
  JD Evora

[FormProc-developer] Test

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

This is a test message.

-Anthony

RE: [FormProc-developer] Getting an iteration of the form element names

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

>> > So it is not possible for your classes to implement the
>> > org.formproc.validation.Rule interface?  Their is no need to be in
>> > any specific package as the classes are dynamically loaded.  Do all
>> > of your rules already implement a common interface?
>>
>> Yes, they do. It's called Rule.java. I could make that extend your
>> Rule interface... It can't be that easy, can it? Why did I think I
>> should dismiss this idea earlier?
> 
> It should be that easy.  If you want to completely decouple your code
> from the FormProc code then you could have an intermediate class which
> implements the FormProc Rule interface call your code.  That adds
> another level of indirection that may not be necessary but it would
> completely separate your code from the FormProc framework except for
> that single class.

That's what I'll do: thanks Anthony! (BTW: the approach you suggest is the
Visitor pattern) My hope is to improve both of our systems.

http://www.clickblocks.org/patterns1/pattern_synopses.htm#Visitor

> Sincerely,
> Anthony Eden
> 

-- 
Nick Bauman 
Cortexity Development
http://www.cortexity.com/

RE: [FormProc-developer] Getting an iteration of the form element names

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

> > So it is not possible for your classes to implement the
> > org.formproc.validation.Rule interface?  Their is no need to be in any
> > specific package as the classes are dynamically loaded.  Do all of your
> > rules already implement a common interface?
>
> Yes, they do. It's called Rule.java. I could make that extend your Rule
> interface... It can't be that easy, can it? Why did I think I should
> dismiss this idea earlier?

It should be that easy.  If you want to completely decouple your code from
the FormProc code then you could have an intermediate class which implements
the FormProc Rule interface call your code.  That adds another level of
indirection that may not be necessary but it would completely separate your
code from the FormProc framework except for that single class.

Sincerely,
Anthony Eden

RE: [FormProc-developer] Getting an iteration of the form element names

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

Anthony,

>> >> >>
>> >> >> You want to be able to reload the config at time intervals for
>> >> >> one.
>> >> >
>> >> > Will do.  I suppose this should be a paramter in the
>> >> > configuration?
>> >>
>> >> Yes. I'm making it an attribute of the top-level integradata
>> >> element.
>> >>
>> >
>> > Nick,
>> >
>> > Actually, it already monitors for configuration changes.  Right now
>> > it defaults to 5 seconds, but I will add the ability to configure it
>> > through a configuration field before the next release.  This is
>> > different then reloading at specific intervals and only works with
>> > resources which maintain a modification time, but I feel that it is
>> > a useful feature none the less. Regardless, I should probably also
>> > provide a way to specify specific reload intervals as well as the
>> > ability to disable all of these features.
>> >
>> > -Anthony
>>
>> Yes, an optional attribute is what I didn't say: I'm influenced
>> by the same
>> forces you are. However, I'm not sure what you mean by "resources
>> which maintain a modification time", as I would assume an XML file
>> would by definition always subject to mod time changes, checksumming
>> and all that.
> 
> XML files may not always be the configuration source, although they are
> the most likely.  However you conceivably pull your XML data from any
> data source which provides an InputStream.

I see what you mean. I have a config (SAX) Handler that reads the config 
file in Integradata, and it requires a Reader. Right now I use a 
ConfigReader class to encapsulate the SAX handler. I haven't uncoupled the 
config from the concept of a File today, but when I find the need (or 
someone screams loadly enough) for it I will. This will end up as a 
SQLConfigReader or something. Not a primo worry for me right now.

>> I still do not have a brilliant idea to make an elegant way to plug my
>> rules into your framework except for an Ant build target that
>> substitutes import statements and all that jazz at compile time. This
>> is
>> "release-only"
>> code. Not much value in the source itself. Yeech.
>>
>> The really interesting thing to me about any data validation framework
>> is high-quality rules-plugability, not merely a system to plug them
>> into. So in my mind this is of cardinal importance and impact for the
>> long run for both of us.
> 
> So it is not possible for your classes to implement the
> org.formproc.validation.Rule interface?  Their is no need to be in any
> specific package as the classes are dynamically loaded.  Do all of your
> rules already implement a common interface?

Yes, they do. It's called Rule.java. I could make that extend your Rule 
interface... It can't be that easy, can it? Why did I think I should 
dismiss this idea earlier?

Let me know.

> -Anthony
> 

-- 
Nick Bauman 
Cortexity Development
Intellectual Process is more important than
Intellectual Property -- you'll see.
http://www.cortexity.com/

RE: [FormProc-developer] Getting an iteration of the form element names

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

>
> >
> >> >>
> >> >> You want to be able to reload the config at time intervals for one.
> >> >
> >> > Will do.  I suppose this should be a paramter in the configuration?
> >>
> >> Yes. I'm making it an attribute of the top-level integradata element.
> >>
> >
> > Nick,
> >
> > Actually, it already monitors for configuration changes.  Right now it
> > defaults to 5 seconds, but I will add the ability to configure it
> > through a configuration field before the next release.  This is
> > different then reloading at specific intervals and only works with
> > resources which maintain a modification time, but I feel that it is a
> > useful feature none the less. Regardless, I should probably also
> > provide a way to specify specific reload intervals as well as the
> > ability to disable all of these features.
> >
> > -Anthony
>
> Yes, an optional attribute is what I didn't say: I'm influenced
> by the same
> forces you are. However, I'm not sure what you mean by "resources which
> maintain a modification time", as I would assume an XML file would by
> definition always subject to mod time changes, checksumming and all that.

XML files may not always be the configuration source, although they are the
most likely.  However you conceivably pull your XML data from any data
source which provides an InputStream.

> I still do not have a brilliant idea to make an elegant way to plug my
> rules into your framework except for an Ant build target that substitutes
> import statements and all that jazz at compile time. This is
> "release-only"
> code. Not much value in the source itself. Yeech.
>
> The really interesting thing to me about any data validation framework is
> high-quality rules-plugability, not merely a system to plug them into. So
> in my mind this is of cardinal importance and impact for the long run for
> both of us.

So it is not possible for your classes to implement the
org.formproc.validation.Rule interface?  Their is no need to be in any
specific package as the classes are dynamically loaded.  Do all of your
rules already implement a common interface?

-Anthony

RE: [FormProc-developer] Getting an iteration of the form element names

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

> 
>> >>
>> >> You want to be able to reload the config at time intervals for one.
>> >
>> > Will do.  I suppose this should be a paramter in the configuration?
>>
>> Yes. I'm making it an attribute of the top-level integradata element.
>>
> 
> Nick,
> 
> Actually, it already monitors for configuration changes.  Right now it
> defaults to 5 seconds, but I will add the ability to configure it
> through a configuration field before the next release.  This is
> different then reloading at specific intervals and only works with
> resources which maintain a modification time, but I feel that it is a
> useful feature none the less. Regardless, I should probably also
> provide a way to specify specific reload intervals as well as the
> ability to disable all of these features.
> 
> -Anthony

Yes, an optional attribute is what I didn't say: I'm influenced by the same 
forces you are. However, I'm not sure what you mean by "resources which 
maintain a modification time", as I would assume an XML file would by 
definition always subject to mod time changes, checksumming and all that.

I still do not have a brilliant idea to make an elegant way to plug my 
rules into your framework except for an Ant build target that substitutes 
import statements and all that jazz at compile time. This is "release-only" 
code. Not much value in the source itself. Yeech.

The really interesting thing to me about any data validation framework is 
high-quality rules-plugability, not merely a system to plug them into. So 
in my mind this is of cardinal importance and impact for the long run for 
both of us.

-- 
Nick Bauman 
Cortexity Development

RE: [FormProc-developer] Getting an iteration of the form element names

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

> >>
> >> You want to be able to reload the config at time intervals for one.
> >
> > Will do.  I suppose this should be a paramter in the configuration?
>
> Yes. I'm making it an attribute of the top-level integradata element.
>

Nick,

Actually, it already monitors for configuration changes.  Right now it
defaults to 5 seconds, but I will add the ability to configure it through a
configuration field before the next release.  This is different then
reloading at specific intervals and only works with resources which maintain
a modification time, but I feel that it is a useful feature none the less.
Regardless, I should probably also provide a way to specify specific reload
intervals as well as the ability to disable all of these features.

-Anthony

[FormProc-developer] Configuration interface

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

I have added a Configuration interface to the CVS a la Avalon.  I have made
a few modifications but the general concept is still the same.  I have also
modified the Validator interface to accept this Configuration interface for
configuration as well as the Rule interface for rules used in the
RuleValidator.

I have not tested it yet, but comments are welcome.

-Anthony

RE: [FormProc-developer] Configuration

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

Kerry,

I like this a lot.  I will work on putting the same concept into FormProc.

Sincerely,
Anthony Eden

> -----Original Message-----
> From: for...@li...
> [mailto:for...@li...]On Behalf Of
> Kerry Todyruik
> Sent: Thursday, November 22, 2001 3:30 PM
> To: for...@li...
> Subject: [FormProc-developer] Configuration
> 
> 
> I'd like to step into this conversation and offer a suggestion.  Have a
> look at the Apache-Jakarta Avalon framework source and see how it
> handles configuration.  It has the same functionality that FormProc has
> now, but instead of passing a JDOM or DOM Element, it passes a
> Configuration object that resulted from some DOM or JDOM code (I didn't
> look close enough to know how it implements the configuration file
> parsing--but I shouldn't have to of course.  As a framework user, all I
> need to be concerned with is the Configuration class API in the
> Javadocs).
> 
> The Avalon page is:
> http://jakarta.apache.org/avalon/
> 
> The Configuration classes are in
> org.apache.avalon.framework.configuration:
> Avalon-4.0/src/java/org/apache/avalon/framework/configuration
> 
> -Kerry
> 
> > > The reason I like passing an Element in is because 1.) it allows the
> > > class to configure itself and 2.) the configuration information can
> > > take advantage of the nice structures which XML provides.
> > 
> > I don't understand how you get something more than what Collections
> provide
> > in XML, especially since XML is still a moving target in a lot of
> areas. A
> > rule can still configure itself if you hardcore model the contract
> with
> > either a Collection (easiest) or with a FormProc-specific class.
> Collections
> > don't take away Rule's self configuration. Maybe it just seems that
> way
> > because you're using DOM, which I still think you should revisit.
> 
> -- 
> Kerry Todyruik <ke...@to...>
> 
> _______________________________________________
> FormProc-developer mailing list
> For...@li...
> https://lists.sourceforge.net/lists/listinfo/formproc-developer
> 
> 

Re: [FormProc-developer] Configuration

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

> I'd like to step into this conversation and offer a suggestion.  Have a
> look at the Apache-Jakarta Avalon framework source and see how it
> handles configuration.  It has the same functionality that FormProc has
> now, but instead of passing a JDOM or DOM Element, it passes a
> Configuration object that resulted from some DOM or JDOM code (I didn't

This is what I was saying: "model the contract". Integradata does this 
using a nested data structure called RuleConfigMap, but only people wanting 
to integrate Integradata into a product need worry about this class. Rule 
consumers and web developers should never have to worry about this stuff.

> look close enough to know how it implements the configuration file
> parsing--but I shouldn't have to of course.  As a framework user, all I
> need to be concerned with is the Configuration class API in the
> Javadocs).
> 
> The Avalon page is:
> http://jakarta.apache.org/avalon/
> 
> The Configuration classes are in
> org.apache.avalon.framework.configuration:
> Avalon-4.0/src/java/org/apache/avalon/framework/configuration
> 
> -Kerry

Interesting.

>> > The reason I like passing an Element in is because 1.) it allows the
>> > class to configure itself and 2.) the configuration information can
>> > take advantage of the nice structures which XML provides.
>> 
>> I don't understand how you get something more than what Collections
> provide
>> in XML, especially since XML is still a moving target in a lot of
> areas. A
>> rule can still configure itself if you hardcore model the contract
> with
>> either a Collection (easiest) or with a FormProc-specific class.
> Collections
>> don't take away Rule's self configuration. Maybe it just seems that
> way
>> because you're using DOM, which I still think you should revisit.
> 
> -- 
> Kerry Todyruik <ke...@to...>
> 
> _______________________________________________
> FormProc-developer mailing list
> For...@li...
> https://lists.sourceforge.net/lists/listinfo/formproc-developer


-- 
Nick Bauman 
Cortexity Development
Intellectual Process is more important than
Intellectual Property -- you'll see.
http://www.cortexity.com/

[FormProc-developer] Configuration

[Kerry T. <ke...@to...>]

I'd like to step into this conversation and offer a suggestion.  Have a
look at the Apache-Jakarta Avalon framework source and see how it
handles configuration.  It has the same functionality that FormProc has
now, but instead of passing a JDOM or DOM Element, it passes a
Configuration object that resulted from some DOM or JDOM code (I didn't
look close enough to know how it implements the configuration file
parsing--but I shouldn't have to of course.  As a framework user, all I
need to be concerned with is the Configuration class API in the
Javadocs).

The Avalon page is:
http://jakarta.apache.org/avalon/

The Configuration classes are in
org.apache.avalon.framework.configuration:
Avalon-4.0/src/java/org/apache/avalon/framework/configuration

-Kerry

> > The reason I like passing an Element in is because 1.) it allows the
> > class to configure itself and 2.) the configuration information can
> > take advantage of the nice structures which XML provides.
> 
> I don't understand how you get something more than what Collections
provide
> in XML, especially since XML is still a moving target in a lot of
areas. A
> rule can still configure itself if you hardcore model the contract
with
> either a Collection (easiest) or with a FormProc-specific class.
Collections
> don't take away Rule's self configuration. Maybe it just seems that
way
> because you're using DOM, which I still think you should revisit.

-- 
Kerry Todyruik <ke...@to...>

[FormProc-developer] Holiday

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

Hey all,

I am taking a vacation this weekend (Thanksgiving).  I will answer any
questions and continue work on FormProc next week.  Happy Holidays!

Sincerely,
Anthony Eden

RE: [FormProc-developer] Integradata and FormProc working together

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

> >>
> >> Before you go and code up a solution, can we see a snippet of XML of
> >> what the config will look like in this case so we can comment? Just a
> >> request.
> >
> > <element name="x">
> > 	<validator type="group">
> > 		<validator type="class"
> > classname="org.formproc.example.UsernameValidator"/>
> > 		<validator type="expression">
> >
> 	<pattern>\w{1,}</pattern>
> > 		</validator>
> > 	</validator>
> > </element>
>
> Since your XML there doesn't have more than one rule inside the "group"
> validator, I can only infer that FormProc will support more than one rule.
> Is this true?

I think the nesting may be unclear.  The "group" type is a validator which
holds other validators.  Look again at how the validators are setup.  The
group validator holds two other validators, a class validator and an
expression validator.

-Anthony

RE: [FormProc-developer] Getting an iteration of the form element names

[Kerry T. <ke...@to...>]

For my purpose at this particular moment... all I really require would
be a list of names in any order.  But I think as a method that others
may want to use it should probably be in the order that it is defined in
the configuration.

And instead of just names it should probably be an iteration of
FormElement objects.  I think that  would be the most useful in
general.  I'll put something together now and email it directly to
Anthony.

-Kerry


> There is no method at this time to enumerate through the element
names.
> Would you expect the list to be in the same order as defined in the
> configuration or in some other order?  Or does it not matter what
order they
> are in?  I suppose that the list should also be passed through the
> Collections.unmodifiableList() method first.
> 
> I wonder: should it be possible to configure forms programtically? 
Should
> you be able to add new FormElement objects to FormConfiguration?  What
other
> areas should be programitically accessible which are not?
> 
> Sincerely,
> Anthony Eden
> 

-- 
Kerry Todyruik <ke...@to...>

RE: [FormProc-developer] Getting an iteration of the form element names

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

Sorry I've been copying you. I hit reply all and forget to remove you
because the list manager always defaults to the poster, not the list.

>> > I wonder: should it be possible to configure forms programtically?
>> > Should you be able to add new FormElement objects to
>> > FormConfiguration?
>> >  What other areas should be programitically accessible which are
>> >  not?
>>
>> You want to be able to reload the config at time intervals for one.
> 
> Will do.  I suppose this should be a paramter in the configuration?

Yes. I'm making it an attribute of the top-level integradata element. 
 
> BTW - There is no need to respond to both me and the mailing list.  One
> message directly to the mailing list is sufficient.  Unless you want to
> scream at me, then we can do that person to person.  :-)
> 
> Sincerely,
> Anthony Eden
> 
> 
> _______________________________________________
> FormProc-developer mailing list
> For...@li...
> https://lists.sourceforge.net/lists/listinfo/formproc-developer


-- 
Nick Bauman 
Cortexity Development
Intellectual Process is more important than
Intellectual Property -- you'll see.
http://www.cortexity.com/

RE: [FormProc-developer] New rules written

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

> The reason I like passing an Element in is because 1.) it allows the
> class to configure itself and 2.) the configuration information can
> take advantage of the nice structures which XML provides.

I don't understand how you get something more than what Collections provide
in XML, especially since XML is still a moving target in a lot of areas. A
rule can still configure itself if you hardcore model the contract with
either a Collection (easiest) or with a FormProc-specific class. Collections
don't take away Rule's self configuration. Maybe it just seems that way
because you're using DOM, which I still think you should revisit.

> As for loading goodies at runtime, I totally agree.   What do you
> propose as an adapter API?

Not enough available buffer space in my brain at the moment (I have a 1k
buffer). Will get to it as soon as I can.

> Something else I think would be good is to be able to use a custom
> class loader to load validators which are not in the classpath at
> startup.  This would allow you to package your validators in a JAR,
> drop them in a directory and off you go - no need to set up the
> classpath.  I am doing this in a couple other projects and it is very
> nice.

Totally agree. I'll consider it. Right now I'm focusing on reloading a
changed config from the filesystem without engine restart and more rules,
rules, rules.

Did you notice how the credit card stuff is far more flexible than ever?
Supports something like 7-8 different card types, too.

RE: [FormProc-developer] Getting an iteration of the form element names

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

> > I wonder: should it be possible to configure forms programtically?
> > Should you be able to add new FormElement objects to FormConfiguration?
> >  What other areas should be programitically accessible which are not?
>
> You want to be able to reload the config at time intervals for one.

Will do.  I suppose this should be a paramter in the configuration?

BTW - There is no need to respond to both me and the mailing list.  One
message directly to the mailing list is sufficient.  Unless you want to
scream at me, then we can do that person to person.  :-)

Sincerely,
Anthony Eden

RE: [FormProc-developer] New rules written

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

The reason I like passing an Element in is because 1.) it allows the class
to configure itself and 2.) the configuration information can take advantage
of the nice structures which XML provides.

As for loading goodies at runtime, I totally agree.   What do you propose as
an adapter API?

Something else I think would be good is to be able to use a custom class
loader to load validators which are not in the classpath at startup.  This
would allow you to package your validators in a JAR, drop them in a
directory and off you go - no need to set up the classpath.  I am doing this
in a couple other projects and it is very nice.

Sincerely,
Anthony Eden

> -----Original Message-----
> From: Nick Bauman [mailto:ni...@co...]
> Sent: Tuesday, November 20, 2001 12:31 AM
> To: me...@an...
> Cc: for...@li...
> Subject: RE: [FormProc-developer] New rules written
>
>
> Anthony,
>
> Sorry I reasked the question in another thread before seeing this in my
> inbox.
>
> >> Anthony,
> >>
> >> I've written a bunch of rules, but they are for my own framework. My
> >> desire
> >> is to see if we can write some kind of bridge that will allow my rules
> >> to be
> >> plugged into your framework without me having to develop in the
> >> FormProc tree. Can we agree this is a worthy goal? If not, you could
> >> always cut and paste, and I would be fine with that, but that means we
> >> miss out on long term cohesiveness and maintainability.
> >
> > As long as your rules implement the org.formproc.validation.Rule
> > interface then you should be able to use them in FormProc.  You could
> > also create a wrapper Rule which just executes your rules through some
> > interface you design.  Two things make this possible: 1.) Rule
> > implementations are specified in the XML file and 2.) you can pass any
> > XML configuration data to you rule through the configure(Element
> > element) method of the Rule interface.
>
> Ah, these 2 things is where we don't see "eye to eye". I think it's a bad
> thing to expose a DOM API call / class into any validation engine. That
> should be totally decoupled. You should either be calling
> specific methods
> (a la SAX, which emphasizes decoupling and is higher performance than DOM
> anyway) or you should be using Collections. Or am I missing something?
>
> I also think we should be able to load each other's goodies at runtime
> using cp and an adapter, otherwise I think what we will end up doing is
> adding an "XML stalagtite" into each other's xml configs for each other's
> framework.
>
> So what I'm saying is "Adopt an adapter into each framework and
> nobody gets
> hurt!" (LOL)
>
> > If this is not sufficient then tell me what you have in mind.
> >
> > Sincerely,
> > Anthony Eden
>
> I hope I didn't come off too assuming. FormProc is great!
>
> >
> > _______________________________________________
> > FormProc-developer mailing list
> > For...@li...
> > https://lists.sourceforge.net/lists/listinfo/formproc-developer
>
>
> --
> Nick Bauman
> Cortexity Development
> Intellectual Process is more important than
> Intellectual Property -- you'll see.
> http://www.cortexity.com/
>
>
>

RE: [FormProc-developer] Integradata and FormProc working together

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

> > As far as multiple validators I have checked in a class to CVS called
> > FormValidatorGroup.  I have not yet added the configuration routines,
> > but it is essentially a collection of FormValidators which must all be
> > valid for a successful validation.  The FormValidatorGroup extends from
> > AbstractFormValidator so it can be used in the same place as any other
> > FormValidator.
> >
> > I will add the configuration logic tomorrow.
>
> Before you go and code up a solution, can we see a snippet of XML of what
> the config will look like in this case so we can comment? Just a request.

<element name="x">
	<validator type="group">
		<validator type="class"
classname="org.formproc.example.UsernameValidator"/>
		<validator type="expression">
			<pattern>\w{1,}</pattern>
		</validator>
	</validator>
</element>


I will also be moving error messages into the validator level, so that:

<validator type="expression">
	<pattern></pattern>
	<error>You did something wrong.</error>
</validator>

Will become the norm.

Sincerely,
Anthony Eden

RE: [FormProc-developer] New rules written

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

Anthony,

Sorry I reasked the question in another thread before seeing this in my 
inbox.

>> Anthony,
>>
>> I've written a bunch of rules, but they are for my own framework. My
>> desire
>> is to see if we can write some kind of bridge that will allow my rules
>> to be
>> plugged into your framework without me having to develop in the
>> FormProc tree. Can we agree this is a worthy goal? If not, you could
>> always cut and paste, and I would be fine with that, but that means we
>> miss out on long term cohesiveness and maintainability.
> 
> As long as your rules implement the org.formproc.validation.Rule
> interface then you should be able to use them in FormProc.  You could
> also create a wrapper Rule which just executes your rules through some
> interface you design.  Two things make this possible: 1.) Rule
> implementations are specified in the XML file and 2.) you can pass any
> XML configuration data to you rule through the configure(Element
> element) method of the Rule interface.

Ah, these 2 things is where we don't see "eye to eye". I think it's a bad 
thing to expose a DOM API call / class into any validation engine. That 
should be totally decoupled. You should either be calling specific methods 
(a la SAX, which emphasizes decoupling and is higher performance than DOM 
anyway) or you should be using Collections. Or am I missing something?

I also think we should be able to load each other's goodies at runtime 
using cp and an adapter, otherwise I think what we will end up doing is 
adding an "XML stalagtite" into each other's xml configs for each other's 
framework.

So what I'm saying is "Adopt an adapter into each framework and nobody gets 
hurt!" (LOL)

> If this is not sufficient then tell me what you have in mind.
> 
> Sincerely,
> Anthony Eden

I hope I didn't come off too assuming. FormProc is great!
 
> 
> _______________________________________________
> FormProc-developer mailing list
> For...@li...
> https://lists.sourceforge.net/lists/listinfo/formproc-developer


-- 
Nick Bauman 
Cortexity Development
Intellectual Process is more important than
Intellectual Property -- you'll see.
http://www.cortexity.com/

RE: [FormProc-developer] Integradata and FormProc working together

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

> Right now there is a single error message for each field because there
> is a single validator.  I can see the value in allowing error messages
> for each validator though.

Can you see the value of what I proposed earlier about Integradata rules? 
What do you think?

> As far as multiple validators I have checked in a class to CVS called
> FormValidatorGroup.  I have not yet added the configuration routines,
> but it is essentially a collection of FormValidators which must all be
> valid for a successful validation.  The FormValidatorGroup extends from
> AbstractFormValidator so it can be used in the same place as any other
> FormValidator.
> 
> I will add the configuration logic tomorrow.

Before you go and code up a solution, can we see a snippet of XML of what 
the config will look like in this case so we can comment? Just a request.

> Sincerely,
> Anthony Eden
> 
>> -----Original Message-----
>> From: for...@li...
>> [mailto:for...@li...]On Behalf Of
>> Nick Bauman
>> Sent: Monday, November 19, 2001 3:32 PM
>> To: for...@li...
>> Subject: Re: [FormProc-developer] Integradata and FormProc working
>> together
>>
>>
>> > This is a suggestion for future development.  I think it would be a
>> > 'nice-to-have' feature.
>> >
>> > I was looking at Nick Bauman's API and noticed that his RuleResult
>> > class holds the error message while FormProc's getMessage method is
>> > in the FormElement.
>>
>> Correct, and I know this is a problem with Integradata. However, my
>> thinking
>> is this:
>>
>> I like that Anthony has I18N error messages "built right in", which
>> Integradata doesn't have (right now). He does this by putting the
>> error message in the XML. But since the Rule knows why, how and when
>> it's field is
>> invalid, the Rule should return a specific result code, which
>> then is mapped
>> to subsequent I18N responses, either in a properties file in the
>> distro or in the XML. The point is, you shouldn't be forced to put the
>> error message in there if you don't want to.
>>
>> Also, Integradata will soon optionally autogenerate Javascript
>> validation functions for validation _on the front end_ too, which I
>> hope
>> Anthony's lib
>> will be able to adopt as well!
>>
>> This is where Integradata is going. If we can go there together, we
>> can leverage the strengths of choice, cohesiveness of each other's
>> parts and scale the maintainability appropriately: a win-win for both
>> FormProc and Integradata.
>>
>> > It looks to me like this design prevents FormProc from being able to
>> > implement multiple rules.
>>
>> If this is true, this is definitely a problem. Integradata does not
>> have this limitation. Your illustration of a valid case for having
>> multiple rules
>> per field is right on the money.
>>
>> > For example, I think it would be useful to be able to configure a
>> > field like this:
>> >
>> > <element name="postalcode">
>> >
>> >   <!-- Rule for making the field required -->
>> >   <validator type="rule">
>> >     <rule>org.formproc.example.RequiredRule</rule>
>> >     <error lang="en">This field is required</error>
>> >   </validator>
>> >
>> >   <!-- Rule for validating a Canadian Postal Code -->
>> >   <validator type="rule">
>> >     <rule>org.formproc.example.CanPostalCodeRule</rule>
>> >     <error lang="en">This is not a valid Canadian Postal
>> >     Code</error>
>> >   </validator>
>> >
>> >   <message lang="en">Please enter a valid postal code</message>
>> >
>> > </element>
>> >
>> >
>> > The first rule would be evaluated, and if the field is blank then
>> > the user would be given the "This field is required" message.  If
>> > the field is entered, but the postal code is invalid, then the
>> > second rule is evaluated and he/she would be presented with the
>> > invalid postal code message.
>> >
>> > It also seems logical to me that the error message would be a
>> > property of the validator for a particular field.
>> >
>> > This change might make porting/merging Nick's rules easier as well.
>>
>> Yup, agreed.
>>
>> >
>> > Regards,
>> > -Kerry
>> >
>> > --
>> > Kerry Todyruik <ke...@to...>
>> >
>> > _______________________________________________
>> > FormProc-developer mailing list
>> > For...@li...
>> > https://lists.sourceforge.net/lists/listinfo/formproc-developer
>>
>>
>> --
>> Nick Bauman
>> Cortexity Development
>> Intellectual Process is more important than
>> Intellectual Property -- you'll see.
>> http://www.cortexity.com/
>>
>>
>> _______________________________________________
>> FormProc-developer mailing list
>> For...@li...
>> https://lists.sourceforge.net/lists/listinfo/formproc-developer
>>
>>
> 
> 
> _______________________________________________
> FormProc-developer mailing list
> For...@li...
> https://lists.sourceforge.net/lists/listinfo/formproc-developer


-- 
Nick Bauman 
Cortexity Development
Intellectual Process is more important than
Intellectual Property -- you'll see.
http://www.cortexity.com/