You are viewing a plain text version of this content. The canonical link for it is here.
Posted to adffaces-dev@incubator.apache.org by Danny Robinson <da...@gmail.com> on 2007/04/20 13:46:00 UTC

Re: Client-side validation - enhance to match server-side

Does anyone have any feedback on this patch?  I don't expect it is perfect
or complete, but I'd like to understand if this is the approach you'd expect
for implementing this feature.

https://issues.apache.org/jira/browse/ADFFACES-391

On 3/16/07, Danny Robinson <da...@gmail.com> wrote:
>
> OK, I've posted an initial patch so client-side validation matches
> server-side here: https://issues.apache.org/jira/browse/ADFFACES-391
>
> Feedback gratefully received.
>
> Description:
>
> Attached patch file will provide an alternative client-side validation
> mode where message layout and appearance exactly follows the server-side
> mode. It renders hidden (skinned) elements that are dynamically populated
> with error text and displayed if c/s validation fails for a given component.
> The 'X' icon is also dynamically displayed. This works for input fields
> rendered inside or outside of panelForm.
>
> It contains certain changes to FormRenderer so that is will render a
> different validation method depending on the setting below. _multiValidate
> method was modified so it returns a 2d array of id, message which is then
> processed by either _validateAlert() or _validateInline. FormRenderer now
> uses the return value of the above methods to determine if submit can occur.
>
>
> Outstanding features:
> * Public js method that can be added to onblur (eg.
> onblur="validateField(this);") to enable immediate validation of fields.
> * Test with fields in tables
>
> I guess this setting would be more at home in trinidad-config.xml though.
> <context-param>
> <param-name>
> org.apache.myfaces.trinidadinternal.renderkit.INLINE_JS_VALIDATION
> </param-name>
> <param-value>true</param-value>
> </context-param>
>   [ Show » <https://issues.apache.org/jira/browse/ADFFACES-391> ]
>  Danny Robinson<https://issues.apache.org/jira/secure/ViewProfile.jspa?name=dannyjrobinson>
> [16/Mar/07 08:59 AM] Attached patch file will provide an alternative
> client-side validation mode where message layout and appearance exactly
> follows the server-side mode. It renders hidden (skinned) elements that are
> dynamically populated with error text and displayed if c/s validation fails
> for a given component. The 'X' icon is also dynamically displayed. This
> works for input fields rendered inside or outside of panelForm. It contains
> certain changes to FormRenderer so that is will render a different
> validation method depending on the setting below. _multiValidate method was
> modified so it returns a 2d array of id, message which is then processed by
> either _validateAlert() or _validateInline. FormRenderer now uses the return
> value of the above methods to determine if submit can occur. Outstanding
> features: * Public js method that can be added to onblur (eg.
> onblur="validateField(this);") to enable immediate validation of fields. *
> Test with fields in tables I guess this setting would be more at home in
> trinidad-config.xml though. <context-param> <param-name>
> org.apache.myfaces.trinidadinternal.renderkit.INLINE_JS_VALIDATION</param-name> <param-value>true</param-value> </context-param>
>
>
>
> On 3/1/07, Adam Winer <awiner@gmail.com > wrote:
> >
> > Trinidad already has essentially the same functionality - input
> > components
> > can be marked as autoSubmit, at which point tabbing out will
> > automatically
> > trigger a server-side submit, and error messages will be automatically
> > inserted into tr:messages, if present.  (There's an existing bug where
> > the inline messages don't show up).
> >
> > -- Adam
> >
> >
> > On 3/1/07, Peter Muir < pmuir@bleepbleep.org.uk > wrote:
> > >
> > > On 28/02/07, Danny Robinson <da...@gmail.com> wrote:
> > > > Would there be support for an enhancement to the client-side
> > validation
> > > so
> > > > that it behaves in the same way as the server-side logic?  Meaning,
> > we'd
> > > get
> > > > rid of the javascript alert dialog and instead dyanamically
> > show/hide
> > > the
> > > > error messages in the page.
> > >
> > > You should look at the way this is done in A4J - the server side
> > > validators are used: the onblur of the input causes it's value to be
> > > sent, and then rendering any error messages (in the normal places),
> > > again using ajax.  Very neat IMO.
> > >
> > > Pete
> > >
> >
>
>
>
> --
> Chordiant Software Inc.
> www.chordiant.com
>



-- 
Chordiant Software Inc.
www.chordiant.com

Re: Client-side validation - enhance to match server-side

Posted by Adam Winer <aw...@gmail.com>.
Sorry - I've been wanting to have a look at it, but been
generally swamped.  Hopefully soon...

-- Adam


On 4/20/07, Danny Robinson <da...@gmail.com> wrote:
> Does anyone have any feedback on this patch?  I don't expect it is perfect
> or complete, but I'd like to understand if this is the approach you'd expect
> for implementing this feature.
>
> https://issues.apache.org/jira/browse/ADFFACES-391
>
> On 3/16/07, Danny Robinson <da...@gmail.com> wrote:
> >
> > OK, I've posted an initial patch so client-side validation matches
> > server-side here: https://issues.apache.org/jira/browse/ADFFACES-391
> >
> > Feedback gratefully received.
> >
> > Description:
> >
> > Attached patch file will provide an alternative client-side validation
> > mode where message layout and appearance exactly follows the server-side
> > mode. It renders hidden (skinned) elements that are dynamically populated
> > with error text and displayed if c/s validation fails for a given component.
> > The 'X' icon is also dynamically displayed. This works for input fields
> > rendered inside or outside of panelForm.
> >
> > It contains certain changes to FormRenderer so that is will render a
> > different validation method depending on the setting below. _multiValidate
> > method was modified so it returns a 2d array of id, message which is then
> > processed by either _validateAlert() or _validateInline. FormRenderer now
> > uses the return value of the above methods to determine if submit can occur.
> >
> >
> > Outstanding features:
> > * Public js method that can be added to onblur (eg.
> > onblur="validateField(this);") to enable immediate validation of fields.
> > * Test with fields in tables
> >
> > I guess this setting would be more at home in trinidad-config.xml though.
> > <context-param>
> > <param-name>
> > org.apache.myfaces.trinidadinternal.renderkit.INLINE_JS_VALIDATION
> > </param-name>
> > <param-value>true</param-value>
> > </context-param>
> >   [ Show » <https://issues.apache.org/jira/browse/ADFFACES-391> ]
> >  Danny Robinson<https://issues.apache.org/jira/secure/ViewProfile.jspa?name=dannyjrobinson>
> > [16/Mar/07 08:59 AM] Attached patch file will provide an alternative
> > client-side validation mode where message layout and appearance exactly
> > follows the server-side mode. It renders hidden (skinned) elements that are
> > dynamically populated with error text and displayed if c/s validation fails
> > for a given component. The 'X' icon is also dynamically displayed. This
> > works for input fields rendered inside or outside of panelForm. It contains
> > certain changes to FormRenderer so that is will render a different
> > validation method depending on the setting below. _multiValidate method was
> > modified so it returns a 2d array of id, message which is then processed by
> > either _validateAlert() or _validateInline. FormRenderer now uses the return
> > value of the above methods to determine if submit can occur. Outstanding
> > features: * Public js method that can be added to onblur (eg.
> > onblur="validateField(this);") to enable immediate validation of fields. *
> > Test with fields in tables I guess this setting would be more at home in
> > trinidad-config.xml though. <context-param> <param-name>
> > org.apache.myfaces.trinidadinternal.renderkit.INLINE_JS_VALIDATION</param-name> <param-value>true</param-value> </context-param>
> >
> >
> >
> > On 3/1/07, Adam Winer <awiner@gmail.com > wrote:
> > >
> > > Trinidad already has essentially the same functionality - input
> > > components
> > > can be marked as autoSubmit, at which point tabbing out will
> > > automatically
> > > trigger a server-side submit, and error messages will be automatically
> > > inserted into tr:messages, if present.  (There's an existing bug where
> > > the inline messages don't show up).
> > >
> > > -- Adam
> > >
> > >
> > > On 3/1/07, Peter Muir < pmuir@bleepbleep.org.uk > wrote:
> > > >
> > > > On 28/02/07, Danny Robinson <da...@gmail.com> wrote:
> > > > > Would there be support for an enhancement to the client-side
> > > validation
> > > > so
> > > > > that it behaves in the same way as the server-side logic?  Meaning,
> > > we'd
> > > > get
> > > > > rid of the javascript alert dialog and instead dyanamically
> > > show/hide
> > > > the
> > > > > error messages in the page.
> > > >
> > > > You should look at the way this is done in A4J - the server side
> > > > validators are used: the onblur of the input causes it's value to be
> > > > sent, and then rendering any error messages (in the normal places),
> > > > again using ajax.  Very neat IMO.
> > > >
> > > > Pete
> > > >
> > >
> >
> >
> >
> > --
> > Chordiant Software Inc.
> > www.chordiant.com
> >
>
>
>
> --
> Chordiant Software Inc.
> www.chordiant.com
>