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/02/28 17:35:14 UTC
Client-side validation - enhance to match server-side
Guys,
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.
If so, I'll raise a JIRA issue and look into possible solutions. Tips &
suggestions welcome.
Danny
--
Chordiant Software Inc.
www.chordiant.com
Re: Client-side validation - enhance to match server-side
Posted by Matthias Wessendorf <ma...@apache.org>.
well,
there is already convertion/validation done on the client.
I am not really interested in adding GWT dependency to Trinidad.
-M
On 2/28/07, Arash Rajaeeyan <ar...@gmail.com> wrote:
> may be you can use GWT compiler for client side validation as well, it is
> also under Apache 2 license.
>
> On 2/28/07, Danny Robinson <da...@gmail.com> wrote:
> >
> > Guys,
> >
> > 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.
> >
> > If so, I'll raise a JIRA issue and look into possible solutions. Tips &
> > suggestions welcome.
> >
> > Danny
> >
> > --
> > Chordiant Software Inc.
> > www.chordiant.com
> >
>
>
>
> --
> Arash Rajaeeyan
>
--
Matthias Wessendorf
http://tinyurl.com/fmywh
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: Client-side validation - enhance to match server-side
Posted by Arash Rajaeeyan <ar...@gmail.com>.
may be you can use GWT compiler for client side validation as well, it is
also under Apache 2 license.
On 2/28/07, Danny Robinson <da...@gmail.com> wrote:
>
> Guys,
>
> 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.
>
> If so, I'll raise a JIRA issue and look into possible solutions. Tips &
> suggestions welcome.
>
> Danny
>
> --
> Chordiant Software Inc.
> www.chordiant.com
>
--
Arash Rajaeeyan
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
>
Re: Client-side validation - enhance to match server-side
Posted by Danny Robinson <da...@gmail.com>.
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 Danny Robinson <da...@gmail.com>.
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 <aw...@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
Re: Client-side validation - enhance to match server-side
Posted by Adam Winer <aw...@gmail.com>.
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 <pm...@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
>
Re: Client-side validation - enhance to match server-side
Posted by Peter Muir <pm...@bleepbleep.org.uk>.
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
Re: Client-side validation - enhance to match server-side
Posted by Martin Marinschek <ma...@gmail.com>.
I don't need the alerts - but there might be people who want it. From
me a 0- on this.
regards,
Martin
On 3/1/07, Danny Robinson <da...@gmail.com> wrote:
> Great, so it seems like everyone's in favour. I'll raise an issue.
>
> Would people want to keep the alert() mechanism also, so both client-side
> options were possible?
> -1 (danny)
>
> Additionally display messages where tr:messages
> +1 (danny)
>
> D.
>
> On 2/28/07, Adam Winer <aw...@gmail.com> wrote:
> >
> > I'd be happy to see functionality like this too. The trickiest part
> > is, I think, figuring out how to clear the messages.
> >
> > I agree with Matthias that we don't need GWT. We already
> > have the client-side JS. It's just the code that decides to
> > turn the messages into an alert that is the problem.
> >
> > -- Adam
> >
> >
> > On 2/28/07, Martin Marinschek <ma...@gmail.com> wrote:
> > > I've been reiterating the necessity for this time and again ;) - I'd
> > > be pretty much for an addition like this.
> > >
> > > regards,
> > >
> > > Martin
> > >
> > > On 2/28/07, Danny Robinson <da...@gmail.com> wrote:
> > > > I was thinking that instead of displaying alert, the messages would
> > appear
> > > > in the same place as they do in server-side. So keep the existing
> > > > javascript validator/converter stuff but change where/how it is
> > displayed.
> > > > We'd probably have to render a hidden container for each field, which
> > the
> > > > javascript would populate and make visible.
> > > >
> > > > Taking this route over a dialog means we could also probably provide
> > some
> > > > kind of on-tab-out instant validation for more data-entry heavy
> > > > applications. That said these approaches are not mutually exclusive.
> > > >
> > > > Danny
> > > >
> > > > On 2/28/07, Matthias Wessendorf <ma...@apache.org> wrote:
> > > > >
> > > > > are you talking about still using JS for the client side
> > > > > converter/validator stuff,
> > > > > but just don't use alert(), instead using a "web2.0-ish" dialog ?
> > > > >
> > > > > The validator/converter stuff isn't just an alert(). We have "client
> > > > > side" Converter (with getAsObject/String) and Validators (with
> > > > > validate) and FacesMessage etc.
> > > > >
> > > > > Here is more on that interesting topic:
> > > > >
> > > > > http://incubator.apache.org/adffaces/devguide/clientValidation.html
> > > > >
> > > > > -Matthias
> > > > >
> > > > > On 2/28/07, Danny Robinson <da...@gmail.com> wrote:
> > > > > > Guys,
> > > > > >
> > > > > > 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.
> > > > > >
> > > > > > If so, I'll raise a JIRA issue and look into possible
> > solutions. Tips &
> > > > > > suggestions welcome.
> > > > > >
> > > > > > Danny
> > > > > >
> > > > > > --
> > > > > > Chordiant Software Inc.
> > > > > > www.chordiant.com
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Matthias Wessendorf
> > > > > http://tinyurl.com/fmywh
> > > > >
> > > > > further stuff:
> > > > > blog: http://jroller.com/page/mwessendorf
> > > > > mail: mwessendorf-at-gmail-dot-com
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Chordiant Software Inc.
> > > > www.chordiant.com
> > > >
> > >
> > >
> > > --
> > >
> > > http://www.irian.at
> > >
> > > Your JSF powerhouse -
> > > JSF Consulting, Development and
> > > Courses in English and German
> > >
> > > Professional Support for Apache MyFaces
> > >
> >
>
>
>
> --
> Chordiant Software Inc.
> www.chordiant.com
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: Client-side validation - enhance to match server-side
Posted by Danny Robinson <da...@gmail.com>.
Great, so it seems like everyone's in favour. I'll raise an issue.
Would people want to keep the alert() mechanism also, so both client-side
options were possible?
-1 (danny)
Additionally display messages where tr:messages
+1 (danny)
D.
On 2/28/07, Adam Winer <aw...@gmail.com> wrote:
>
> I'd be happy to see functionality like this too. The trickiest part
> is, I think, figuring out how to clear the messages.
>
> I agree with Matthias that we don't need GWT. We already
> have the client-side JS. It's just the code that decides to
> turn the messages into an alert that is the problem.
>
> -- Adam
>
>
> On 2/28/07, Martin Marinschek <ma...@gmail.com> wrote:
> > I've been reiterating the necessity for this time and again ;) - I'd
> > be pretty much for an addition like this.
> >
> > regards,
> >
> > Martin
> >
> > On 2/28/07, Danny Robinson <da...@gmail.com> wrote:
> > > I was thinking that instead of displaying alert, the messages would
> appear
> > > in the same place as they do in server-side. So keep the existing
> > > javascript validator/converter stuff but change where/how it is
> displayed.
> > > We'd probably have to render a hidden container for each field, which
> the
> > > javascript would populate and make visible.
> > >
> > > Taking this route over a dialog means we could also probably provide
> some
> > > kind of on-tab-out instant validation for more data-entry heavy
> > > applications. That said these approaches are not mutually exclusive.
> > >
> > > Danny
> > >
> > > On 2/28/07, Matthias Wessendorf <ma...@apache.org> wrote:
> > > >
> > > > are you talking about still using JS for the client side
> > > > converter/validator stuff,
> > > > but just don't use alert(), instead using a "web2.0-ish" dialog ?
> > > >
> > > > The validator/converter stuff isn't just an alert(). We have "client
> > > > side" Converter (with getAsObject/String) and Validators (with
> > > > validate) and FacesMessage etc.
> > > >
> > > > Here is more on that interesting topic:
> > > >
> > > > http://incubator.apache.org/adffaces/devguide/clientValidation.html
> > > >
> > > > -Matthias
> > > >
> > > > On 2/28/07, Danny Robinson <da...@gmail.com> wrote:
> > > > > Guys,
> > > > >
> > > > > 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.
> > > > >
> > > > > If so, I'll raise a JIRA issue and look into possible
> solutions. Tips &
> > > > > suggestions welcome.
> > > > >
> > > > > Danny
> > > > >
> > > > > --
> > > > > Chordiant Software Inc.
> > > > > www.chordiant.com
> > > > >
> > > >
> > > >
> > > > --
> > > > Matthias Wessendorf
> > > > http://tinyurl.com/fmywh
> > > >
> > > > further stuff:
> > > > blog: http://jroller.com/page/mwessendorf
> > > > mail: mwessendorf-at-gmail-dot-com
> > > >
> > >
> > >
> > >
> > > --
> > > Chordiant Software Inc.
> > > www.chordiant.com
> > >
> >
> >
> > --
> >
> > http://www.irian.at
> >
> > Your JSF powerhouse -
> > JSF Consulting, Development and
> > Courses in English and German
> >
> > Professional Support for Apache MyFaces
> >
>
--
Chordiant Software Inc.
www.chordiant.com
Re: Client-side validation - enhance to match server-side
Posted by Arash Rajaeeyan <ar...@gmail.com>.
the difference is with GWT, user can write java code for client side
validation instead of JS.
they can compile it with their own Java IDE.
but I also agree that adding another dependency to MyFaces is not good,
specially dependency to such a big project.
On 3/1/07, Adam Winer <aw...@gmail.com> wrote:
>
> I'd be happy to see functionality like this too. The trickiest part
> is, I think, figuring out how to clear the messages.
>
> I agree with Matthias that we don't need GWT. We already
> have the client-side JS. It's just the code that decides to
> turn the messages into an alert that is the problem.
>
> -- Adam
>
>
> On 2/28/07, Martin Marinschek <ma...@gmail.com> wrote:
> > I've been reiterating the necessity for this time and again ;) - I'd
> > be pretty much for an addition like this.
> >
> > regards,
> >
> > Martin
> >
> > On 2/28/07, Danny Robinson <da...@gmail.com> wrote:
> > > I was thinking that instead of displaying alert, the messages would
> appear
> > > in the same place as they do in server-side. So keep the existing
> > > javascript validator/converter stuff but change where/how it is
> displayed.
> > > We'd probably have to render a hidden container for each field, which
> the
> > > javascript would populate and make visible.
> > >
> > > Taking this route over a dialog means we could also probably provide
> some
> > > kind of on-tab-out instant validation for more data-entry heavy
> > > applications. That said these approaches are not mutually exclusive.
> > >
> > > Danny
> > >
> > > On 2/28/07, Matthias Wessendorf <ma...@apache.org> wrote:
> > > >
> > > > are you talking about still using JS for the client side
> > > > converter/validator stuff,
> > > > but just don't use alert(), instead using a "web2.0-ish" dialog ?
> > > >
> > > > The validator/converter stuff isn't just an alert(). We have "client
> > > > side" Converter (with getAsObject/String) and Validators (with
> > > > validate) and FacesMessage etc.
> > > >
> > > > Here is more on that interesting topic:
> > > >
> > > > http://incubator.apache.org/adffaces/devguide/clientValidation.html
> > > >
> > > > -Matthias
> > > >
> > > > On 2/28/07, Danny Robinson <da...@gmail.com> wrote:
> > > > > Guys,
> > > > >
> > > > > 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.
> > > > >
> > > > > If so, I'll raise a JIRA issue and look into possible
> solutions. Tips &
> > > > > suggestions welcome.
> > > > >
> > > > > Danny
> > > > >
> > > > > --
> > > > > Chordiant Software Inc.
> > > > > www.chordiant.com
> > > > >
> > > >
> > > >
> > > > --
> > > > Matthias Wessendorf
> > > > http://tinyurl.com/fmywh
> > > >
> > > > further stuff:
> > > > blog: http://jroller.com/page/mwessendorf
> > > > mail: mwessendorf-at-gmail-dot-com
> > > >
> > >
> > >
> > >
> > > --
> > > Chordiant Software Inc.
> > > www.chordiant.com
> > >
> >
> >
> > --
> >
> > http://www.irian.at
> >
> > Your JSF powerhouse -
> > JSF Consulting, Development and
> > Courses in English and German
> >
> > Professional Support for Apache MyFaces
> >
>
--
Arash Rajaeeyan
Re: Client-side validation - enhance to match server-side
Posted by Adam Winer <aw...@gmail.com>.
I'd be happy to see functionality like this too. The trickiest part
is, I think, figuring out how to clear the messages.
I agree with Matthias that we don't need GWT. We already
have the client-side JS. It's just the code that decides to
turn the messages into an alert that is the problem.
-- Adam
On 2/28/07, Martin Marinschek <ma...@gmail.com> wrote:
> I've been reiterating the necessity for this time and again ;) - I'd
> be pretty much for an addition like this.
>
> regards,
>
> Martin
>
> On 2/28/07, Danny Robinson <da...@gmail.com> wrote:
> > I was thinking that instead of displaying alert, the messages would appear
> > in the same place as they do in server-side. So keep the existing
> > javascript validator/converter stuff but change where/how it is displayed.
> > We'd probably have to render a hidden container for each field, which the
> > javascript would populate and make visible.
> >
> > Taking this route over a dialog means we could also probably provide some
> > kind of on-tab-out instant validation for more data-entry heavy
> > applications. That said these approaches are not mutually exclusive.
> >
> > Danny
> >
> > On 2/28/07, Matthias Wessendorf <ma...@apache.org> wrote:
> > >
> > > are you talking about still using JS for the client side
> > > converter/validator stuff,
> > > but just don't use alert(), instead using a "web2.0-ish" dialog ?
> > >
> > > The validator/converter stuff isn't just an alert(). We have "client
> > > side" Converter (with getAsObject/String) and Validators (with
> > > validate) and FacesMessage etc.
> > >
> > > Here is more on that interesting topic:
> > >
> > > http://incubator.apache.org/adffaces/devguide/clientValidation.html
> > >
> > > -Matthias
> > >
> > > On 2/28/07, Danny Robinson <da...@gmail.com> wrote:
> > > > Guys,
> > > >
> > > > 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.
> > > >
> > > > If so, I'll raise a JIRA issue and look into possible solutions. Tips &
> > > > suggestions welcome.
> > > >
> > > > Danny
> > > >
> > > > --
> > > > Chordiant Software Inc.
> > > > www.chordiant.com
> > > >
> > >
> > >
> > > --
> > > Matthias Wessendorf
> > > http://tinyurl.com/fmywh
> > >
> > > further stuff:
> > > blog: http://jroller.com/page/mwessendorf
> > > mail: mwessendorf-at-gmail-dot-com
> > >
> >
> >
> >
> > --
> > Chordiant Software Inc.
> > www.chordiant.com
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
Re: Client-side validation - enhance to match server-side
Posted by Martin Marinschek <ma...@gmail.com>.
I've been reiterating the necessity for this time and again ;) - I'd
be pretty much for an addition like this.
regards,
Martin
On 2/28/07, Danny Robinson <da...@gmail.com> wrote:
> I was thinking that instead of displaying alert, the messages would appear
> in the same place as they do in server-side. So keep the existing
> javascript validator/converter stuff but change where/how it is displayed.
> We'd probably have to render a hidden container for each field, which the
> javascript would populate and make visible.
>
> Taking this route over a dialog means we could also probably provide some
> kind of on-tab-out instant validation for more data-entry heavy
> applications. That said these approaches are not mutually exclusive.
>
> Danny
>
> On 2/28/07, Matthias Wessendorf <ma...@apache.org> wrote:
> >
> > are you talking about still using JS for the client side
> > converter/validator stuff,
> > but just don't use alert(), instead using a "web2.0-ish" dialog ?
> >
> > The validator/converter stuff isn't just an alert(). We have "client
> > side" Converter (with getAsObject/String) and Validators (with
> > validate) and FacesMessage etc.
> >
> > Here is more on that interesting topic:
> >
> > http://incubator.apache.org/adffaces/devguide/clientValidation.html
> >
> > -Matthias
> >
> > On 2/28/07, Danny Robinson <da...@gmail.com> wrote:
> > > Guys,
> > >
> > > 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.
> > >
> > > If so, I'll raise a JIRA issue and look into possible solutions. Tips &
> > > suggestions welcome.
> > >
> > > Danny
> > >
> > > --
> > > Chordiant Software Inc.
> > > www.chordiant.com
> > >
> >
> >
> > --
> > Matthias Wessendorf
> > http://tinyurl.com/fmywh
> >
> > further stuff:
> > blog: http://jroller.com/page/mwessendorf
> > mail: mwessendorf-at-gmail-dot-com
> >
>
>
>
> --
> Chordiant Software Inc.
> www.chordiant.com
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: Client-side validation - enhance to match server-side
Posted by Danny Robinson <da...@gmail.com>.
I was thinking that instead of displaying alert, the messages would appear
in the same place as they do in server-side. So keep the existing
javascript validator/converter stuff but change where/how it is displayed.
We'd probably have to render a hidden container for each field, which the
javascript would populate and make visible.
Taking this route over a dialog means we could also probably provide some
kind of on-tab-out instant validation for more data-entry heavy
applications. That said these approaches are not mutually exclusive.
Danny
On 2/28/07, Matthias Wessendorf <ma...@apache.org> wrote:
>
> are you talking about still using JS for the client side
> converter/validator stuff,
> but just don't use alert(), instead using a "web2.0-ish" dialog ?
>
> The validator/converter stuff isn't just an alert(). We have "client
> side" Converter (with getAsObject/String) and Validators (with
> validate) and FacesMessage etc.
>
> Here is more on that interesting topic:
>
> http://incubator.apache.org/adffaces/devguide/clientValidation.html
>
> -Matthias
>
> On 2/28/07, Danny Robinson <da...@gmail.com> wrote:
> > Guys,
> >
> > 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.
> >
> > If so, I'll raise a JIRA issue and look into possible solutions. Tips &
> > suggestions welcome.
> >
> > Danny
> >
> > --
> > Chordiant Software Inc.
> > www.chordiant.com
> >
>
>
> --
> Matthias Wessendorf
> http://tinyurl.com/fmywh
>
> further stuff:
> blog: http://jroller.com/page/mwessendorf
> mail: mwessendorf-at-gmail-dot-com
>
--
Chordiant Software Inc.
www.chordiant.com
Re: Client-side validation - enhance to match server-side
Posted by Matthias Wessendorf <ma...@apache.org>.
are you talking about still using JS for the client side
converter/validator stuff,
but just don't use alert(), instead using a "web2.0-ish" dialog ?
The validator/converter stuff isn't just an alert(). We have "client
side" Converter (with getAsObject/String) and Validators (with
validate) and FacesMessage etc.
Here is more on that interesting topic:
http://incubator.apache.org/adffaces/devguide/clientValidation.html
-Matthias
On 2/28/07, Danny Robinson <da...@gmail.com> wrote:
> Guys,
>
> 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.
>
> If so, I'll raise a JIRA issue and look into possible solutions. Tips &
> suggestions welcome.
>
> Danny
>
> --
> Chordiant Software Inc.
> www.chordiant.com
>
--
Matthias Wessendorf
http://tinyurl.com/fmywh
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com