You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Gerald Müllan <bi...@gmail.com> on 2006/02/08 01:25:58 UTC
Some thoughts about HtmlInputTextAjax component
Hi *,
I have tried to add some new features to the HtmlInputTextAjax
component, contributed by travis.
He did great work, but there are still some open thoughts I would like
to discuss over the list.
In short, added features are:
-) highlighting the input fields with a given style after a validation
error has occured
-) possibility of displaying error messages of all ajax input fields
on one site in a central place
-) displaying the messages over t:message and t:messages, via a new
attribute forceRenderSpan, which renders a span out, even if there is
no message getting through via a "normal" jsf processing.
While trying to implement these new enhancements it was really hard to
get along with the high amount of legacy JavaScript code in the
AjaxRendererUtils class.
However, it may also be difficult for others to maintain it in the
future, so swapping some JavaScript fragments out, sounds like a good
idea to me, right?
We can do this by introducing a utility class, or just throw the whole
thing away :)
I have discussed this issue with Martin; Why displaying an error
message via the whole JavaScript processing on client? Just render it
out with some enhancements to the message components.
So we could save a lot of JavaScript code and it is not a need to do
so much client side things. For highlighting the fields, a little bit
JavaScript is still necessary.
Any drawbacks, issues we have not thought about?
Furthermore, Travis has introduced a own HtmlMessageTag and Renderer
in order to put the error message in the span over JavaScript. Is this
approach necessary? Adding new attributes to the message comps sounds
more preferable to me.
@Werner; Any idea how the dojo library comes along with this ajax
validation stuff?
regards,
Gerald
--
Gerald Muellan
Schelleingasse 2/11
1040 Vienna, Austria
0043 699 11772506
Bierbrauen@gmail.com
Re: Some thoughts about HtmlInputTextAjax component
Posted by Werner Punz <we...@gmx.at>.
Travis Reeder schrieb:
> Just to make things clear, the validation that I put into the ajax form
> components is server side validation through ajax meaning that when a
> field changes, the change is sent to the server through ajax and if
> validation fails, the error message ir returned to the client and
> displayed in the <s:message> tag.
>
Ah ok... thanks for the clarification ;-)
Re: Some thoughts about HtmlInputTextAjax component
Posted by Travis Reeder <tr...@gmail.com>.
Just to make things clear, the validation that I put into the ajax form
components is server side validation through ajax meaning that when a field
changes, the change is sent to the server through ajax and if validation
fails, the error message ir returned to the client and displayed in the
<s:message> tag.
Travis
On 2/8/06, Werner Punz <we...@gmx.at> wrote:
>
> Werner Punz schrieb:
> > Gerald Müllan schrieb:
> >
> >> @Werner; Any idea how the dojo library comes along with this ajax
> >> validation stuff?
> >>
> > Definitely no hooks into JSF ;-)
> > dojo basically gives you a simplified ajax infrastructure which is
> > basically a class definition with a callback function within the class.
> > (it also encapsules the transportation layer)
> > what you do within the function is up to you.
> > I have not looked into dojo that much to know if there also is a
> > validation framework on top of it. But it is not very likely.
> >
> >
>
> Ok to clarify the things, I checked the examples, dojo definitely has
> some client side validation framework, which works as expected,
> http://archive.dojotoolkit.org/nightly/tests/widget/test_validate.html
>
> This one is really interesting, but you wont get hooks into jsf that
> way, on the other hand you probably wont need them.
>
> As I said, I am fairly new to dojo as well, my knowledge grows with its
> usage every day. So I cannot give precise answers currently ;-).
> But something is there, it does not seem to be ajax, but definitely
> input validation ;-)
>
>
Re: Some thoughts about HtmlInputTextAjax component
Posted by Martin Marinschek <ma...@gmail.com>.
I don't love to do it either, but we'll obey the technical
constraints. There are replacements for the stuff we need in dojo,
it's just a question of implementing it.
regards,
Martin
On 2/10/06, Volker Weber <us...@weber-oldenburg.de> wrote:
> Hi,
>
> are there replacements for script.aculo.us library functions in dojo?
>
> We need at least replacements for Autocompleter from there and
> Ajax.Updater from prototype.js before we can ditch it.
>
> And i don't like to reimplement this stuff.
>
> Regards,
> Volker
>
>
> Martin Marinschek wrote:
> > Yes, we ditch prototype.
> >
> > I liked it personally - but they do not support namespacing, and that
> > is an issue.
> >
> > If you define a global javascript object named Effect, you do not
> > expect to cooperate with any other javascript library out there, and
> > we cannot afford that in our case... I absolutely buy Martin Coopers
> > position here after having talked with the prototype guys again...
> >
> > regards,
> >
> > Martin
> >
> > On 2/9/06, Travis Reeder <tr...@gmail.com> wrote:
> >
> >>On 2/9/06, Werner Punz <we...@gmx.at> wrote:
> >>
> >>>Actually to my knowledge dojo does not have anything in this regard, and
> >>>I cannot see how, because this is heavy jsf specific in how to do
> >>>things, but it is possible to do it anyway, and dojo can help in certain
> >>>areas. First the whole ajax calling structure can be simplified and made
> >>>protocol agnostic:
> >>>
> >>>dojo.io.bind({
> >>> url: "http://foo.bar.com/sampleData.js",
> >>> load: function(type, evaldObj){ /* do something */ },
> >>> mimetype: "text/plain", // get plain text, don't eval()
> >>> transport: "XMLHTTPTransport"
> >>>});
> >>>
> >>>theoretically you can get away with that one:
> >>>
> >>>dojo.io.bind({
> >>> url: "http://foo.bar.com/sampleData.txt",
> >>> load: function(type, data, evt){ /*do something w/ the data */ },
> >>> mimetype: "text/plain"
> >>>});
> >>
> >>Are we ditching prototype then? This looks just like the prototype
> >>functions.
> >>
> >
> >
> >
> > --
> >
> > http://www.irian.at
> >
> > Your JSF powerhouse -
> > JSF Consulting, Development and
> > Courses in English and German
> >
> > Professional Support for Apache MyFaces
> >
>
> --
> Don't answer to From: address!
> Mail to this account are droped if not recieved via mailinglist.
> To contact me direct create the mail address by
> concatenating my forename to my senders domain.
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: Some thoughts about HtmlInputTextAjax component
Posted by Volker Weber <us...@weber-oldenburg.de>.
Hi,
are there replacements for script.aculo.us library functions in dojo?
We need at least replacements for Autocompleter from there and
Ajax.Updater from prototype.js before we can ditch it.
And i don't like to reimplement this stuff.
Regards,
Volker
Martin Marinschek wrote:
> Yes, we ditch prototype.
>
> I liked it personally - but they do not support namespacing, and that
> is an issue.
>
> If you define a global javascript object named Effect, you do not
> expect to cooperate with any other javascript library out there, and
> we cannot afford that in our case... I absolutely buy Martin Coopers
> position here after having talked with the prototype guys again...
>
> regards,
>
> Martin
>
> On 2/9/06, Travis Reeder <tr...@gmail.com> wrote:
>
>>On 2/9/06, Werner Punz <we...@gmx.at> wrote:
>>
>>>Actually to my knowledge dojo does not have anything in this regard, and
>>>I cannot see how, because this is heavy jsf specific in how to do
>>>things, but it is possible to do it anyway, and dojo can help in certain
>>>areas. First the whole ajax calling structure can be simplified and made
>>>protocol agnostic:
>>>
>>>dojo.io.bind({
>>> url: "http://foo.bar.com/sampleData.js",
>>> load: function(type, evaldObj){ /* do something */ },
>>> mimetype: "text/plain", // get plain text, don't eval()
>>> transport: "XMLHTTPTransport"
>>>});
>>>
>>>theoretically you can get away with that one:
>>>
>>>dojo.io.bind({
>>> url: "http://foo.bar.com/sampleData.txt",
>>> load: function(type, data, evt){ /*do something w/ the data */ },
>>> mimetype: "text/plain"
>>>});
>>
>>Are we ditching prototype then? This looks just like the prototype
>>functions.
>>
>
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
--
Don't answer to From: address!
Mail to this account are droped if not recieved via mailinglist.
To contact me direct create the mail address by
concatenating my forename to my senders domain.
Re: Some thoughts about HtmlInputTextAjax component
Posted by Martin Marinschek <ma...@gmail.com>.
Yes, we ditch prototype.
I liked it personally - but they do not support namespacing, and that
is an issue.
If you define a global javascript object named Effect, you do not
expect to cooperate with any other javascript library out there, and
we cannot afford that in our case... I absolutely buy Martin Coopers
position here after having talked with the prototype guys again...
regards,
Martin
On 2/9/06, Travis Reeder <tr...@gmail.com> wrote:
> On 2/9/06, Werner Punz <we...@gmx.at> wrote:
> >
> > Actually to my knowledge dojo does not have anything in this regard, and
> > I cannot see how, because this is heavy jsf specific in how to do
> > things, but it is possible to do it anyway, and dojo can help in certain
> > areas. First the whole ajax calling structure can be simplified and made
> > protocol agnostic:
> >
> > dojo.io.bind({
> > url: "http://foo.bar.com/sampleData.js",
> > load: function(type, evaldObj){ /* do something */ },
> > mimetype: "text/plain", // get plain text, don't eval()
> > transport: "XMLHTTPTransport"
> > });
> >
> > theoretically you can get away with that one:
> >
> > dojo.io.bind({
> > url: "http://foo.bar.com/sampleData.txt",
> > load: function(type, data, evt){ /*do something w/ the data */ },
> > mimetype: "text/plain"
> > });
>
> Are we ditching prototype then? This looks just like the prototype
> functions.
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: Some thoughts about HtmlInputTextAjax component
Posted by Travis Reeder <tr...@gmail.com>.
On 2/9/06, Werner Punz <we...@gmx.at> wrote:
>
>
> Actually to my knowledge dojo does not have anything in this regard, and
> I cannot see how, because this is heavy jsf specific in how to do
> things, but it is possible to do it anyway, and dojo can help in certain
> areas. First the whole ajax calling structure can be simplified and made
> protocol agnostic:
>
> dojo.io.bind({
> url: "http://foo.bar.com/sampleData.js",
> load: function(type, evaldObj){ /* do something */ },
> mimetype: "text/plain", // get plain text, don't eval()
> transport: "XMLHTTPTransport"
> });
>
> theoretically you can get away with that one:
>
> dojo.io.bind({
> url: "http://foo.bar.com/sampleData.txt",
> load: function(type, data, evt){ /*do something w/ the data */ },
> mimetype: "text/plain"
> });
Are we ditching prototype then? This looks just like the prototype
functions.
Re: Some thoughts about HtmlInputTextAjax component
Posted by Werner Punz <we...@gmx.at>.
Gerald Müllan schrieb:
> Hi Werner,
>
>> As I said, I am fairly new to dojo as well, my knowledge grows with its
>> usage every day. So I cannot give precise answers currently ;-).
>> But something is there, it does not seem to be ajax, but definitely
>> input validation ;-)
>
> Yes, definitely. Really nice examples, but it seems to be only client
> side validation without ajax.
>
> Going to the server to validate the input, like it is in the inputAjax
> component, let us do many things in a quite easy manner.
>
Actually to my knowledge dojo does not have anything in this regard, and
I cannot see how, because this is heavy jsf specific in how to do
things, but it is possible to do it anyway, and dojo can help in certain
areas. First the whole ajax calling structure can be simplified and made
protocol agnostic:
dojo.io.bind({
url: "http://foo.bar.com/sampleData.js",
load: function(type, evaldObj){ /* do something */ },
mimetype: "text/plain", // get plain text, don't eval()
transport: "XMLHTTPTransport"
});
theoretically you can get away with that one:
dojo.io.bind({
url: "http://foo.bar.com/sampleData.txt",
load: function(type, data, evt){ /*do something w/ the data */ },
mimetype: "text/plain"
});
thats all and you have an ajax request with a defined callback and error
handler and a defined transport (you can leave that one free and dojo
takes care of that), mo messing around with return states anymore, in
the future you probably can move the transport from xmlhttp to iframe
and other callback structures within a switch etc...
You also can move the returned content from xml, to html and to json and
dojo can take care of some aspects of dealing with it.
But no, as far as I have an overlook of the framework no dedicated
server side ajaxed validation yet, but I will ask the devs the next days
(I maybe have missed it)
Re: Some thoughts about HtmlInputTextAjax component
Posted by Gerald Müllan <bi...@gmail.com>.
Hi Werner,
> As I said, I am fairly new to dojo as well, my knowledge grows with its
> usage every day. So I cannot give precise answers currently ;-).
> But something is there, it does not seem to be ajax, but definitely
> input validation ;-)
Yes, definitely. Really nice examples, but it seems to be only client
side validation without ajax.
Going to the server to validate the input, like it is in the inputAjax
component, let us do many things in a quite easy manner.
regards,
Gerald
--
Gerald Muellan
Schelleingasse 2/11
1040 Vienna, Austria
0043 699 11772506
Bierbrauen@gmail.com
Re: Some thoughts about HtmlInputTextAjax component
Posted by Werner Punz <we...@gmx.at>.
Werner Punz schrieb:
> Gerald Müllan schrieb:
>
>> @Werner; Any idea how the dojo library comes along with this ajax
>> validation stuff?
>>
> Definitely no hooks into JSF ;-)
> dojo basically gives you a simplified ajax infrastructure which is
> basically a class definition with a callback function within the class.
> (it also encapsules the transportation layer)
> what you do within the function is up to you.
> I have not looked into dojo that much to know if there also is a
> validation framework on top of it. But it is not very likely.
>
>
Ok to clarify the things, I checked the examples, dojo definitely has
some client side validation framework, which works as expected,
http://archive.dojotoolkit.org/nightly/tests/widget/test_validate.html
This one is really interesting, but you wont get hooks into jsf that
way, on the other hand you probably wont need them.
As I said, I am fairly new to dojo as well, my knowledge grows with its
usage every day. So I cannot give precise answers currently ;-).
But something is there, it does not seem to be ajax, but definitely
input validation ;-)
Re: Some thoughts about HtmlInputTextAjax component
Posted by Werner Punz <we...@gmx.at>.
Gerald Müllan schrieb:
> @Werner; Any idea how the dojo library comes along with this ajax
> validation stuff?
>
Definitely no hooks into JSF ;-)
dojo basically gives you a simplified ajax infrastructure which is
basically a class definition with a callback function within the class.
(it also encapsules the transportation layer)
what you do within the function is up to you.
I have not looked into dojo that much to know if there also is a
validation framework on top of it. But it is not very likely.
Re: Some thoughts about HtmlInputTextAjax component
Posted by Travis Reeder <tr...@gmail.com>.
I'm all for that, I just didn't want to mess with tomahawk stuff until it's
been in the sandbox for testing and feedback.
Travis
On 2/9/06, Martin Marinschek <ma...@gmail.com> wrote:
>
> I agree with Gerald on using an attribute instead of a separate
> component - "forceSpan" should be just enough.
>
> regards,
>
> Martin
>
> On 2/9/06, Gerald Müllan <bi...@gmail.com> wrote:
> > Hi Travis,
> >
> > > Not sure what you mean here?
> >
> > Currently there is one message tag for each input ajax field. This can
> > be reduced now to one messages tag for all the input ajax fields on
> > the site.
> >
> > So, if there are three input fields, you can define for example one
> > div element (with nice style), embedded the messages tag. Each time an
> > error occurs in one of the ajax fields, the error message is displayed
> > in this area.
> >
> > If you do not correct the errors in, all the fields, three messages
> > are shown there.
> >
> > However, it is also possible to have a message tag for each field, and
> > additional the messages stuff. Ok, this usecase maybe not really
> > useful :)
> >
> > > This is exactly what happens now, the span will be rendered no matter
> what,
> > > but you must use the s:message tag (which is the new HtmlMessageTag
> you are
> > > referring to) because it sets the id on the span. It sets the id so
> that
> > > the client side javascript knows what span to show the error message
> in.
> > > The examples in inputAjax.jsp show this error handling in action.
> >
> > Sure, you are right. But if we add a new attribute to the t:message
> > and t:messages components, which do exactly these things, there is no
> > need for an additional tag and an additional renderer.
> >
> > > The javascript definitely needs to be cleaned up, most of it could be
> put
> > > into a an external js file. I have been meaning to do that (i have a
> todo
> > > in the code somewhere about that), but this Maven thing has put a dent
> in my
> > > plans... ;)
> >
> > It seems you are really overhelmed with work, so I will do this issue
> for you :)
> >
> > > The javascript needs to be somewhere, if not on the ajax end, then it
> has to
> > > be on the component end. It seems to me it should stay on the ajax
> side of
> > > things, so the message tag remains a simple dumb component that isn't
> tied
> > > to ajax.
> >
> > I agree. Ajax stuff should be not tied to the messag tag.
> >
> > > The new tag is required as I explained above because it needs to set
> the id.
> >
> > Yes, definitely required. But maybe added to t:message and t:messages.
> > See above.
> >
> > Seems that we really have a great component out there :)
> >
> > regards,
> >
> > Gerald
> >
> > --
> > Gerald Muellan
> > Schelleingasse 2/11
> > 1040 Vienna, Austria
> > 0043 699 11772506
> > Bierbrauen@gmail.com
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
Re: Some thoughts about HtmlInputTextAjax component
Posted by Martin Marinschek <ma...@gmail.com>.
I agree with Gerald on using an attribute instead of a separate
component - "forceSpan" should be just enough.
regards,
Martin
On 2/9/06, Gerald Müllan <bi...@gmail.com> wrote:
> Hi Travis,
>
> > Not sure what you mean here?
>
> Currently there is one message tag for each input ajax field. This can
> be reduced now to one messages tag for all the input ajax fields on
> the site.
>
> So, if there are three input fields, you can define for example one
> div element (with nice style), embedded the messages tag. Each time an
> error occurs in one of the ajax fields, the error message is displayed
> in this area.
>
> If you do not correct the errors in, all the fields, three messages
> are shown there.
>
> However, it is also possible to have a message tag for each field, and
> additional the messages stuff. Ok, this usecase maybe not really
> useful :)
>
> > This is exactly what happens now, the span will be rendered no matter what,
> > but you must use the s:message tag (which is the new HtmlMessageTag you are
> > referring to) because it sets the id on the span. It sets the id so that
> > the client side javascript knows what span to show the error message in.
> > The examples in inputAjax.jsp show this error handling in action.
>
> Sure, you are right. But if we add a new attribute to the t:message
> and t:messages components, which do exactly these things, there is no
> need for an additional tag and an additional renderer.
>
> > The javascript definitely needs to be cleaned up, most of it could be put
> > into a an external js file. I have been meaning to do that (i have a todo
> > in the code somewhere about that), but this Maven thing has put a dent in my
> > plans... ;)
>
> It seems you are really overhelmed with work, so I will do this issue for you :)
>
> > The javascript needs to be somewhere, if not on the ajax end, then it has to
> > be on the component end. It seems to me it should stay on the ajax side of
> > things, so the message tag remains a simple dumb component that isn't tied
> > to ajax.
>
> I agree. Ajax stuff should be not tied to the messag tag.
>
> > The new tag is required as I explained above because it needs to set the id.
>
> Yes, definitely required. But maybe added to t:message and t:messages.
> See above.
>
> Seems that we really have a great component out there :)
>
> regards,
>
> Gerald
>
> --
> Gerald Muellan
> Schelleingasse 2/11
> 1040 Vienna, Austria
> 0043 699 11772506
> Bierbrauen@gmail.com
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: Some thoughts about HtmlInputTextAjax component
Posted by Gerald Müllan <bi...@gmail.com>.
Hi Travis,
> Not sure what you mean here?
Currently there is one message tag for each input ajax field. This can
be reduced now to one messages tag for all the input ajax fields on
the site.
So, if there are three input fields, you can define for example one
div element (with nice style), embedded the messages tag. Each time an
error occurs in one of the ajax fields, the error message is displayed
in this area.
If you do not correct the errors in, all the fields, three messages
are shown there.
However, it is also possible to have a message tag for each field, and
additional the messages stuff. Ok, this usecase maybe not really
useful :)
> This is exactly what happens now, the span will be rendered no matter what,
> but you must use the s:message tag (which is the new HtmlMessageTag you are
> referring to) because it sets the id on the span. It sets the id so that
> the client side javascript knows what span to show the error message in.
> The examples in inputAjax.jsp show this error handling in action.
Sure, you are right. But if we add a new attribute to the t:message
and t:messages components, which do exactly these things, there is no
need for an additional tag and an additional renderer.
> The javascript definitely needs to be cleaned up, most of it could be put
> into a an external js file. I have been meaning to do that (i have a todo
> in the code somewhere about that), but this Maven thing has put a dent in my
> plans... ;)
It seems you are really overhelmed with work, so I will do this issue for you :)
> The javascript needs to be somewhere, if not on the ajax end, then it has to
> be on the component end. It seems to me it should stay on the ajax side of
> things, so the message tag remains a simple dumb component that isn't tied
> to ajax.
I agree. Ajax stuff should be not tied to the messag tag.
> The new tag is required as I explained above because it needs to set the id.
Yes, definitely required. But maybe added to t:message and t:messages.
See above.
Seems that we really have a great component out there :)
regards,
Gerald
--
Gerald Muellan
Schelleingasse 2/11
1040 Vienna, Austria
0043 699 11772506
Bierbrauen@gmail.com
Re: Some thoughts about HtmlInputTextAjax component
Posted by Travis Reeder <tr...@gmail.com>.
Hi Gerald,
Responses inline:
On 2/7/06, Gerald Müllan <bi...@gmail.com> wrote:
>
> Hi *,
>
> I have tried to add some new features to the HtmlInputTextAjax
> component, contributed by travis.
>
> He did great work, but there are still some open thoughts I would like
> to discuss over the list.
>
> In short, added features are:
>
> -) highlighting the input fields with a given style after a validation
> error has occured
This would be a great feature.
-) possibility of displaying error messages of all ajax input fields
> on one site in a central place
Not sure what you mean here?
-) displaying the messages over t:message and t:messages, via a new
> attribute forceRenderSpan, which renders a span out, even if there is
> no message getting through via a "normal" jsf processing.
This is exactly what happens now, the span will be rendered no matter what,
but you must use the s:message tag (which is the new HtmlMessageTag you are
referring to) because it sets the id on the span. It sets the id so that
the client side javascript knows what span to show the error message in.
The examples in inputAjax.jsp show this error handling in action.
While trying to implement these new enhancements it was really hard to
> get along with the high amount of legacy JavaScript code in the
> AjaxRendererUtils class.
However, it may also be difficult for others to maintain it in the
> future, so swapping some JavaScript fragments out, sounds like a good
> idea to me, right?
The javascript definitely needs to be cleaned up, most of it could be put
into a an external js file. I have been meaning to do that (i have a todo
in the code somewhere about that), but this Maven thing has put a dent in my
plans... ;)
We can do this by introducing a utility class, or just throw the whole
> thing away :)
>
> I have discussed this issue with Martin; Why displaying an error
> message via the whole JavaScript processing on client? Just render it
> out with some enhancements to the message components.
> So we could save a lot of JavaScript code and it is not a need to do
> so much client side things. For highlighting the fields, a little bit
> JavaScript is still necessary.
The javascript needs to be somewhere, if not on the ajax end, then it has to
be on the component end. It seems to me it should stay on the ajax side of
things, so the message tag remains a simple dumb component that isn't tied
to ajax.
Any drawbacks, issues we have not thought about?
>
> Furthermore, Travis has introduced a own HtmlMessageTag and Renderer
> in order to put the error message in the span over JavaScript. Is this
> approach necessary? Adding new attributes to the message comps sounds
> more preferable to me.
>
The new tag is required as I explained above because it needs to set the
id.
@Werner; Any idea how the dojo library comes along with this ajax
> validation stuff?
>
> regards,
>
> Gerald <Bi...@gmail.com>
>