A new approach to JSF error handling
Key: TOMAHAWK-1139
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1139
Project: MyFaces Tomahawk
Issue Type: Improvement
Reporter: Val Blant
I
a literal, an el expression or via
an id of another ValueHolder. All of these work in data tables.
I will describe how it works in the following comment.
A new approach to JSF error handling
Key: TOMAHAWK-1139
URL: https
/i1259467_Example4.png
A new approach to JSF error handling
Key: TOMAHAWK-1139
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1139
Project: MyFaces Tomahawk
Issue Type: Improvement
Reporter
the same as the snippet shown above, but the inputText
component is referencing a text box, so the label text is going to be whatever
the user types into the text box:
http://www.imagehosting.com/out.php/i1259467_Example4.png
A new approach to JSF error handling
Hmm. I honestly don't remember calling saveAttachedState() -- maybe
that was my problem :-) Good to know for the future if it ever comes
up again.
You can create a JIRA issue for it at any time. Just open it under
TOMAHAWK and set it to NEW COMPONENT. If we decide to make a COMMONS
or
Hi Val,
I was just referring to your code snippet, which didn't show you were
using Tomahawk. So you don't want to change JSF
error-message-handling, but Tomahawk message-handling?
regards,
Martin
On 10/19/07, Val [EMAIL PROTECTED] wrote:
Yes, I am using tomahawk 1.1.2. Specifically, I use
Hi, Martin.
The change I am proposing is completely independent from Tomahawk. Since
the message decoration happens in the wrapper converter/validator, we
get to decorate any JSF message with or without Tomahawk. In fact, this
should work with any bare JSF implementation and it supersedes
It would definitely be a Tomahawk thing rather than a MyFaces Core change.
I haven't looked at your architecture in detail, but trying to wrap a
validator or converter is problematic, at least under JSF 1.1 + jsp.
It will probably work for JSF 1.2 or JSF 1.1 with facelets, though, if
I remember
On 10/24/07, Val [EMAIL PROTECTED] wrote:
I handled the addition of a converter or validators into the wrapper by
having my custom tag push a dummy UIInput tag onto the tag stack that
UIComponentTag uses and then having the wrapped converter/validators set
themselves up in the dummy component
Well, it's been two-and-a-half years, but I seem to remember the
problem was that under JSF 1.1 + jsp, the converters and validators
are created from scratch every request rather than restored using the
JSF state-saving mechanism. So all of the values set on the
converters/validators would
hi, in recent time, i needed, that the error message of the component was
more explicit, i thing that will good, that was a html-popup or alert
javascript, with the mesagge and the focus in the first elemnt with the
problem, also the style of the component change. i wait that this are the
theme of
Yes, but your wrapping validator doesn't have the ability to save the
state of the wrapped validator, does it? Sorry. I really don't
remember the details, but I would expect Myfaces 1.1.x to still have
the same problem. Perhaps we were just doing it wrong back then,
though :-)
The process
Yes, but your wrapping validator doesn't have the ability to save the
state of the wrapped validator, does it?
All I needed to do here was make my wrapping validator a StateHolder and
call saveAttachedState() on the wrapped validators. So everything is
saved and restored properly this way.
You are not reinventing the wheel - first, are you using tomahawk?
Cause if you use the standard-components you said you use, I wonder
why you get this error-handling at all, you should only see the client
id, so like this:
'firstName': is required
regards,
Martin
On 10/18/07, Val [EMAIL
14 matches
Mail list logo
