You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Danny Robinson <da...@gmail.com> on 2007/08/29 17:05:54 UTC
[TRINIDAD] onchange event registration
Folks,
Need some pointers here. I've mainly got the event based c/s validation
working fine. However, this morning we uncovered an issue that needs some
of your feedback. Basically, we're registering the _validateInput(event)
method against onchange programmatically from within the _addValidators()
method (which I think is the direction we want to take for event
registration). Note - you can try this out by inserting
_TrEventBasedValidation=true; into a script at the top of your page.
This works just great, until you use autoSubmit="true", which causes the
SimpleInputTextRenderer (and others) to render the autoSubmit script via
onchange="_adfspu(...);return true;". This obviously fires the autoSubmit
code prior to the _validateInput and hence causes the server-side validators
to be used.
So, does anyone have a suggested workaround to this? Should
autoSubmit="true" render the _adfspu() call differently, if so how could we
ensure validators registered prior to autoSubmit event handlers?
Thanks,
Danny
--
Chordiant Software Inc.
www.chordiant.com
Re: [TRINIDAD] onchange event registration
Posted by Adam Winer <aw...@gmail.com>.
The really important APIs here are _validateInput()
and _submitPartialChange(). The former is an interesting
one to make public; the latter's really mostly just a cover
for an already-public AdfPage API. This function itself
includes details (like the "autosub" parameter) that are
specific to internal Trinidad renderers.
-- Adam
On 9/5/07, Danny Robinson <da...@gmail.com> wrote:
>
> Mainly because it's not an independently callable method, it requires
> validation to be correctly configured behind the scenes. We could consider
> something similar as a public api though.
>
> On 9/5/07, Andrew Robinson <an...@gmail.com> wrote:
> >
> > Out of curiosity, why is TrPage._autoSubmit named with an underscore,
> > shouldn't it be exposed as an API method? I would think people may
> > want to call it if they want to submit their own component using an
> > event other than the default one for the control.
> >
> > On 9/5/07, Danny Robinson <da...@gmail.com> wrote:
> > > OK, so this seems to work for me. No scriptlet required, and less
> > > parameters.
> > >
> > > <input id="_id22" class="af_inputText_content" type="text" size ="5"
> > > onchange="TrPage._autoSubmit('_id22',event,1);return true;
> > > " name="_id22"/>
> > >
> > > TrPage._autoSubmit = function(inputId, event, validate)
> > > {
> > > if (_agent.isIE)
> > > {
> > > // in many forms there is a hidden field named "event"
> > > // Sometimes IE gets confused and sends us that instead of
> > > // the true event, so...
> > > if (event["type"] == "hidden")
> > > event = window.event;
> > > }
> > >
> > > var target = event.target || event.srcElement;
> > > if (!target)
> > > return;
> > >
> > > var form = _getForm(target);
> > > if (!form)
> > > return;
> > >
> > > // Assume input is valid
> > > var isValid = true;
> > >
> > > // Validate the current input
> > > if (validate)
> > > isValid = _validateInput(event);
> > >
> > > if (isValid)
> > > {
> > > var params = new Object();
> > > params.event = "autosub";
> > > params.source = inputId;
> > >
> > > _submitPartialChange(form.id, validate, params);
> > >
> > > }
> > > }
> > >
> > >
> > > On 9/4/07, Adam Winer < awiner@gmail.com> wrote:
> > > > On 9/4/07, Danny Robinson <da...@gmail.com> wrote:
> > > > >
> > > > > > I think that autoSubmit code should automatically call
> > _validateInput
> > > > > > on its own - that is, we probably need a new JS method that
> > will:
> > > > > > - run _validateInput() on the target field
> > > > > > - run the equivalent of the existing adfspu code
> > > > > >
> > > > > > Maybe TrPage._autoSubmit()?
> > > > >
> > > > > ... and refactor the AutoSubmitUtils class to call this method
> > instead?
> > > >
> > > > Yep.
> > > >
> > > > > > BTW, I think we should start making a habit of putting variables
> > > > > > like _TrEventBasedValidation on the TrPage object - even
> > > > > > without a JS API, just using the JS object itself as a way to
> > > > > > stash variables without polluting the top-level namespace.
> > > > > > And I know this is a clear case of throwing stones and living in
> > > > > > glass houses, as it were. :)
> > > > >
> > > > > Agreed, it wasn't permanent, just there to allow enable/disable
> > of the
> > > > > feature while it evolves. Will move anything similar to TrPage in
> > > future.
> > > >
> > > > Cool, makes total sense.
> > > >
> > > > -- Adam
> > > >
> > > >
> > > > > > -- Adam
> > > > > >
> > > > > > On 9/4/07, Danny Robinson < dannyjrobinson@gmail.com> wrote:
> > > > > > > pinging for responses.
> > > > > > >
> > > > > > >
> > > > > > > On 8/29/07, Danny Robinson < dannyjrobinson@gmail.com > wrote:
> > > > > > > > Folks,
> > > > > > > >
> > > > > > > > Need some pointers here. I've mainly got the event based
> > c/s
> > > > > validation
> > > > > > > working fine. However, this morning we uncovered an issue
> > that
> > > needs
> > > > > some
> > > > > > > of your feedback. Basically, we're registering the
> > > > > _validateInput(event)
> > > > > > > method against onchange programmatically from within the
> > > > > _addValidators()
> > > > > > > method (which I think is the direction we want to take for
> > event
> > > > > > > registration). Note - you can try this out by inserting
> > > > > > > _TrEventBasedValidation=true; into a script at the top of your
> > page.
> > > > > > > >
> > > > > > > > This works just great, until you use autoSubmit="true",
> > which
> > > causes
> > > > > the
> > > > > > > SimpleInputTextRenderer (and others) to render the autoSubmit
> > script
> > > via
> > > > > > > onchange="_adfspu(...);return true;". This obviously fires
> > the
> > > > > autoSubmit
> > > > > > > code prior to the _validateInput and hence causes the
> > server-side
> > > > > validators
> > > > > > > to be used.
> > > > > > > >
> > > > > > > > So, does anyone have a suggested workaround to this? Should
> > > > > > > autoSubmit="true" render the _adfspu() call differently, if so
> > how
> > > could
> > > > > we
> > > > > > > ensure validators registered prior to autoSubmit event
> > handlers?
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > >
> > > > > > > > Danny
> > > > > > > >
> > > > > > > > --
> > > > > > > > Chordiant Software Inc.
> > > > > > > > www.chordiant.com
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Chordiant Software Inc.
> > > > > > > www.chordiant.com
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > >
> > > > > Chordiant Software Inc.
> > > > > www.chordiant.com
> > > >
> > >
> > >
> > >
> > > --
> > >
> > > Chordiant Software Inc.
> > > www.chordiant.com
> >
>
>
>
> --
> Chordiant Software Inc.
> www.chordiant.com
>
Re: [TRINIDAD] onchange event registration
Posted by Danny Robinson <da...@gmail.com>.
Mainly because it's not an independently callable method, it requires
validation to be correctly configured behind the scenes. We could consider
something similar as a public api though.
On 9/5/07, Andrew Robinson <an...@gmail.com> wrote:
>
> Out of curiosity, why is TrPage._autoSubmit named with an underscore,
> shouldn't it be exposed as an API method? I would think people may
> want to call it if they want to submit their own component using an
> event other than the default one for the control.
>
> On 9/5/07, Danny Robinson <da...@gmail.com> wrote:
> > OK, so this seems to work for me. No scriptlet required, and less
> > parameters.
> >
> > <input id="_id22" class="af_inputText_content" type="text" size ="5"
> > onchange="TrPage._autoSubmit('_id22',event,1);return true;
> > " name="_id22"/>
> >
> > TrPage._autoSubmit = function(inputId, event, validate)
> > {
> > if (_agent.isIE)
> > {
> > // in many forms there is a hidden field named "event"
> > // Sometimes IE gets confused and sends us that instead of
> > // the true event, so...
> > if (event["type"] == "hidden")
> > event = window.event;
> > }
> >
> > var target = event.target || event.srcElement;
> > if (!target)
> > return;
> >
> > var form = _getForm(target);
> > if (!form)
> > return;
> >
> > // Assume input is valid
> > var isValid = true;
> >
> > // Validate the current input
> > if (validate)
> > isValid = _validateInput(event);
> >
> > if (isValid)
> > {
> > var params = new Object();
> > params.event = "autosub";
> > params.source = inputId;
> >
> > _submitPartialChange(form.id, validate, params);
> >
> > }
> > }
> >
> >
> > On 9/4/07, Adam Winer <aw...@gmail.com> wrote:
> > > On 9/4/07, Danny Robinson <da...@gmail.com> wrote:
> > > >
> > > > > I think that autoSubmit code should automatically call
> _validateInput
> > > > > on its own - that is, we probably need a new JS method that will:
> > > > > - run _validateInput() on the target field
> > > > > - run the equivalent of the existing adfspu code
> > > > >
> > > > > Maybe TrPage._autoSubmit()?
> > > >
> > > > ... and refactor the AutoSubmitUtils class to call this method
> instead?
> > >
> > > Yep.
> > >
> > > > > BTW, I think we should start making a habit of putting variables
> > > > > like _TrEventBasedValidation on the TrPage object - even
> > > > > without a JS API, just using the JS object itself as a way to
> > > > > stash variables without polluting the top-level namespace.
> > > > > And I know this is a clear case of throwing stones and living in
> > > > > glass houses, as it were. :)
> > > >
> > > > Agreed, it wasn't permanent, just there to allow enable/disable of
> the
> > > > feature while it evolves. Will move anything similar to TrPage in
> > future.
> > >
> > > Cool, makes total sense.
> > >
> > > -- Adam
> > >
> > >
> > > > > -- Adam
> > > > >
> > > > > On 9/4/07, Danny Robinson < dannyjrobinson@gmail.com> wrote:
> > > > > > pinging for responses.
> > > > > >
> > > > > >
> > > > > > On 8/29/07, Danny Robinson < dannyjrobinson@gmail.com > wrote:
> > > > > > > Folks,
> > > > > > >
> > > > > > > Need some pointers here. I've mainly got the event based c/s
> > > > validation
> > > > > > working fine. However, this morning we uncovered an issue that
> > needs
> > > > some
> > > > > > of your feedback. Basically, we're registering the
> > > > _validateInput(event)
> > > > > > method against onchange programmatically from within the
> > > > _addValidators()
> > > > > > method (which I think is the direction we want to take for event
> > > > > > registration). Note - you can try this out by inserting
> > > > > > _TrEventBasedValidation=true; into a script at the top of your
> page.
> > > > > > >
> > > > > > > This works just great, until you use autoSubmit="true", which
> > causes
> > > > the
> > > > > > SimpleInputTextRenderer (and others) to render the autoSubmit
> script
> > via
> > > > > > onchange="_adfspu(...);return true;". This obviously fires the
> > > > autoSubmit
> > > > > > code prior to the _validateInput and hence causes the
> server-side
> > > > validators
> > > > > > to be used.
> > > > > > >
> > > > > > > So, does anyone have a suggested workaround to this? Should
> > > > > > autoSubmit="true" render the _adfspu() call differently, if so
> how
> > could
> > > > we
> > > > > > ensure validators registered prior to autoSubmit event handlers?
> > > > > > >
> > > > > > > Thanks,
> > > > > > >
> > > > > > > Danny
> > > > > > >
> > > > > > > --
> > > > > > > Chordiant Software Inc.
> > > > > > > www.chordiant.com
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Chordiant Software Inc.
> > > > > > www.chordiant.com
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > >
> > > > Chordiant Software Inc.
> > > > www.chordiant.com
> > >
> >
> >
> >
> > --
> >
> > Chordiant Software Inc.
> > www.chordiant.com
>
--
Chordiant Software Inc.
www.chordiant.com
Re: [TRINIDAD] onchange event registration
Posted by Andrew Robinson <an...@gmail.com>.
Out of curiosity, why is TrPage._autoSubmit named with an underscore,
shouldn't it be exposed as an API method? I would think people may
want to call it if they want to submit their own component using an
event other than the default one for the control.
On 9/5/07, Danny Robinson <da...@gmail.com> wrote:
> OK, so this seems to work for me. No scriptlet required, and less
> parameters.
>
> <input id="_id22" class="af_inputText_content" type="text" size ="5"
> onchange="TrPage._autoSubmit('_id22',event,1);return true;
> " name="_id22"/>
>
> TrPage._autoSubmit = function(inputId, event, validate)
> {
> if (_agent.isIE)
> {
> // in many forms there is a hidden field named "event"
> // Sometimes IE gets confused and sends us that instead of
> // the true event, so...
> if (event["type"] == "hidden")
> event = window.event;
> }
>
> var target = event.target || event.srcElement;
> if (!target)
> return;
>
> var form = _getForm(target);
> if (!form)
> return;
>
> // Assume input is valid
> var isValid = true;
>
> // Validate the current input
> if (validate)
> isValid = _validateInput(event);
>
> if (isValid)
> {
> var params = new Object();
> params.event = "autosub";
> params.source = inputId;
>
> _submitPartialChange(form.id, validate, params);
>
> }
> }
>
>
> On 9/4/07, Adam Winer <aw...@gmail.com> wrote:
> > On 9/4/07, Danny Robinson <da...@gmail.com> wrote:
> > >
> > > > I think that autoSubmit code should automatically call _validateInput
> > > > on its own - that is, we probably need a new JS method that will:
> > > > - run _validateInput() on the target field
> > > > - run the equivalent of the existing adfspu code
> > > >
> > > > Maybe TrPage._autoSubmit()?
> > >
> > > ... and refactor the AutoSubmitUtils class to call this method instead?
> >
> > Yep.
> >
> > > > BTW, I think we should start making a habit of putting variables
> > > > like _TrEventBasedValidation on the TrPage object - even
> > > > without a JS API, just using the JS object itself as a way to
> > > > stash variables without polluting the top-level namespace.
> > > > And I know this is a clear case of throwing stones and living in
> > > > glass houses, as it were. :)
> > >
> > > Agreed, it wasn't permanent, just there to allow enable/disable of the
> > > feature while it evolves. Will move anything similar to TrPage in
> future.
> >
> > Cool, makes total sense.
> >
> > -- Adam
> >
> >
> > > > -- Adam
> > > >
> > > > On 9/4/07, Danny Robinson < dannyjrobinson@gmail.com> wrote:
> > > > > pinging for responses.
> > > > >
> > > > >
> > > > > On 8/29/07, Danny Robinson < dannyjrobinson@gmail.com > wrote:
> > > > > > Folks,
> > > > > >
> > > > > > Need some pointers here. I've mainly got the event based c/s
> > > validation
> > > > > working fine. However, this morning we uncovered an issue that
> needs
> > > some
> > > > > of your feedback. Basically, we're registering the
> > > _validateInput(event)
> > > > > method against onchange programmatically from within the
> > > _addValidators()
> > > > > method (which I think is the direction we want to take for event
> > > > > registration). Note - you can try this out by inserting
> > > > > _TrEventBasedValidation=true; into a script at the top of your page.
> > > > > >
> > > > > > This works just great, until you use autoSubmit="true", which
> causes
> > > the
> > > > > SimpleInputTextRenderer (and others) to render the autoSubmit script
> via
> > > > > onchange="_adfspu(...);return true;". This obviously fires the
> > > autoSubmit
> > > > > code prior to the _validateInput and hence causes the server-side
> > > validators
> > > > > to be used.
> > > > > >
> > > > > > So, does anyone have a suggested workaround to this? Should
> > > > > autoSubmit="true" render the _adfspu() call differently, if so how
> could
> > > we
> > > > > ensure validators registered prior to autoSubmit event handlers?
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > Danny
> > > > > >
> > > > > > --
> > > > > > Chordiant Software Inc.
> > > > > > www.chordiant.com
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Chordiant Software Inc.
> > > > > www.chordiant.com
> > > >
> > >
> > >
> > >
> > > --
> > >
> > > Chordiant Software Inc.
> > > www.chordiant.com
> >
>
>
>
> --
>
> Chordiant Software Inc.
> www.chordiant.com
Re: [TRINIDAD] onchange event registration
Posted by Danny Robinson <da...@gmail.com>.
OK, so this seems to work for me. No scriptlet required, and less
parameters.
<input id="_id22" class="af_inputText_content" type="text" size="5" onchange
="TrPage._autoSubmit('_id22',event,1);return true;" name="_id22"/>
TrPage._autoSubmit = function(inputId, event, validate)
{
if (_agent.isIE)
{
// in many forms there is a hidden field named "event"
// Sometimes IE gets confused and sends us that instead of
// the true event, so...
if (event["type"] == "hidden")
event = window.event;
}
var target = event.target || event.srcElement;
if (!target)
return;
var form = _getForm(target);
if (!form)
return;
// Assume input is valid
var isValid = true;
// Validate the current input
if (validate)
isValid = _validateInput(event);
if (isValid)
{
var params = new Object();
params.event = "autosub";
params.source = inputId;
_submitPartialChange(form.id, validate, params);
}
}
On 9/4/07, Adam Winer <aw...@gmail.com> wrote:
>
> On 9/4/07, Danny Robinson <da...@gmail.com> wrote:
> >
> > > I think that autoSubmit code should automatically call _validateInput
> > > on its own - that is, we probably need a new JS method that will:
> > > - run _validateInput() on the target field
> > > - run the equivalent of the existing adfspu code
> > >
> > > Maybe TrPage._autoSubmit()?
> >
> > ... and refactor the AutoSubmitUtils class to call this method instead?
>
> Yep.
>
> > > BTW, I think we should start making a habit of putting variables
> > > like _TrEventBasedValidation on the TrPage object - even
> > > without a JS API, just using the JS object itself as a way to
> > > stash variables without polluting the top-level namespace.
> > > And I know this is a clear case of throwing stones and living in
> > > glass houses, as it were. :)
> >
> > Agreed, it wasn't permanent, just there to allow enable/disable of the
> > feature while it evolves. Will move anything similar to TrPage in
> future.
>
> Cool, makes total sense.
>
> -- Adam
>
>
> > > -- Adam
> > >
> > > On 9/4/07, Danny Robinson <da...@gmail.com> wrote:
> > > > pinging for responses.
> > > >
> > > >
> > > > On 8/29/07, Danny Robinson < dannyjrobinson@gmail.com> wrote:
> > > > > Folks,
> > > > >
> > > > > Need some pointers here. I've mainly got the event based c/s
> > validation
> > > > working fine. However, this morning we uncovered an issue that
> needs
> > some
> > > > of your feedback. Basically, we're registering the
> > _validateInput(event)
> > > > method against onchange programmatically from within the
> > _addValidators()
> > > > method (which I think is the direction we want to take for event
> > > > registration). Note - you can try this out by inserting
> > > > _TrEventBasedValidation=true; into a script at the top of your page.
> > > > >
> > > > > This works just great, until you use autoSubmit="true", which
> causes
> > the
> > > > SimpleInputTextRenderer (and others) to render the autoSubmit script
> via
> > > > onchange="_adfspu(...);return true;". This obviously fires the
> > autoSubmit
> > > > code prior to the _validateInput and hence causes the server-side
> > validators
> > > > to be used.
> > > > >
> > > > > So, does anyone have a suggested workaround to this? Should
> > > > autoSubmit="true" render the _adfspu() call differently, if so how
> could
> > we
> > > > ensure validators registered prior to autoSubmit event handlers?
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Danny
> > > > >
> > > > > --
> > > > > Chordiant Software Inc.
> > > > > www.chordiant.com
> > > >
> > > >
> > > >
> > > > --
> > > > Chordiant Software Inc.
> > > > www.chordiant.com
> > >
> >
> >
> >
> > --
> >
> > Chordiant Software Inc.
> > www.chordiant.com
>
--
Chordiant Software Inc.
www.chordiant.com
Re: [TRINIDAD] onchange event registration
Posted by Adam Winer <aw...@gmail.com>.
On 9/4/07, Danny Robinson <da...@gmail.com> wrote:
>
> > I think that autoSubmit code should automatically call _validateInput
> > on its own - that is, we probably need a new JS method that will:
> > - run _validateInput() on the target field
> > - run the equivalent of the existing adfspu code
> >
> > Maybe TrPage._autoSubmit()?
>
> ... and refactor the AutoSubmitUtils class to call this method instead?
Yep.
> > BTW, I think we should start making a habit of putting variables
> > like _TrEventBasedValidation on the TrPage object - even
> > without a JS API, just using the JS object itself as a way to
> > stash variables without polluting the top-level namespace.
> > And I know this is a clear case of throwing stones and living in
> > glass houses, as it were. :)
>
> Agreed, it wasn't permanent, just there to allow enable/disable of the
> feature while it evolves. Will move anything similar to TrPage in future.
Cool, makes total sense.
-- Adam
> > -- Adam
> >
> > On 9/4/07, Danny Robinson <da...@gmail.com> wrote:
> > > pinging for responses.
> > >
> > >
> > > On 8/29/07, Danny Robinson < dannyjrobinson@gmail.com> wrote:
> > > > Folks,
> > > >
> > > > Need some pointers here. I've mainly got the event based c/s
> validation
> > > working fine. However, this morning we uncovered an issue that needs
> some
> > > of your feedback. Basically, we're registering the
> _validateInput(event)
> > > method against onchange programmatically from within the
> _addValidators()
> > > method (which I think is the direction we want to take for event
> > > registration). Note - you can try this out by inserting
> > > _TrEventBasedValidation=true; into a script at the top of your page.
> > > >
> > > > This works just great, until you use autoSubmit="true", which causes
> the
> > > SimpleInputTextRenderer (and others) to render the autoSubmit script via
> > > onchange="_adfspu(...);return true;". This obviously fires the
> autoSubmit
> > > code prior to the _validateInput and hence causes the server-side
> validators
> > > to be used.
> > > >
> > > > So, does anyone have a suggested workaround to this? Should
> > > autoSubmit="true" render the _adfspu() call differently, if so how could
> we
> > > ensure validators registered prior to autoSubmit event handlers?
> > > >
> > > > Thanks,
> > > >
> > > > Danny
> > > >
> > > > --
> > > > Chordiant Software Inc.
> > > > www.chordiant.com
> > >
> > >
> > >
> > > --
> > > Chordiant Software Inc.
> > > www.chordiant.com
> >
>
>
>
> --
>
> Chordiant Software Inc.
> www.chordiant.com
Re: [TRINIDAD] onchange event registration
Posted by Danny Robinson <da...@gmail.com>.
>
> I think that autoSubmit code should automatically call _validateInput
> on its own - that is, we probably need a new JS method that will:
> - run _validateInput() on the target field
> - run the equivalent of the existing adfspu code
>
> Maybe TrPage._autoSubmit()?
... and refactor the AutoSubmitUtils class to call this method instead?
BTW, I think we should start making a habit of putting variables
> like _TrEventBasedValidation on the TrPage object - even
> without a JS API, just using the JS object itself as a way to
> stash variables without polluting the top-level namespace.
> And I know this is a clear case of throwing stones and living in
> glass houses, as it were. :)
Agreed, it wasn't permanent, just there to allow enable/disable of the
feature while it evolves. Will move anything similar to TrPage in future.
-- Adam
>
> On 9/4/07, Danny Robinson <da...@gmail.com> wrote:
> > pinging for responses.
> >
> >
> > On 8/29/07, Danny Robinson <da...@gmail.com> wrote:
> > > Folks,
> > >
> > > Need some pointers here. I've mainly got the event based c/s
> validation
> > working fine. However, this morning we uncovered an issue that needs
> some
> > of your feedback. Basically, we're registering the
> _validateInput(event)
> > method against onchange programmatically from within the
> _addValidators()
> > method (which I think is the direction we want to take for event
> > registration). Note - you can try this out by inserting
> > _TrEventBasedValidation=true; into a script at the top of your page.
> > >
> > > This works just great, until you use autoSubmit="true", which causes
> the
> > SimpleInputTextRenderer (and others) to render the autoSubmit script via
> > onchange="_adfspu(...);return true;". This obviously fires the
> autoSubmit
> > code prior to the _validateInput and hence causes the server-side
> validators
> > to be used.
> > >
> > > So, does anyone have a suggested workaround to this? Should
> > autoSubmit="true" render the _adfspu() call differently, if so how could
> we
> > ensure validators registered prior to autoSubmit event handlers?
> > >
> > > Thanks,
> > >
> > > Danny
> > >
> > > --
> > > Chordiant Software Inc.
> > > www.chordiant.com
> >
> >
> >
> > --
> > Chordiant Software Inc.
> > www.chordiant.com
>
--
Chordiant Software Inc.
www.chordiant.com
Re: [TRINIDAD] onchange event registration
Posted by Adam Winer <aw...@gmail.com>.
I think that autoSubmit code should automatically call _validateInput
on its own - that is, we probably need a new JS method that will:
- run _validateInput() on the target field
- run the equivalent of the existing adfspu code
Maybe TrPage._autoSubmit()?
BTW, I think we should start making a habit of putting variables
like _TrEventBasedValidation on the TrPage object - even
without a JS API, just using the JS object itself as a way to
stash variables without polluting the top-level namespace.
And I know this is a clear case of throwing stones and living in
glass houses, as it were. :)
-- Adam
On 9/4/07, Danny Robinson <da...@gmail.com> wrote:
> pinging for responses.
>
>
> On 8/29/07, Danny Robinson <da...@gmail.com> wrote:
> > Folks,
> >
> > Need some pointers here. I've mainly got the event based c/s validation
> working fine. However, this morning we uncovered an issue that needs some
> of your feedback. Basically, we're registering the _validateInput(event)
> method against onchange programmatically from within the _addValidators()
> method (which I think is the direction we want to take for event
> registration). Note - you can try this out by inserting
> _TrEventBasedValidation=true; into a script at the top of your page.
> >
> > This works just great, until you use autoSubmit="true", which causes the
> SimpleInputTextRenderer (and others) to render the autoSubmit script via
> onchange="_adfspu(...);return true;". This obviously fires the autoSubmit
> code prior to the _validateInput and hence causes the server-side validators
> to be used.
> >
> > So, does anyone have a suggested workaround to this? Should
> autoSubmit="true" render the _adfspu() call differently, if so how could we
> ensure validators registered prior to autoSubmit event handlers?
> >
> > Thanks,
> >
> > Danny
> >
> > --
> > Chordiant Software Inc.
> > www.chordiant.com
>
>
>
> --
> Chordiant Software Inc.
> www.chordiant.com
Re: [TRINIDAD] onchange event registration
Posted by Danny Robinson <da...@gmail.com>.
pinging for responses.
On 8/29/07, Danny Robinson <da...@gmail.com> wrote:
>
> Folks,
>
> Need some pointers here. I've mainly got the event based c/s validation
> working fine. However, this morning we uncovered an issue that needs some
> of your feedback. Basically, we're registering the _validateInput(event)
> method against onchange programmatically from within the _addValidators()
> method (which I think is the direction we want to take for event
> registration). Note - you can try this out by inserting
> _TrEventBasedValidation=true; into a script at the top of your page.
>
> This works just great, until you use autoSubmit="true", which causes the
> SimpleInputTextRenderer (and others) to render the autoSubmit script via
> onchange="_adfspu(...);return true;". This obviously fires the autoSubmitcode prior to the _validateInput and hence causes the server-side validators
> to be used.
>
> So, does anyone have a suggested workaround to this? Should autoSubmit="true"
> render the _adfspu() call differently, if so how could we ensure validators
> registered prior to autoSubmit event handlers?
>
> Thanks,
>
> Danny
>
> --
> Chordiant Software Inc.
> www.chordiant.com
--
Chordiant Software Inc.
www.chordiant.com