a faces converter (there both of us agree) is something that converts between a string and the backing bean value back and forth, now you want to have an additional converter which will convert between the converted value and the backing bean?
The thing is that internally the renderer will need to know that it is working on a date, and how is it supposed to know anything about Joda if the classes are not available?
it still sounds a little bit flurry to me... why don't you implement a suggestion, and I would say you rather go with b (less intrusion), and we will see how we like it afterwards?
regards,
Martin
On 8/3/05, Mario Ivankovits <[EMAIL PROTECTED]> wrote:
Martin Marinschek wrote:
> You know that there is something like a converter tag already in JSF,
> right?
Sure, I know. And it is sufficient during setting the value, a custom
converter to convert the string to joda-time do the job, ...
>
> what would your variant b be different from that?
... but during getting the value the HtmlCalendarRenderer.encodeEnd uses
RendererUtils.getDateValue() which requires the valueHolder to provide a
java.util.Date.
Now the inputCalendar need to now how to convert from this class to
java.util.Date.
Or at least it need to know how to get the needed informations out of
the object.
Another solution could be to add (beside the joda-converter) a
valueInterpreter="" attribute to inputCalendar which provides a class to
get the needed informations out of the whatever-date object.
Those methods called on timeKeeper in HtmlCalendarRenderer should then
be routed through this "Interpreter" (better name is welcome). If no
inpterpreter was set the default is used which is able to deal with
java.util.Date.
---
Mario
