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/