If you really want to thank me,
1) Provide patches when you've got this all worked out
2) Create a wiki page on adding new value-binding attribute methods to
existing components/converters/validators, clean up the email I sent
out, and stuff it into the wiki page.
:-)
On 6/7/07, Daniel Herb <[EMAIL PROTECTED]> wrote:
Wow, thank you very much for your last post.
After I read the post I really think that it will be easy to patch.
I will try that as soon as possible.
Hopefully that I will not ask you again about that problem :)
Thank you for your help.
Mike Kienenberger wrote:
>
> 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.
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/Possible-bug-in-the-columns-tag-with-the-convertDateTime-tag-tf3845423.html#a11016632
Sent from the My Faces - Dev mailing list archive at Nabble.com.
