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.
