RE: Tomahawk on JBoss 4.2.2 (JSF 1.2)
Thanks, I've moved a step further. But now I got: 09:16:21,434 ERROR [ExtensionsFilter] Exception wile retrieving addResource java.lang.IllegalStateException: Cannot create a session after the response has been committed at org.apache.catalina.connector.Request.doGetSession(Request.java:2301) at org.apache.catalina.connector.Request.getSession(Request.java:2075) at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade. java:833) at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade. java:844) at org.apache.myfaces.renderkit.html.util.AddResourceFactory.getInstance (AddResourceFactory.java:279) at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(Extensions Filter.java:126) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl icationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF ilterChain.java:206) at tools.filter.CharsetFilter.doFilter(CharsetFilter.java:48) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl icationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF ilterChain.java:206) at tools.filter.HTTPSFilter.doFilter(HTTPSFilter.java:73) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl icationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF ilterChain.java:206) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFi lter.java:96) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl icationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF ilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV alve.java:230) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextV alve.java:175) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(Securit yAssociationValve.java:179) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authentica torBase.java:524) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValv e.java:84) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j ava:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j ava:102) at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedC onnectionValve.java:157) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal ve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav a:262) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java :844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.proce ss(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:44 6) at java.lang.Thread.run(Thread.java:619) Looks like Extensions Filter from MyFaces is complaining again :( -- View this message in context: http://www.nabble.com/Tomahawk-on-JBoss-4.2.2-%28JSF-1.2%29-tf4797532.html#a13742205 Sent from the MyFaces - Users mailing list archive at Nabble.com.
[Trinidad] avoiding style class aliasing
Hi, I noticed an unpleasant effect due to Trinidad class
compression/aliasing. If I define my own class such as:
.invisible {
display: none;
visibility: hidden;
}
then the generated css contains:
.invisible,.xe0 {display:none;visibility:hidden}
The rendered html page contains always *both* classes, even in places
where xhtml source specified just .invisible.
The final result is that any js code looking for .invisible fails.
I'm using Trinidad 1.0.3. Till 1.0.1 these things were running properly.
Even adding dummy attributes to my classes seems not working: an alias
is generated anyway, and used in html (in place of original class name).
Should I disable alisasing - leaving original class names ? Is that
possible at all ?
-- Renzo
panelPopup demo failed
Everyone,
I am trying Trinidad component demos on my box. I am able see the demos
of all components except panelPopup. When I click on panel popup, I
ended up with the following error
Compilation of JSP File '/components/panelPopup.jspx' failed:
panelPopup.jspx:39:14: This tag is not recognized.
tr:panelPopup binding=#{editor.component} text=Click
Here
^---^
panelPopup.jspx:39:14: This tag is not recognized.
tr:panelPopup binding=#{editor.component} text=Click
Here
^---^
panelPopup.jspx:39:14: This tag is not recognized.
tr:panelPopup binding=#{editor.component} text=Click
Here
^---^
Any Idea?
Using : Trinidad-api-1.0.4-SNAPSHOT.jar,
Trinidad-impl-1.0.4-SNAPSHOT.jar, myfaces-api-1.1.5.jar,
myfaces-impl-1.1.5.jar
Thanks in advance
Krishna
What is the best way to handle a view that is used in two different use cases?
Thanks for your help in advance.
I have a view (jspx page and backing bean) that is used in two different use
cases. The view (viewA) is navigated to when the user clicks on either of two
Menu items - call them MenuItem A and MenuItem B. If MenuItem A was pressed,
viewA is displayed and when the user is done, viewB is displayed next.
However, if MenuItem B is pressed, viewA is displayed and then viewC is
displayed next.
Currently, I have one jspx page and a single backing bean for viewA and both
MenuItems navigate to the same from-outcome. My first question is how can I
determine which MenuItem was clicked in the backing bean? One thought is to
have two different from-outcomes and map them to two to-view-ids that are
differentiated by a query parameter. The query parameter would then be checked
in a scriptlet (Yuck.) in the page that could put an attribute in some
scope(session or request) that indicated which menuItem was pressed. The other
idea that I have is to copy the jspx page to another name and then do a global
search and replace of the references to the backing bean and change it to a
slightly different name (ie. backingB). I could then refactor my backing bean
into parent and child classes where the parent class would handle one of the
uses cases and the child would handle the other use case. The child backing
class would have a few methods that would have some additional logic and then
invoke the parents method.
The downside I see to the firsst approach is that it involves the use of a
scriptlet in the jspx file and conditional logic that checks for the presence
of a session or request attribute in the backing bean.
The disandvantage of the second approache is that I would then need to
maintain two jspx pages that are identical except for the backingBean names in
the JSF EL expressions. I don't see that having the two backing beans as much
as a problem because it alleviates having a lot of conditional logic in the
bean (ie.
String flag = (String) request.getSession().getAttribute(menuItemA_flag);
if (flag != null) {
// handle menuItemA case
} else {
// handle menuItemB case
}
// more common code
if (flag != null) {
// handle menuItemA case
} else {
// handle menuItemB case
}
If anyone else has faced a similar problem, I would be interested in knowing
how you handled it.
Thanks,
Richard
--
Re: [Trinidad] avoiding style class aliasing
Hmmm, sounds like a bug. In compression mode, only .xe0 should be generated.
You can try to disable content compression for now using
context-param
param-nameorg.apache.myfaces.trinidad.DISABLE_CONTENT_COMPRESSION/param-name
param-valuetrue/param-value
/context-param
Regards,
~ Simon
On Nov 14, 2007 3:55 AM, Renzo Tomaselli [EMAIL PROTECTED] wrote:
Hi, I noticed an unpleasant effect due to Trinidad class
compression/aliasing. If I define my own class such as:
.invisible {
display: none;
visibility: hidden;
}
then the generated css contains:
.invisible,.xe0 {display:none;visibility:hidden}
The rendered html page contains always *both* classes, even in places
where xhtml source specified just .invisible.
The final result is that any js code looking for .invisible fails.
I'm using Trinidad 1.0.3. Till 1.0.1 these things were running properly.
Even adding dummy attributes to my classes seems not working: an alias
is generated anyway, and used in html (in place of original class name).
Should I disable alisasing - leaving original class names ? Is that
possible at all ?
-- Renzo
Re: Re: Re: [Trinidad]Why does body-contents(of PPR response) break off on the way that responce is wrote, without '/content'?
There will be an 1.2.1 release of myfaces core soon.
That one has had already several bugfixes.
Thanks for sharing!
-M
On Nov 13, 2007 11:05 PM, [EMAIL PROTECTED] wrote:
Thank you.
The problem was solved thanks to Matthias.
In MyFaces1.2.1-SNAPSHOT, after endDocument is called, flushToWriter is called
correctly.
This solved the problem which I had only by exchanging from 1.2.0 to 1.2.1.
Since URL of MyFaces1.2.1-SNAPSHOT was not found, I took pains to look for it.
The following URL is stuck for those who are taking pains to look for MyFaces1
.2.1-SNAPSHOT like me.
[[ URL to MyFaces 1.2.1-SNAPSHOT ]]
http://people.apache.org/repo/m2-snapshot-repository/org/apache/myfaces/core/
Thanks Matthias,
but I checked that the phenomenon same as Trinidad1.2.3 occurred...Of course,
it is debugging.
Although I investigated and understand, endDocument 'is' called on the PPRRes
p
onsewriter by org.apache.myfaces.application.jsp.JspViewHandlerImpl.
renderView on the JspViewHandlerImpl is processing in following order.
Step1)[start]
Step2)stateAwareWriter.flushToWriter(response.getWriter());
Step3)newResponseWriter.endDocument();
Step4)response.flushBuffer();
Step5)[finish]
FlushToWriter on the stateAwareWriter(step2) takes charge of the output of a
r
esponse.
I think that it may be the cause to have not outputted the response hencefort
h
[Step3].
When replacing Step 2 and Step 3, contenttag was closed correctly and went
w
ell.
However, I think that I want to solve this problem, without changing MyFaces
i
mplementation.
Please give me good solution or hints...
Thanks in advance.
- Original Message -
Date: Fri, 9 Nov 2007 16:51:02 +0100
From: Matthias Wessendorf [EMAIL PROTECTED]
To: MyFaces Discussion users@myfaces.apache.org
Subject: Re: [Trinidad]Why does body-contents(of PPR response) break off on
t
he way that responce is wrote, without '/content'?
script and endElement (content) is missing...
Looks like endDocument isn't called on the PPRResponsewriter.
Tried
-Myfaces 1.2.1-SNAP ?
-Trinidad 1.2.3 `?
-M
On Nov 9, 2007 7:14 AM, [EMAIL PROTECTED] wrote:
Hi all,
I use MyFaces1.2.0 and Trinidad1.2.2 with Tomcat6.0.
I built environment like 'http://www.irian.at/trinidad-demo/faces/componen
t
s/t
able.jspx'.
but, error message displayed 'Invalid PPR response.' when I changed the ra
n
ge
by the range navigation feature.
so, I investigated the response.My response had a difference in respect of
the
following compared with the normal response.
*** my response ***
?xml version=1.0 ?
?Tr-XHR-Response-Type ?
content action=/trinidad-demo-1.2.2/faces/components/table.jspx
fragment
...
/fragment
*** normal response (by irian's demo) ***
?xml version=1.0 ?
?Tr-XHR-Response-Type ?
content action=/trinidad-demo/faces/components/table.jspx
fragment
...
/fragment
script
![CDATA[function _navSubmit(formName, event, id, vld, val){return
...
/script
/content
Why does body-contents(of PPR response) break off on the way that responce
is
wrote, without '/content'?
Thanks in advance.
--PR
[EMAIL PROTECTED]
http://nifmail.jp
--PR
麻雀牌や全自動卓を細部まで描き込んだ、リアルな画面のオンライン麻雀ゲーム！
http://navi.nifty.com/nifmail/654571b5/
--PR
麻雀牌や全自動卓を細部まで描き込んだ、リアルな画面のオンライン麻雀ゲーム！
http://navi.nifty.com/nifmail/654571b5/
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
mail: matzew-at-apache-dot-org
Re: [Trinidad] serious tr:chooseDate bug
The same error is also on
http://www.irian.at/trinidad-demo/faces/components/inputDate.jspx
Luka Surija wrote:
Hi,
I've found a serious bug in tr:chooseDate bug. It has something to do
with day light saving.
1. scenario:
tr:inputDate value=#{myBean.date}
tr:convertDateTime pattern=dd.MM. HH:mm /
tr:chooseDate /
/tr:inputDate
time-zone in trinidad-config.xml doesn't matter.
inital value for myBean.date is null.
1. select: 18. August 2007 on date picker
displayed date is 18.08.2007 18:38 (18:38 is client browser time)
2. select again: 18. August 2007 on date picker
displayed date is 18.08.2007 17:37 (18:38 is client browser time)
3. select again: 18. August 2007 on date picker
displayed date is 18.08.2007 16:36 (18:38 is client browser time)
4. select again: 18. August 2007 on date picker
displayed date is 18.08.2007 15:35 (18:39 is client browser time)
etc
2. scenario:
tr:inputDate value=#{myBean.date}
tr:convertDateTime pattern=dd.MM. /
tr:chooseDate /
/tr:inputDate
inital value for myBean.date is null.
1. select: 18. August 2007 on date picker
displayed date is 18.08.2007
2. select again: 18. August 2007 on date picker
displayed date is 17.08.2007
3. select again: 18. August 2007 on date picker
displayed date is 17.08.2007
4. select again: 17. August 2007 on date picker
displayed date is 16.08.2007
etc
I don't know for you guys, but this is a nightmare for me and I don't
have any clue how to fix this issue.
My server timezone is Europe/Zagreb. Setting
time-zoneEurope/Zagreb/time-zone in trinidad-config.xml or leaving
without time-zone setting doesn't make any difference.
Any known workaround for this problem?
Regards,
Luka
Re: [Trinidad] serious tr:chooseDate bug
Can you please file an issue ?
With details in.
That way we can keep track of it
On Nov 14, 2007 8:56 AM, Luka Surija [EMAIL PROTECTED] wrote:
The same error is also on
http://www.irian.at/trinidad-demo/faces/components/inputDate.jspx
Luka Surija wrote:
Hi,
I've found a serious bug in tr:chooseDate bug. It has something to do
with day light saving.
1. scenario:
tr:inputDate value=#{myBean.date}
tr:convertDateTime pattern=dd.MM. HH:mm /
tr:chooseDate /
/tr:inputDate
time-zone in trinidad-config.xml doesn't matter.
inital value for myBean.date is null.
1. select: 18. August 2007 on date picker
displayed date is 18.08.2007 18:38 (18:38 is client browser time)
2. select again: 18. August 2007 on date picker
displayed date is 18.08.2007 17:37 (18:38 is client browser time)
3. select again: 18. August 2007 on date picker
displayed date is 18.08.2007 16:36 (18:38 is client browser time)
4. select again: 18. August 2007 on date picker
displayed date is 18.08.2007 15:35 (18:39 is client browser time)
etc
2. scenario:
tr:inputDate value=#{myBean.date}
tr:convertDateTime pattern=dd.MM. /
tr:chooseDate /
/tr:inputDate
inital value for myBean.date is null.
1. select: 18. August 2007 on date picker
displayed date is 18.08.2007
2. select again: 18. August 2007 on date picker
displayed date is 17.08.2007
3. select again: 18. August 2007 on date picker
displayed date is 17.08.2007
4. select again: 17. August 2007 on date picker
displayed date is 16.08.2007
etc
I don't know for you guys, but this is a nightmare for me and I don't
have any clue how to fix this issue.
My server timezone is Europe/Zagreb. Setting
time-zoneEurope/Zagreb/time-zone in trinidad-config.xml or leaving
without time-zone setting doesn't make any difference.
Any known workaround for this problem?
Regards,
Luka
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
mail: matzew-at-apache-dot-org
Re: [Trinidad] avoiding style class aliasing
Thanks, Simon. Disabling compression makes things working like they did
previously.
Btw, the reason why it used to work with previous versions was that
until some versions ago (1.0.1) we could disable compression on:
org.apache.myfaces.trinidadinternal.DISABLE_CONTENT_COMPRESSION
while now it's org.apache.myfaces.trinidad.
Moreover, the best solution would be to compress only Trinidad classes
- leaving custom classes as they are, but I gues this is impossible if
translation occurs after css merging.
-- Renzo
Simon Lessard wrote:
Hmmm, sounds like a bug. In compression mode, only .xe0 should be
generated. You can try to disable content compression for now using
context-param
param-nameorg.apache.myfaces.trinidad.DISABLE_CONTENT_COMPRESSION
/param-name
param-valuetrue/param-value
/context-param
Regards,
~ Simon
On Nov 14, 2007 3:55 AM, Renzo Tomaselli
[EMAIL PROTECTED] wrote:
Hi, I noticed an unpleasant effect due to Trinidad class
compression/aliasing. If I define my own class such as:
.invisible {
display: none;
visibility: hidden;
}
then the generated css contains:
.invisible,.xe0 {display:none;visibility:hidden}
The rendered html page contains always *both* classes, even in places
where xhtml source specified just .invisible.
The final result is that any js code looking for .invisible fails.
I'm using Trinidad 1.0.3. Till 1.0.1 these things were running properly.
Even adding dummy attributes to my classes seems not working: an alias
is generated anyway, and used in html (in place of original class name).
Should I disable alisasing - leaving original class names ? Is that
possible at all ?
-- Renzo
[Tobago] Incorrect character set conversion in file upload
Hi, when you upload a file with the tc:file tag with umlauts in the filename the umlauts are not converted correctly when you request the filename with FileItem.getName(). For example ü is converted to ü. I use utf-8 in my pages. Regards Helmut
Re: How to integrate myfaces in RSA 7 for portlet?
I will prepare a sample of myfaces on portal 6 and send u the link soon (may be during week ends). On May 23, 2007 7:13 AM, loseyourself [EMAIL PROTECTED] wrote: And an interesting thing is, if I deploy the portlet twice, there won't be any error message during the publishment, then I re-reference the application with the shared library, once try to run the portlet, get the following error: [23/05/07 15:11:49:982 EST] 0097 ActionManager W com.ibm.wps.state.accessors.action.manager.ActionManagerImpl executeActions id = bMX9f1 is invalid. [23/05/07 15:11:51:719 EST] 0097 ServletWrappe A SRVE0242I: [WorkplaceTreeEAR] [/.WorkplaceTree] [com_ibm_wps_AdminServlet]: ?? [23/05/07 15:11:51:953 EST] 0097 ServletWrappe A SRVE0242I: [WorkplaceTreeEAR] [/.WorkplaceTree] [WorkplaceTree]: ?? [23/05/07 15:11:52:063 EST] 0097 ServletWrappe A SRVE0253I: [WorkplaceTreeEAR] [/.WorkplaceTree] [WorkplaceTree]?? [23/05/07 15:11:52:094 EST] 0097 PortletRender E com.ibm.wps.engine.tags.PortletRenderTag doStartTag EJPEJ0066E: portlet? javax.portlet.UnavailableException: Exception during portlet initialization at com.ibm.wps.pe.pc.std.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:229) at com.ibm.wps.pe.pc.std.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:168) at com.ibm.wps.pe.pc.std.invoker.impl.PortletInvokerImpl.render(PortletInvokerImpl.java:97) at com.ibm.wps.pe.pc.std.PortletContainerImpl.renderPortlet(PortletContainerImpl.java:110) at com.ibm.wps.pe.pc.PortletContainerImpl.doRenderPortlet(PortletContainerImpl.java:587) at com.ibm.wps.pe.ext.render.AbstractRenderManager.performService(AbstractRenderManager.java:247) at com.ibm.wps.pe.pc.PortletContainerImpl.renderPortlet(PortletContainerImpl.java:115) at com.ibm.wps.engine.tags.PortletRenderTag.doStartTag(PortletRenderTag.java:161) at com.ibm._jsp._Control._jspx_meth_portal$1skin_portletRender_0(_Control.java:852) at com.ibm._jsp._Control._jspx_meth_portal$1logic_if_3(_Control.java:884) at com.ibm._jsp._Control._jspService(_Control.java:498) at com.ibm.ws.jsp.runtime.HttpJspBase.service(HttpJspBase.java:91) at javax.servlet.http.HttpServlet.service(HttpServlet.java:856) at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1282) at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1239) at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:113) at com.ibm.ws.webcontainer.filter.WebAppFilterChain._doFilter(WebAppFilterChain.java:82) at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:670) at com.ibm.wsspi.webcontainer.servlet.GenericServletWrapper.handleRequest(GenericServletWrapper.java:117) at com.ibm.ws.jsp.webcontainerext.JSPExtensionServletWrapper.handleRequest(JSPExtensionServletWrapper.java:178) at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.include(WebAppRequestDispatcher.java:613) at com.ibm.wps.services.dispatcher.DispatcherServiceImpl.handleRequest(DispatcherServiceImpl.java:87) at com.ibm.wps.services.dispatcher.DispatcherServiceImpl.include(DispatcherServiceImpl.java:52) at com.ibm.wps.services.dispatcher.Dispatcher.include(Dispatcher.java:45) at com.ibm.wps.engine.templates.skins.Default.render(Default.java:115) at com.ibm.wps.engine.templates.SkinTemplate.render(SkinTemplate.java:71) at com.ibm.wps.composition.elements.Component.render(Component.java:845) at com.ibm.wps.composition.elements.Control.render(Control.java:124) at com.ibm.wps.composition.Composition.render(Composition.java:2568) at com.ibm.websphere.personalization.transformation.PznTransformationLayoutModel.render(PznTransformationLayoutModel.java:70) at com.ibm.wps.model.wrappers.LayoutModelWrapperFactoryImpl$LayoutModelWrapperImpl.render(LayoutModelWrapperFactoryImpl.java:218) at com.ibm.wps.engine.tags.ComponentRenderTag.doStartTag(ComponentRenderTag.java:89) at com.ibm._jsp._UnlayeredContainer_2D_V._jspx_meth_portal$1skin_layoutNodeRender_0(_UnlayeredContainer_2D_V.java:246) at com.ibm._jsp._UnlayeredContainer_2D_V._jspService(_UnlayeredContainer_2D_V.java:150) at com.ibm.ws.jsp.runtime.HttpJspBase.service(HttpJspBase.java:91) at javax.servlet.http.HttpServlet.service(HttpServlet.java:856) at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1282) at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1239) at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:113) at
[Tomahawk] Scrolling text JSF component
Does anyone know of a Scrolling text JSF component ? If not, and I write one, is anyone willing to sponser it into the Sandbox ? -Thanks Steve More
Re: [Trinidad] avoiding style class aliasing
The fact that it generates both compressed and uncompressed in this test
case is not a bug, but as designed.
In selectors without a namespace, like af|, I output both compressed and
uncompressed since these could be a user's styleclass that they are
using in a way that doesn't get compressed, like through their own html
tags.
I don't think this is the reason for Renzo's problem, but instead it is
because he wasn't turning compression off. The problem must be that he
sets styleClass=invisible and this gets compressed because the
renderer calls renderStyleClass which compresses it if compression is
enabled.
Another workaround might be to try adding to the styleClass attribute
another styleclass name that is not written in the skin css file.
Then it won't compress. The reason is that when we process the skin css
file, we get the selector and put it in a map of selector-compressed
selector. If it isn't in the skin css file, it won't get in this map,
thus it won't get compressed, even when renderStyleClass is called.
This is a kludge, no doubt about it. But it will keep you from having to
uncompress everything.
- Jeanne
Renzo Tomaselli wrote:
Thanks, Simon. Disabling compression makes things working like they did
previously.
Btw, the reason why it used to work with previous versions was that
until some versions ago (1.0.1) we could disable compression on:
org.apache.myfaces.trinidadinternal.DISABLE_CONTENT_COMPRESSION
while now it's org.apache.myfaces.trinidad.
Moreover, the best solution would be to compress only Trinidad classes -
leaving custom classes as they are, but I gues this is impossible if
translation occurs after css merging.
-- Renzo
Simon Lessard wrote:
Hmmm, sounds like a bug. In compression mode, only .xe0 should be
generated. You can try to disable content compression for now using
context-param
param-nameorg.apache.myfaces.trinidad.DISABLE_CONTENT_COMPRESSION
/param-name
param-valuetrue/param-value
/context-param
Regards,
~ Simon
On Nov 14, 2007 3:55 AM, Renzo Tomaselli [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Hi, I noticed an unpleasant effect due to Trinidad class
compression/aliasing. If I define my own class such as:
.invisible {
display: none;
visibility: hidden;
}
then the generated css contains:
.invisible,.xe0 {display:none;visibility:hidden}
The rendered html page contains always *both* classes, even in places
where xhtml source specified just .invisible.
The final result is that any js code looking for .invisible fails.
I'm using Trinidad 1.0.3. Till 1.0.1 these things were running
properly.
Even adding dummy attributes to my classes seems not working: an alias
is generated anyway, and used in html (in place of original class
name).
Should I disable alisasing - leaving original class names ? Is that
possible at all ?
-- Renzo
Re: [Trinidad] avoiding style class aliasing
On Nov 14, 2007 2:19 PM, Jeanne Waldman [EMAIL PROTECTED] wrote:
The fact that it generates both compressed and uncompressed in this test
case is not a bug, but as designed.
Oh true, my bad, else doing some styleClass alteration at runtime using
JavaScript would become impossible since the style class wouldn't be in the
final CSS.
In selectors without a namespace, like af|, I output both compressed and
uncompressed since these could be a user's styleclass that they are
using in a way that doesn't get compressed, like through their own html
tags.
I don't think this is the reason for Renzo's problem, but instead it is
because he wasn't turning compression off. The problem must be that he
sets styleClass=invisible and this gets compressed because the
renderer calls renderStyleClass which compresses it if compression is
enabled.
Another workaround might be to try adding to the styleClass attribute
another styleclass name that is not written in the skin css file.
Then it won't compress. The reason is that when we process the skin css
file, we get the selector and put it in a map of selector-compressed
selector. If it isn't in the skin css file, it won't get in this map,
thus it won't get compressed, even when renderStyleClass is called.
This is a kludge, no doubt about it. But it will keep you from having to
uncompress everything.
- Jeanne
Renzo Tomaselli wrote:
Thanks, Simon. Disabling compression makes things working like they did
previously.
Btw, the reason why it used to work with previous versions was that
until some versions ago (1.0.1) we could disable compression on:
org.apache.myfaces.trinidadinternal.DISABLE_CONTENT_COMPRESSION
while now it's org.apache.myfaces.trinidad.
Moreover, the best solution would be to compress only Trinidad classes -
leaving custom classes as they are, but I gues this is impossible if
translation occurs after css merging.
-- Renzo
Simon Lessard wrote:
Hmmm, sounds like a bug. In compression mode, only .xe0 should be
generated. You can try to disable content compression for now using
context-param
param-nameorg.apache.myfaces.trinidad.DISABLE_CONTENT_COMPRESSION
/param-name
param-valuetrue/param-value
/context-param
Regards,
~ Simon
On Nov 14, 2007 3:55 AM, Renzo Tomaselli [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Hi, I noticed an unpleasant effect due to Trinidad class
compression/aliasing. If I define my own class such as:
.invisible {
display: none;
visibility: hidden;
}
then the generated css contains:
.invisible,.xe0 {display:none;visibility:hidden}
The rendered html page contains always *both* classes, even in
places
where xhtml source specified just .invisible.
The final result is that any js code looking for .invisible fails.
I'm using Trinidad 1.0.3. Till 1.0.1 these things were running
properly.
Even adding dummy attributes to my classes seems not working: an
alias
is generated anyway, and used in html (in place of original class
name).
Should I disable alisasing - leaving original class names ? Is that
possible at all ?
-- Renzo
