No, you don't need to add any encode methods.
Let's take convertDateTime type as an example. Note that this one is
a little trickier than most since the default value isn't null -- the
default is Type.DATE.getName() so we can't simply call the
super.getType() method. We'll also have to create our own local
storage for type.
1) Make a subclass of javax.faces.convert.DateTimeConverter (or copy it).
2) Create "protected String localType;"
3) Create String accessors for type. These already exist in the
superclass for this attribute, so we will just override them below.
4) public String getType() would be changed to this:
public String getType() {
if (localType != null) return localType;
ValueBinding vb = getValueBinding("type");
String evaluatedType = vb != null ?
org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils.getStringValue(getFacesContext(),
vb) : null;
if (null == evaluatedType) evaluatedType = Type.DATE.getName();
}
5) public void setType() would be changed to this:
public void setType(String message) {
localType = message;
}
6) since we created our own variable, we'll need to deal with state saving.
// STATE SAVE/RESTORE
public void restoreState(FacesContext facesContext, Object state) {
Object[] values = (Object[]) state;
super.restoreState(facesContext, values[0]);
_type = (String) values[1];
}
public Object saveState(FacesContext facesContext) {
Object[] values = new Object[2];
values[0] = super.saveState(facesContext);
values[1] = localType;
return values;
}
Fortunately, the superclass never refers to _type directly, so the
converter is finished at this point. If it did, we'd have been better
off copying the source code of the original rather than subclassing.
Next you'll need to register the converter in faces-config. Left as
an exercise to the reader.
If you're using facelets, all you have to do is create a taglib entry
at this point. Left as an exercise to the reader.
If you're using jsp, you need to create a tag handler.
1) Make a subclass of
org.apache.myfaces.shared_tomahawk.taglib.core.ConvertDateTimeTagBase
(or copy it).
2) Create "protected String localType;"
3) Create setType to use our type instead of inaccessible private _type.
public void setType(String type)
{
localType = type;
}
4) Extend createConverter to use our type instead of private _type.
protected Converter createConverter() throws JspException
{
DateTimeConverter converter =
(DateTimeConverter)super.createConverter();
FacesContext facesContext = FacesContext.getCurrentInstance();
if (localType != null)
{
if (UIComponentTag.isValueReference(localType))
{
ValueBinding vb =
facesContext.getApplication().createValueBinding(localType);
converter.setValueBinding("type",vb);
}
else
{
converter.setType(localType);
}
}
return converter;
}
5) extend release
public void release()
{
super.release();
localType= null;
}
6) Somehow define your converter id -- I'm not a jsp user so I can't
say for sure if this is the best way to do it, but this is how it's
done for the default DateTimeConverter.
public void setPageContext(PageContext context)
{
super.setPageContext(context);
setConverterId(YOUR_CONVERTER_ID);
}
7) Create a tld entry? Left as an exercise for the reader.
For converters, it may also be possible to simply override the default
date time registered converter which might make tld/faces-config setup
and using the converter in the page a bit easier.
That should be it -- I cut and pasted the various pieces out of the
Tomahawk source code, so it's likely there are syntax errors and
possibly some other things I've overlooked. However, it should give
you the general process you need to follow in order to write your own
converter and show you what steps you need to take for each attribute
to convert the remaining ones. For String-typed attributes that
don't provide a non-null default (it looks like only "pattern" falls
into this category), you can simply call super.getPattern() and
super.setPattern() instead of creating localPattern variable.
Probably not worthwhile in this case -- I'd just create local
variables for all of them to be consistent.
On 6/6/07, Daniel Herb <[EMAIL PROTECTED]> wrote:
Okay I opened up a a report.
Currently I am trying to do the change by myself but it seems that I have
not enought experience with jsf-tag-development.
If I understood you right, I have to extend the ConvertDateTimeTag-Class and
add a encodeBegin-method wherein the values are resolved over value binding.
My Problem is that the ConvertDateTimeTag is normally not rendered so I
can't override the encodeBegin-method.
Sorry for all that questions but because of this problem we are currently
stucked.
Mike Kienenberger wrote:
>
> Yep. Just open a JIRA issue and provide them, using unified diff
> format for changes to existing files. (You can drop the new files in
> as is although having them in the diff format will make it slightly
> easier to apply the patch).
>
> On 6/5/07, Daniel Herb <[EMAIL PROTECTED]> wrote:
>>
>>
>> Mike Kienenberger wrote:
>> >
>> > Converters that evaluate at rendertime would be an excellent addition
>> > to Tomahawk. I don't currently see any Tomahawk equivalents of the
>> > existing converters.
>> >
>> Do you mean the existing converters? If so, that would be really nice.
>> I had a likewise problem in the same project and had to do a workaround
>> for
>> it.
>> I am wondering why nobody else had a problem like that.
>>
>> Thank you for your help.
>>
>>
>> Mike Kienenberger wrote:
>> >
>> > Hmm. Not much to see here.
>> >
>> > However, it looks like the converter type is being set at component
>> > tree build time rather than render type.
>> >
>> > So there is no data table row active at this point, and thus no
>> variable.
>> >
>> > Looking at ConvertDateTimeTagBase, I see that the value binding is
>> > evaluated at converter creation time rather than converter-use time.
>> >
>> > Same for timezone, pattern and everything else.
>> >
>> > I'd say that's a bad design since we evaluate value bindings during
>> > rendering for everything else.
>> >
>> > Unfortunately, this design is part of the JSF spec.
>> >
>> > http://java.sun.com/javaee/javaserverfaces/1.1_01/docs/api/
>> >
>> > If it were me, I'd write my own converter. All you need to do is to
>> > change the converter to take value bindings instead of evaluated value
>> > binding results, and change the getters to return the evaluated value
>> > bindings. In fact, you can simply extend the existing converter to
>> > add some set*ValueBinding() methods, and then, if the value binding
>> > exists, evaluate it instead of using the constant object.
>> >
>> > For the end user of the final tag, there shouldn't be any difference
>> > -- the difference would only show up at the java code level.
>> >
>> > Converters that evaluate at rendertime would be an excellent addition
>> > to Tomahawk. I don't currently see any Tomahawk equivalents of the
>> > existing converters.
>> >
>> > On 6/5/07, Daniel Herb <[EMAIL PROTECTED]> wrote:
>> >>
>> >> ConvertDateTimeTagBase.setConverterType(FacesContext,
>> >> DateTimeConverter,
>> >> String) line: 206
>> >> ConvertDateTimeTag(ConvertDateTimeTagBase).createConverter()
>> >> line: 89
>> >> ConvertDateTimeTag(ConverterTag).doStartTag() line: 66
>> >> columnsTest.jsp line: 12
>> >> columnsTest.jsp line: not available
>> >> columnsTest.jsp line: not available
>> >> columnsTest.jsp line: not available
>> >> columnsTest.jsp line: not available
>> >> columnsTest.jsp line: not available
>> >> columnsTest.jsp line: not available
>> >> testpage_jsp(HttpJspBase).service(HttpServletRequest,
>> >> HttpServletResponse)
>> >> line: 98
>> >> testpage_jsp(HttpServlet).service(ServletRequest,
>> >> ServletResponse) line:
>> >> 803
>> >> JspServletWrapper.service(HttpServletRequest,
>> >> HttpServletResponse, boolean)
>> >> line: 328
>> >
>> > [...]
>> >
>> >> ServletExternalContextImpl.dispatch(String) line: 419
>> >> JspTilesViewHandlerImpl.dispatch(ExternalContext, UIViewRoot,
>> >> String) line:
>> >> 236
>> >> JspTilesViewHandlerImpl.renderView(FacesContext, UIViewRoot)
>> >> line: 222
>> >> RenderResponseExecutor.execute(FacesContext) line: 41
>> >> LifecycleImpl.render(FacesContext) line: 132
>> >> FacesServlet.service(ServletRequest, ServletResponse) line:
>> 140
>> >
>> >
>>
>> --
>> View this message in context:
>>
http://www.nabble.com/Possible-bug-in-the-columns-tag-with-the-convertDateTime-tag-tf3845423.html#a10972746
>> Sent from the My Faces - Dev mailing list archive at Nabble.com.
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/Possible-bug-in-the-columns-tag-with-the-convertDateTime-tag-tf3845423.html#a10984918
Sent from the My Faces - Dev mailing list archive at Nabble.com.
