[veltools] validator Tool

[Tim Colson <tc...@cisco.com>]

> > btw. Timo did you get a chance to look at the proposals for the
> > ValidatorTool?
Sorry, was on biz travel week before last... and then all those msg's
(hah) about logging got me bogged down [almost] reading them. (I wonder
if a conference call once in a while could help the process.)

If you throw a link or three to help me understand what I should read -
I promise I'll have a look at it and give feedback.

Cheers,
Timo


---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org

Re: [veltools] validator Tool

[Nathan Bubna <na...@esha.com>]

Marino A. Jonsson said:
...
> However they do have two boolean attributes, staticJavascript and
> dynamicJavascript.  When staticJavascript is true all the _static_
> javascript methods in validator-rules.xml are rendered.  When
> dynamicJavascript is true the _dynamic_ methods (that serve as access points
> to the static methods for the validation process) are constructed from the
> relevant form info.
>
> By default both these attributes are true, which puts all the javascript in
> a single page ... however, a more sane approach would be to put the static
> methods in a seperate .js file and just render the dynamic parts with the
> form on a given page.  In order to do that you would have to manually set
> the two dynamic/static attributes before calling the getJavascript method in
> each case - setStaticJavascript(true/false) and
> setDynamicJavascript(true/false).
>
> I cleaned it up a bit and made the interface more intuitive (I hope) ... now
> there are basically five public methods (apart from the getters/setters):
>
> getJavaScript()
> getJavaScript(String formName)
>
> getDynamicJavascript()
> getDynamicJavascript(String formName)
>
> getStaticJavascript()
>
>
> The getDynamicJavascript and getStaticJavascript methods are useful if the
> static methods should be seperate from the dynamic code, i.e. in a seperate
> .js file.
>
> getJavascript renders the dynamic parts as well as all the static methods in
> one big pile.
>
> thoughts?

makes good sense to me.  :)

Nathan Bubna
nathan@esha.com


---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org

RE: [veltools] validator Tool

[Tim Colson <tc...@cisco.com>]

> It was only a single post, 
I obviously missed it, sorry about that.

> so I threw out the respective get/set methods.
Seems cool.

> a more sane approach would be to 
As I recall, there were a few things that could be improved and made
more sane, but the new method calls you've added sound like a great
start to me!

I've got a simple little app I'm working on now with 1.1 - so I'll have
a look at the Validator stuff directly.

Cheers,
Timo



---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org

Re: [veltools] validator Tool

["Marino A. Jonsson" <ma...@hotmail.com>]

It was only a single post, and I've already committed the changes, but I'd
like feedback from you and Nathan (others are welcome to comment too :-) ).
Here are the most relevant parts:

As the ValidatorTool is based on the ValidatorJavascriptTag it has a lot of
optional attributes that translate to a lot of public getter/setter methods
in the corresponding Velocity tool (eight to be exact).  The majority of the
attributes are rarely used and so it doesn't really bug me that one would
have to set the attribute in a seperate call to change it.  One of the
attributes is really redundant (formName) since it's either determined
dynamically or supplied as a parameter to the getJavascript() method, so I
threw out the respective get/set methods.

However they do have two boolean attributes, staticJavascript and
dynamicJavascript.  When staticJavascript is true all the _static_
javascript methods in validator-rules.xml are rendered.  When
dynamicJavascript is true the _dynamic_ methods (that serve as access points
to the static methods for the validation process) are constructed from the
relevant form info.

By default both these attributes are true, which puts all the javascript in
a single page ... however, a more sane approach would be to put the static
methods in a seperate .js file and just render the dynamic parts with the
form on a given page.  In order to do that you would have to manually set
the two dynamic/static attributes before calling the getJavascript method in
each case - setStaticJavascript(true/false) and
setDynamicJavascript(true/false).

I cleaned it up a bit and made the interface more intuitive (I hope) ... now
there are basically five public methods (apart from the getters/setters):

getJavaScript()
getJavaScript(String formName)

getDynamicJavascript()
getDynamicJavascript(String formName)

getStaticJavascript()


The getDynamicJavascript and getStaticJavascript methods are useful if the
static methods should be seperate from the dynamic code, i.e. in a seperate
.js file.

getJavascript renders the dynamic parts as well as all the static methods in
one big pile.

thoughts?

cheers,
Marin�

"Tim Colson" <tc...@cisco.com> wrote in message
news:000201c3f1d1$b8f5c800$0a18190a@amer.cisco.com...
> > > btw. Timo did you get a chance to look at the proposals for the
> > > ValidatorTool?
> Sorry, was on biz travel week before last... and then all those msg's
> (hah) about logging got me bogged down [almost] reading them. (I wonder
> if a conference call once in a while could help the process.)
>
> If you throw a link or three to help me understand what I should read -
> I promise I'll have a look at it and give feedback.
>
> Cheers,
> Timo




---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org