Re: [Myfaces Wiki] Update of JSF and MVC by SimonKitching
Hi! I don't think this will be controversial - I find it a rather good basic introduction to the concepts behind JSF, actually. I too think that this is a good introduction for any newbie. Something you'll normally read in a book but now public for everyone. Ciao, Mario regards, Martin On Wed, Feb 6, 2008 at 12:03 AM, Matthias Wessendorf [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: haha :) On Feb 5, 2008 10:37 PM, Andrew Robinson [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I was wondering what the purpose was. It seemed to me like the apache wiki was going to start turning into a personal blog site :) On Feb 5, 2008 1:34 PM, simon [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On Tue, 2008-02-05 at 20:31 +, Apache Wiki wrote: Dear Wiki user, You have subscribed to a wiki page or wiki category on Myfaces Wiki for change notification. The following page has been changed by SimonKitching: http://wiki.apache.org/myfaces/JSF_and_MVC I expect this page will be a little controversial :-) The main goal was to address the why doesn't it work like struts/webwork questions. But feel free to modify any bits that you don't agree with.. Regards, Simon -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- mit freundlichen Grüßen Mario Ivankovits Software Engineering OPS EDV VertriebsgesmbH A-1120 Wien, Michael-Bernhard-Gasse 10 Firmenbuch Nr.: FN51233v, Handelsgericht Wien Tel.: +43-1-8938810; Fax: +43-1-8938810/3700 http://www.ops.co.at E-Mail: [EMAIL PROTECTED] Skype: mario_ivankovits
[Jira] Question about Fix Version field
our jira instance has these fields (and more...): Fix Version/s: Affects Version/s: Both are editable by the bug filer. The Affects Version/s: makes sense, since they need to identify the broken version. Now, I have problems in understanding the Fix Version/s field. I understand it this way: -a committer fixed the problem and marks the fixed version is this field. If this is correct, why should we leave it editable by the filer ? Or is it more a I wish to have a fix for version blah ? If so, not sure if that really works well in OS culture. Would be great if someone could help me :-) -Matthias -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
[jira] Updated: (TRINIDAD-934) UIXCollection.invokeOnComponent() is not calling _flushCachedModel() because of a typo in the IF statement
[ https://issues.apache.org/jira/browse/TRINIDAD-934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Weßendorf updated TRINIDAD-934: Resolution: Fixed Fix Version/s: (was: 1.2.5-core) 1.2.6-core Status: Resolved (was: Patch Available) fixed in trunk UIXCollection.invokeOnComponent() is not calling _flushCachedModel() because of a typo in the IF statement -- Key: TRINIDAD-934 URL: https://issues.apache.org/jira/browse/TRINIDAD-934 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.2.4-core Reporter: Max Starets Priority: Critical Fix For: 1.2.6-core Attachments: trinidad-934.patch The code in the UIXCollection.invokeOnComponent() was written with the intent to call _flushCollectionModel() if it has not been already flushed for the request. _getAndMarkFirstInvokeForRequest() returns true if the model has been already flushed, so the check: if (_getAndMarkFirstInvokeForRequest(context, clientId)) should be: if (!_getAndMarkFirstInvokeForRequest(context, clientId)) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: embedded table
Hi!
Sounds good - can you send your example again utilizing the
detailStamp approach if that fits?
So, not it is getting stressy again. I have a bad need for it now.
So, using the detailStamp approach it might look like:
t:datable var=group1 value=#{bean.data}
...
t:column colspan=10
t:outputText value=#{group1.headerValue} /
/t:column
f:facet name=detailStamp
t:datable var=group2 value=#{group1.groupData} embedded=true
t:column colspan=2
t:outputText value=#{group2.headerValue2} /
/t:column
t:column colspan=8
t:outputText value=#{group2.headerValue2} /
/t:column
f:facet name=detailStamp
t:datable var=detail value=#{group2.detailData}
embedded=true
t:column
t:outputText value=#{detail.value1} /
/t:column
t:column
t:outputText value=#{detail.value10} /
/t:column
/t:datable
/f:facet
/t:datable
/f:facet
/t:datable
Additionally I'd like to introduce a headerStamp and footerStamp which
renders into the head/foot of the table (if possible) and thus allows
you to have multi-row header/footer.
Effectively these new stamps might work with an embedded datatable only
(for now).
I'll start doing so now, ok?
Ciao,
Mario
Re: [Jira] Question about Fix Version field
On Feb 6, 2008 12:01 PM, Manfred Geiler [EMAIL PROTECTED] wrote: Matze, This is a (hardcoded?) Jira feature. I don't know. There is one special issue permission in Jira that controls who is allowed to assign a fix version: Resolve Issues (Ability to resolve and reopen issues. This includes the ability to set a fix version.) Since it is necessary for the reporter to be able to reopen issues, this permission is assigned to the reporter role in the Standard Permission Scheme that MyFaces uses. I agree, that you need to reopen issues, but the Fix version/s should be only for the committer, when closing. We never have backported issues to older releases (like releasing a 1.1.4.1 of MyFaces CORE). Not sure I got you 100% ... -M --Manfred On Feb 6, 2008 10:49 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote: our jira instance has these fields (and more...): Fix Version/s: Affects Version/s: Both are editable by the bug filer. The Affects Version/s: makes sense, since they need to identify the broken version. Now, I have problems in understanding the Fix Version/s field. I understand it this way: -a committer fixed the problem and marks the fixed version is this field. If this is correct, why should we leave it editable by the filer ? Or is it more a I wish to have a fix for version blah ? If so, not sure if that really works well in OS culture. Would be great if someone could help me :-) -Matthias -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: [Jira] Question about Fix Version field
Matze, This is a (hardcoded?) Jira feature. There is one special issue permission in Jira that controls who is allowed to assign a fix version: Resolve Issues (Ability to resolve and reopen issues. This includes the ability to set a fix version.) Since it is necessary for the reporter to be able to reopen issues, this permission is assigned to the reporter role in the Standard Permission Scheme that MyFaces uses. --Manfred On Feb 6, 2008 10:49 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote: our jira instance has these fields (and more...): Fix Version/s: Affects Version/s: Both are editable by the bug filer. The Affects Version/s: makes sense, since they need to identify the broken version. Now, I have problems in understanding the Fix Version/s field. I understand it this way: -a committer fixed the problem and marks the fixed version is this field. If this is correct, why should we leave it editable by the filer ? Or is it more a I wish to have a fix for version blah ? If so, not sure if that really works well in OS culture. Would be great if someone could help me :-) -Matthias -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [Jira] Question about Fix Version field
Yes, and this is only possible by taking away the Resolve Issues permission for reporters (=issue-filers) which would also forbid the reporter to reopen an issue. Question is: do we want this. My feeling is: no, because: In a perfect world :-) the reporter downloads the fix version release as soon as it is out and tests his issue with this new release. In case the fix did not really fix the issue in question, the reporter changes the jira issue to reopened and sets the fix version field to unknown. This is the idea behind this permission, I think. --Manfred On Feb 6, 2008 12:31 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: On Feb 6, 2008 12:29 PM, Antonio Petrelli [EMAIL PROTECTED] wrote: 2008/2/6, Matthias Wessendorf [EMAIL PROTECTED]: but the Fix version/s should be only for the committer, when closing. Not only when closing. It can be used to schedule tickets. At Struts and Tiles we use this technique very frequently: at least it is useful to schedule on a branch or on the trunk. yeah, I was unclear. let's say it this way: -an issue-filer (a non-committer) should not be able to edit this field. -M Antonio -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [Jira] Question about Fix Version field
2008/2/6, Matthias Wessendorf [EMAIL PROTECTED]: but the Fix version/s should be only for the committer, when closing. Not only when closing. It can be used to schedule tickets. At Struts and Tiles we use this technique very frequently: at least it is useful to schedule on a branch or on the trunk. Antonio
Re: [Jira] Question about Fix Version field
On Feb 6, 2008 12:29 PM, Antonio Petrelli [EMAIL PROTECTED] wrote: 2008/2/6, Matthias Wessendorf [EMAIL PROTECTED]: but the Fix version/s should be only for the committer, when closing. Not only when closing. It can be used to schedule tickets. At Struts and Tiles we use this technique very frequently: at least it is useful to schedule on a branch or on the trunk. yeah, I was unclear. let's say it this way: -an issue-filer (a non-committer) should not be able to edit this field. -M Antonio -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: [Jira] Question about Fix Version field
On Feb 6, 2008 12:44 PM, Manfred Geiler [EMAIL PROTECTED] wrote: Yes, and this is only possible by taking away the Resolve Issues permission for reporters (=issue-filers) which would also forbid the reporter to reopen an issue. ah... Question is: do we want this. no :) My feeling is: no, because: In a perfect world :-) the reporter downloads the fix version release as soon as it is out and tests his issue with this new release. In case the fix did not really fix the issue in question, the reporter changes the jira issue to reopened and sets the fix version field to unknown. This is the idea behind this permission, I think. OK... so, perhaps we can try to encourage users to not use the Fix version/s field, when reporting a new bug :-) Thx, M --Manfred On Feb 6, 2008 12:31 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: On Feb 6, 2008 12:29 PM, Antonio Petrelli [EMAIL PROTECTED] wrote: 2008/2/6, Matthias Wessendorf [EMAIL PROTECTED]: but the Fix version/s should be only for the committer, when closing. Not only when closing. It can be used to schedule tickets. At Struts and Tiles we use this technique very frequently: at least it is useful to schedule on a branch or on the trunk. yeah, I was unclear. let's say it this way: -an issue-filer (a non-committer) should not be able to edit this field. -M Antonio -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
[jira] Created: (ORCHESTRA-15) Orchestra in Portal Environment
Orchestra in Portal Environment --- Key: ORCHESTRA-15 URL: https://issues.apache.org/jira/browse/ORCHESTRA-15 Project: MyFaces Orchestra Issue Type: Bug Affects Versions: 1.0 Environment: myfaces1.1.5, liferay portal4.3.3, orchestra-core1.0, tomcat 5.5 Reporter: Rashmi Priority: Blocker In the portlet environment ConversationManager is not getting initialized. The FrameworkAdapter.getCurrentInstance() is as well NULL. The part of the exception is as follows: Caused by: java.lang.NullPointerException at org.apache.myfaces.orchestra.conversation.ConversationManager.getInstance(ConversationManager.java:90) at org.apache.myfaces.orchestra.conversation.ConversationManager.getInstance(ConversationManager.java:76) at org.apache.myfaces.orchestra.conversation.spring.AbstractSpringOrchestraScope.getBean(AbstractSpringOrchestraScope.java:125) at org.apache.myfaces.orchestra.conversation.spring.AbstractSpringOrchestraScope.get(AbstractSpringOrchestraScope.java:117) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:285) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:160) at org.springframework.aop.target.SimpleBeanTargetSource.getTarget(SimpleBeanTargetSource.java:33) at org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.getTarget(Cglib2AopProxy.java:661) at org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.intercept(Cglib2AopProxy.java:611) at de.seat.mitarbeiterinfo.view.mitarbeiterlist$$EnhancerByCGLIB$$4f90561b.getMitarbeiterListModel(generated) ... 125 more The filter is not working as expected in Portlet environment but works perfetly well in norman Servlet container. Can myfaces-portlet-bridge be used in someway to configure the filter to run in portlet environment? Thanks and Regards, Rashmi -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: embedded table
Sounds good!
regards,
Martin
On 2/6/08, Mario Ivankovits [EMAIL PROTECTED] wrote:
Hi!
Sounds good - can you send your example again utilizing the
detailStamp approach if that fits?
So, not it is getting stressy again. I have a bad need for it now.
So, using the detailStamp approach it might look like:
t:datable var=group1 value=#{bean.data}
...
t:column colspan=10
t:outputText value=#{group1.headerValue} /
/t:column
f:facet name=detailStamp
t:datable var=group2 value=#{group1.groupData} embedded=true
t:column colspan=2
t:outputText value=#{group2.headerValue2} /
/t:column
t:column colspan=8
t:outputText value=#{group2.headerValue2} /
/t:column
f:facet name=detailStamp
t:datable var=detail value=#{group2.detailData}
embedded=true
t:column
t:outputText value=#{detail.value1} /
/t:column
t:column
t:outputText value=#{detail.value10} /
/t:column
/t:datable
/f:facet
/t:datable
/f:facet
/t:datable
Additionally I'd like to introduce a headerStamp and footerStamp which
renders into the head/foot of the table (if possible) and thus allows
you to have multi-row header/footer.
Effectively these new stamps might work with an embedded datatable only
(for now).
I'll start doing so now, ok?
Ciao,
Mario
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
[jira] Created: (TRINIDAD-938) panelBox is inside of panelHorizontalLayout with valign=top halign=end does not render correctly.
panelBox is inside of panelHorizontalLayout with valign=top halign=end does not render correctly. - Key: TRINIDAD-938 URL: https://issues.apache.org/jira/browse/TRINIDAD-938 Project: MyFaces Trinidad Issue Type: Bug Components: Skinning Affects Versions: 1.2.5-core Reporter: Sandy Schaffner Priority: Minor When panelBox is inside of panelHorizontalLayout with valign=top halign=end, the panelBox does not render correctly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-939) shortcut links in Skinning document do not work.
shortcut links in Skinning document do not work. Key: TRINIDAD-939 URL: https://issues.apache.org/jira/browse/TRINIDAD-939 Project: MyFaces Trinidad Issue Type: Bug Components: Documentation Affects Versions: 1.2.5-core Reporter: Jeanne Waldman Priority: Minor The skinning doc's table of contents links do not work. http://myfaces.apache.org/trinidad/devguide/skinning.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-939) shortcut links in Skinning document do not work.
[ https://issues.apache.org/jira/browse/TRINIDAD-939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12566276#action_12566276 ] Jeanne Waldman commented on TRINIDAD-939: - in other words, clicking on them does nothing. shortcut links in Skinning document do not work. Key: TRINIDAD-939 URL: https://issues.apache.org/jira/browse/TRINIDAD-939 Project: MyFaces Trinidad Issue Type: Bug Components: Documentation Affects Versions: 1.2.5-core Reporter: Jeanne Waldman Priority: Minor The skinning doc's table of contents links do not work. http://myfaces.apache.org/trinidad/devguide/skinning.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-1181) allow to embed a datatable within the parent
[ https://issues.apache.org/jira/browse/TOMAHAWK-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12566287#action_12566287 ] Mario Ivankovits commented on TOMAHAWK-1181: Three new attribute on the datatable have been added: embedded true|false Render the table in the embedded mode (no table/thead/tfoot/th tags will be used) detailStampLocation after|before Render the detailStamp after of before the row of the master table. before allow you to treat the master table as a list of summs of the child tables data. detailStampExpandedDefault true|false Render all the details by default. No further special header handling for now, lets have a look if this is enough for now. allow to embed a datatable within the parent Key: TOMAHAWK-1181 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1181 Project: MyFaces Tomahawk Issue Type: New Feature Components: Extended Datatable Reporter: Mario Ivankovits Fix For: 1.1.7-SNAPSHOT As discussed in this thread http://marc.info/?l=myfaces-devm=120118289000330w=2 add a new attribute to the datatable which allows to reuse the layout of the parent table. The attribute name so far is embed=true|false where false is the default. When embed=true: * avoid rendering the table start/end tag * do not add the thead/tfoot tags around the header or footer - instead simply render them at the start/end of the embedded table * do not render the header cells using the th tag Probably we have to think about another way how to define the header on the parent datatable. Not sure about that yet. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TOMAHAWK-1181) allow to embed a datatable within the parent
[ https://issues.apache.org/jira/browse/TOMAHAWK-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivankovits resolved TOMAHAWK-1181. Resolution: Fixed Fix Version/s: 1.1.7-SNAPSHOT Assignee: Mario Ivankovits allow to embed a datatable within the parent Key: TOMAHAWK-1181 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1181 Project: MyFaces Tomahawk Issue Type: New Feature Components: Extended Datatable Reporter: Mario Ivankovits Assignee: Mario Ivankovits Fix For: 1.1.7-SNAPSHOT As discussed in this thread http://marc.info/?l=myfaces-devm=120118289000330w=2 add a new attribute to the datatable which allows to reuse the layout of the parent table. The attribute name so far is embed=true|false where false is the default. When embed=true: * avoid rendering the table start/end tag * do not add the thead/tfoot tags around the header or footer - instead simply render them at the start/end of the embedded table * do not render the header cells using the th tag Probably we have to think about another way how to define the header on the parent datatable. Not sure about that yet. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TOMAHAWK-1187) submitOnEvent callback can not bind to bean method
[
https://issues.apache.org/jira/browse/TOMAHAWK-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Marinschek resolved TOMAHAWK-1187.
-
Resolution: Fixed
Fix Version/s: 1.1.7-SNAPSHOT
Assignee: Martin Marinschek
Bug is fixed - but the rendered-property should already have worked for this
component. For your suggestion: please open a separate improvement request for
this.
regards,
Martin
submitOnEvent callback can not bind to bean method
--
Key: TOMAHAWK-1187
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1187
Project: MyFaces Tomahawk
Issue Type: Bug
Components: submitOnEvent
Reporter: Dave
Assignee: Martin Marinschek
Fix For: 1.1.7-SNAPSHOT
callback=#{bean.submit? \func1\ : \ func2\}
The bean method is not called, and the callback is always func2.
Suggest onsubmit that takes javascript code (return true or false)
true -- submit (click the link/button)
false -- do not submit
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [continuum] BUILD FAILURE: Apache MyFaces Trinidad
hrm. on my box it works (sure the mentioned commit isn't related to the failure, but wondering if someone else is seeing this too) -M On Feb 6, 0008 9:15 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Online report : http://myfaces.zones.apache.org:8080/continuum/buildResult.action?buildId=6299projectId=48 Build statistics: State: Failed Previous State: Error Started at: Wed 6 Feb 2008 20:13:12 + Finished at: Wed 6 Feb 2008 20:14:53 + Total time: 1m 41s Build Trigger: Schedule Build Number: 71 Exit code: 1 Building machine hostname: myfaces.zones.apache.org Operating system : SunOS(unknown) Java Home version : java version 1.5.0_13 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05) Java HotSpot(TM) Server VM (build 1.5.0_13-b05, mixed mode) Builder version : Maven version: 2.0.8 Java version: 1.5.0_13 OS name: sunos version: 5.10 arch: x86 Family: unix SCM Changes: Changed: matzew @ Wed 6 Feb 2008 18:28:21 + Comment: TRINIDAD-918 Files changed: /myfaces/trinidad/trunk/trinidad-examples/trinidad-demo/src/main/webapp/WEB-INF/trinidad-skins.xml ( 619096 ) /myfaces/trinidad/trunk/trinidad-examples/trinidad-demo/src/main/webapp/skins/suede ( 619096 ) /myfaces/trinidad/trunk/trinidad-examples/trinidad-demo/src/main/webapp/skins/suede/images ( 619096 ) /myfaces/trinidad/trunk/trinidad-examples/trinidad-demo/src/main/webapp/skins/suede/images/asort.gif ( 619096 ) /myfaces/trinidad/trunk/trinidad-examples/trinidad-demo/src/main/webapp/skins/suede/images/bltdscn.gif ( 619096 ) /myfaces/trinidad/trunk/trinidad-examples/trinidad-demo/src/main/webapp/skins/suede/images/bltdscs.gif ( 619096 ) /myfaces/trinidad/trunk/trinidad-examples/trinidad-demo/src/main/webapp/skins/suede/images/cccdts.gif ( 619096 ) /myfaces/trinidad/trunk/trinidad-examples/trinidad-demo/src/main/webapp/skins/suede/images/ccclts.gif ( 619096 ) /myfaces/trinidad/trunk/trinidad-examples/trinidad-demo/src/main/webapp/skins/suede/images/cccmts.gif ( 619096 ) /myfaces/trinidad/trunk/trinidad-examples/trinidad-demo/src/main/webapp/skins/suede/images/ccctts.gif ( 619096 ) /myfaces/trinidad/trunk/trinidad-examples/trinidad-demo/src/main/webapp/skins/suede/images/cfso.gif ( 619096 ) /myfaces/trinidad/trunk/trinidad-examples/trinidad-demo/src/main/webapp/skins/suede/images/cseparator.gif ( 619096 ) /myfaces/trinidad/trunk/trinidad-examples/trinidad-demo/src/main/webapp/skins/suede/images/cseparator4x.gif ( 619096 ) /myfaces/trinidad/trunk/trinidad-examples/trinidad-demo/src/main/webapp/skins/suede/images/csnb.gif ( 619096 ) /myfaces/trinidad/trunk/trinidad-examples/trinidad-demo/src/main/webapp/skins/suede/images/csnbld.gif ( 619096 ) /myfaces/trinidad/trunk/trinidad-examples/trinidad-demo/src/main/webapp/skins/suede/images/csnbr.gif ( 619096 ) /myfaces/trinidad/trunk/trinidad-examples/trinidad-demo/src/main/webapp/skins/suede/images/ctruj.gif ( 619096 ) /myfaces/trinidad/trunk/trinidad-examples/trinidad-demo/src/main/webapp/skins/suede/images/ctrumore.gif ( 619096 ) /myfaces/trinidad/trunk/trinidad-examples/trinidad-demo/src/main/webapp/skins/suede/images/dp.gif ( 619096 ) /myfaces/trinidad/trunk/trinidad-examples/trinidad-demo/src/main/webapp/skins/suede/images/dprtl.gif ( 619096 ) /myfaces/trinidad/trunk/trinidad-examples/trinidad-demo/src/main/webapp/skins/suede/images/dsort.gif ( 619096 ) /myfaces/trinidad/trunk/trinidad-examples/trinidad-demo/src/main/webapp/skins/suede/images/err.gif ( 619096 ) /myfaces/trinidad/trunk/trinidad-examples/trinidad-demo/src/main/webapp/skins/suede/images/errorl.gif ( 619096 ) /myfaces/trinidad/trunk/trinidad-examples/trinidad-demo/src/main/webapp/skins/suede/images/focus.gif ( 619096 ) /myfaces/trinidad/trunk/trinidad-examples/trinidad-demo/src/main/webapp/skins/suede/images/hgrid_crumbs.gif ( 619096 ) /myfaces/trinidad/trunk/trinidad-examples/trinidad-demo/src/main/webapp/skins/suede/images/hsd.gif ( 619096 ) /myfaces/trinidad/trunk/trinidad-examples/trinidad-demo/src/main/webapp/skins/suede/images/hsu.gif ( 619096 ) /myfaces/trinidad/trunk/trinidad-examples/trinidad-demo/src/main/webapp/skins/suede/images/info.gif ( 619096 ) /myfaces/trinidad/trunk/trinidad-examples/trinidad-demo/src/main/webapp/skins/suede/images/lovi.gif ( 619096 ) /myfaces/trinidad/trunk/trinidad-examples/trinidad-demo/src/main/webapp/skins/suede/images/lovirtl.gif ( 619096 ) /myfaces/trinidad/trunk/trinidad-examples/trinidad-demo/src/main/webapp/skins/suede/images/pgsInd0.gif ( 619096 )
[jira] Created: (TRINIDAD-940) GenericConverterFactory.getInstance() should not be storing factory instance as a static variable
GenericConverterFactory.getInstance() should not be storing factory instance as a static variable - Key: TRINIDAD-940 URL: https://issues.apache.org/jira/browse/TRINIDAD-940 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.2.5-core Reporter: Max Starets Fix For: 1.2.6-core This is a follow-up to the problem that we discovered during fixing TRINIDAD-858. GenericConverterFactory should not be static because different applications may be registering different GenericConverters. Instead, it should be stored on the Application map. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-940) GenericConverterFactory.getInstance() should not be storing factory instance as a static variable
[ https://issues.apache.org/jira/browse/TRINIDAD-940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-940: - Status: Patch Available (was: Open) GenericConverterFactory.getInstance() should not be storing factory instance as a static variable - Key: TRINIDAD-940 URL: https://issues.apache.org/jira/browse/TRINIDAD-940 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.2.5-core Reporter: Max Starets Fix For: 1.2.6-core Attachments: TRINIDAD-940.patch This is a follow-up to the problem that we discovered during fixing TRINIDAD-858. GenericConverterFactory should not be static because different applications may be registering different GenericConverters. Instead, it should be stored on the Application map. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-940) GenericConverterFactory.getInstance() should not be storing factory instance as a static variable
[ https://issues.apache.org/jira/browse/TRINIDAD-940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12566334#action_12566334 ] Max Starets commented on TRINIDAD-940: -- Changes in the patch were reviewed by Blake and Gabrielle when I was working on TRINIDAD-858. I was just waiting for the new version of Trinidad to be consumed by Oracle, so that we could start using getInstance() version taking ExternalContext. With that change, we can now switch to using ApplicationMap to store factory instance, GenericConverterFactory.getInstance() should not be storing factory instance as a static variable - Key: TRINIDAD-940 URL: https://issues.apache.org/jira/browse/TRINIDAD-940 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.2.5-core Reporter: Max Starets Fix For: 1.2.6-core Attachments: TRINIDAD-940.patch This is a follow-up to the problem that we discovered during fixing TRINIDAD-858. GenericConverterFactory should not be static because different applications may be registering different GenericConverters. Instead, it should be stored on the Application map. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
TRINIDAD-935
hello, is someone able to provide a quick answer (see [1])? (before i'll have a look at it.) regards, gerhard [1] https://issues.apache.org/jira/browse/TRINIDAD-935 -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[jira] Created: (MYFACES-1813) inputHtml
inputHtml - Key: MYFACES-1813 URL: https://issues.apache.org/jira/browse/MYFACES-1813 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.2.2 Environment: myfaces 1.2.2, tomahawk 1.1.6, facelets 1.1.13. Reporter: Ken McArthur Get the following exception in the rendering facelets phases: Caused by: java.lang.ClassCastException: java.lang.Class at org.apache.myfaces.util.AbstractAttributeMap.put(AbstractAttributeMap.java:35) at org.apache.myfaces.custom.inputHtml.InputHtmlRenderer.setThisPageAlreadyRenderedAnInputHtml(InputHtmlRenderer.java:107) at org.apache.myfaces.custom.inputHtml.InputHtmlRenderer.encodeEnd(InputHtmlRenderer.java:93) at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:556) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Deleted: (MYFACES-1813) inputHtml
[ https://issues.apache.org/jira/browse/MYFACES-1813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Marinschek deleted MYFACES-1813: --- inputHtml - Key: MYFACES-1813 URL: https://issues.apache.org/jira/browse/MYFACES-1813 Project: MyFaces Core Issue Type: Bug Environment: myfaces 1.2.2, tomahawk 1.1.6, facelets 1.1.13. Reporter: Ken McArthur Get the following exception in the rendering facelets phases: Caused by: java.lang.ClassCastException: java.lang.Class at org.apache.myfaces.util.AbstractAttributeMap.put(AbstractAttributeMap.java:35) at org.apache.myfaces.custom.inputHtml.InputHtmlRenderer.setThisPageAlreadyRenderedAnInputHtml(InputHtmlRenderer.java:107) at org.apache.myfaces.custom.inputHtml.InputHtmlRenderer.encodeEnd(InputHtmlRenderer.java:93) at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:556) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: TRINIDAD-935
Not tested it: If removing it doesn't break existing apps, I think removing is OK -M On Feb 6, 2008 10:16 PM, Gerhard Petracek [EMAIL PROTECTED] wrote: hello, is someone able to provide a quick answer (see [1])? (before i'll have a look at it.) regards, gerhard [1] https://issues.apache.org/jira/browse/TRINIDAD-935 -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
