Sorry - I've been wanting to have a look at it, but been
generally swamped.  Hopefully soon...

-- Adam


On 4/20/07, Danny Robinson <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED] > 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 < [EMAIL PROTECTED] > wrote:
> > >
> > > On 28/02/07, Danny Robinson <[EMAIL PROTECTED]> 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

Reply via email to