Hey good news.
The converter now works fine for me.
I am going to write a patch for tomahawk but I think someone who has more
knowlege about tomahawk should look over the code because I think that I
have code in there which does not fit in your convention.
Where can I post some of my code?
Hmm... I ran into troubles again.
The method getValueBinding(...) is not available in the converter-class. So
I can't get the expression-strings.
An alternative would be to save the expressions in the converter but I think
that would be only a quick-and-dirty solution.
Do you have an other
True, you'll need to copy these methods into your Converter (or base
converter) class.
I did the same thing in Tomahawk for validators, and that's the best
model to use as an example.
org.apache.myfaces.validator.ValidatorBase
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
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
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
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
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
Thank you for your suggestion, I will try that.
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.
Hmm. Not much to see here.
However, it looks like
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
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
Can you post a stack trace from when getDateString() is called?
Perhaps the converter is caching the value during component tree build
time or being called when the table row index is not set.
On 6/2/07, Daniel Herb [EMAIL PROTECTED] wrote:
After some further testing I am relative sure that
Hi ,
thank you for answering.
Mike Kienenberger wrote:
Can you post a stack trace from when getDateString() is called?
But the problem is that getDateString() is not called, so I can't make a
stacktrace.
As written in my last post the getDateString method can't be resolved by the
I wasn't clear (or wasn't reading your post closely enough).
Post the stack track for the execution of the following call:
Further you can set a breakpoint to the line 197 in the file
org.apache.myfaces.shared_impl.taglib.core.ConvertDateTimeTagBase.class.
- This
Thank you for your fast replying.
Maybe a dumb question but how can I make a stacktrace without the
write-privilege in the tomahawk? I thought can copy the source-code directly
in my project but something seems to be wrong.
Is there an easy way to do a stacktrace within tomahawk?
Mike
In Eclipse, if you're stopped at a breakpoint, you can then copy the
stack trace from the debug view. I'm not sure how it works in other
IDEs, but that's probably your best bet.
I suppose the other quick-fix would be to change the EL expression to
#{someBean.property} and simply have that bean
ConvertDateTimeTagBase.setConverterType(FacesContext, DateTimeConverter,
String) line: 206
ConvertDateTimeTag(ConvertDateTimeTagBase).createConverter() line: 89
ConvertDateTimeTag(ConverterTag).doStartTag() line: 66
columnsTest.jsp line: 12
After some further testing I am relative sure that is it a bug from myfaces.
I hope with this post I can clearly descibe the problem.
I have set up a complete fresh
System:
- Tomcat 5.0.28
- MyFaces/Tomahawk 1.1.5
Bugdescription:
The getter of the Attribute date is not called by the
You are correct. That was a typing error from me when writing the bug. I have
entered the correct code below - unfortuntale the problem is still the same.
We havce also discovered that the problem - the getter is not called -
exists with all the tags from the JSF Core taglib.
The timeZone and
) View
this message in context: Possible bug in the columns tag with the
convertDateTime tag Sent from the My Faces - Dev mailing list archive at
Nabble.com.
View this message in context: Re: Possible bug in the columns tag with the
convertDateTime tag
Sent
: Re: Possible bug in the columns tag with the convertDateTime tag
Sent from the My Faces - Dev mailing list archive at Nabble.com.
View this message in context: Re: Possible bug in the columns tag with the
convertDateTime tag
Sent from the My Faces - Dev
: Possible bug in the columns tag with the
convertDateTime tag Sent from the My Faces - Dev mailing list archive
at
Nabble.com.
View this message in context: Re: Possible bug in the columns tag with
the
convertDateTime tag
Sent from the My Faces - Dev
) View
this message in context: Possible bug in the columns tag with the
convertDateTime tag Sent from the My Faces - Dev mailing list archive
at
Nabble.com.
View this message in context: Re: Possible bug in the columns tag with
the
convertDateTime tag
Sent from
will be
displayed) View
this message in context: Possible bug in the columns tag with the
convertDateTime tag Sent from the My Faces - Dev mailing list archive at
Nabble.com.
View this message in context: Re: Possible bug
bug in the columns tag with the
convertDateTime tag Sent from the My Faces - Dev mailing list archive at
Nabble.com.
View this message in context: Re: Possible bug in the columns tag with the
convertDateTime tag
Sent from the My Faces - Dev mailing
) View
this message in context: Possible bug in the columns tag with the
convertDateTime tag Sent from the My Faces - Dev mailing list archive
at
Nabble.com.
View this message in context: Re: Possible bug in the columns tag
What you posted isn't valid:
You have:
t:outputText ... / -- should be '' not '/'
f:convert.../
/t:outputText
I could see how that might cause this tag to be ignored, provided it
was parsed at all.
On 5/31/07, Johnny Sutherland [EMAIL PROTECTED] wrote:
The timeZone and pattern values
27 matches
Mail list logo
