[jira] Commented: (TRINIDAD-1490) tr:inputDate's chooseId attribute is not prepended with j_id_ when used in tr:forEach
[ https://issues.apache.org/jira/browse/TRINIDAD-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13003897#comment-13003897 ] Markus Reichert commented on TRINIDAD-1490: --- Same problem exists when using tr:inputDate's chooseId attribute in combination with tr:chooseDate in tr:table: input type=text ... onfocus=_dff(this,'table_name:picker') .../ (missing row index) id of chooseDate table: id=table_name:0:picker (with row index) tr:inputDate's chooseId attribute is not prepended with j_id_ when used in tr:forEach - Key: TRINIDAD-1490 URL: https://issues.apache.org/jira/browse/TRINIDAD-1490 Project: MyFaces Trinidad Issue Type: Bug Components: Components Environment: Tomcat 6.0, Trinidad 1.2.11, JDK 1.6.0_07, Windows XP SP2 and Ubuntu 8.04 Reporter: Jasper de Vries tr:inputDate's chooseId attribute is *not* prepeded with j_id_ when used in tr:forEach. The tr:chooseDate's id attribute *is* prepeded with j_id_ when used in tr:forEach. I've seen this behavior on other id-referring attributes as well. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Html5 Component Library - Status and Demo
Hello Manfred, Could you create the subproject of Myfaces with key MFHTML5 please? Thanks, Ali On Mon, Mar 7, 2011 at 3:38 PM, Gerhard gerhard.petra...@gmail.com wrote: hi ali, manfred is able to create it. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/3/7 Ali Ok al...@aliok.com.tr Hi all, Can someone with the administration right create the new project in JIRA? I want to go on with the further process after that (preparing an alpha release). Thanks, Ali On Mon, Jan 31, 2011 at 7:31 PM, Jakob Korherr jakob.korh...@gmail.comwrote: Hi Ali, Great to hear! I think we should create the project in the JIRA (e.g. MFHTML5, as discussed), move it into myfaces/html5 and do a first alpha release. WDYT guys? Regards, Jakob 2011/1/31 Ali Ok al...@aliok.com.tr: Hi all, I've deployed a new version of my webapp which demonstrates Html5 component library at http://bit.ly/myfaces-html5-demo This demo is based on the one presented in JavaOne, but I've removed all third party Apache License incompatible code and resources. So, the demo will be a subproject of the component library. I've added several new components and features into the component lib and I think now it is a good time for an alpha release. Having a JIRA space would be a great first step. PS: Sorry about the low speed of the demo, it is deployed on Google App Engine. The source code is here Cheers, Ali -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
Re: Html5 Component Library - Status and Demo
Done. https://issues.apache.org/jira/browse/MFHTML5 On Tue, Mar 8, 2011 at 2:41 PM, Ali Ok al...@aliok.com.tr wrote: Hello Manfred, Could you create the subproject of Myfaces with key MFHTML5 please? Thanks, Ali On Mon, Mar 7, 2011 at 3:38 PM, Gerhard gerhard.petra...@gmail.com wrote: hi ali, manfred is able to create it. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/3/7 Ali Ok al...@aliok.com.tr Hi all, Can someone with the administration right create the new project in JIRA? I want to go on with the further process after that (preparing an alpha release). Thanks, Ali On Mon, Jan 31, 2011 at 7:31 PM, Jakob Korherr jakob.korh...@gmail.com wrote: Hi Ali, Great to hear! I think we should create the project in the JIRA (e.g. MFHTML5, as discussed), move it into myfaces/html5 and do a first alpha release. WDYT guys? Regards, Jakob 2011/1/31 Ali Ok al...@aliok.com.tr: Hi all, I've deployed a new version of my webapp which demonstrates Html5 component library at http://bit.ly/myfaces-html5-demo This demo is based on the one presented in JavaOne, but I've removed all third party Apache License incompatible code and resources. So, the demo will be a subproject of the component library. I've added several new components and features into the component lib and I think now it is a good time for an alpha release. Having a JIRA space would be a great first step. PS: Sorry about the low speed of the demo, it is deployed on Google App Engine. The source code is here Cheers, Ali -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: Html5 Component Library - Status and Demo
Thanks Matthias. Greetings, Ali On Tue, Mar 8, 2011 at 4:47 PM, Matthias Wessendorf mat...@apache.orgwrote: Done. https://issues.apache.org/jira/browse/MFHTML5 On Tue, Mar 8, 2011 at 2:41 PM, Ali Ok al...@aliok.com.tr wrote: Hello Manfred, Could you create the subproject of Myfaces with key MFHTML5 please? Thanks, Ali On Mon, Mar 7, 2011 at 3:38 PM, Gerhard gerhard.petra...@gmail.com wrote: hi ali, manfred is able to create it. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/3/7 Ali Ok al...@aliok.com.tr Hi all, Can someone with the administration right create the new project in JIRA? I want to go on with the further process after that (preparing an alpha release). Thanks, Ali On Mon, Jan 31, 2011 at 7:31 PM, Jakob Korherr jakob.korh...@gmail.com wrote: Hi Ali, Great to hear! I think we should create the project in the JIRA (e.g. MFHTML5, as discussed), move it into myfaces/html5 and do a first alpha release. WDYT guys? Regards, Jakob 2011/1/31 Ali Ok al...@aliok.com.tr: Hi all, I've deployed a new version of my webapp which demonstrates Html5 component library at http://bit.ly/myfaces-html5-demo This demo is based on the one presented in JavaOne, but I've removed all third party Apache License incompatible code and resources. So, the demo will be a subproject of the component library. I've added several new components and features into the component lib and I think now it is a good time for an alpha release. Having a JIRA space would be a great first step. PS: Sorry about the low speed of the demo, it is deployed on Google App Engine. The source code is here Cheers, Ali -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
Re: html5 lib
Hi, Current location of the code is : http://svn.apache.org/repos/asf/myfaces/gsoc/html5-comp-lib/ and subprojects: * http://svn.apache.org/repos/asf/myfaces/gsoc/html5-comp-lib/trunk/html5-comp-lib-core/ * http://svn.apache.org/repos/asf/myfaces/gsoc/html5-comp-lib/trunk/html5-comp-lib-examples/ * http://svn.apache.org/repos/asf/myfaces/gsoc/html5-comp-lib/trunk/myfaces-shared-html5/ What about http://svn.apache.org/repos/asf/myfaces/html5/ ? * http://svn.apache.org/repos/asf/myfaces/html5/trunk/html5-comp-lib-core/ * http://svn.apache.org/repos/asf/myfaces/html5/trunk/html5-comp-lib-examples/ * http://svn.apache.org/repos/asf/myfaces/html5/trunk/myfaces-shared-html5/ http://svn.apache.org/repos/asf/myfaces/gsoc/html5-comp-lib/I remember I've read about a decision not adding another top level folder (not 100% sure). Is that so? Cheers, Ali On Thu, Jan 20, 2011 at 1:23 PM, Matthias Wessendorf mat...@apache.orgwrote: +1 let me use that... On Thu, Jan 20, 2011 at 12:16 PM, Jakob Korherr jakob.korh...@gmail.com wrote: Maybe MFHTML5 like we did in MyFaces commons (-- MFCOMMONS). Regards, Jakob Am Donnerstag, 20. Januar 2011 schrieb Matthias Wessendorf mat...@apache.org: the issue is, something like MYFACES-HTML5 does not work (because of -) :-) On Thu, Jan 20, 2011 at 8:18 AM, Gerhard gerhard.petra...@gmail.com wrote: +1 for a new jira project regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/1/20 Matthias Wessendorf mat...@apache.org Question: Should we add a new JIRA project (MYFACESHTML5) Or is it enough to have a HTML5 component ? I personally don't mind having a new project for it.. -M On Thu, Jan 20, 2011 at 6:06 AM, Matthias Wessendorf mat...@apache.org wrote: Nope On Wednesday, January 19, 2011, Ali Ok al...@aliok.com.tr wrote: Hi, totally - let's create a jira instance for myfaces-html5 ?Do we need voting for this? Cheers,Ali On Tue, Jan 18, 2011 at 3:50 PM, Ali Ok al...@aliok.com.tr wrote: Hi, For example, for the hx:video component there is a fallback facet. But I can't say we're able cope with this problem (yet). So far, I've experimented Html5, CSS and other Javascript APIs; created some components, behaviors and etc. Providing fallbacks automatically is not that easy and for some features, it is impossible. Of course, we would have allow users to plug in their fallbacks.That would be an important part of this project. How do others cope with this situation? Is there an established pattern for this case? If so, then we should add it to our WIKI.There is a Javascript library called Modernizr [1] which can detect the support for features. AFAIK, people use that to use Html5 features or fallback to old stuff. Furthermore, Html side of the Html5 (Html + JS APIs + CSS3) mostly designed in a way that old browsers will just ignore the component, but not it's children elements. So, that is another way of providing fallbacks, as nested elements, since new browsers will consider the Html5 elements, but ignore it's non-applicable children. [1] https://github.com/Modernizr/Modernizr Greetings,Ali On Tue, Jan 18, 2011 at 3:31 PM, Mark Struberg strub...@yahoo.de wrote: Please allow me a question (I'm a complete noob on this topic), just for getting the 'big picture': The html5 components are obviously only for html-5 compatible browsers. Is there a strategy to also serve older (xhtml-4 only) browsers? Or do we just show them a 'not available for your old browser' page in this case? How do others cope with this situation? Is there an established pattern for this case? If so, then we should add it to our WIKI. LieGrue, strub --- On Tue, 1/18/11, Matthias Wessendorf mat...@apache.org wrote: From: Matthias Wessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
Re: html5 lib
Hi Ali, +1 to What about http://svn.apache.org/repos/asf/myfaces/html5/ ? * http://svn.apache.org/repos/asf/myfaces/html5/trunk/html5-comp-lib-core/ * http://svn.apache.org/repos/asf/myfaces/html5/trunk/html5-comp-lib-examples/ but myfaces-shared-html5 should be a module of myfaces shared itself (like shared-impl and shared-tomahawk). Regards, Jakob 2011/3/8 Ali Ok al...@aliok.com.tr: Hi, Current location of the code is : http://svn.apache.org/repos/asf/myfaces/gsoc/html5-comp-lib/ and subprojects: * http://svn.apache.org/repos/asf/myfaces/gsoc/html5-comp-lib/trunk/html5-comp-lib-core/ * http://svn.apache.org/repos/asf/myfaces/gsoc/html5-comp-lib/trunk/html5-comp-lib-examples/ * http://svn.apache.org/repos/asf/myfaces/gsoc/html5-comp-lib/trunk/myfaces-shared-html5/ What about http://svn.apache.org/repos/asf/myfaces/html5/ ? * http://svn.apache.org/repos/asf/myfaces/html5/trunk/html5-comp-lib-core/ * http://svn.apache.org/repos/asf/myfaces/html5/trunk/html5-comp-lib-examples/ * http://svn.apache.org/repos/asf/myfaces/html5/trunk/myfaces-shared-html5/ I remember I've read about a decision not adding another top level folder (not 100% sure). Is that so? Cheers, Ali On Thu, Jan 20, 2011 at 1:23 PM, Matthias Wessendorf mat...@apache.org wrote: +1 let me use that... On Thu, Jan 20, 2011 at 12:16 PM, Jakob Korherr jakob.korh...@gmail.com wrote: Maybe MFHTML5 like we did in MyFaces commons (-- MFCOMMONS). Regards, Jakob Am Donnerstag, 20. Januar 2011 schrieb Matthias Wessendorf mat...@apache.org: the issue is, something like MYFACES-HTML5 does not work (because of -) :-) On Thu, Jan 20, 2011 at 8:18 AM, Gerhard gerhard.petra...@gmail.com wrote: +1 for a new jira project regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/1/20 Matthias Wessendorf mat...@apache.org Question: Should we add a new JIRA project (MYFACESHTML5) Or is it enough to have a HTML5 component ? I personally don't mind having a new project for it.. -M On Thu, Jan 20, 2011 at 6:06 AM, Matthias Wessendorf mat...@apache.org wrote: Nope On Wednesday, January 19, 2011, Ali Ok al...@aliok.com.tr wrote: Hi, totally - let's create a jira instance for myfaces-html5 ?Do we need voting for this? Cheers,Ali On Tue, Jan 18, 2011 at 3:50 PM, Ali Ok al...@aliok.com.tr wrote: Hi, For example, for the hx:video component there is a fallback facet. But I can't say we're able cope with this problem (yet). So far, I've experimented Html5, CSS and other Javascript APIs; created some components, behaviors and etc. Providing fallbacks automatically is not that easy and for some features, it is impossible. Of course, we would have allow users to plug in their fallbacks.That would be an important part of this project. How do others cope with this situation? Is there an established pattern for this case? If so, then we should add it to our WIKI.There is a Javascript library called Modernizr [1] which can detect the support for features. AFAIK, people use that to use Html5 features or fallback to old stuff. Furthermore, Html side of the Html5 (Html + JS APIs + CSS3) mostly designed in a way that old browsers will just ignore the component, but not it's children elements. So, that is another way of providing fallbacks, as nested elements, since new browsers will consider the Html5 elements, but ignore it's non-applicable children. [1] https://github.com/Modernizr/Modernizr Greetings,Ali On Tue, Jan 18, 2011 at 3:31 PM, Mark Struberg strub...@yahoo.de wrote: Please allow me a question (I'm a complete noob on this topic), just for getting the 'big picture': The html5 components are obviously only for html-5 compatible browsers. Is there a strategy to also serve older (xhtml-4 only) browsers? Or do we just show them a 'not available for your old browser' page in this case? How do others cope with this situation? Is there an established pattern for this case? If so, then we should add it to our WIKI. LieGrue, strub --- On Tue, 1/18/11, Matthias Wessendorf mat...@apache.org wrote: From: Matthias Wessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- My Blog: http://blog.aliok.com.tr Twitter:
[jira] Resolved: (TRINIDAD-1581) Add the ability to get a sessionId from ExternalContextUtils
[ https://issues.apache.org/jira/browse/TRINIDAD-1581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott O'Bryan resolved TRINIDAD-1581. - Resolution: Fixed Fix Version/s: 1.2.12-core Add the ability to get a sessionId from ExternalContextUtils Key: TRINIDAD-1581 URL: https://issues.apache.org/jira/browse/TRINIDAD-1581 Project: MyFaces Trinidad Issue Type: New Feature Affects Versions: 1.2.12-core Reporter: Scott O'Bryan Assignee: Scott O'Bryan Priority: Minor Fix For: 1.2.12-core The ExternalContextUtils has a way to get the requested sessionId, but not a way to get the real sessionId. getting the real sessionId is a bit more complex because it relies on two different session implmentations and must use reflection if you want to do it in a container agnostic fashion. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MFCOMMONS-29) Advanced JSF 2 ResourceHandler
Advanced JSF 2 ResourceHandler
--
Key: MFCOMMONS-29
URL: https://issues.apache.org/jira/browse/MFCOMMONS-29
Project: MyFaces Commons
Issue Type: New Feature
Affects Versions: 1.0.2-SNAPSHOT
Reporter: Jakob Korherr
Assignee: Jakob Korherr
The features of this ResourceHandler include the following:
- relative paths between resources (css files referencing images
without using #resource['..'])
- caching resources in the client (disabled if ProjectStage == Development)
- GZIP compression and local cache in tmp dir (disabled if
ProjectStage == Development)
- i18n (supporting country code and language).
In addition, it does NOT support ValueExpressions in resource files
for performance reasons.
The most important feature, in my opinion, is how the resource URL is
built, e.g. /faces/javax.faces.resource/de_AT/$/some/library/$/my/resource.css
... because it permits resources referencing other resources without
#{resource['...']} (e.g. css files referencing images or other css
files). With the standard ResourceHandler this is 1) annoying if you
have to change the files you get from your designer and 2) a
performance bottleneck, because resources with ValueExpressions are
not cached and also regenerated for each request.
Furthermore, the resource URL contains the locale and thus you have no
problems with cached resources if a users changes the locale, because
he/she will get a new URL and thus a new resource (the right one).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MFCOMMONS-29) Advanced JSF 2 ResourceHandler
[
https://issues.apache.org/jira/browse/MFCOMMONS-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13004077#comment-13004077
]
Leonardo Uribe commented on MFCOMMONS-29:
-
cool stuff! a good candidate to put on myfaces-commons-utils, so the user can
just add the resource handler on its webapp faces-config.
Advanced JSF 2 ResourceHandler
--
Key: MFCOMMONS-29
URL: https://issues.apache.org/jira/browse/MFCOMMONS-29
Project: MyFaces Commons
Issue Type: New Feature
Affects Versions: 1.0.2-SNAPSHOT
Reporter: Jakob Korherr
Assignee: Jakob Korherr
The features of this ResourceHandler include the following:
- relative paths between resources (css files referencing images
without using #resource['..'])
- caching resources in the client (disabled if ProjectStage == Development)
- GZIP compression and local cache in tmp dir (disabled if
ProjectStage == Development)
- i18n (supporting country code and language).
In addition, it does NOT support ValueExpressions in resource files
for performance reasons.
The most important feature, in my opinion, is how the resource URL is
built, e.g. /faces/javax.faces.resource/de_AT/$/some/library/$/my/resource.css
... because it permits resources referencing other resources without
#{resource['...']} (e.g. css files referencing images or other css
files). With the standard ResourceHandler this is 1) annoying if you
have to change the files you get from your designer and 2) a
performance bottleneck, because resources with ValueExpressions are
not cached and also regenerated for each request.
Furthermore, the resource URL contains the locale and thus you have no
problems with cached resources if a users changes the locale, because
he/she will get a new URL and thus a new resource (the right one).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Advanced JSF 2 ResourceHandler for MyFaces commons
Hi,
I just committed the code, see r1079447.
In addition, I created the following issue for reference in the jira:
MFCOMMONS-29.
Feel free to look at it, use it, change it,... - input is always welcome :)
Regards,
Jakob
2011/2/23 Jakob Korherr jakob.korh...@gmail.com:
Hi guys,
I developed a custom JSF 2 ResourceHandler for one of my current
projects and I want to donate it to MyFaces commons (JSF 2 branch).
The features of this ResourceHandler include the following:
- relative paths between resources (css files referencing images
without using #resource['..'])
- caching resources in the client (disabled if ProjectStage == Development)
- GZIP compression and local cache in tmp dir (disabled if
ProjectStage == Development)
- i18n (supporting country code and language).
In addition, it does NOT support ValueExpressions in resource files
for performance reasons.
The most important feature, in my opinion, is how the resource URL is
built, e.g. /faces/javax.faces.resource/de_AT/$/some/library/$/my/resource.css
... because it permits resources referencing other resources without
#{resource['...']} (e.g. css files referencing images or other css
files). With the standard ResourceHandler this is 1) annoying if you
have to change the files you get from your designer and 2) a
performance bottleneck, because resources with ValueExpressions are
not cached and also regenerated for each request.
Furthermore, the resource URL contains the locale and thus you have no
problems with cached resources if a users changes the locale, because
he/she will get a new URL and thus a new resource (the right one).
I'd like to commit the code as a new module on the JSF 2 branch of
MyFaces commons. Are there any objections?
Regards,
Jakob
--
Jakob Korherr
blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at
--
Jakob Korherr
blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at
[jira] Commented: (MFCOMMONS-29) Advanced JSF 2 ResourceHandler
[
https://issues.apache.org/jira/browse/MFCOMMONS-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13004083#comment-13004083
]
Jakob Korherr commented on MFCOMMONS-29:
:)
IMO it's better to keep this code in an own module, so that we can keep it
lightweight and also deliver the faces-config with the module!
Advanced JSF 2 ResourceHandler
--
Key: MFCOMMONS-29
URL: https://issues.apache.org/jira/browse/MFCOMMONS-29
Project: MyFaces Commons
Issue Type: New Feature
Affects Versions: 1.0.2-SNAPSHOT
Reporter: Jakob Korherr
Assignee: Jakob Korherr
The features of this ResourceHandler include the following:
- relative paths between resources (css files referencing images
without using #resource['..'])
- caching resources in the client (disabled if ProjectStage == Development)
- GZIP compression and local cache in tmp dir (disabled if
ProjectStage == Development)
- i18n (supporting country code and language).
In addition, it does NOT support ValueExpressions in resource files
for performance reasons.
The most important feature, in my opinion, is how the resource URL is
built, e.g. /faces/javax.faces.resource/de_AT/$/some/library/$/my/resource.css
... because it permits resources referencing other resources without
#{resource['...']} (e.g. css files referencing images or other css
files). With the standard ResourceHandler this is 1) annoying if you
have to change the files you get from your designer and 2) a
performance bottleneck, because resources with ValueExpressions are
not cached and also regenerated for each request.
Furthermore, the resource URL contains the locale and thus you have no
problems with cached resources if a users changes the locale, because
he/she will get a new URL and thus a new resource (the right one).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MFCOMMONS-29) Advanced JSF 2 ResourceHandler
[
https://issues.apache.org/jira/browse/MFCOMMONS-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13004086#comment-13004086
]
Leonardo Uribe commented on MFCOMMONS-29:
-
Yes, even better, so it is just required to add it on the classpath.
Advanced JSF 2 ResourceHandler
--
Key: MFCOMMONS-29
URL: https://issues.apache.org/jira/browse/MFCOMMONS-29
Project: MyFaces Commons
Issue Type: New Feature
Affects Versions: 1.0.2-SNAPSHOT
Reporter: Jakob Korherr
Assignee: Jakob Korherr
The features of this ResourceHandler include the following:
- relative paths between resources (css files referencing images
without using #resource['..'])
- caching resources in the client (disabled if ProjectStage == Development)
- GZIP compression and local cache in tmp dir (disabled if
ProjectStage == Development)
- i18n (supporting country code and language).
In addition, it does NOT support ValueExpressions in resource files
for performance reasons.
The most important feature, in my opinion, is how the resource URL is
built, e.g. /faces/javax.faces.resource/de_AT/$/some/library/$/my/resource.css
... because it permits resources referencing other resources without
#{resource['...']} (e.g. css files referencing images or other css
files). With the standard ResourceHandler this is 1) annoying if you
have to change the files you get from your designer and 2) a
performance bottleneck, because resources with ValueExpressions are
not cached and also regenerated for each request.
Furthermore, the resource URL contains the locale and thus you have no
problems with cached resources if a users changes the locale, because
he/she will get a new URL and thus a new resource (the right one).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MFCOMMONS-29) Advanced JSF 2 ResourceHandler
[
https://issues.apache.org/jira/browse/MFCOMMONS-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13004101#comment-13004101
]
Jakob Korherr commented on MFCOMMONS-29:
Exactly!
I just committed the necessary faces-config.xml
Advanced JSF 2 ResourceHandler
--
Key: MFCOMMONS-29
URL: https://issues.apache.org/jira/browse/MFCOMMONS-29
Project: MyFaces Commons
Issue Type: New Feature
Affects Versions: 1.0.2-SNAPSHOT
Reporter: Jakob Korherr
Assignee: Jakob Korherr
Fix For: 1.0.2-SNAPSHOT
The features of this ResourceHandler include the following:
- relative paths between resources (css files referencing images
without using #resource['..'])
- caching resources in the client (disabled if ProjectStage == Development)
- GZIP compression and local cache in tmp dir (disabled if
ProjectStage == Development)
- i18n (supporting country code and language).
In addition, it does NOT support ValueExpressions in resource files
for performance reasons.
The most important feature, in my opinion, is how the resource URL is
built, e.g. /faces/javax.faces.resource/de_AT/$/some/library/$/my/resource.css
... because it permits resources referencing other resources without
#{resource['...']} (e.g. css files referencing images or other css
files). With the standard ResourceHandler this is 1) annoying if you
have to change the files you get from your designer and 2) a
performance bottleneck, because resources with ValueExpressions are
not cached and also regenerated for each request.
Furthermore, the resource URL contains the locale and thus you have no
problems with cached resources if a users changes the locale, because
he/she will get a new URL and thus a new resource (the right one).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (MFCOMMONS-29) Advanced JSF 2 ResourceHandler
[
https://issues.apache.org/jira/browse/MFCOMMONS-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jakob Korherr resolved MFCOMMONS-29.
Resolution: Fixed
Fix Version/s: 1.0.2-SNAPSHOT
Advanced JSF 2 ResourceHandler
--
Key: MFCOMMONS-29
URL: https://issues.apache.org/jira/browse/MFCOMMONS-29
Project: MyFaces Commons
Issue Type: New Feature
Affects Versions: 1.0.2-SNAPSHOT
Reporter: Jakob Korherr
Assignee: Jakob Korherr
Fix For: 1.0.2-SNAPSHOT
The features of this ResourceHandler include the following:
- relative paths between resources (css files referencing images
without using #resource['..'])
- caching resources in the client (disabled if ProjectStage == Development)
- GZIP compression and local cache in tmp dir (disabled if
ProjectStage == Development)
- i18n (supporting country code and language).
In addition, it does NOT support ValueExpressions in resource files
for performance reasons.
The most important feature, in my opinion, is how the resource URL is
built, e.g. /faces/javax.faces.resource/de_AT/$/some/library/$/my/resource.css
... because it permits resources referencing other resources without
#{resource['...']} (e.g. css files referencing images or other css
files). With the standard ResourceHandler this is 1) annoying if you
have to change the files you get from your designer and 2) a
performance bottleneck, because resources with ValueExpressions are
not cached and also regenerated for each request.
Furthermore, the resource URL contains the locale and thus you have no
problems with cached resources if a users changes the locale, because
he/she will get a new URL and thus a new resource (the right one).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TRINIDAD-2054) Messages from exceptions in tr:fileDownloadActionListener are not displayed
[ https://issues.apache.org/jira/browse/TRINIDAD-2054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kentaro Kinebuchi updated TRINIDAD-2054: Status: Patch Available (was: Open) Messages from exceptions in tr:fileDownloadActionListener are not displayed --- Key: TRINIDAD-2054 URL: https://issues.apache.org/jira/browse/TRINIDAD-2054 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.0-beta-2 Environment: x86 Reporter: Kentaro Kinebuchi Priority: Minor When the bean method referenced by tr:fileDownloadActionListener throws an exception, what is displayed to the user is always a generic message The file was not downloaded or was not downloaded correctly.. The exception message itself is not displayed which makes it very hard for the user to know what actually went wrong. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TRINIDAD-2054) Messages from exceptions in tr:fileDownloadActionListener are not displayed
[ https://issues.apache.org/jira/browse/TRINIDAD-2054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13004243#comment-13004243 ] Scott O'Bryan commented on TRINIDAD-2054: - I don't know if I understand this patch. It looks like you are adding two faces messages when the fileUpload fails.. Is this true? That said, I'm not sure I'm comfortable with using the base message. I'd have to take a look at what gets added as the message when it is thrown but we don't want to expose anything that may be considered a security risk. Further, it seems we would want to utilize a localized message as well. Messages from exceptions in tr:fileDownloadActionListener are not displayed --- Key: TRINIDAD-2054 URL: https://issues.apache.org/jira/browse/TRINIDAD-2054 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.0-beta-2 Environment: x86 Reporter: Kentaro Kinebuchi Priority: Minor Attachments: JIRA2054.patch When the bean method referenced by tr:fileDownloadActionListener throws an exception, what is displayed to the user is always a generic message The file was not downloaded or was not downloaded correctly.. The exception message itself is not displayed which makes it very hard for the user to know what actually went wrong. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TRINIDAD-2054) Messages from exceptions in tr:fileDownloadActionListener are not displayed
[ https://issues.apache.org/jira/browse/TRINIDAD-2054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott O'Bryan updated TRINIDAD-2054: Status: Open (was: Patch Available) Messages from exceptions in tr:fileDownloadActionListener are not displayed --- Key: TRINIDAD-2054 URL: https://issues.apache.org/jira/browse/TRINIDAD-2054 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.0-beta-2 Environment: x86 Reporter: Kentaro Kinebuchi Priority: Minor Attachments: JIRA2054.patch When the bean method referenced by tr:fileDownloadActionListener throws an exception, what is displayed to the user is always a generic message The file was not downloaded or was not downloaded correctly.. The exception message itself is not displayed which makes it very hard for the user to know what actually went wrong. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MYFACES-3062) drop cglib from api tests
drop cglib from api tests - Key: MYFACES-3062 URL: https://issues.apache.org/jira/browse/MYFACES-3062 Project: MyFaces Core Issue Type: Test Components: build process Affects Versions: 2.0.4 Reporter: Mark Struberg Assignee: Mark Struberg our api tests use cglib for creating a mock Application object. Sadly this cglib version causes problems in the sonar scan due to conflicting cglib versions being used. We should get rid of cglib and replace it with a simple subclass in this case. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (MYFACES-3062) drop cglib from api tests
[ https://issues.apache.org/jira/browse/MYFACES-3062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved MYFACES-3062. Resolution: Fixed Fix Version/s: 2.0.5-SNAPSHOT I've dropped the native cglib usage. Of course, there is still a jmock-cglib in the game. Will wait for the next sonar scan to see if this causes troubles too. drop cglib from api tests - Key: MYFACES-3062 URL: https://issues.apache.org/jira/browse/MYFACES-3062 Project: MyFaces Core Issue Type: Test Components: build process Affects Versions: 2.0.4 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 2.0.5-SNAPSHOT our api tests use cglib for creating a mock Application object. Sadly this cglib version causes problems in the sonar scan due to conflicting cglib versions being used. We should get rid of cglib and replace it with a simple subclass in this case. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TRINIDAD-2050) NO GOOD DIAGNOSTIC MESSAGE FROM SKINNING FRAMEWORK FOR CASE OF BLANK TRINIDAD-SKINS.XML
[ https://issues.apache.org/jira/browse/TRINIDAD-2050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13004301#comment-13004301 ] Jeanne Waldman commented on TRINIDAD-2050: -- ok. this looks good. I will commit. NO GOOD DIAGNOSTIC MESSAGE FROM SKINNING FRAMEWORK FOR CASE OF BLANK TRINIDAD-SKINS.XML --- Key: TRINIDAD-2050 URL: https://issues.apache.org/jira/browse/TRINIDAD-2050 Project: MyFaces Trinidad Issue Type: Bug Components: Skinning Affects Versions: 2.0.0-beta-3 Reporter: Prakash Udupa Assignee: Jeanne Waldman Attachments: JIRA_2050_empty_skin_config_issue.patch Original Estimate: 24h Remaining Estimate: 24h There is possibility of a trinidad-skin.xml in the class path being without any content, mostly due to packaging errrors. In this circumstance, the XML parser callback and error handler implementations in Trinidad just logs the entire stack trace of the SAXException, with no indication of the xml file that fails, this makes it hard to diagnose given that there could be multiple config files that get merged. We need a more informative log message, even better if the message contained the complete path to the specific trinidad-skins.xml file that has the issue. Here is a sample exception logged that does not provide much useful information: - TreeBuilder$Handler _logError Parsing error, line 1, column 1: org.xml.sax.SAXParseException: Premature end of file. at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:195) at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.fatalError(ErrorHandlerWrapper.java:174) at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:388) at com.sun.org.apache.xerces.internal.impl.XMLScanner.reportFatalError(XMLScanner.java:1414) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next(XMLDocumentScannerImpl.java:1059) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:648) at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:140) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:511) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:808) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:119) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205) at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522) at weblogic.xml.jaxp.WebLogicXMLReader.parse(WebLogicXMLReader.java:133) at weblogic.xml.jaxp.RegistryXMLReader.parse(RegistryXMLReader.java:173) at org.apache.myfaces.trinidadinternal.share.xml.TreeBuilder.parse(TreeBuilder.java:169) at org.apache.myfaces.trinidadinternal.share.xml.TreeBuilder.parse(TreeBuilder.java:120) at org.apache.myfaces.trinidadinternal.skin.SkinUtils._getSkinsNodeFromInputStream(SkinUtils.java:256) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
