Re: [VOTE] Release Tobago 1.0.15

The vote has passed with the following votes: +1 lofwyr (binding) grantsmith (binding) bommel (binding) idus -1 weber (binding) I will proceed with the next steps. Regards Bernd Bernd Bohmann schrieb: Hello, I would like to release Tobago 1.0.15, This release contains only 11

[orchestra] conversation-scoped converters

Hi, Currently in Orchestra a lot of effort goes into allowing this: someComponent id=comp1 value= f:converter id=convId/ /someComponent where the actual converter instance attached to comp1 is pulled from Spring. In particular, this is AFAIK the only reason why class

[jira] Commented: (TRINIDAD-885) Provide selector to show navigation bar on bottom of table

[ https://issues.apache.org/jira/browse/TRINIDAD-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12569566#action_12569566 ] Stephen Friedrich commented on TRINIDAD-885: Also a problem for me. I have to

[jira] Commented: (TRINIDAD-944) Improvement of table skinning (skinning the sorted column)

[ https://issues.apache.org/jira/browse/TRINIDAD-944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12569567#action_12569567 ] Stephen Friedrich commented on TRINIDAD-944: Also: Sort icon position (in

Re: [orchestra] conversation-scoped converters

Hi! It *is* useful to be able to create converters that have access to conversation scopes, which in turn mean they need to be instantiated by pulling them from Spring. But this syntax is already supported by jsf: someComponent id=comp2 converter=#{convId}/ I don't think so. Isnt it that the

[jira] Created: (MYFACES-1820) Infinite loop can occur when custom FacesContext subclass compiled against JSF1.1 but used with JSF1.2

Infinite loop can occur when custom FacesContext subclass compiled against JSF1.1 but used with JSF1.2 -- Key: MYFACES-1820 URL:

Re: [orchestra] conversation-scoped converters

Hi Mario, Nice to see you back! On Sat, 2008-02-16 at 16:37 +0100, Mario Ivankovits wrote: Hi! It *is* useful to be able to create converters that have access to conversation scopes, which in turn mean they need to be instantiated by pulling them from Spring. But this syntax is already

Re: [orchestra] conversation-scoped converters

Hi! Nice to see you back! Hehe - Thanks! Yea, and in after-ski-mode now ;-) Nope. The EL expression returns a Converter instance ah - wasn't aware from top of my head. Ok, so probably the ony thing we have to take a look at is how those converters work installed as child of a component using

Re: [orchestra] conversation-scoped converters

On Sat, 2008-02-16 at 18:10 +0100, Mario Ivankovits wrote: Hi! Nice to see you back! Hehe - Thanks! Yea, and in after-ski-mode now ;-) Go on, rub it in .. I've been spending all my spare time working on an Orchestra release :-) Nope. The EL expression returns a Converter instance

Result: [VOTE] start trinidad sandbox on trunk and trunk 1.2.x

Ok we have 4 +1 Andrew Robinson Bruno Aranda Matthias Wessendorf Leonardo Uribe So I will commit what I have now regards Leonardo Uribe

Re: [orchestra] conversation-scoped converters

Hi! Go on, rub it in .. I've been spending all my spare time working on an Orchestra release :-) That's fun too, isn't it ;-) If we find a way how these could work I wouldn't mind if we get rid of the current solution. Your wish is my command. When thinking about it, this one wasn't

[jira] Created: (TOMAHAWK-1198) submit a t:datatable accurred NullPointerException In org.apache.myfaces.component.html.ext.HtmlDataTable.updateModelFromPreservedDataModel

submit a t:datatable accurred NullPointerException In org.apache.myfaces.component.html.ext.HtmlDataTable.updateModelFromPreservedDataModel ---