Responses inline:
On 2/7/06, Gerald Müllan <
[EMAIL PROTECTED]> wrote:
This would be a great feature.
Not sure what you mean here?
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.
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... ;)
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.
The new tag is required as I explained above because it needs to set the id.
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
