You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by "Marinó A. Jónsson" <ma...@centrum.is> on 2004/01/31 02:36:03 UTC

possible improvements to the ValidatorTool ...

Hey guys,

As you've probably noticed I've been putting some xdocs in order for the
release, and it struck me when I was turning to the ValidatorTool that the
interface to the tool is horrible! :)

As it 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, that one would think would be mutually exclusive, but
both are true by default!  When staticJavascript is true all the static
javascript methods in validator-rules.xml are rendered.  When
dynamicJavascript is true only the static javascript methods that apply to
the current form are rendered, and a single "entry-method" is constructed to
be called from the html-form.  So the four scenarios are:


1. when both attributes are true we get the entry-method and all the static
methods. 

2. when both attributes are false we get nothing 

3. when staticJavascript is true and dynamicJavascript is false we only get
the static javascript methods from the validator-rules.xml (no
entry-method).  These can then be put in separate page so the browser can
cache the static JavaScript. 

4. when dynamicJavascript is true and staticJavascript is false we get the
entry-method and only the static javascript methods needed for validating
the current form.


Somehow I think the most common scenario is #4 - which means, under current
circumstances the following two lines are needed to render the javascript
within a velocity template:

$velocity.setStaticJavascript(false)
$velocity.getJavascript()


IMO there are a few, more feasible, solutions:

1. Just changing the default for staticJavascript from true to false and let
all else be. 

2. Add a parameter to the getJavascript() methods, perhaps a String that can
take the values "all", "static", and "dynamic" that correspond to scenarios
#1, #3, and #4 respectively. 

3. Add a couple of utility methods, i.e. getStaticJavascript() that
corresponds to scenario #3, and getDynamicJavascript() that corresponds to
scenario #4 (with the original getJavascript() still corresponding to
scenario #1). 

4. Making static vs. dynamic mutually exclusive, dropping one of the
attributes.  This would entail either adding an optional boolean parameter
to the getJavascript() methods, or changing getJavascript to
getDynamicJavascript() and adding getStaticJavascript().  However it would
no longer be possible to render both entry-method and all static methods at
once.


I'm inclined to go for #4, but with reservations because of the (rather
trivial) limitations.

thoughts?

cheers,
Marinó 



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