Improving validation and form components in 3.1

[Paul Ferraro <pm...@columbia.edu>]

Here are my latest thoughts on some improvements to validation and form 
components.  Please respond with any thoughts, comments, additions, 
subtractions, suggestions, etc...

Validation improvements
* Move validation decoration out of IValidationDelegate and into new 
FieldDecorator and LabelDecorator components.
  - These components will decorate and individual field labels or form 
element if its corresponding field is in error.
  - FieldLabel will wrap its body with a LabelDecorator component.
  - Each form element component wraps it's body with a FieldDecorator 
component.
  - To customize decoration logic, instead of creating a custom 
IValidationDelegate, a user overrides the decorators.
* Move error message render logic out of IValidationDelegate and into 
new ValidationErrors component.
  - Default implementation will display all validation errors - not just 
the first one.
  - A user can customize the display logic by wrapping the 
ValidationError component or by overriding it.
* Rather than define an IValidationDelegate via the 'delegate' parameter 
in each Form, use HiveMind to define its implementation.
  - No need to define IValidationDelegate helper bean in every page with 
a form
  - 'delegate' parameter can be removed from Form component.
  - Since IValidationDelegate is no longer responsible for rendering 
anything, it will rarely need to be overridden.
* Every IFormComponent will possess an optional IValidator (or a 
list/array of IValidators?) parameter.
  - ValidField can be deprecated in favor of validatable TextField.
  - Is it time yet to deprecate contrib:DateField, contrib:NumericField, 
contrib:ValidatingTextField?
* FieldLabel component will generate <label> tags.
* Create new java.text.Format-based IValidator implementations.

Form-related component improvements
* Add support for enabling HTTPS in form actions.
  - One possible implementatin is to create a IFormRenderer interface 
(analogous to ILinkRenderer for link components) to allow configurable 
rendering of Form component.
  - Create DefaultFormRenderer and AbsoluteFormRender (analogous to 
AbsoluteLinkRenderer) to render full urls (i.e. scheme + port + uri) in 
the form action.
* Add ability for PropertySelection to optionally include a label row.
  - e.g.
    <select>
      <option value="">Select a state</option>
        <option value="AL">Alabama</option>
        <option value="AK">Alaska</option>
        <!-- etc. -->
    </select>
  - The label, value (defaults to ""), and bound property value 
(defaults to null) will all be configurable.
  - The optional label row is transparent to the underlying 
IPropertySelectionModel.
* Create abstract IPropertySelectionModel for use with collections of 
domain objects.
* Add support for <optgroup> elements within <select>.  I haven't 
thought this one through yet.
* Add "element" parameter to RadioGroup group component.
  - This can eliminate the need to use superfluous <span> tags in HTML 
templates that may make for invalid XHTML.
* Upgrade Submit and Button components to render using <button> tags.  
This has several advantages/consequences:
  - Adds more flexibity for button labels.
  - ImageSubmit can be deprecated.  It is equivalent to using a Submit 
button with a nested Image component.
  - It will then be possible to nest a Submit component with a Rollover 
component to gain rollover behavior for image submit buttons.
  - One implementation option is to create an IButtonRenderer 
interface.  This would also enable the implementation of a 
LinkButtonRenderer that would allow the LinkSubmit component to be 
deprecated.
  - How does this affect existing CSS?
* Create ButtonLinkRenderer, an implementation of ILinkRenderer.  This 
creates a <button type="button" onclick="...">...</button>
  - If link defines a target, then onclick uses 'window.open(url, 
target)', otherwise, onclick simply modifies 'window.location=url'.
  - Very useful for implementing Cancel buttons.
    e.g.
    <button jwcid="@DirectLink" listener="ognl:listeners:cancel" 
renderer="ognl:new 
org.apache.tapestry.link.ButtonLinkRenderer()">Cancel</button>
* contrib:MultiplePropertySelection updates
  - Update renderComponent() so that during the rewind cycle it uses the 
mutator method of the bound list (i.e. setXXX) rather than clearing the 
list and adding to it (i.e. getXXX().clear(), getXXX().add(...)).  This 
keeps it consistent with the rewind behavior of every other form component.
  - Create SelectMultiplePropertySelectionRenderer implementation that 
generates <select multiple="multiple"></select>.
* Shell component parameter updates
  - Modify "stylesheets" parameter to handle Iterator, Collection, 
Asset[], or Asset (analogous to source property of Foreach component).
  - Remove superfluous "stylesheet" parameter.
  - Add optional "scripts" parameter (Iterator, Collection, Asset[], or 
Asset) that one can reference static js files in <head>.

Paul

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

Re: Improving validation and form components in 3.1

[Richard Lewis-Shell <rl...@mac.com>]

>> * Every IFormComponent will possess an optional IValidator (or a 
>> list/array of IValidators?) parameter.
>>  - ValidField can be deprecated in favor of validatable TextField.
>>  - Is it time yet to deprecate contrib:DateField, 
>> contrib:NumericField, contrib:ValidatingTextField?
> 
> 
> I would be happy to have only a single text field component, that can be 
> bound to any type, such that conversions happen automatically (and 
> customizable) and that validations can occur on.  All form components 
> should be capable of hooking into validation.
> 
> So, I'm in favor of deprecating all of these other text field components 
> in favor of unifying them.

ditto - the contrib field components existed as a migration path to 
ValidField, but then gained a longer life due to being easier to use 
than ValidField.  If the new validation component(s) are as easy to use 
(or easier?), then they really are not needed any more.

>> * Add ability for PropertySelection to optionally include a label row.
>>  - e.g.
>>    <select>
>>      <option value="">Select a state</option>
>>        <option value="AL">Alabama</option>
>>        <option value="AK">Alaska</option>
>>        <!-- etc. -->
>>    </select>
>>  - The label, value (defaults to ""), and bound property value 
>> (defaults to null) will all be configurable.
>>  - The optional label row is transparent to the underlying 
>> IPropertySelectionModel.
> 
> 
> That would be great!   I've always hacked the label row into a custom 
> model.

ditto again, but doing it this way allows a label to appear multiple 
times throughout the model, which is useful for grouping values.  Maybe 
the <optgroup> idea can help.

>> * Create abstract IPropertySelectionModel for use with collections of 
>> domain objects.
> 
> 
> At Darden, we created a relatively generic model that worked well with 
> any domain objects using reflection, such that the label and value 
> properties were specified when creating the model.  Unfortunately, I 
> think that model has evolved more complexity than would be worth 
> contributing directly.  And I suspect OGNL should be used to handle 
> expressions to label and value properties rather than just basic 
> reflection.

we have such an OGNL based IPropertySelectionModel implementation (with 
the label row hack mentioned above) which has been pretty useful.  I 
could donate it back.  I think it only uses OGNL for the labels though, 
using an int (array index) for the value.

>> * Shell component parameter updates
>>  - Modify "stylesheets" parameter to handle Iterator, Collection, 
>> Asset[], or Asset (analogous to source property of Foreach component).
>>  - Remove superfluous "stylesheet" parameter.
>>  - Add optional "scripts" parameter (Iterator, Collection, Asset[], or 
>> Asset) that one can reference static js files in <head>.
> 
> 
> The stylesheets parameter should also be modified to easily allow media 
> specification for each sheet too - this is becoming a common practice of 
> having screen and print stylesheets, and the only way to accomplish this 
> with @Shell now is to create an IRender delegate to plug in.  Perhaps 
> stylesheets could take a Map also:
> 
>     stylesheets="ognl:#{'print' : stylesheet1, 'screen' : stylesheet2}"
> 
> I haven't thought through this yet - I just came up with this example on 
> the fly, so it should definitely be ironed out.
> 
> Also, since we're on @Shell - we should add a switch, or remove 
> altogether, the HTML comments that it generates since this has become a 
> sticky issue recently.  One can always add a servlet filter to add a 
> timing comment for a render if desired.

+1 to removing it in favour of a (framework supplied) filter.

Richard

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

Re: Improving validation and form components in 3.1

[Erik Hatcher <er...@ehatchersolutions.com>]

My replies inline below....

On Jan 17, 2005, at 7:22 PM, Paul Ferraro wrote:

> Validation improvements
> * Rather than define an IValidationDelegate via the 'delegate' 
> parameter in each Form, use HiveMind to define its implementation.
>  - No need to define IValidationDelegate helper bean in every page 
> with a form
>  - 'delegate' parameter can be removed from Form component.
>  - Since IValidationDelegate is no longer responsible for rendering 
> anything, it will rarely need to be overridden.

Big +1!

> * Every IFormComponent will possess an optional IValidator (or a 
> list/array of IValidators?) parameter.
>  - ValidField can be deprecated in favor of validatable TextField.
>  - Is it time yet to deprecate contrib:DateField, 
> contrib:NumericField, contrib:ValidatingTextField?

I would be happy to have only a single text field component, that can 
be bound to any type, such that conversions happen automatically (and 
customizable) and that validations can occur on.  All form components 
should be capable of hooking into validation.

So, I'm in favor of deprecating all of these other text field 
components in favor of unifying them.

> * Add ability for PropertySelection to optionally include a label row.
>  - e.g.
>    <select>
>      <option value="">Select a state</option>
>        <option value="AL">Alabama</option>
>        <option value="AK">Alaska</option>
>        <!-- etc. -->
>    </select>
>  - The label, value (defaults to ""), and bound property value 
> (defaults to null) will all be configurable.
>  - The optional label row is transparent to the underlying 
> IPropertySelectionModel.

That would be great!   I've always hacked the label row into a custom 
model.

> * Create abstract IPropertySelectionModel for use with collections of 
> domain objects.

At Darden, we created a relatively generic model that worked well with 
any domain objects using reflection, such that the label and value 
properties were specified when creating the model.  Unfortunately, I 
think that model has evolved more complexity than would be worth 
contributing directly.  And I suspect OGNL should be used to handle 
expressions to label and value properties rather than just basic 
reflection.

> * Shell component parameter updates
>  - Modify "stylesheets" parameter to handle Iterator, Collection, 
> Asset[], or Asset (analogous to source property of Foreach component).
>  - Remove superfluous "stylesheet" parameter.
>  - Add optional "scripts" parameter (Iterator, Collection, Asset[], or 
> Asset) that one can reference static js files in <head>.

The stylesheets parameter should also be modified to easily allow media 
specification for each sheet too - this is becoming a common practice 
of having screen and print stylesheets, and the only way to accomplish 
this with @Shell now is to create an IRender delegate to plug in.  
Perhaps stylesheets could take a Map also:

	stylesheets="ognl:#{'print' : stylesheet1, 'screen' : stylesheet2}"

I haven't thought through this yet - I just came up with this example 
on the fly, so it should definitely be ironed out.

Also, since we're on @Shell - we should add a switch, or remove 
altogether, the HTML comments that it generates since this has become a 
sticky issue recently.  One can always add a servlet filter to add a 
timing comment for a render if desired.

	Erik


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