Re: Facelets+Tomahawk+Trinidad=Disaster?
Hello everyone! I'm getting the same problem No RenderingContext, when trying to combine: - Myfaces 1.2.4 - Trinidad 1.2.8 - Tomahawk 1.1.7 for JSF 1.2 I've checked and double-checked my web.xml. Plus, I've used Hazem Saleh's web.xml and the problem remains. I'm using Tomcat 6.0.16. What could I still be missing? Francisco On Wed, Oct 8, 2008 at 21:37, Matthias Wessendorf [EMAIL PROTECTED] wrote: -java.lang.ClassNotFoundException: org.apache.myfaces.webapp.StartupServletContextListener = something wrong in your setup / classpath. -Caused by: java.lang.IllegalStateException: No RenderingContext at org.apache.myfaces.trinidad.render.CoreRenderer.encodeBegin(CoreRenderer.java:194) at org.apache.myfaces.trinidadinternal.renderkit.htmlBasic.HtmlFormRenderer.encodeBegin(HtmlFormRenderer.java:56) at javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:579) = something wrong with the config of you project. check the TrinidadFilter config in web.xml (there are several post on that here, also there is a demo in Trinidad itself and some are outside of Apache. And no, several folks use it. There are some inital setup issues (especially tomahawk+facelets since there is no taglib.xml included), but all is manageable. -M On Wed, Oct 8, 2008 at 10:07 PM, mjovanov [EMAIL PROTECTED] wrote: OK, from everything I've read on this forum it seems that integrating Trinidad with Tomahawk and Facelets should be a breeze; yet, when I follow all the clearly documented steps, I get the following errors: Can anyone please tell me what I am doing wrong? I would greatly appreciate it! Regards, -M SEVERE: Error configuring application listener of class org.apache.myfaces.webapp.StartupServletContextListener java.lang.ClassNotFoundException: org.apache.myfaces.webapp.StartupServletContextListener at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1363) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1209) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3712) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4216) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1014) at org.apache.catalina.core.StandardHost.start(StandardHost.java:736) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1014) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443) at org.apache.catalina.core.StandardService.start(StandardService.java:448) at org.apache.catalina.core.StandardServer.start(StandardServer.java:700) at org.apache.catalina.startup.Catalina.start(Catalina.java:552) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:295) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:433) Oct 8, 2008 3:54:59 PM org.apache.catalina.core.StandardContext listenerStart SEVERE: Error configuring application listener of class org.apache.myfaces.trinidadinternal.webapp.TrinidadListenerImpl java.lang.ClassNotFoundException: org.apache.myfaces.trinidadinternal.webapp.TrinidadListenerImpl at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1363) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1209) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3712) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4216) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1014) at org.apache.catalina.core.StandardHost.start(StandardHost.java:736) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1014) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443) at org.apache.catalina.core.StandardService.start(StandardService.java:448) at org.apache.catalina.core.StandardServer.start(StandardServer.java:700) at org.apache.catalina.startup.Catalina.start(Catalina.java:552) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:295) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:433) Oct 8,
Re: Trinidad PPR on Weblogic 9 or 10
Yes, I can tell you every version up to 1.0.6 or 1.0.7 would not allow me to get proper PPR. I just kept trying until one version fixed that and did not introduce any other bugs, since this was an application already at a very advanced state, nearly in production. Our Weblogic is 9.2.2 on a Unix machine, but I can run it successfully locally on Windows with Weblogic 9.2.1. I hope this information helps you. Good luck! Francisco On 6/12/08, Sandor Nemeth [EMAIL PROTECTED] wrote: Hi, thanks for replay! I did a lot of test with it and in the end i tried to deploy the Trinidad's own demo app can be downloaded from Trinidad site. And PPR doesn't work neither in the demo app. Exactly what I noticed, that the tr:table component range navigation (next, previous links) and detail facet (show detail, hide detail, Show all details, Hide all details links) doesm't work. The logging shows that the server side actions performed, but the screen is not refreshed. Sometimes after an exact page refresh (F5) the desired screen displayed (next or previous range, displayed detail, etc). And i would emphasize again i can reproduce it with the Trinidad's own demo app. What do you think should be any diffrence in the weblogic environment? Our weblogic is an absolutely unpatched 9.2 version on a windows xp. Do you know whether your weblogic needed any patch for sucessfully run Trinidad PPR? And does your project use any of above mentioned features? As i could see in your thread about a year ago, you also had problems with Trinidad PPR on weblogic. Was that solved only with replace Trinidad version 1.0.1. with 1.0.7? Since my last mail i tried ADF Faces on weblogic and it worked. Almost the same code, just replace tr: with af: Francisco, if you have any suggestion, i would hihgly appreciate it! Thanks! On Thu, Jun 12, 2008 at 8:42 PM, Francisco Passos [EMAIL PROTECTED] wrote: I have a working project running on Weblogic 9.2 with Trinidad 1.0.7. PPR works fine and, dare I say, a whole lot faster than 1.0.1 used to, since it now uses AJAX and several improvements have been made regarding bandwidth. On Wed, Jun 11, 2008 at 7:22 AM, Sandor Nemeth [EMAIL PROTECTED] wrote: Hi, I've found only one thread among archives about Trinidad PPR doesn't work on Weblogic 9 or 10. Unfortunately that thread doesn't contain real solution. The suggestion changing content type from text/html to text/xml doesn't work for me. I tried it with the latest trinidad release 1.0.8. Is there any solution or workaround to this issue? Or should i choose another faces implementation for a weblogic project? As far as i can see, ADF faces has no problem with PPR on weblogic. Thanks!
Re: Trinidad PPR on Weblogic 9 or 10
I have a working project running on Weblogic 9.2 with Trinidad 1.0.7. PPR works fine and, dare I say, a whole lot faster than 1.0.1 used to, since it now uses AJAX and several improvements have been made regarding bandwidth. On Wed, Jun 11, 2008 at 7:22 AM, Sandor Nemeth [EMAIL PROTECTED] wrote: Hi, I've found only one thread among archives about Trinidad PPR doesn't work on Weblogic 9 or 10. Unfortunately that thread doesn't contain real solution. The suggestion changing content type from text/html to text/xml doesn't work for me. I tried it with the latest trinidad release 1.0.8. Is there any solution or workaround to this issue? Or should i choose another faces implementation for a weblogic project? As far as i can see, ADF faces has no problem with PPR on weblogic. Thanks!
Re: Does MyFaces 1.2 require JSP 2.1?
Excellent news! Thank you Bernhard and Matthias. Francisco On Nov 23, 2007 6:17 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: I just committed Bernhard's patch for https://issues.apache.org/jira/browse/MYFACES-1693 -Matthias On Jul 19, 2007 6:54 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: nice! that's a cool feature. -M On 7/19/07, Jesse Alexander (KSFD 121) [EMAIL PROTECTED] wrote: No.. RI just makes a test on the JSP-version and disables certain stuff, when it detects a J2EE 1.4 environment (as in TC 5 and WLS 9.2). It then relies on facelets to provide certain functionality... Sounds like MyFaces is a bit harsher on the user here than the RI. OK... JSF 1.2 officially needs JEE 5. BUT... 1:0 for RI to allow for the gracefull degradation. Just set up a 1.2 RI-app in TC 5.x and watch the log when starting up. You will notice some entries like INFO: JSF1027: [null] The ELResolvers for JSF were not registered with the JSP container. See what I mean? regards Alexander -Original Message- From: Andrew Robinson [mailto:[EMAIL PROTECTED] Sent: Thursday, July 19, 2007 7:24 PM To: MyFaces Discussion Subject: Re: Does MyFaces 1.2 require JSP 2.1? I would ask the facelets list then. According to the JSF specification, JSP 2.1 and Servlet 2.5 support is required for JSF 1.2. On 7/19/07, mraible [EMAIL PROTECTED] wrote: I am using Facelets - that's why I find it strange. I'm able to use Sun's RI (the latest version) in place of MyFaces in the same application and everything works fine. Matt Andrew Robinson-5 wrote: JSF 1.2 requires JSP 2.1 unless you use facelets. I believe you have to run Tomcat 6 as a minimum version (servlet 2.5 support is required) On 7/19/07, mraible [EMAIL PROTECTED] wrote: I should mention: I get the error below on startup when deploying on Tomcat 5.0.25. If I change from MyFaces to Sun's RI and deploy on Tomcat 5.0.25 again, no error. Matt mraible wrote: From what I can tell, MyFaces 1.2 requires JSP 2.1. I developed a quick prototype using MyFaces 1.2 + Facelets 1.1.13 and I get the following error on startup: Exception sending context initialized event to listener instance of class org.apache.myfaces.webapp.StartupServletContextListener java.lang.NoSuchMethodError: javax.servlet.jsp.JspFactory.getJspApplicationContext (Ljavax/servlet/Ser vletContext;)Ljavax/servlet/jsp/JspApplicationContext; at org.apache.myfaces.webapp.DefaultFacesInitializer.initFaces (DefaultFaces Initializer.java:102) at org.apache.myfaces.webapp.StartupServletContextListener.contextInitializ ed(StartupServletContextListener.java:57) If I deploy my app to Tomcat 6, this problem doesn't exist. If I change from MyFaces 1.2 to Sun's RI 1.2_04, this problem doesn't exist either. For this reason, it appears to me that MyFaces 1.2 requires JSP 2.1. Cheers, Matt -- View this message in context: http://www.nabble.com/Does-MyFaces-1.2-require-JSP-2.1--tf4112432.html#a 11693503 Sent from the MyFaces - Users mailing list archive at Nabble.com. -- View this message in context: http://www.nabble.com/Does-MyFaces-1.2-require-JSP-2.1--tf4112432.html#a 11693795 Sent from the MyFaces - Users mailing list archive at Nabble.com. -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: [Tomahawk Trinidad] Tomahawk's jsCookMenu seems to malfunction with Trinidad's PPR
After losing a great deal of time with that, I had postponed addressing that issue in my app until a later non-specified time. Thank you, it works! Francisco On Nov 19, 2007 11:05 AM, Pedro Calcao [EMAIL PROTECTED] wrote: Greetings, I solved this problem by explicitly setting the id of the t:jscookMenu instead of letting it be handled automagically. Seems like this id was getting scrambled somehow after a PPR request, causing the next menu action not to be executed, after that, the menu was reconstructed with a new ID and all worked like it should again. I suppose this was caused by some mix up between the id's in the page, and the id's stored in the server's copy of the component tree, altough I cannot know for sure. Best regards, Pedro On Nov 15, 2007 5:57 PM, Pedro Calcao [EMAIL PROTECTED] wrote: Hello, I currently face the exact same problem, everything works fine, except the request immediatly after a PPR. I have the content of the page and the menu in different forms (the menu in h:form and the content in tr:form). When I try to use a menu link after a PPR, the same page is redisplayed, if I try to do so again, it works correctly. I have tried to debug the myFacesHack.js that overrides the jscookmenu function, with no success, everything looks exactly the same, either following a PPR or not. Looking into the generated response after the first PPR request on a page, I see that the iframe element of the html has a copy of the jscookmenu currently on the page, with the same value for _jscook_action_Postscript, but I don't know what influence this might have on the next menu click. I would deeply appreciate any light anyone could shed on this subject. Thanks, Pedro On Nov 5, 2007 12:20 PM, Francisco Passos [EMAIL PROTECTED] wrote: Thank you for your help Alvaro. Try as I might, either with one form or with several forms, I can't get it to work. Are there any other things I might be doing (or not doing enough) that can cause this? Perhaps configuration parameters? Francisco On 10/31/07, alvaro tovar [EMAIL PROTECTED] wrote: i use myfaces 1.6, tomahawk 1.6 On 10/31/07, Francisco Passos [EMAIL PROTECTED] wrote: Thank you Alvaro. I can't get it to work though. What version of Tomahawk are you using? And are you using Sun RI or Myfaces? Thank you, Francisco On 10/31/07, alvaro tovar [EMAIL PROTECTED] wrote: also the id of the form is jscook_action look my page %@ page contentType=text/html;charset=ISO-8859-1 language=java % %@ taglib uri= http://java.sun.com/jsf/html; prefix=h % %@ taglib uri=http://java.sun.com/jsf/core prefix=f% %@ taglib uri= http://myfaces.apache.org/tomahawk; prefix=t% %@ taglib uri= http://myfaces.apache.org/sandbox prefix=s% %@ taglib prefix=tiles uri= http://struts.apache.org/tags-tiles % !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN http://www.w3.org/TR/html4/loose.dtd; html head meta http-equiv=Content-Type content=text/html; charset=iso-8859-1 / link href=%=request.getContextPath ()%/css/estilosHermes.css rel=stylesheet type=text/css / link href=%=request.getContextPath()%/css/hermes- bog.css rel=stylesheet type=text/css / link href=%=request.getContextPath()%/css/hermes- footer.css rel=stylesheet type=text/css / link href=%=request.getContextPath()%/css/hermes- header.css rel=stylesheet type=text/css / link href=%=request.getContextPath()%/css/hermes- jsf.css rel=stylesheet type=text/css / link href=%=request.getContextPath()%/css/menuhermes.css rel=stylesheet type=text/css //head f:view body f:verbatimdiv id=global/f:verbatim f:verbatimdiv id=cabecera/f:verbatim f:subview id=header tiles:insert attribute=header flush=false/ /f:subview f:verbatim/div/f:verbatim f:verbatimdiv id=clear/div/f:verbatim f:verbatimdiv id=contenido/f:verbatim h:panelGrid columns=1 h:form id=jscook_action2 h:panelGroup id=opcionesHermes f:subview id=menuIzq tiles:insert attribute=menu flush=false/ /f:subview /h:panelGroup t:commandLink/%--no borrar, bug --% /h:form h:panelGroup h:panelGrid columns=1 cellspacing=5 cellpadding=5 h:panelGroup id=opcionesProyecto f:verbatimdiv id=izquierdaopciones
Re: [Trinidad] Update from 1.0.1 to 1.0.3 breaks PPR
I'm using facelets 1.1.11 and it doesn't work and there have been reports of
it not working on 1.1.13 and 1.1.14 as well.
Furthermore, there are restrictions to the use of JSP on non J2EE 5
containers, as is my case, since I'm stuck with Weblogic 9 for my current
app.
Regards,
Francisco
On Nov 13, 2007 11:04 AM, Simon Kitching [EMAIL PROTECTED] wrote:
Ah, Max Staret's comment on that jira issue explains why jsp/jspx could
make a difference.
When using a jsp page it's easy to accidentally cause whitespace to be
written to the response at the start of the page.
And the whitespace output at the start is what is killing PPR. If an xml
document has an ?xml declaration in it, it must be the first thing -
without even whitespace coming first. If whitespace is there first, then it
isn't a valid xml document.
The jspx format is much more resistant to this as there is a tag
(jsp:root) that clearly marks the start of the content.
So yes, facelets should also be immune to this problem as it also controls
whitespace better.
Cheers,
Simon
Oscar Reitsma [EMAIL PROTECTED] schrieb:
Hi Simon,
I am 99% sure it was the move to jspx that did the trick, where 1% is
always
left for an arbitrary CPU transistor malfunction :-)
refer to this:
https://issues.apache.org/jira/browse/TRINIDAD-802
By the looks of things though it may not be the issue when using
facelets
1.1.14, but good to keep in mind anyway.
thanks,
Oscar
On Nov 13, 2007 10:54 AM, Simon Kitching [EMAIL PROTECTED]
wrote:
Hi,
Are you sure jspx has something to do with it?
As I understand it, both jsp and jspx result in a servlet being
generated.
They are just different input formats to the jsp compiler, but in
the end
exactly the same servlet class should be created in either case. And
it is
that servlet class that then actually invokes all the JSF classes and
other
content.
I therefore cannot see why switching from jsp to jspx would make any
difference at all.
Using jspx does potentially point out bugs in a jsp page that
otherwise go
unnoticed (bad tag nesting etc). So maybe moving to jspx forced you to
fix
those bugs, and so the page started working?
Regards,
Simon
Oscar Reitsma [EMAIL PROTECTED] schrieb:
This may help or not, sounds like there has been more discussion on
this
issue.
We had problems with PPR in all versions above 1.0.1 because we
weren't
using jspx:
i.e. use something like this:
?xml version=1.0 encoding=iso-8859-1 standalone=yes ?
jsp:root xmlns:jsp=http://java.sun.com/JSP/Page; version=2.0
xmlns:f=http://java.sun.com/jsf/core;
xmlns:tr=http://myfaces.apache.org/trinidad;
jsp:directive.page contentType=text/html;charset=utf-8 /
f:view
f:loadBundle basename=com.cyest.spms.resources.messages
var=msgs /
tr:document
tr:form
/tr:form
/tr:document
/f:view
/jsp:root
Regards,
Oscar
On Nov 13, 2007 1:42 AM, Francisco Passos
[EMAIL PROTECTED]
wrote:
Thank you, it's reassuring to know that it's not forgotten :)
Francisco
On Nov 12, 2007 8:23 PM, Matthias Wessendorf [EMAIL PROTECTED]
wrote:
We'll look at it. Got a demo application, that shows the issue.
Have to check it. But not fixed in 1.0.4.
I am not able to reproduce it in my environment, just in this
demo.
Hadn't had much time to check, but I'll check it.
-Matthias
On Nov 12, 2007 8:34 PM, Francisco Passos
[EMAIL PROTECTED]
wrote:
Sorry to bother, but I was wondering if this issue has had
developments and
if so, if it has been addressed in version 1.0.4.
Thank you,
Francisco
On Nov 2, 2007 5:15 PM, shhQuiet [EMAIL PROTECTED]
wrote:
I am having this problem, using Facelets 1.1.14 and any
version
of
Trinidad
greater than 1.0.1.
I believe the cause is that the xml PPR response has a
content
type
of
text/html.
Bertrand, Shawn R wrote:
During the PPR request, do you happen to disable the
component
which
originated the request?
--
View this message in context:
http://www.nabble.com/-Trinidad--Update-from-1.0.1-to-1.0.3-breaks-PPR-tf4634155.html#a13551730
Sent from the MyFaces - Users mailing list archive at
Nabble.com.
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
mail: matzew-at-apache-dot-org
Re: [Trinidad] Update from 1.0.1 to 1.0.3 breaks PPR
Sorry to bother, but I was wondering if this issue has had developments and if so, if it has been addressed in version 1.0.4. Thank you, Francisco On Nov 2, 2007 5:15 PM, shhQuiet [EMAIL PROTECTED] wrote: I am having this problem, using Facelets 1.1.14 and any version of Trinidad greater than 1.0.1. I believe the cause is that the xml PPR response has a content type of text/html. Bertrand, Shawn R wrote: During the PPR request, do you happen to disable the component which originated the request? -- View this message in context: http://www.nabble.com/-Trinidad--Update-from-1.0.1-to-1.0.3-breaks-PPR-tf4634155.html#a13551730 Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: [Trinidad] Update from 1.0.1 to 1.0.3 breaks PPR
Thank you, it's reassuring to know that it's not forgotten :) Francisco On Nov 12, 2007 8:23 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: We'll look at it. Got a demo application, that shows the issue. Have to check it. But not fixed in 1.0.4. I am not able to reproduce it in my environment, just in this demo. Hadn't had much time to check, but I'll check it. -Matthias On Nov 12, 2007 8:34 PM, Francisco Passos [EMAIL PROTECTED] wrote: Sorry to bother, but I was wondering if this issue has had developments and if so, if it has been addressed in version 1.0.4. Thank you, Francisco On Nov 2, 2007 5:15 PM, shhQuiet [EMAIL PROTECTED] wrote: I am having this problem, using Facelets 1.1.14 and any version of Trinidad greater than 1.0.1. I believe the cause is that the xml PPR response has a content type of text/html. Bertrand, Shawn R wrote: During the PPR request, do you happen to disable the component which originated the request? -- View this message in context: http://www.nabble.com/-Trinidad--Update-from-1.0.1-to-1.0.3-breaks-PPR-tf4634155.html#a13551730 Sent from the MyFaces - Users mailing list archive at Nabble.com. -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
Re: [Trinidad] Inner table values do not update on the bean
Good afternoon everyone. I'd be amazed if no-one had yet faced difficulty editing inputTexts in a table and an inner table at the same time. Does this ring no bell at all? Francisco On Nov 5, 2007 11:40 AM, Francisco Passos [EMAIL PROTECTED] wrote: Good morning everyone. I've got a list of objects with a property which I need to edit (a quantity). Then, alongside that property I have a list of a second type of objects with a similar editable property (a quantity as well). I need to let the user edit these quantities, but I need to assure that the outer quantity is the sum of the inner quantities. Yes, I know it would be best not to have the outer edit at all, but it is a requisite. So, I used a tr:table for the outer objects (with an inputText for the outer quantity) and the detailStamp facet in which I placed a second tr:table with the inner objects and an inputText to edit the inner quantities. Then I used a button to invoke an action on the bean that has the data, where I sum the inner fields and check the sum against the outer field. Suppose I have an outer line with the value 100 and two inner lines with 50 each. All is well. Now, if I edit the outer to 101 and one of the inner to 51, then click the button, I fail the verification, because the inner field still sum up to 100, instead of 101 ! I suppose there is a very good explanation for this, lifecycle-wise. Can anyone enlighten me why this happens and give me a hint on how to solve it? Thank you, Francisco
[Trinidad] Inner table values do not update on the bean
Good morning everyone. I've got a list of objects with a property which I need to edit (a quantity). Then, alongside that property I have a list of a second type of objects with a similar editable property (a quantity as well). I need to let the user edit these quantities, but I need to assure that the outer quantity is the sum of the inner quantities. Yes, I know it would be best not to have the outer edit at all, but it is a requisite. So, I used a tr:table for the outer objects (with an inputText for the outer quantity) and the detailStamp facet in which I placed a second tr:table with the inner objects and an inputText to edit the inner quantities. Then I used a button to invoke an action on the bean that has the data, where I sum the inner fields and check the sum against the outer field. Suppose I have an outer line with the value 100 and two inner lines with 50 each. All is well. Now, if I edit the outer to 101 and one of the inner to 51, then click the button, I fail the verification, because the inner field still sum up to 100, instead of 101 ! I suppose there is a very good explanation for this, lifecycle-wise. Can anyone enlighten me why this happens and give me a hint on how to solve it? Thank you, Francisco
Re: [Tomahawk Trinidad] Tomahawk's jsCookMenu seems to malfunction with Trinidad's PPR
Thank you for your help Alvaro.
Try as I might, either with one form or with several forms, I can't get it
to work. Are there any other things I might be doing (or not doing enough)
that can cause this? Perhaps configuration parameters?
Francisco
On 10/31/07, alvaro tovar [EMAIL PROTECTED] wrote:
i use myfaces 1.6, tomahawk 1.6
On 10/31/07, Francisco Passos [EMAIL PROTECTED] wrote:
Thank you Alvaro.
I can't get it to work though. What version of Tomahawk are you using?
And are you using Sun RI or Myfaces?
Thank you,
Francisco
On 10/31/07, alvaro tovar [EMAIL PROTECTED] wrote:
also the id of the form is jscook_action
look my page
%@ page contentType=text/html;charset=ISO-8859-1 language=java %
%@ taglib uri= http://java.sun.com/jsf/html; prefix=h %
%@ taglib uri=http://java.sun.com/jsf/core prefix=f%
%@ taglib uri= http://myfaces.apache.org/tomahawk; prefix=t%
%@ taglib uri= http://myfaces.apache.org/sandbox prefix=s%
%@ taglib prefix=tiles uri=http://struts.apache.org/tags-tiles %
!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN
http://www.w3.org/TR/html4/loose.dtd;
html
head
meta http-equiv=Content-Type content=text/html;
charset=iso-8859-1 /
link href=%=request.getContextPath()%/css/estilosHermes.css
rel=stylesheet type=text/css /
link href=%=request.getContextPath()%/css/hermes- bog.css
rel=stylesheet type=text/css /
link href=%=request.getContextPath()%/css/hermes-footer.css
rel=stylesheet type=text/css /
link href=%=request.getContextPath()%/css/hermes-header.css
rel=stylesheet type=text/css /
link href=%=request.getContextPath()%/css/hermes- jsf.css
rel=stylesheet type=text/css /
link href=%=request.getContextPath()%/css/menuhermes.css
rel=stylesheet type=text/css //head
f:view
body
f:verbatimdiv id=global/f:verbatim
f:verbatimdiv id=cabecera/f:verbatim
f:subview id=header
tiles:insert attribute=header flush=false/
/f:subview
f:verbatim/div/f:verbatim
f:verbatimdiv id=clear/div/f:verbatim
f:verbatimdiv id=contenido/f:verbatim
h:panelGrid columns=1
h:form id=jscook_action2
h:panelGroup id=opcionesHermes
f:subview id=menuIzq
tiles:insert attribute=menu flush=false/
/f:subview
/h:panelGroup
t:commandLink/%--no borrar, bug --%
/h:form
h:panelGroup
h:panelGrid columns=1 cellspacing=5
cellpadding=5
h:panelGroup id=opcionesProyecto
f:verbatimdiv id=izquierdaopciones
pb/f:verbatim
h:outputText id=texto3Menu value=Usted
puede acceder a los siguientes formularios para edición del proyecto:/
f:verbatim/bbr //p/f:verbatim
h:form id=jscook_action
t:commandLink/%--no
borrar, bug --%
t:jscookMenu id=menuFormulario
layout=hbl theme=ThemeOffice
t:navigationMenuItem
itemLabel=formularios Proyecto
t:navigationMenuItem itemLabel=Datos
básicos action=#{ manejadorMenuFormularios.iraDatosBasicos}
rendered=#{manejadorMenuFormularios.posicionMenuActivo[0]}/
t:navigationMenuItem
itemLabel=Empresas action=#{ manejadorMenuFormularios.iraEmpresas}
rendered=#{(manejadorMenuFormularios.posicionMenuActivo[0]) (
manejadorMenuFormularios.esMostrarEmpresa)}/
t:navigationMenuItem
itemLabel=Investigadores action=#{
manejadorMenuFormularios.iraInvestigadores} rendered=#{
manejadorMenuFormularios.posicionMenuActivo[1]}/
t:navigationMenuItem
itemLabel=Líneas action=#{ manejadorMenuFormularios.iraLineas}
rendered=#{manejadorMenuFormularios.posicionMenuActivo[2]}/
t:navigationMenuItem
itemLabel=Objetivos y resultados action=#{
manejadorMenuFormularios.iraObjetivosResultados} rendered=#{
manejadorMenuFormularios.posicionMenuActivo[3]}/
t:navigationMenuItem
itemLabel=Información específica action=#{
manejadorMenuFormularios.iraInformacionEspecifica} rendered=#{
manejadorMenuFormularios.posicionMenuActivo[4]}/
t:navigationMenuItem
itemLabel=Actividades action=#{
manejadorMenuFormularios.iraActividades} rendered=#{
manejadorMenuFormularios.posicionMenuActivo[5]}/
t:navigationMenuItem
[Tomahawk Trinidad] Tomahawk's jsCookMenu seems to malfunction with Trinidad's PPR
Good morning to all. I've come to realize the following in an application using t:jsCookMenu and Trinidad's PPR. The menu always works properly, except if the last interaction with the web app was a PPR request. In this case, selecting an option from the menu does not send the user where intended, but instead a full page refresh of the current page takes place. A second click (in the newly refreshed page) always seems to work, but nevertheless now the last request is no longer a PPR one. Has anyone experienced this or has any idea what might be causing it? More info: I'm using Trinidad 1.0.1 and Tomahawk 1.1.6 and have attempted to migrate to Trinidad 1.0.2 and 1.0.3, but gave up on that because PPR ceases to work on my app. Thank you, Francisco
Re: [Tomahawk Trinidad] Tomahawk's jsCookMenu seems to malfunction with Trinidad's PPR
Hello Alvaro, thanks for your hint. Could you please post a copy of the xhtml you use for an example page? I've tried placing jscookmenu within a form and the remainder of the page on a different form, but the problem persists. Thank you, Francisco On 10/31/07, alvaro tovar [EMAIL PROTECTED] wrote: yes, i solved this, using 2 form one for the jscookmenu and other for the page On 10/31/07, Francisco Passos [EMAIL PROTECTED] wrote: Good morning to all. I've come to realize the following in an application using t:jsCookMenu and Trinidad's PPR. The menu always works properly, except if the last interaction with the web app was a PPR request. In this case, selecting an option from the menu does not send the user where intended, but instead a full page refresh of the current page takes place. A second click (in the newly refreshed page) always seems to work, but nevertheless now the last request is no longer a PPR one. Has anyone experienced this or has any idea what might be causing it? More info: I'm using Trinidad 1.0.1 and Tomahawk 1.1.6 and have attempted to migrate to Trinidad 1.0.2 and 1.0.3, but gave up on that because PPR ceases to work on my app. Thank you, Francisco
Re: [Tomahawk Trinidad] Tomahawk's jsCookMenu seems to malfunction with Trinidad's PPR
]}/
t:navigationMenuItem itemLabel=Productos
action=#{ manejadorMenuFormularios.iraProductos} rendered=#{
manejadorMenuFormularios.posicionMenuActivo[8]}/
t:navigationMenuItem
itemLabel=Evaluadores action=#{ manejadorMenuFormularios.iraEvaluadores}
rendered=#{manejadorMenuFormularios.posicionMenuActivo[9]}/
t:navigationMenuItem itemLabel=Fuentes
de financiación action=#{ manejadorMenuFormularios.iraFuentes}
rendered=#{manejadorMenuFormularios.posicionMenuActivo[10] (
manejadorMenuFormularios.esMostrarFinanciacion)}/
t:navigationMenuItem itemLabel=Gastos
action=#{ manejadorMenuFormularios.iraRubros} rendered=#{
manejadorMenuFormularios.posicionMenuActivo[11] (
manejadorMenuFormularios.esMostrarGastos)}/
t:navigationMenuItem itemLabel=Adjuntar
archivos action=#{ manejadorMenuFormularios.iraSubirArchivo}
rendered=#{manejadorMenuFormularios.posicionMenuActivo[12]}/
/t:navigationMenuItem
/t:jscookMenu
/h:form
f:verbatim/div/f:verbatim
/h:panelGroup
/h:panelGrid
/h:panelGroup
/h:panelGrid
h:panelGrid columns=1 width=100%
h:form enctype=multipart/form-data
t:commandLink/
h:panelGroup id=cuerpo
f:subview id=content
tiles:insert attribute=body flush=false/
/f:subview
/h:panelGroup
/h:form
/h:panelGrid
f:verbatim/div
div id=clear/div/f:verbatim
f:verbatimdiv id=pie/f:verbatim
f:subview id=footer
tiles:insert attribute=footer flush=false/
/f:subview
f:verbatim/div
div id=clear/div
/div/f:verbatim
/body
/f:view
/html
On 10/31/07, Francisco Passos [EMAIL PROTECTED] wrote:
Hello Alvaro, thanks for your hint.
Could you please post a copy of the xhtml you use for an example page?
I've tried placing jscookmenu within a form and the remainder of the page on
a different form, but the problem persists.
Thank you,
Francisco
On 10/31/07, alvaro tovar [EMAIL PROTECTED] wrote:
yes, i solved this, using 2 form one for the jscookmenu and other for
the page
On 10/31/07, Francisco Passos [EMAIL PROTECTED] wrote:
Good morning to all.
I've come to realize the following in an application using
t:jsCookMenu and Trinidad's PPR.
The menu always works properly, except if the last interaction with
the web app was a PPR request. In this case, selecting an option from
the
menu does not send the user where intended, but instead a full page
refresh
of the current page takes place. A second click (in the newly refreshed
page) always seems to work, but nevertheless now the last request is no
longer a PPR one.
Has anyone experienced this or has any idea what might be causing
it?
More info: I'm using Trinidad 1.0.1 and Tomahawk 1.1.6 and have
attempted to migrate to Trinidad 1.0.2 and 1.0.3, but gave up on
that because PPR ceases to work on my app.
Thank you,
Francisco
[Trinidad] tr:poll
Good morning! I'm using tr:poll to periodically refresh some panels on a page during an ongoing process in the server. However, if the process is not running, I do not want to keep polling, so I'm using the rendered attribute to ensure the poll object only gets rendered if the process is running. Which leaves me with a problem: when the process is running, the poll is in place and periodically updating some labels on the page. But when the process on the server ends, the following refresh causes the poll not to be rendered and thus the fields are no longer updated... so the labels remain with the results immediately before the process conclusion and never update - and I need to properly present the conclusion of the process. Has anyone encountered a similar situation? I appreciate any suggestions you may have to point me in the right direction. Thank you, Francisco Passos
Re: [Trinidad] tr:poll
I managed to get this to work using an attributeChangeListener (since the rendered attribute changes) and refreshing the data in the corresponding listener method. Regards, Francisco On 10/24/07, Francisco Passos [EMAIL PROTECTED] wrote: Good morning! I'm using tr:poll to periodically refresh some panels on a page during an ongoing process in the server. However, if the process is not running, I do not want to keep polling, so I'm using the rendered attribute to ensure the poll object only gets rendered if the process is running. Which leaves me with a problem: when the process is running, the poll is in place and periodically updating some labels on the page. But when the process on the server ends, the following refresh causes the poll not to be rendered and thus the fields are no longer updated... so the labels remain with the results immediately before the process conclusion and never update - and I need to properly present the conclusion of the process. Has anyone encountered a similar situation? I appreciate any suggestions you may have to point me in the right direction. Thank you, Francisco Passos
[Trinidad] Getting no-session PPR-redirect in 1.0.1
Good morning! I'm using Trinidad 1.0.1, because PPR doesn't work in my app in either 1.0.2nor 1.0.3 (has been discussed in another thread). However, there's one functionality from 1.0.2 that I'd like to have ( https://issues.apache.org/jira/browse/TRINIDAD-158) which is being able to redirect PPR requests to login when the session has timed out. I don't know if what I'm saying is possible, but I'm wondering if, since 1.0.1 is using iframes, it would be possible to return to the iframe a page whose body, onload, would do anything like top.location.href=loginPage.jsf I'm betting this is not possible - at least not as simple as I'm saying; and even if it was, I'd have no idea as to how to return specific html code. Maybe the iframe doesn't even get html back from the server, but since this functionality is quite important for the application I'm working with, I either have to get it working or make sure it isn't possible. Does anyone know if this is possible? Or any alternative? Thank you, Francisco Passos
[Trinidad] Update from 1.0.1 to 1.0.3 breaks PPR
Good afternoon. I've been developing an application with Trinidad 1.0.1 and am considering upgrading to 1.0.3 for the improvements in PPR, the statusIndicator and also to be able to redirect AJAX requests to the login page after the session has expired. However, immediatly after replacing the 1.0.1 libs with their 1.0.3counterparts, I find that AJAX interactions no longer work, generating an error on the browser, which Firebug identifies this way: [Invalid PPR response. The response-headers were:\nDate: Tue, 16 Oct 2007 13:09:56 GMT\nTransfer-Encodi...] Common1_0_3.js (line 10458) [Error , TypeError: a5 has no properties message=a5 has no properties, delivering XML request status changed to , function()] What can cause this and is there a workaround? Thank you, Francisco
Re: [Trinidad] Update from 1.0.1 to 1.0.3 breaks PPR
Hello Simon, I've just tried 1.0.2 and the same problem happens (plus some changes in the way panelBoxes appear). If you need more information that I can provide, please feel free to ask. I actually need to upgrade to 1.0.3 in the next few days or not upgrade at all. Francisco On 10/16/07, Simon Lessard [EMAIL PROTECTED] wrote: Hello Francisco, Can you try with 1.0.2 first please? This is not the first post we get about issues such as this one and we would like to locate it more precisely so knowing if the problem was introduced with 1.0.2 or 1.0.3 would certainly helps. Thanks, ~ Simon On 10/16/07, Francisco Passos [EMAIL PROTECTED] wrote: Good afternoon. I've been developing an application with Trinidad 1.0.1 and am considering upgrading to 1.0.3 for the improvements in PPR, the statusIndicator and also to be able to redirect AJAX requests to the login page after the session has expired. However, immediatly after replacing the 1.0.1 libs with their 1.0.3counterparts, I find that AJAX interactions no longer work, generating an error on the browser, which Firebug identifies this way: [Invalid PPR response. The response-headers were:\nDate: Tue, 16 Oct 2007 13:09:56 GMT\nTransfer-Encodi... ] Common1_0_3.js (line 10458) [Error , TypeError: a5 has no properties message=a5 has no properties, delivering XML request status changed to , function()] What can cause this and is there a workaround? Thank you, Francisco
Re: [Trinidad] Update from 1.0.1 to 1.0.3 breaks PPR
Simon, unfortunately clearing the browser cache didn't seem to do anything :( Francisco On 10/16/07, Simon Lessard [EMAIL PROTECTED] wrote: Hello Francisco, Let try an easy attempt then (and very unlikely to work), try to clear your browser cache. :) That issue is quite a nuisance as you're not the first to report it and none of the dev team can reproduce it to my knowledge. Regards, ~ Simon On 10/16/07, Francisco Passos [EMAIL PROTECTED] wrote: Hello Simon, I've just tried 1.0.2 and the same problem happens (plus some changes in the way panelBoxes appear). If you need more information that I can provide, please feel free to ask. I actually need to upgrade to 1.0.3 in the next few days or not upgrade at all. Francisco On 10/16/07, Simon Lessard [EMAIL PROTECTED] wrote: Hello Francisco, Can you try with 1.0.2 first please? This is not the first post we get about issues such as this one and we would like to locate it more precisely so knowing if the problem was introduced with 1.0.2 or 1.0.3 would certainly helps. Thanks, ~ Simon On 10/16/07, Francisco Passos [EMAIL PROTECTED] wrote: Good afternoon. I've been developing an application with Trinidad 1.0.1 and am considering upgrading to 1.0.3 for the improvements in PPR, the statusIndicator and also to be able to redirect AJAX requests to the login page after the session has expired. However, immediatly after replacing the 1.0.1 libs with their 1.0.3counterparts, I find that AJAX interactions no longer work, generating an error on the browser, which Firebug identifies this way: [Invalid PPR response. The response-headers were:\nDate: Tue, 16 Oct 2007 13:09:56 GMT\nTransfer-Encodi... ] Common1_0_3.js (line 10458) [Error , TypeError: a5 has no properties message=a5 has no properties, delivering XML request status changed to , function()] What can cause this and is there a workaround? Thank you, Francisco
Re: [Trinidad] Update from 1.0.1 to 1.0.3 breaks PPR
No, this is not the case. It happens with tr:table navigation and also with commandLinks which do partialSubmits. Regards, Francisco Passos On 10/16/07, Bertrand, Shawn R [EMAIL PROTECTED] wrote: During the PPR request, do you happen to disable the component which originated the request? We see something similar to this, though not the same error, when a commandButton is clicked to start PPR and we disable the button in an actionListener. We had been using 1.0.2 and had to leave our buttons enabled all the time to avoid this error, but hope to get it working with 1.0.3. Shawn Bertrand Tyco Electronics Corporation -- *From:* Francisco Passos [mailto:[EMAIL PROTECTED] *Sent:* Tuesday, October 16, 2007 10:11 AM *To:* MyFaces Discussion *Subject:* Re: [Trinidad] Update from 1.0.1 to 1.0.3 breaks PPR Simon, unfortunately clearing the browser cache didn't seem to do anything :( Francisco On 10/16/07, *Simon Lessard* [EMAIL PROTECTED] wrote: Hello Francisco, Let try an easy attempt then (and very unlikely to work), try to clear your browser cache. :) That issue is quite a nuisance as you're not the first to report it and none of the dev team can reproduce it to my knowledge. Regards, ~ Simon On 10/16/07, *Francisco Passos* [EMAIL PROTECTED] wrote: Hello Simon, I've just tried 1.0.2 and the same problem happens (plus some changes in the way panelBoxes appear). If you need more information that I can provide, please feel free to ask. I actually need to upgrade to 1.0.3 in the next few days or not upgrade at all. Francisco On 10/16/07, *Simon Lessard* [EMAIL PROTECTED] wrote: Hello Francisco, Can you try with 1.0.2 first please? This is not the first post we get about issues such as this one and we would like to locate it more precisely so knowing if the problem was introduced with 1.0.2 or 1.0.3 would certainly helps. Thanks, ~ Simon On 10/16/07, *Francisco Passos *[EMAIL PROTECTED] wrote: Good afternoon. I've been developing an application with Trinidad 1.0.1 and am considering upgrading to 1.0.3 for the improvements in PPR, the statusIndicator and also to be able to redirect AJAX requests to the login page after the session has expired. However, immediatly after replacing the 1.0.1 libs with their 1.0.3counterparts, I find that AJAX interactions no longer work, generating an error on the browser, which Firebug identifies this way: [Invalid PPR response. The response-headers were:\nDate: Tue, 16 Oct 2007 13:09:56 GMT\nTransfer-Encodi... ] Common1_0_3.js (line 10458) [Error , TypeError: a5 has no properties message=a5 has no properties, delivering XML request status changed to , function()] What can cause this and is there a workaround? Thank you, Francisco
Re: [Trinidad] Update from 1.0.1 to 1.0.3 breaks PPR
By the way, did you manage to get a work-around for your specific problem or did you revert to 1.0.1? Francisco Passos On 10/16/07, Bertrand, Shawn R [EMAIL PROTECTED] wrote: During the PPR request, do you happen to disable the component which originated the request? We see something similar to this, though not the same error, when a commandButton is clicked to start PPR and we disable the button in an actionListener. We had been using 1.0.2 and had to leave our buttons enabled all the time to avoid this error, but hope to get it working with 1.0.3. Shawn Bertrand Tyco Electronics Corporation -- *From:* Francisco Passos [mailto:[EMAIL PROTECTED] *Sent:* Tuesday, October 16, 2007 10:11 AM *To:* MyFaces Discussion *Subject:* Re: [Trinidad] Update from 1.0.1 to 1.0.3 breaks PPR Simon, unfortunately clearing the browser cache didn't seem to do anything :( Francisco On 10/16/07, *Simon Lessard* [EMAIL PROTECTED] wrote: Hello Francisco, Let try an easy attempt then (and very unlikely to work), try to clear your browser cache. :) That issue is quite a nuisance as you're not the first to report it and none of the dev team can reproduce it to my knowledge. Regards, ~ Simon On 10/16/07, *Francisco Passos* [EMAIL PROTECTED] wrote: Hello Simon, I've just tried 1.0.2 and the same problem happens (plus some changes in the way panelBoxes appear). If you need more information that I can provide, please feel free to ask. I actually need to upgrade to 1.0.3 in the next few days or not upgrade at all. Francisco On 10/16/07, *Simon Lessard* [EMAIL PROTECTED] wrote: Hello Francisco, Can you try with 1.0.2 first please? This is not the first post we get about issues such as this one and we would like to locate it more precisely so knowing if the problem was introduced with 1.0.2 or 1.0.3 would certainly helps. Thanks, ~ Simon On 10/16/07, *Francisco Passos *[EMAIL PROTECTED] wrote: Good afternoon. I've been developing an application with Trinidad 1.0.1 and am considering upgrading to 1.0.3 for the improvements in PPR, the statusIndicator and also to be able to redirect AJAX requests to the login page after the session has expired. However, immediatly after replacing the 1.0.1 libs with their 1.0.3counterparts, I find that AJAX interactions no longer work, generating an error on the browser, which Firebug identifies this way: [Invalid PPR response. The response-headers were:\nDate: Tue, 16 Oct 2007 13:09:56 GMT\nTransfer-Encodi... ] Common1_0_3.js (line 10458) [Error , TypeError: a5 has no properties message=a5 has no properties, delivering XML request status changed to , function()] What can cause this and is there a workaround? Thank you, Francisco
Re: [Trinidad] RangeChangeEvent problem
Although I'm not familiar with that situation, at first glance it appears to be a bug, since the range properties probably ought to present the same semantics independently of the view containing only one page of data or all the data at once. Nevertheless, can anyone more knowledgeable on this topic give their input as to whether this is a bug or not and if not, how one can work around it? Thank you Francisco Passos On 10/11/07, Pedro Calcao [EMAIL PROTECTED] wrote: Greetings, I have a table in which I have set a rangeChangeListener to my backing bean, there, I use the getNewStart and getNewEnd properties of the event to fetch data to my list from another source. Everything works fine when the user navigates through the pages, except if he chooses Display All X. The problem is that the getNewStart and getNewEnd usually give the values from the first element (included, zero based), to the last (zero based). When the Display All is selected, what these properties give is 0 to list size (included). I believe this might be a bug, since the indexes should be consistent with the navigation, in the latter case, I would expect the range to be: newStart = 0 newEnd = list.size-1 Thanks, Pedro -- Os melhores cumprimentos, Pedro Calção
Re: [Trinidad] tr:iterator
Hello there.
I tried ui:repeat and the same happened. Before I tried t:dataList, I
realized I was using a facelet and conditionally including two other pages
which both had this code. I figured it might be causing some problems, so I
switched them both to compositions with the original page. The problem
ceased.
Thank you for your help!
Francisco
On 9/27/07, Martin Marinschek [EMAIL PROTECTED] wrote:
May I also suggest to look at t:dataList?
regards,
Martin
On 9/28/07, William Gosse [EMAIL PROTECTED] wrote:
I've seen tr:iterator not behave well when laying out commandLinks
horizontally. I've had much better luck with the Facelets ui:repeat tag
for
this kind of stuff. Unfortunately it doesn't have a varStatus.
From: Francisco Passos [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 27, 2007 12:42 PM
To: MyFaces Discussion
Subject: [Trinidad] tr:iterator
Good afternoon!
I'm using tr:iterator to present various commandLinks on a page.
The problem is: they are always duplicated. I've checked and the list
on
the bean only has 2 elements. However 4 links are generated. Here's the
xhtml:
tr:iterator id=tabber value=#{fichaBean.gruposAtributos}
var=grupoAtributos binding=#{fichaBean.tabNavigationPane}
varStatus=status
tr:spacer width=15px /
tr:commandLink id=tab text=#{grupoAtributos.ndenomin }
partialSubmit=true selected=#{grupoAtributos.igrupoid eq
fichaBean.selectedGroupId} actionListener=#{fichaBean.refreshIt}
tr:setActionListener from=#{grupoAtributos.igrupoid}
to=#{fichaBean.selectedGroupId} /
/tr:commandLink
/tr:iterator
Does anyone know why this happens and what I can do to avoid it?
Thank you,
Francisco Passos
The information transmitted herewith is sensitive information of
Chordiant
Software or its customers and is intended only for use to the individual
or
entity to which it is addressed. If the reader of this message is not
the
intended recipient, you are hereby notified that any review,
retransmission,
dissemination, distribution, copying or other use of, or taking of any
action in reliance upon, this information is strictly prohibited. If you
have received this communication in error, please contact the sender and
delete the material from your computer.
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
[Trinidad] tr:iterator
Good afternoon!
I'm using tr:iterator to present various commandLinks on a page.
The problem is: they are always duplicated. I've checked and the list on the
bean only has 2 elements. However 4 links are generated. Here's the xhtml:
tr:iterator id=tabber value=#{fichaBean.gruposAtributos}
var=grupoAtributos binding=#{fichaBean.tabNavigationPane}
varStatus=status
tr:spacer width=15px /
tr:commandLink id=tab text=#{grupoAtributos.ndenomin}
partialSubmit=true selected=#{grupoAtributos.igrupoid eq
fichaBean.selectedGroupId} actionListener=#{fichaBean.refreshIt}
tr:setActionListener from=#{grupoAtributos.igrupoid}
to=#{fichaBean.selectedGroupId} /
/tr:commandLink
/tr:iterator
Does anyone know why this happens and what I can do to avoid it?
Thank you,
Francisco Passos
Re: Bookmarking request state-keeping
Thanks for your response Simon. I reckon your proposed solution is viable in many cases and, although it requires much control on keeping and discarding state, it might be excellent for specific situations. However in the current situation it is not feasible for performance reasons. What I meant to say is that, even though it is not necessary, I'd like to have bookmarkable pages, since it is in fact a standard in user navigation - or at least in his perception. However, for me to achieve bookmarkability in JSF I have to use a mechanism that breaks request state-keeping. And I understand why this happens and why it is necessary, however I get the feeling we are still lacking something when we can't have both this standard things side by side. Thank you, Francisco On 9/23/07, simon [EMAIL PROTECTED] wrote: The point of t:saveState is to save data about the user's current context. However bookmarks are very simple things that save just a URL. You're therefore basically asking the impossible. Eeither the application has no complex state (therefore has no need of t:saveState) or does have complex state (and is therefore not representable as a bookmark). One way around this that does occur to me is to save the user state as data in a database table, and encode the appropriate record key into the url. You've therefore got a bookmarkable url that has enough information to recreate the user context from. It probably isn't feasable, though, for a number of reasons: * when should data be deleted from the database? * performance will be slow * need to write a custom ViewHandler to save/restore view using DB rather than posted or session data. Regards, Simon On Fri, 2007-09-21 at 17:56 +0100, Pedro Calcao wrote: Greetings, I've recently been told of t:saveState's incompatibility with redirect, and it indeed poses a problem. There are some situations where I would like for users to be able to use bookmarks, while maintaining all my pages in request scope with the use of t:saveState. Altough I can compreend this limitation, I believe there should be some kind of solution or workaround to let us couple these two funcionalities. Pedro On 9/21/07, Francisco Passos [EMAIL PROTECTED] wrote: Greetings. I'm using t:saveState to persist bean information on successive requests. However I'd like to address the bookmarking issue and for that, I understand using redirect not only implies a further component tree duplication, but naturally does not keep state from the previous request, despite the usage of t:saveState. So, I'd like to know what solutions there are to get both of these at the same time: request save stating and bookmarkability. Francisco Passos
Bookmarking request state-keeping
Greetings. I'm using t:saveState to persist bean information on successive requests. However I'd like to address the bookmarking issue and for that, I understand using redirect not only implies a further component tree duplication, but naturally does not keep state from the previous request, despite the usage of t:saveState. So, I'd like to know what solutions there are to get both of these at the same time: request save stating and bookmarkability. Francisco Passos
[Tomahawk] saveState security
Hello all! I've been wondering how secure saveState actually is. To what extent can we trust the values we get back from the client? Are they ciphered with a server key so they can't be tampered with until they get sent back to the server? Or should I assume a client can tamper with the serialized bean and change its values? That would make me have to retrieve them again from a liable source, thus beating the whole purpose of saveState. I'm an avid user of t:saveState, but I need to know what I can count on. Thank you, Francisco Passos
Re: [Tomahawk] saveState security
Hello Martin. Thank you for your answer. It raises two more questions though, could you clarify these for me as well? - When using server side state saving, is it kept in the session? and - How does one use encryption for client-side state saving? Regards, Francisco On 9/9/07, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Francisco, do you use server side state saving? Then the value of t:saveState is not transferred to the client. Do you use client side state saving? Then you can switch on encryption for your state. regards, Martin On 9/9/07, Francisco Passos [EMAIL PROTECTED] wrote: Hello all! I've been wondering how secure saveState actually is. To what extent can we trust the values we get back from the client? Are they ciphered with a server key so they can't be tampered with until they get sent back to the server? Or should I assume a client can tamper with the serialized bean and change its values? That would make me have to retrieve them again from a liable source, thus beating the whole purpose of saveState. I'm an avid user of t:saveState, but I need to know what I can count on. Thank you, Francisco Passos -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [Tomahawk] saveState security
Thank you so much! Francisco On 9/9/07, Cagatay Civici [EMAIL PROTECTED] wrote: Hi, - When using server side state saving, is it kept in the session? Yep - How does one use encryption for client-side state saving? http://wiki.apache.org/myfaces/Secure_Your_Application Regards, Cagatay Coast Guard On 9/9/07, Francisco Passos [EMAIL PROTECTED] wrote: Hello Martin. Thank you for your answer. It raises two more questions though, could you clarify these for me as well? - When using server side state saving, is it kept in the session? and - How does one use encryption for client-side state saving? Regards, Francisco On 9/9/07, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Francisco, do you use server side state saving? Then the value of t:saveState is not transferred to the client. Do you use client side state saving? Then you can switch on encryption for your state. regards, Martin On 9/9/07, Francisco Passos [EMAIL PROTECTED] wrote: Hello all! I've been wondering how secure saveState actually is. To what extent can we trust the values we get back from the client? Are they ciphered with a server key so they can't be tampered with until they get sent back to the server? Or should I assume a client can tamper with the serialized bean and change its values? That would make me have to retrieve them again from a liable source, thus beating the whole purpose of saveState. I'm an avid user of t:saveState, but I need to know what I can count on. Thank you, Francisco Passos -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [Trinidad] Working with large tables
Thank you, I'll delve into this whenever such a situation arises. I'm confident now, though. On 9/5/07, Adam Winer [EMAIL PROTECTED] wrote: The model for the Trinidad table is not java.util.List. It's org.apache.myfaces.trinidad.model.CollectionModel; and Trinidad also supports javax.faces.model.DataModel. Both of these fully support large datasets. The Tomahawk page you refer to is 100% applicable to Trinidad as well, as it talks about the JSF DataModel API, not anything Tomahawk-specific. If you want to support efficient Trinidad sorting on large datasets, you'd need to implement the full CollectionModel API, not just DataModel. -- Adam On 9/4/07, Francisco Passos [EMAIL PROTECTED] wrote: Good evening. I'm wondering if there is a way to use tr:tables with large datasets that allows us to fetch the specific data page from the database upon navigation to that page, instead of having the whole list in memory. It works fine for small tables, but for tables with a couple million of records it could hit the server memory really hard. I know Tomahawk addresses this issue for their tables here http://wiki.apache.org/myfaces/WorkingWithLargeTables . I imagine I could just extend a java.util.List and override the getSize() - that coupled with the rangechangelisteners could do the trick. The question is: is it already done? -- Francisco Passos
[Trinidad] Working with large tables
Good evening. I'm wondering if there is a way to use tr:tables with large datasets that allows us to fetch the specific data page from the database upon navigation to that page, instead of having the whole list in memory. It works fine for small tables, but for tables with a couple million of records it could hit the server memory really hard. I know Tomahawk addresses this issue for their tables here http://wiki.apache.org/myfaces/WorkingWithLargeTables . I imagine I could just extend a java.util.List and override the getSize() - that coupled with the rangechangelisteners could do the trick. The question is: is it already done? -- Francisco Passos
Re: [Trinidad] Skinning tr:table lines on hover
Thank you for all your tips!
Andrew, your solution might work, but as you put it, it is highly dependent
on the rendered html, which means any change in the hierarchy will make it
stop working.
As for Simon, your solution:
af|table::content tr:hover
{
background-color: yellow;
}
Doesn't work, because I'm using banding.
However if I add
af|column::cell-text{-tr-inhibit: background-color}
af|column::cell-text-band{-tr-inhibit: background-color}
like Chris suggested, it works fine for the hover, but I lose banding.
Is there a way to get hover AND banding together?
On 8/30/07, Jeanne Waldman [EMAIL PROTECTED] wrote:
I agree as well. The components my team is working on now have a lot more
skinning hooks mainly because we don't want people to have to do what you
are doing.
- Jeanne
Simon Lessard wrote:
Yeah, I agree more component parts need their own selector...
The following might work, but will cause some problem with nesting:
af|table::content tr:hover
{
background-color: yellow;
}
Regards,
~ Simon
On 8/30/07, Andrew Robinson [EMAIL PROTECTED] wrote:
I got it to work, but it is very ugly and a really bad hack:
CSS:
.hoverTable TBODY TR TD TABLE TBODY TR TD {
background-color: transparent;
}
.hoverTable TBODY TR TD TABLE TBODY TR:hover {
background-color: yellow;
}
XHTML:
tr:table var=_cookie value=#{
facesContext.externalContext.request.cookies}
styleClass=hoverTable
tr:column
#{_cookie.name}
/tr:column
tr:column
#{_cookie.value}
/tr:column
/tr:table
It would be great to get skinning class support on every element
written by any of the Trinidad renderers.
Maybe one of the skin experts can shed some light and a better solution.
-Andrew
On 8/30/07, Francisco Passos [EMAIL PROTECTED] wrote:
Hello Andrew, thank you for your tip.
I just tried your solution, but it doesn't appear to work.
The generated css has this
.af_table.p_AFContent TR:hover {background-color:yellow}
However it is mentioned nowhere in the html, nor is it implicitly
used and
applied to the table...
What could cause this? Are there alternatives?
Thank you,
Francisco Passos
On 8/29/07, Andrew Robinson [EMAIL PROTECTED] wrote:
It doesn't look like the table renderer adds any style classes onto
the TR elements. You could use CSS to do it. Have you tried:
af|table:content TR:hover {
background-color: yellow;
}
This should theoretically work in IE7 and the good browsers
On 8/29/07, Francisco Passos [EMAIL PROTECTED] wrote:
Hello all!
I'm wondering if it is possible to change the css style for a
tr:table
line
when the mouse is hovering.
And if so, can one do it directly on the skin?
Thank you,
Francisco Passos
Re: [Trinidad] Skinning tr:table lines on hover
Indeed it works!
Firefox and IE7 seem to like this solution, although IE6 doesn't. Although
I'm not sure if that is going to ultimately matter for the project I'm
working on, I've got a solution when I thought there might be none.
Thank you Simon, Andrew and Chris.
On 8/31/07, Simon Lessard [EMAIL PROTECTED] wrote:
Hello Francisco,
Try the following selectors
af|table::content tr:hover af|column::cell-text
af|table::content tr:hover af|column::cell-text-band
I did not test it though, but it should work.
Regards,
~ Simon
On 8/31/07, Francisco Passos [EMAIL PROTECTED] wrote:
Thank you for all your tips!
Andrew, your solution might work, but as you put it, it is highly
dependent on the rendered html, which means any change in the hierarchy will
make it stop working.
As for Simon, your solution:
af|table::content tr:hover
{
background-color: yellow;
}
Doesn't work, because I'm using banding.
However if I add
af|column::cell-text{-tr-inhibit: background-color}
af|column::cell-text-band{-tr-inhibit: background-color}
like Chris suggested, it works fine for the hover, but I lose banding.
Is there a way to get hover AND banding together?
On 8/30/07, Jeanne Waldman [EMAIL PROTECTED] wrote:
I agree as well. The components my team is working on now have a lot
more skinning hooks mainly because we don't want people to have to do what
you are doing.
- Jeanne
Simon Lessard wrote:
Yeah, I agree more component parts need their own selector...
The following might work, but will cause some problem with nesting:
af|table::content tr:hover
{
background-color: yellow;
}
Regards,
~ Simon
On 8/30/07, Andrew Robinson [EMAIL PROTECTED] wrote:
I got it to work, but it is very ugly and a really bad hack:
CSS:
.hoverTable TBODY TR TD TABLE TBODY TR TD {
background-color: transparent;
}
.hoverTable TBODY TR TD TABLE TBODY TR:hover {
background-color: yellow;
}
XHTML:
tr:table var=_cookie value=#{
facesContext.externalContext.request.cookies}
styleClass=hoverTable
tr:column
#{_cookie.name}
/tr:column
tr:column
#{_cookie.value}
/tr:column
/tr:table
It would be great to get skinning class support on every element
written by any of the Trinidad renderers.
Maybe one of the skin experts can shed some light and a better
solution.
-Andrew
On 8/30/07, Francisco Passos [EMAIL PROTECTED] wrote:
Hello Andrew, thank you for your tip.
I just tried your solution, but it doesn't appear to work.
The generated css has this
.af_table.p_AFContent TR:hover {background-color:yellow}
However it is mentioned nowhere in the html, nor is it implicitly
used and
applied to the table...
What could cause this? Are there alternatives?
Thank you,
Francisco Passos
On 8/29/07, Andrew Robinson [EMAIL PROTECTED] wrote:
It doesn't look like the table renderer adds any style classes
onto
the TR elements. You could use CSS to do it. Have you tried:
af|table:content TR:hover {
background-color: yellow;
}
This should theoretically work in IE7 and the good browsers
On 8/29/07, Francisco Passos [EMAIL PROTECTED] wrote:
Hello all!
I'm wondering if it is possible to change the css style for a
tr:table
line
when the mouse is hovering.
And if so, can one do it directly on the skin?
Thank you,
Francisco Passos
Re: [Trinidad] Skinning tr:table lines on hover
I've just discovered our client will be running the application on IE6 :S
Which means I'll have to find some other way. Is there anything else you
could imagine?
On 8/31/07, Simon Lessard [EMAIL PROTECTED] wrote:
It doesn't work in IE 6 because Microsoft, in its ultimate wisdom, decided
that IE 6 should support :hover only on a and that :hover on other
elements was not so useful and/or to long to implement and/or some other
very good reasons.
I'm pretty sure Miscrosoft would go bankrupt if every single company was
to sue them for the loss of time and efficiency they suffered to make their
application work with IE.
~ Simon
On 8/31/07, Francisco Passos [EMAIL PROTECTED] wrote:
Indeed it works!
Firefox and IE7 seem to like this solution, although IE6 doesn't.
Although I'm not sure if that is going to ultimately matter for the project
I'm working on, I've got a solution when I thought there might be none.
Thank you Simon, Andrew and Chris.
On 8/31/07, Simon Lessard [EMAIL PROTECTED] wrote:
Hello Francisco,
Try the following selectors
af|table::content tr:hover af|column::cell-text
af|table::content tr:hover af|column::cell-text-band
I did not test it though, but it should work.
Regards,
~ Simon
On 8/31/07, Francisco Passos [EMAIL PROTECTED] wrote:
Thank you for all your tips!
Andrew, your solution might work, but as you put it, it is highly
dependent on the rendered html, which means any change in the hierarchy
will
make it stop working.
As for Simon, your solution:
af|table::content tr:hover
{
background-color: yellow;
}
Doesn't work, because I'm using banding.
However if I add
af|column::cell-text{-tr-inhibit: background-color}
af|column::cell-text-band{-tr-inhibit: background-color}
like Chris suggested, it works fine for the hover, but I lose
banding.
Is there a way to get hover AND banding together?
On 8/30/07, Jeanne Waldman [EMAIL PROTECTED] wrote:
I agree as well. The components my team is working on now have a
lot more skinning hooks mainly because we don't want people to have
to do
what you are doing.
- Jeanne
Simon Lessard wrote:
Yeah, I agree more component parts need their own selector...
The following might work, but will cause some problem with
nesting:
af|table::content tr:hover
{
background-color: yellow;
}
Regards,
~ Simon
On 8/30/07, Andrew Robinson [EMAIL PROTECTED] wrote:
I got it to work, but it is very ugly and a really bad hack:
CSS:
.hoverTable TBODY TR TD TABLE TBODY TR TD {
background-color: transparent;
}
.hoverTable TBODY TR TD TABLE TBODY TR:hover {
background-color: yellow;
}
XHTML:
tr:table var=_cookie value=#{
facesContext.externalContext.request.cookies}
styleClass=hoverTable
tr:column
#{_cookie.name}
/tr:column
tr:column
#{_cookie.value}
/tr:column
/tr:table
It would be great to get skinning class support on every element
written by any of the Trinidad renderers.
Maybe one of the skin experts can shed some light and a better
solution.
-Andrew
On 8/30/07, Francisco Passos [EMAIL PROTECTED] wrote:
Hello Andrew, thank you for your tip.
I just tried your solution, but it doesn't appear to work.
The generated css has this
.af_table.p_AFContent TR:hover {background-color:yellow}
However it is mentioned nowhere in the html, nor is it
implicitly used and
applied to the table...
What could cause this? Are there alternatives?
Thank you,
Francisco Passos
On 8/29/07, Andrew Robinson [EMAIL PROTECTED]
wrote:
It doesn't look like the table renderer adds any style
classes onto
the TR elements. You could use CSS to do it. Have you tried:
af|table:content TR:hover {
background-color: yellow;
}
This should theoretically work in IE7 and the good
browsers
On 8/29/07, Francisco Passos [EMAIL PROTECTED]
wrote:
Hello all!
I'm wondering if it is possible to change the css style
for a tr:table
line
when the mouse is hovering.
And if so, can one do it directly on the skin?
Thank you,
Francisco Passos
Re: [Trinidad] Skinning tr:table lines on hover
Thank you, I intend to try this soon.
Regards,
Francisco Passos
On 8/31/07, Andrew Robinson [EMAIL PROTECTED] wrote:
Try this:
http://www.xs4all.nl/~peterned/csshover.html
On 8/31/07, Francisco Passos [EMAIL PROTECTED] wrote:
I've just discovered our client will be running the application on IE6
:S
Which means I'll have to find some other way. Is there anything else you
could imagine?
On 8/31/07, Simon Lessard [EMAIL PROTECTED] wrote:
It doesn't work in IE 6 because Microsoft, in its ultimate wisdom,
decided
that IE 6 should support :hover only on a and that :hover on other
elements was not so useful and/or to long to implement and/or some other
very good reasons.
I'm pretty sure Miscrosoft would go bankrupt if every single company
was
to sue them for the loss of time and efficiency they suffered to make
their
application work with IE.
~ Simon
On 8/31/07, Francisco Passos [EMAIL PROTECTED] wrote:
Indeed it works!
Firefox and IE7 seem to like this solution, although IE6 doesn't.
Although I'm not sure if that is going to ultimately matter for the
project
I'm working on, I've got a solution when I thought there might be none.
Thank you Simon, Andrew and Chris.
On 8/31/07, Simon Lessard [EMAIL PROTECTED] wrote:
Hello Francisco,
Try the following selectors
af|table::content tr:hover af|column::cell-text
af|table::content tr:hover af|column::cell-text-band
I did not test it though, but it should work.
Regards,
~ Simon
On 8/31/07, Francisco Passos [EMAIL PROTECTED] wrote:
Thank you for all your tips!
Andrew, your solution might work, but as you put it, it is
highly
dependent on the rendered html, which means any change in the hierarchy
will
make it stop working.
As for Simon, your solution:
af|table::content tr:hover
{
background-color: yellow;
}
Doesn't work, because I'm using banding.
However if I add
af|column::cell-text{-tr-inhibit: background-color}
af|column::cell-text-band{-tr-inhibit:
background-color}
like Chris suggested, it works fine for the hover, but I lose
banding.
Is there a way to get hover AND banding together?
On 8/30/07, Jeanne Waldman [EMAIL PROTECTED] wrote:
I agree as well. The components my team is working on now have
a
lot more skinning hooks mainly because we don't want people to have to
do
what you are doing.
- Jeanne
Simon Lessard wrote:
Yeah, I agree more component parts need their own selector...
The following might work, but will cause some problem with
nesting:
af|table::content tr:hover
{
background-color: yellow;
}
Regards,
~ Simon
On 8/30/07, Andrew Robinson [EMAIL PROTECTED]
wrote:
I got it to work, but it is very ugly and a really bad hack:
CSS:
.hoverTable TBODY TR TD TABLE TBODY TR TD {
background-color: transparent;
}
.hoverTable TBODY TR TD TABLE TBODY TR:hover {
background-color: yellow;
}
XHTML:
tr:table var=_cookie
value=#{facesContext.externalContext.request.cookies}
styleClass=hoverTable
tr:column
#{_cookie.name}
/tr:column
tr:column
#{_cookie.value}
/tr:column
/tr:table
It would be great to get skinning class support on every
element
written by any of the Trinidad renderers.
Maybe one of the skin experts can shed some light and a
better
solution.
-Andrew
On 8/30/07, Francisco Passos [EMAIL PROTECTED]
wrote:
Hello Andrew, thank you for your tip.
I just tried your solution, but it doesn't appear to work.
The generated css has this
.af_table.p_AFContent TR:hover {background-color:yellow}
However it is mentioned nowhere in the html, nor is it
implicitly used and
applied to the table...
What could cause this? Are there alternatives?
Thank you,
Francisco Passos
On 8/29/07, Andrew Robinson [EMAIL PROTECTED]
wrote:
It doesn't look like the table renderer adds any style
classes onto
the TR elements. You could use CSS to do it. Have you
tried:
af|table:content TR:hover {
background-color: yellow;
}
This should theoretically work in IE7 and the good
browsers
On 8/29/07, Francisco Passos
Re: [Trinidad] Skinning tr:table lines on hover
Hello Andrew, thank you for your tip.
I just tried your solution, but it doesn't appear to work.
The generated css has this
.af_table.p_AFContent TR:hover {background-color:yellow}
However it is mentioned nowhere in the html, nor is it implicitly used and
applied to the table...
What could cause this? Are there alternatives?
Thank you,
Francisco Passos
On 8/29/07, Andrew Robinson [EMAIL PROTECTED] wrote:
It doesn't look like the table renderer adds any style classes onto
the TR elements. You could use CSS to do it. Have you tried:
af|table:content TR:hover {
background-color: yellow;
}
This should theoretically work in IE7 and the good browsers
On 8/29/07, Francisco Passos [EMAIL PROTECTED] wrote:
Hello all!
I'm wondering if it is possible to change the css style for a tr:table
line
when the mouse is hovering.
And if so, can one do it directly on the skin?
Thank you,
Francisco Passos
[Trinidad] Skinning tr:table lines on hover
Hello all! I'm wondering if it is possible to change the css style for a tr:table line when the mouse is hovering. And if so, can one do it directly on the skin? Thank you, Francisco Passos
Re: Myfaces 1.1.5 and JSTL 1.1.0
Thank you for clearing this up for me. Is it part of the plan to make these situations work? Or are they structural limitations with no workaround? On 8/25/07, simon [EMAIL PROTECTED] wrote: On Fri, 2007-08-24 at 10:12 +0100, Francisco Passos wrote: Good day! I know JSTL is more fully supported in the JSF 1.2 branch of Myfaces. However, I'd like to know specifically what does not or might not work properly when using the JSTL library on myfaces 1.1.5. JSTL expressions that can change the number of JSF components in the view are the main issue So things like having a JSF component within a c:if or a c:forEach is a problem. I think c:if/c:forEach are ok if the condition of the if/forEach does not change during the lifetime of the view. I've certainly used c:if successfully with JSF to conditionally include subviews, but the subview never disappeared while the view was active... Regards, Simon
Myfaces 1.1.5 and JSTL 1.1.0
Good day! I know JSTL is more fully supported in the JSF 1.2 branch of Myfaces. However, I'd like to know specifically what does not or might not work properly when using the JSTL library on myfaces 1.1.5. Thank you, Francisco Passos
Re: [TRINIDAD] 1.0.3: new PPR features
Excellent!
Will 1.0.3 include real AJAX like 1.2.1? Or AJAX is not intented to be a
part of the JSF 1.1 branch?
On 8/22/07, Andrew Robinson [EMAIL PROTECTED] wrote:
Sounds great Adam
Any idea on the time line of a 1.0.3 release?
On 8/21/07, Adam Winer [EMAIL PROTECTED] wrote:
Just added:
- PPR should be a good bit more efficient, as most input + output
components will not render anything unless they are being PPR'd,
and tables, trees, treeTables, navigationPanes and trains
will be entirely skipped unless they or one of their contents
is being PPR'd.
Until now, PPR rendered everything and a ResponseWriter trimmed
out what shouldn't be rendered. That's still the case in part, but
we can now entirely skip some branches of the UIComponent hierarchy.
(The client validation code had to be somewhat overhauled to make
this possible.)
- A new addDomReplaceListener() method provides notification
of DOM changes from PPR. A trivial example is:
function notePpr(oldDom, newDom)
{
console.log(old, oldDom);
console.log(new, newDom);
}
TrPage.getInstance().addDomReplaceListener(notePpr);
... which logs to Firebug any DOM elements that have been
added or removed.
Feedback we need: currently, this API is called *after*
the DOM replacement has happened, and gives you no
way of preventing or overriding the DOM replacement. I'm
far from convinced that's the right choice: it might be better
to run this before replacement and allow this function to return
false;, in which case no replacement would happen.
Cheers,
Adam Winer
[Trinidad] Simple skinning question - inputText
Hello all! I intend to know what I need to define in my skin to be able to do something like this. If I use: tr:inputText styleClass=inputStyle1 I want my inputText label to be bold. And if I use: tr:inputText styleClass=inputStyle2 I want my inputText label to not be bold. I know that I can use the css class af|inputText::label to define global inputText behaviour. But in this case, I want to define specific behaviour. I chose this example, because it clearly illustrates my need to have more than one kind of component style within the same skin.
Re: [Trinidad] When will the JSF 1.2 branch become trunk?
Personally, and I think a reasonable amount of users are in this situation, and despite the fact that I would love to move to 1.2, I cannot. We are using myfaces and facelets on a non-J2EE5 container, which means no myfaces 1.2 for us, even if using facelets - although it would be possible if we decided to use the RI instead. Decisions, decisions... On 8/16/07, noah [EMAIL PROTECTED] wrote: We're using 1.2. We didn't have any problems with the upgrade. On 8/15/07, Adam Winer [EMAIL PROTECTED] wrote: Nope. FWIW, I'd personally be thrilled for the trunk to be 1.2 - I've just assumed that this is not what the majority of our users want, and would like to get some of the really big features - like improved PPR - done before we move trunk to 1.2, so they're available to all. I think the committers could use some feedback from the community on this issue! -- Adam On 8/15/07, Graeme Steyn [EMAIL PROTECTED] wrote: Hi Adam, In the Trinidad JSF 1.2 Support wiki (http://wiki.apache.org/myfaces/Trinidad_JSF12_Support) you mentioned that my current thinking is that this should happen when MyFaces switches their trunk to JSF 1.2. We should continue to keep around a JSF 1.1 branch. Have there been any further updates related to when this is likely to happen? Thank you. Regards, Graeme.
Re: [Trinidad] ADF Rich Faces status
Greetings! What's the current status on RCF? Francisco Passos On 7/11/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: I have to add the report later, but no drop yet, working on it. On 7/11/07, Simon Lessard [EMAIL PROTECTED] wrote: Hello Mike, My best resource to stay tuned about that is http://wiki.apache.org/incubator/ in the Board Reports section. Jor June, you can read: 'RCF is a rich component set for JSF. The SVN, mailing lists are set up. JIRA needs to be set up. Also three committers, that are part of the RCF team don't have an Apache account yet. We are waiting for an import of a current code drop into the repository. Incubating since: May 2007 iPMC questions / comments: robertburrelldonkin - no code drop as yet mvdb - code drop is being worked on, but takes time.' There's no entry for July currently but it's due for today, so I keep hope that we'll get a new encouraging notice very soon. Regards, ~ Simon On 7/11/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Are there any updates as to when the Oracle ADF Rich Faces components will be donated and available through Myfaces/Trinidad? -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
Re: [Trinidad] Assertions (TRINIDAD-44)
Hello Adam, thank you for your response. I actually meant that this restrictive proxy I'm behind is... restrictive enough to not support certain kinds of HTTP requests, such as those made by SVN (using webdav). But you're right, I hadn't noticed the source is packed with the release. Thank you for pointing that out. Now, for the main subject, I am indeed setting a style-sheet-name with a prefixing slash: /resources/css/skin-stp.css I placed the slash, because a while ago when running the application expanded, it worked fine, but when I packed it in a jar it wouldn't recognize the skin... Do you happen to know what might cause this behaviour? Thank you, Francisco On 8/10/07, Adam Winer [EMAIL PROTECTED] wrote: Francisco, I've looked at this assertion this morning, and I can't reproduce a case where it fires on Tomcat 5.0. Can you tell what string is failing this assertion? By any chance, are you setting a style-sheet-name in trinidad-skins.xml that starts with a slash? The source for Trinidad is available whether or not you're behind a firewall; the SVN repository is at: http://svn.apache.org/repos/asf/myfaces/trinidad/ and each of our releases includes source, for example: http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/myfaces/trinidad/trinidad-impl/1.0.1/trinidad-impl-1.0.1-sources.jar -- Adam On 8/10/07, Francisco Passos [EMAIL PROTECTED] wrote: Good morning. The problem reported in https://issues.apache.org/jira/browse/TRINIDAD-44 remains. I tried editing the issue to reopen it, but couldn't. This is a really annoying bug that prevents one from debugging Trinidad applications. Alternatively, I'd like to be able to at least comment the assertion... but can't get it from maven, since I'm behind a restrictive proxy. Is there a way to download the source from 1.0.1 with its dependencies and all that's needed to compile? Thank you, Francisco Passos
[Trinidad] Assertions (TRINIDAD-44)
Good morning. The problem reported in https://issues.apache.org/jira/browse/TRINIDAD-44remains. I tried editing the issue to reopen it, but couldn't. This is a really annoying bug that prevents one from debugging Trinidad applications. Alternatively, I'd like to be able to at least comment the assertion... but can't get it from maven, since I'm behind a restrictive proxy. Is there a way to download the source from 1.0.1 with its dependencies and all that's needed to compile? Thank you, Francisco Passos
Re: Browser Back Button
Simple jsf apps can be written without session-scoped beans, but it takes some effort to avoid them in larger apps. The t:saveState tag doesn't really scale ;-) It's a shame to hear that... :( I guess this means back to the drawing board. What kind of a scale are we talking about that makes t:saveState not work as efficiently as one would like? And what is the main impact? Bandwidth? Server processing due to constant serialization / desserialization of beans being kept from previous requests? These are things important to take in consideration when deciding what to go for at application design time, because after you commit either to session or saveState, it gets hard to go back pretty quick. On 8/7/07, simon [EMAIL PROTECTED] wrote: The server-side support for back buttons in MyFaces only ensures that the data held by JSF components doesn't get confused by back-buttons. Of course this issue is irrelevant when using client-side state-saving. However in either case, if there are any session-scoped backing beans being used by the app then they get out-of-sync with the GUI when back buttons are pressed, regardless. Simple jsf apps can be written without session-scoped beans, but it takes some effort to avoid them in larger apps. The t:saveState tag doesn't really scale ;-) Regards, Simon On Tue, 2007-08-07 at 16:45 -0400, Mike Kienenberger wrote: I'm not entirely certain, but setting this parameter to 1 might solve the problem for you if you use server-side state-saving. However, I use client-side state-saving so I can't say for sure. context-param param-nameorg.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION /param-name param-value1/param-value descriptionOnly applicable if state saving method is server (= default). Defines the amount (default = 20) of the latest views are stored in session. /description /context-param On 8/6/07, Escalada Sergio [EMAIL PROTECTED] wrote: Hello. I am using MyFaces 1.1.5, Tomahawk 1.1.6 in my WEB Aplication, and i have a requirement mandatory to disable the browser back button while the user is interacting with the aplication. The requirement is really serious and compromise the usability of the aplication, can anyone tell me if it is possible to do anything to avoid the use of the browser back button?, or at least to control the use of it trying to avoid the consecuences it carry. Thanks in advance, sorry for my english.
Re: Does MyFaces 1.2 require JSP 2.1?
I've had the same problem using Facelets on Weblogic 9.2, which does not support JSP 2.1. Simon, the fact that both JSP 2.1 and JSF 1.2 use the unified EL does not mean that JSP 2.1 and JSF 1.2 must always come together. What it means is that the pairs JSP 2.1/unified EL and JSF 1.2/unified EL must come together by themselves. There might be some dependency there though, which is bad news for those who are limited to a non-JSP 2.1compliant application server and would like to use JSF 1.2. On 7/19/07, Andrew Robinson [EMAIL PROTECTED] wrote: JSF 1.2 requires JSP 2.1 unless you use facelets. I believe you have to run Tomcat 6 as a minimum version (servlet 2.5 support is required) On 7/19/07, mraible [EMAIL PROTECTED] wrote: I should mention: I get the error below on startup when deploying on Tomcat 5.0.25. If I change from MyFaces to Sun's RI and deploy on Tomcat 5.0.25 again, no error. Matt mraible wrote: From what I can tell, MyFaces 1.2 requires JSP 2.1. I developed a quick prototype using MyFaces 1.2 + Facelets 1.1.13 and I get the following error on startup: Exception sending context initialized event to listener instance of class org.apache.myfaces.webapp.StartupServletContextListener java.lang.NoSuchMethodError: javax.servlet.jsp.JspFactory.getJspApplicationContext (Ljavax/servlet/ServletContext;)Ljavax/servlet/jsp/JspApplicationContext; at org.apache.myfaces.webapp.DefaultFacesInitializer.initFaces( DefaultFacesInitializer.java:102) at org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized (StartupServletContextListener.java:57) If I deploy my app to Tomcat 6, this problem doesn't exist. If I change from MyFaces 1.2 to Sun's RI 1.2_04, this problem doesn't exist either. For this reason, it appears to me that MyFaces 1.2 requires JSP 2.1. Cheers, Matt -- View this message in context: http://www.nabble.com/Does-MyFaces-1.2-require-JSP-2.1--tf4112432.html#a11693503 Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: Does MyFaces 1.2 require JSP 2.1?
Will the Myfaces team consider the possibility of providing similar support for non-JSP 2.1 containers using facelets? That would be very welcome :) On 7/19/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: nice! that's a cool feature. -M On 7/19/07, Jesse Alexander (KSFD 121) [EMAIL PROTECTED] wrote: No.. RI just makes a test on the JSP-version and disables certain stuff, when it detects a J2EE 1.4 environment (as in TC 5 and WLS 9.2). It then relies on facelets to provide certain functionality... Sounds like MyFaces is a bit harsher on the user here than the RI. OK... JSF 1.2 officially needs JEE 5. BUT... 1:0 for RI to allow for the gracefull degradation. Just set up a 1.2 RI-app in TC 5.x and watch the log when starting up. You will notice some entries like INFO: JSF1027: [null] The ELResolvers for JSF were not registered with the JSP container. See what I mean? regards Alexander -Original Message- From: Andrew Robinson [mailto:[EMAIL PROTECTED] Sent: Thursday, July 19, 2007 7:24 PM To: MyFaces Discussion Subject: Re: Does MyFaces 1.2 require JSP 2.1? I would ask the facelets list then. According to the JSF specification, JSP 2.1 and Servlet 2.5 support is required for JSF 1.2. On 7/19/07, mraible [EMAIL PROTECTED] wrote: I am using Facelets - that's why I find it strange. I'm able to use Sun's RI (the latest version) in place of MyFaces in the same application and everything works fine. Matt Andrew Robinson-5 wrote: JSF 1.2 requires JSP 2.1 unless you use facelets. I believe you have to run Tomcat 6 as a minimum version (servlet 2.5 support is required) On 7/19/07, mraible [EMAIL PROTECTED] wrote: I should mention: I get the error below on startup when deploying on Tomcat 5.0.25. If I change from MyFaces to Sun's RI and deploy on Tomcat 5.0.25 again, no error. Matt mraible wrote: From what I can tell, MyFaces 1.2 requires JSP 2.1. I developed a quick prototype using MyFaces 1.2 + Facelets 1.1.13 and I get the following error on startup: Exception sending context initialized event to listener instance of class org.apache.myfaces.webapp.StartupServletContextListener java.lang.NoSuchMethodError: javax.servlet.jsp.JspFactory.getJspApplicationContext(Ljavax/servlet/Ser vletContext;)Ljavax/servlet/jsp/JspApplicationContext; at org.apache.myfaces.webapp.DefaultFacesInitializer.initFaces(DefaultFaces Initializer.java:102) at org.apache.myfaces.webapp.StartupServletContextListener.contextInitializ ed(StartupServletContextListener.java:57) If I deploy my app to Tomcat 6, this problem doesn't exist. If I change from MyFaces 1.2 to Sun's RI 1.2_04, this problem doesn't exist either. For this reason, it appears to me that MyFaces 1.2 requires JSP 2.1. Cheers, Matt -- View this message in context: http://www.nabble.com/Does-MyFaces-1.2-require-JSP-2.1--tf4112432.html#a 11693503 Sent from the MyFaces - Users mailing list archive at Nabble.com. -- View this message in context: http://www.nabble.com/Does-MyFaces-1.2-require-JSP-2.1--tf4112432.html#a 11693795 Sent from the MyFaces - Users mailing list archive at Nabble.com. -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
Re: [ANNOUNCE] MyFaces Core 1.2.0 Release
Excellent news! Thank you. On 7/18/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: The Apache MyFaces team is pleased to announce the release of MyFaces Core 1.2.0. MyFaces Core 1.2.x is a JavaServer(tm) Faces 1.2 implementation as specified by JSR-252. MyFaces Core has passed Sun's JSR-252 TCK and is 100% compliant with the JSR-252 specification. MyFaces Core 1.2.0 is available in both binary and source distributions. * http://myfaces.apache.org/download.html MyFaces Core is also available in the central Maven repository under Group ID org.apache.myfaces.core. Release Notes - MyFaces Core - Version 1.2.0 Sub-task * [MYFACES-1436] - Add element deferred-value/method for elements in the taglibs * [MYFACES-1437] - Implement UIComponentTagUtils to use ValueExpression and MethodExpression * [MYFACES-1440] - Implement method: ApplicationImpl.createComponent(ValueExpression,FacesContext, String) * [MYFACES-1441] - Implement method: ApplicationImpl.getResourceBundle(FacesContext ,String) * [MYFACES-1444] - Change all the html basic tag attributes to ValueExpression * [MYFACES-1453] - Implement JSR-252 core tag: ActionListenerTag * [MYFACES-1454] - Implement JSR-252 core tag: ConvertNumberTag * [MYFACES-1455] - Implement JSR-252 core tag: LoadBundleTag * [MYFACES-1456] - Implement JSR-252 core tag: ParamTag * [MYFACES-1457] - Implement JSR-252 core tag: SelectItemsTag * [MYFACES-1458] - Implement JSR-252 core tag: SubviewTag * [MYFACES-1459] - Implement JSR-252 core tag: ValidateDoubleRangeTag * [MYFACES-1460] - Implement JSR-252 core tag: ValidateLengthTag * [MYFACES-1461] - Implement JSR-252 core tag: ValidateLongRangeTag * [MYFACES-1462] - Implement JSR-252 core tag: ValueChangeListenerTag * [MYFACES-1463] - Implement JSR-252 core tag: VerbatimTag * [MYFACES-1464] - Implement JSR-252 core tag: ViewTag * [MYFACES-1473] - Implement JSR-252 core tag: SelectItemTag * [MYFACES-1475] - ValidatorTag * [MYFACES-1478] - Implement JSR-252 core tag: convertDateTimeTag * [MYFACES-1484] - Implement JSR-252 core tag: phaseListenerTag * [MYFACES-1485] - Implement JSR-252 core tag: FacetTag Bug * [MYFACES-1212] - JSR-252 Issue #21: Provide additional binding attribute for the core Converter, Listener, and Validator tags that would be used as a ValueExpression to alternatively create the instance * [MYFACES-1218] - JSR-252 Issue #45: Avoided concurrent read issues by using a java.util.HashMap instead of java.util.WeakHashMap for a component's Property Descriptor Map * [MYFACES-1331] - Value attribute in f:selectItem is documented as not required, but javax.faces.FacesException: SelectItem with no value is thrown * [MYFACES-1344] - get svn meta data out of impl jar file * [MYFACES-1381] - JSR-252 Issue #303: Clarified the use of encodeChildren with no renderer: render not no-op * [MYFACES-1474] - Fix for ActionListenerTag * [MYFACES-1521] - tag class generator (datatable . setVar()) * [MYFACES-1536] - Resolvers assume that all JSPs produce a FacesContext * [MYFACES-1544] - Verbatim Components are not created during JSP dispatch * [MYFACES-1548] - UIComponent State change if getValueBinding() is called. * [MYFACES-1551] - UIViewRoot.getPhaseListeners() must not be generated * [MYFACES-1557] - MyfacesConfig.getCurrentInstance not thread safe * [MYFACES-1562] - ValueBinding's getType always returns object when trying to converter for class * [MYFACES-1572] - getFirst() and getRows() methods in UIData don't return correct values * [MYFACES-1574] - HtmlOutputLink returns the wrong renderer type * [MYFACES-1575] - MethodBinding.invoke() should provide cause exception * [MYFACES-1576] - PropertyResolver.getType() should check arguments * [MYFACES-1577] - PropertyResolver should throw PropertyNotFoundException * [MYFACES-1579] - VariableResolver throws IllegalStateException because scope is unknown * [MYFACES-1582] - web-facesconfig_1_2.xsd contains restrictive copyright * [MYFACES-1584] - DateTimeConverter contains an extra non-spec field * [MYFACES-1588] - managed beans are not resolved when scope is none * [MYFACES-1592] - cannot render selectBooleanCheckbox tag when a boolean value is supplied * [MYFACES-1593] - javax.el.CompositeELResolver cannot resolve managed beans * [MYFACES-1594] - Passthrough attribute acceptcharset for form not being rendered * [MYFACES-1595] - spec compliance for HtmlCommandButton * [MYFACES-1596] - In an inputText, If the autocomplete attribute is not set or the value is on, render nothing. * [MYFACES-1597] - In inputTextarea, pass thru attributes cols and rows should not be rendered if they are not set * [MYFACES-1598] - JSF 1.2 TLD compliance: attributes binding and converter with wrong deferred-type * [MYFACES-1599] - JSF 1.2 TLD compliance: attribute action with wrong
Re: Re: Trinidad table paging
You are probably right about the automatic clean-up. That is actually what makes sense. However I should point to what caused me to think otherwise. In the Trinidad developer manual, on the page http://myfaces.apache.org/trinidad/devguide/communicatingBetweenPages.html it is stated: pageFlowScope never empties itself; the only way to clear pageFlowScope is to manually force it to clear What do you make of this? Am I interpreting it wrongly, is it not up-to-date? I imagine the scope is emptied at specific points, but I can't make out specifically when. Or conversely when the scope is kept between requests. Can anyone clarify this? On 7/16/07, Laperle, Denis [EMAIL PROTECTED] wrote: You're right about the automatic clean-up upon process termination but only a new window starts a new process so it's not very useful unless a new window is associated to each process and sub-process you need. I read the documentation about the Spring Webflow JSF integration and it seems very interesting to handle managed-beans state and navigation with this framework. I will seriously consider it for any serious JSF application development requiring conversation scope. -Message d'origine- De: news [mailto:[EMAIL PROTECTED] De la part de Laurie Harper Envoyé: 13 juillet 2007 17:38 À: users@myfaces.apache.org Objet: Re: Trinidad table paging Francisco Passos wrote: Great to know you've got it working. I'm now using the process scope feature of Trinidad and it's works fine but it means that I will have to clear the process scope context manually at the appropriate time within the application to avoid high memory consumption on the server side. That is exactly why I'm choosing to avoid to use process scope as much as I'm avoiding session. I guess I'll only use it if I need to do something session-scoped that requires support for tabbed browsing, for instance. I haven't played much with process scope and haven't used it recently, so I could be wrong, but: That's the point of process scope, though; the clean-up is handled for you automatically. That's the difference between process scope and session scope. IIRC, the way it works is that data you place *into* process scope in request N will be available *from* process scope in request N+1, but will be gone in request N+2 unless you explicitly refresh it. L.
Re: Trinidad table paging
As I have come to understand, this is expected. Although personally I believe it is not intuitive at all for any user. What happens is your bean is request scoped and as such its contents are lost when you make the second request. What you need is either request-scoped state saving (for instance using Tomahawk's saveState component) or using Trinidad's processScope, which I'm convinced uses session-scoped variables to keep state in a clever way. Personally I'm using t:saveState and everything works like a charm - table paging and inner table support (having tables render inside a column of a table) with paging. On 7/12/07, Laperle, Denis [EMAIL PROTECTED] wrote: Hello I'm trying to code a single page JSF application to get familiar with Trinidad components (1.0.1) and the JSF framework. I simply click on a command button to execute a method initialising a List property of a managed bean (scope=request) and use a tr:table component to display the 25 first element of the list. If I use the built-in paging support of the tr:table component to see the 25 next elements, the list elements disappears and a new managed bean gets instantiated. I just want to be sure that it's a normal behaviour and not something I'm doing wrong. If I set the managed bean with the session scope attribute it works fine but I thought it wouldn't be necessary to deal with session beans till I add some complexities like selecting an element in the list to display its detailed information on a second page. Please help clarifying this.
Login filter + redirect to previous
Good afternoon. I'm using a filter to check for a session bean with user login details and redirecting to a login page to enforce the user to login once more if the session has expired or if the user is not logged in. I'd like to know which alternatives I have to redirect the user after the login to the page he intended to go in the first place. Thank you, Francisco Passos
Re: [Trinidad] PPR + back button
Thanks for your clarification Adam. When do you expect there to be an official 1.0.2. build? On the same topic, how can I implement a button that can send me one page back (one navigation rule back) ? You'd need Trinidad 1.0.2. By the way, how will we be able to do this on Trinidad 1.0.2? Is it possible with the current snapshot? On 7/9/07, Adam Winer [EMAIL PROTECTED] wrote: On 7/9/07, Francisco Passos [EMAIL PROTECTED] wrote: Greetings. I've noticed with Trinidad 1.0.1 whenever I interact with elements that cause PPR, my browser's back history adds another entry. This way, when the user wants to navigate back, one might be surprised to remain in place, although the browser displays communication. Is this solved in Trinidad 1.0.2 where real AJAX is used instead of iframes? Yes, exactly. On the same topic, how can I implement a button that can send me one page back (one navigation rule back) ? You'd need Trinidad 1.0.2. -- Adam I was trying to use history.go(-1) but the forementioned problem stops me from doing so. Thank you, Francisco Passos
[Trinidad] PPR + back button
Greetings. I've noticed with Trinidad 1.0.1 whenever I interact with elements that cause PPR, my browser's back history adds another entry. This way, when the user wants to navigate back, one might be surprised to remain in place, although the browser displays communication. Is this solved in Trinidad 1.0.2 where real AJAX is used instead of iframes? On the same topic, how can I implement a button that can send me one page back (one navigation rule back) ? I was trying to use history.go(-1) but the forementioned problem stops me from doing so. Thank you, Francisco Passos
Re: [Trinidad] tr:panelTabbed examples?
Simon,
thank you once more.
I've tried the solution you provided, without the unnecessary component .
Apparently everything runs fine on the background (things get invoked,
properties get updated), but still neither the clicked tab becomes selected
nor does the outputText get updated.
On the first render of the page I get this warning twice:
WARNING: The viewId property in ViewIdPropertyMenuModel is null. The viewId
property is needed to find the focus rowKey.
5/Jul/2007 10:29:30
org.apache.myfaces.trinidad.model.ViewIdPropertyMenuModel _addToMap
Then, when I click a tab, I get it twice more and then refreshIt is called
(I'm printing something to the logs).
Might something still be missing? Maybe some way to tell the component to
generate an event which alerts its registered partialTriggers... Although
having it be partially re-rendered ought to do it.
Francisco
On 7/4/07, Simon Lessard [EMAIL PROTECTED] wrote:
Hello Francisco,
This is not how you must deal with binding. You can still let JSF
initialise the component. You'll need something like the following:
public class MyBeanClass
{
private UIComponent myNavigationPane;
public UIComponent getMyNavigationPane()
{
return myNavigationPane;
}
public void setMyNavigationPane(UIComponent myNavigationPane)
{
this.myNavigationPane = myNavigationPane;
}
public void refreshIt(ActionEvent ev)
{
RequestContext.getCurrentInstance().addPartialTarget(myNavigationPane);
}
}
In the page do the following:
tr:navigationPane id=tabber hint=tabs value=#{
fichaBean.gruposAtributos} var=grupoAtributos binding=#{
myBean.myNavigationPane}
f:facet name=nodeStamp
tr:commandNavigationItem action=#{fichaBean.selectGroup} id=tab
text=#{grupoAtributos.ndenomin} partialSubmit=true selected=#{
grupoAtributos.igrupoid eq fichaBean.selectedGroupId} actionListener=#{
myBean.refreshIt }
tr:setActionListener from=#{grupoAtributos.igrupoid} to=#{
fichaBean.selectedGroupId } /
/tr:commandNavigationItem
/f:facet
/tr:navigationPane
tr:outputText value=#{fichaBean.selectedGroupId}
partialTriggers=tabber /
~ Simon
On 7/4/07, Francisco Passos [EMAIL PROTECTED] wrote:
I'm on it. Having to create the binding is not dramatic :) I'm having
this exception though:
java.lang.NullPointerException
at
org.apache.myfaces.trinidad.component.UIXComponentBase.getClientId(
UIXComponentBase.java :261)
at
org.apache.myfaces.trinidadinternal.context.RequestContextImpl.addPartialTarget
(RequestContextImpl.java:488)
at pt.dgaiec.stp.beans.FichaBean.init(FichaBean.java:43)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(
NativeConstructorAccessorImpl.java:39)
Truncated. see log file for complete stacktrace
This is how I declared the reference:
private transient CoreNavigationPane navigationPane = new
CoreNavigationPane();
this is the xhtml now:
tr:navigationPane binding=#{fichaBean.navigationPane} id=tabber
hint=tabs value=#{fichaBean.gruposAtributos} var=grupoAtributos
f:facet name=nodeStamp
tr:commandNavigationItem action=#{fichaBean.selectGroup}
id=tab text=#{grupoAtributos.ndenomin} partialSubmit=true
selected=#{grupoAtributos.igrupoid eq fichaBean.selectedGroupId}
partialTriggers=:
tr:setActionListener from=#{grupoAtributos.igrupoid}
to=#{fichaBean.selectedGroupId} /
/tr:commandNavigationItem
/f:facet
/tr:navigationPane
tr:outputText id=texty value=#{fichaBean.selectedGroupId}
partialTriggers=tabber /
and this is the action called when a tab is clicked:
public void selectGroup() {
RequestContext.getCurrentInstance
().addPartialTarget(navigationPane);
}
I should mention that on the first render (before getting the
exception), I get this warning on the logs:
4/Jul/2007 19:27:40
org.apache.myfaces.trinidad.model.ViewIdPropertyMenuModel _addToMap
WARNING: The viewId property in ViewIdPropertyMenuModel is null. The
viewId property is needed to find the focus rowKey.
I understand there's an id missing. I just can't figure out where and
probably am going to start spreading ids all over the tags that don't have
one to see if anything changes.
It is probably a good time to thank you and the members here on the list
that have helped me out over the past weeks. So, thank you. I figure either
I'll get good at this or I'll get banned from the list :)
Francisco
On 7/4/07, Simon Lessard [EMAIL PROTECTED] wrote:
Hello again,
you can add a component to the list of component to refresh during a
PPR request by using the following code snippet:
RequestContext.getCurrentInstance().addPartialTarget(componentToRefresh);
Sadly you'll have to use binding attribute on our navigationPane to
get a ref to the UIComponent.
Regards,
~ Simon
On 7/4/07, Francisco Passos [EMAIL
Re: [Announce] Release of Apache MyFaces Trinidad 1.2.1
Is it possible to use this version on a non-J2EE container? I figure it should be possible, since one can use JSF 1.2 with facelets (and not JSP), but apparently there's a restriction in trinidad: org.apache.myfaces.trinidadinternal.application.ViewHandlerImp extends javax.faces.application.ViewHandlerWrapper I guess I'll have to stick with Trinidad 1.0.1 for the time being. On 7/5/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: The Apache MyFaces Trinidad team is pleased to announce the release of Apache MyFaces Trinidad Core 1.2.1. Apache MyFaces Trinidad 1.2.x is a JavaServer(tm) Faces 1.2 component library. Trinidad Core 1.2.1 is available in both binary and source distributions: * http://myfaces.apache.org/trinidad/download.html Apache MyFaces Trinidad is available in the central Maven repository under Group ID org.apache.myfaces.trinidad. Release Notes: http://tinyurl.com/yttonw Enjoy! -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
Re: [Trinidad] tr:panelTabbed examples?
Yes, I should have explained it sooner.
What I intend is to have a couple of tabs (dynamically rendered) that will
allow the presentation of something below (with PPR) which depends on which
tab is selected.
Since I'm not yet proficient with these technologies I'm going to evaluate
alternatives to the implementation of MenuModel.
Thank you for all your help!
Francisco Passos
On 7/5/07, Simon Lessard [EMAIL PROTECTED] wrote:
Hello Francisco,
From what I understand of your menu system, you want to stay in the same
page. If that's the case, then ViewIdPropertyModel is not appropriate as it
was explicitely made for one tab - one page/viewId. For your need you might
have to create your own implementation of MenuModel.
On 7/5/07, Francisco Passos [EMAIL PROTECTED] wrote:
Simon,
thank you once more.
I've tried the solution you provided, without the unnecessary component
. Apparently everything runs fine on the background (things get invoked,
properties get updated), but still neither the clicked tab becomes selected
nor does the outputText get updated.
On the first render of the page I get this warning twice:
WARNING: The viewId property in ViewIdPropertyMenuModel is null. The
viewId property is needed to find the focus rowKey.
5/Jul/2007 10:29:30
org.apache.myfaces.trinidad.model.ViewIdPropertyMenuModel _addToMap
Then, when I click a tab, I get it twice more and then refreshIt is
called (I'm printing something to the logs).
Might something still be missing? Maybe some way to tell the component
to generate an event which alerts its registered partialTriggers... Although
having it be partially re-rendered ought to do it.
Francisco
On 7/4/07, Simon Lessard [EMAIL PROTECTED] wrote:
Hello Francisco,
This is not how you must deal with binding. You can still let JSF
initialise the component. You'll need something like the following:
public class MyBeanClass
{
private UIComponent myNavigationPane;
public UIComponent getMyNavigationPane()
{
return myNavigationPane;
}
public void setMyNavigationPane(UIComponent myNavigationPane)
{
this.myNavigationPane = myNavigationPane;
}
public void refreshIt(ActionEvent ev)
{
RequestContext.getCurrentInstance().addPartialTarget(myNavigationPane);
}
}
In the page do the following:
tr:navigationPane id=tabber hint=tabs value=#{
fichaBean.gruposAtributos} var=grupoAtributos binding=#{
myBean.myNavigationPane}
f:facet name=nodeStamp
tr:commandNavigationItem action=#{fichaBean.selectGroup}
id=tab text=#{grupoAtributos.ndenomin} partialSubmit=true
selected=#{grupoAtributos.igrupoid eq fichaBean.selectedGroupId}
actionListener=#{myBean.refreshIt }
tr:setActionListener from=#{grupoAtributos.igrupoid} to=#{
fichaBean.selectedGroupId } /
/tr:commandNavigationItem
/f:facet
/tr:navigationPane
tr:outputText value=#{fichaBean.selectedGroupId}
partialTriggers=tabber /
~ Simon
On 7/4/07, Francisco Passos [EMAIL PROTECTED] wrote:
I'm on it. Having to create the binding is not dramatic :) I'm
having this exception though:
java.lang.NullPointerException
at
org.apache.myfaces.trinidad.component.UIXComponentBase.getClientId(
UIXComponentBase.java :261)
at
org.apache.myfaces.trinidadinternal.context.RequestContextImpl.addPartialTarget
(RequestContextImpl.java:488)
at pt.dgaiec.stp.beans.FichaBean.init(FichaBean.java:43)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(
NativeConstructorAccessorImpl.java:39)
Truncated. see log file for complete stacktrace
This is how I declared the reference:
private transient CoreNavigationPane navigationPane = new
CoreNavigationPane();
this is the xhtml now:
tr:navigationPane binding=#{fichaBean.navigationPane} id=tabber
hint=tabs value=#{fichaBean.gruposAtributos}
var=grupoAtributos
f:facet name=nodeStamp
tr:commandNavigationItem action=#{
fichaBean.selectGroup} id=tab text=#{grupoAtributos.ndenomin}
partialSubmit=true selected=#{grupoAtributos.igrupoid eq
fichaBean.selectedGroupId} partialTriggers=:
tr:setActionListener from=#{
grupoAtributos.igrupoid} to=#{fichaBean.selectedGroupId} /
/tr:commandNavigationItem
/f:facet
/tr:navigationPane
tr:outputText id=texty value=#{fichaBean.selectedGroupId}
partialTriggers=tabber /
and this is the action called when a tab is clicked:
public void selectGroup() {
RequestContext.getCurrentInstance
().addPartialTarget(navigationPane);
}
I should mention that on the first render (before getting the
exception), I get this warning on the logs:
4/Jul/2007 19:27:40
Re: [Trinidad] tr:panelTabbed examples?
Because it doesn't support dynamic tabs in the first place. I didn't try
tr:iterator though. And probably it's time to give it a try. I think when I
tried c:forEach it didn't work.
What I want is to show a list of items below. However I want them to be
filtered according to a category. I currently have a tr:table with all the
items.
What I need is:
1. dynamic tabs
2. know which tab is selected
3. force the rerender of the table on tab click (and because of number 2 I
can feed the elements from that category)
Francisco
On 7/5/07, Simon Lessard [EMAIL PROTECTED] wrote:
Hello Francisco,
Why did you drop panelTabbed for that need? It's what it does, show a part
of the page (showDetailItem content) based on user selection.
On 7/5/07, Francisco Passos [EMAIL PROTECTED] wrote:
Yes, I should have explained it sooner.
What I intend is to have a couple of tabs (dynamically rendered) that
will allow the presentation of something below (with PPR) which depends on
which tab is selected.
Since I'm not yet proficient with these technologies I'm going to
evaluate alternatives to the implementation of MenuModel.
Thank you for all your help!
Francisco Passos
On 7/5/07, Simon Lessard [EMAIL PROTECTED] wrote:
Hello Francisco,
From what I understand of your menu system, you want to stay in the
same page. If that's the case, then ViewIdPropertyModel is not appropriate
as it was explicitely made for one tab - one page/viewId. For your need you
might have to create your own implementation of MenuModel.
On 7/5/07, Francisco Passos [EMAIL PROTECTED] wrote:
Simon,
thank you once more.
I've tried the solution you provided, without the unnecessary
component . Apparently everything runs fine on the background (things get
invoked, properties get updated), but still neither the clicked tab
becomes
selected nor does the outputText get updated.
On the first render of the page I get this warning twice:
WARNING: The viewId property in ViewIdPropertyMenuModel is null. The
viewId property is needed to find the focus rowKey.
5/Jul/2007 10:29:30
org.apache.myfaces.trinidad.model.ViewIdPropertyMenuModel _addToMap
Then, when I click a tab, I get it twice more and then refreshIt is
called (I'm printing something to the logs).
Might something still be missing? Maybe some way to tell the
component to generate an event which alerts its registered
partialTriggers... Although having it be partially re-rendered ought to do
it.
Francisco
On 7/4/07, Simon Lessard [EMAIL PROTECTED] wrote:
Hello Francisco,
This is not how you must deal with binding. You can still let JSF
initialise the component. You'll need something like the following:
public class MyBeanClass
{
private UIComponent myNavigationPane;
public UIComponent getMyNavigationPane()
{
return myNavigationPane;
}
public void setMyNavigationPane(UIComponent myNavigationPane)
{
this.myNavigationPane = myNavigationPane;
}
public void refreshIt(ActionEvent ev)
{
RequestContext.getCurrentInstance().addPartialTarget(myNavigationPane);
}
}
In the page do the following:
tr:navigationPane id=tabber hint=tabs value=#{
fichaBean.gruposAtributos} var=grupoAtributos binding=#{
myBean.myNavigationPane}
f:facet name=nodeStamp
tr:commandNavigationItem action=#{fichaBean.selectGroup}
id=tab text=#{grupoAtributos.ndenomin} partialSubmit=true
selected=#{grupoAtributos.igrupoid eq fichaBean.selectedGroupId}
actionListener=#{myBean.refreshIt }
tr:setActionListener from=#{grupoAtributos.igrupoid}
to=#{ fichaBean.selectedGroupId } /
/tr:commandNavigationItem
/f:facet
/tr:navigationPane
tr:outputText value=#{fichaBean.selectedGroupId}
partialTriggers=tabber /
~ Simon
On 7/4/07, Francisco Passos [EMAIL PROTECTED] wrote:
I'm on it. Having to create the binding is not dramatic :) I'm
having this exception though:
java.lang.NullPointerException
at
org.apache.myfaces.trinidad.component.UIXComponentBase.getClientId(
UIXComponentBase.java :261)
at
org.apache.myfaces.trinidadinternal.context.RequestContextImpl.addPartialTarget
(RequestContextImpl.java:488)
at pt.dgaiec.stp.beans.FichaBean.init(FichaBean.java
:43)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance0 (Native
Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance
(NativeConstructorAccessorImpl.java:39)
Truncated. see log file for complete stacktrace
This is how I declared the reference:
private transient CoreNavigationPane navigationPane = new
CoreNavigationPane();
this is the xhtml now
Re: [Trinidad] tr:panelTabbed examples?
That's a good enough encouragement.
But... how should I go about at it?
I imagine I must extend org.apache.myfaces.model.MenuModel. But how do I use
it?
On 7/5/07, Simon Lessard [EMAIL PROTECTED] wrote:
Implementing your own MenuModel seems like a good solution then. It's not
as bad as it seems really.
On 7/5/07, Francisco Passos [EMAIL PROTECTED] wrote:
Because it doesn't support dynamic tabs in the first place. I didn't try
tr:iterator though. And probably it's time to give it a try. I think when I
tried c:forEach it didn't work.
What I want is to show a list of items below. However I want them to be
filtered according to a category. I currently have a tr:table with all the
items.
What I need is:
1. dynamic tabs
2. know which tab is selected
3. force the rerender of the table on tab click (and because of number 2
I can feed the elements from that category)
Francisco
On 7/5/07, Simon Lessard [EMAIL PROTECTED] wrote:
Hello Francisco,
Why did you drop panelTabbed for that need? It's what it does, show a
part of the page (showDetailItem content) based on user selection.
On 7/5/07, Francisco Passos [EMAIL PROTECTED] wrote:
Yes, I should have explained it sooner.
What I intend is to have a couple of tabs (dynamically rendered)
that will allow the presentation of something below (with PPR) which
depends
on which tab is selected.
Since I'm not yet proficient with these technologies I'm going to
evaluate alternatives to the implementation of MenuModel.
Thank you for all your help!
Francisco Passos
On 7/5/07, Simon Lessard [EMAIL PROTECTED] wrote:
Hello Francisco,
From what I understand of your menu system, you want to stay in
the same page. If that's the case, then ViewIdPropertyModel is not
appropriate as it was explicitely made for one tab - one page/viewId.
For
your need you might have to create your own implementation of MenuModel.
On 7/5/07, Francisco Passos [EMAIL PROTECTED] wrote:
Simon,
thank you once more.
I've tried the solution you provided, without the unnecessary
component . Apparently everything runs fine on the background (things
get
invoked, properties get updated), but still neither the clicked tab
becomes
selected nor does the outputText get updated.
On the first render of the page I get this warning twice:
WARNING: The viewId property in ViewIdPropertyMenuModel is null.
The viewId property is needed to find the focus rowKey.
5/Jul/2007 10:29:30
org.apache.myfaces.trinidad.model.ViewIdPropertyMenuModel_addToMap
Then, when I click a tab, I get it twice more and then refreshIt
is called (I'm printing something to the logs).
Might something still be missing? Maybe some way to tell the
component to generate an event which alerts its registered
partialTriggers... Although having it be partially re-rendered ought
to do
it.
Francisco
On 7/4/07, Simon Lessard [EMAIL PROTECTED] wrote:
Hello Francisco,
This is not how you must deal with binding. You can still let
JSF initialise the component. You'll need something like the
following:
public class MyBeanClass
{
private UIComponent myNavigationPane;
public UIComponent getMyNavigationPane()
{
return myNavigationPane;
}
public void setMyNavigationPane(UIComponent
myNavigationPane)
{
this.myNavigationPane = myNavigationPane;
}
public void refreshIt(ActionEvent ev)
{
RequestContext.getCurrentInstance().addPartialTarget(myNavigationPane);
}
}
In the page do the following:
tr:navigationPane id=tabber hint=tabs value=#{
fichaBean.gruposAtributos} var=grupoAtributos binding=#{
myBean.myNavigationPane}
f:facet name=nodeStamp
tr:commandNavigationItem action=#{fichaBean.selectGroup}
id=tab text=#{grupoAtributos.ndenomin}
partialSubmit=true selected=#{grupoAtributos.igrupoid eq
fichaBean.selectedGroupId} actionListener=#{myBean.refreshIt}
tr:setActionListener from=#{grupoAtributos.igrupoid}
to=#{ fichaBean.selectedGroupId } /
/tr:commandNavigationItem
/f:facet
/tr:navigationPane
tr:outputText value=#{fichaBean.selectedGroupId}
partialTriggers=tabber /
~ Simon
On 7/4/07, Francisco Passos [EMAIL PROTECTED]
wrote:
I'm on it. Having to create the binding is not dramatic :)
I'm having this exception though:
java.lang.NullPointerException
at
org.apache.myfaces.trinidad.component.UIXComponentBase.getClientId(
UIXComponentBase.java :261
Re: [Announce] Release of Apache MyFaces Trinidad 1.2.1
That's it Adam, I'm using myfaces 1.1.5 which is JSF 1.1. I wasn't realizing it, thank you. Do you know where I can download 1.2.5 to try it out? Francisco On 7/5/07, Adam Winer [EMAIL PROTECTED] wrote: On 7/5/07, Francisco Passos [EMAIL PROTECTED] wrote: Is it possible to use this version on a non-J2EE container? I figure it should be possible, since one can use JSF 1.2 with facelets (and not JSP), but apparently there's a restriction in trinidad: org.apache.myfaces.trinidadinternal.application.ViewHandlerImp extends javax.faces.application.ViewHandlerWrapper That class is in JSF 1.2, which this version of Trinidad requires. As long as your webapp contains JSF 1.2, you should be fine. If this is giving you a problem, you've still got JSF 1.1 installed. -- Adam I guess I'll have to stick with Trinidad 1.0.1 for the time being. On 7/5/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: The Apache MyFaces Trinidad team is pleased to announce the release of Apache MyFaces Trinidad Core 1.2.1. Apache MyFaces Trinidad 1.2.x is a JavaServer(tm) Faces 1.2 component library. Trinidad Core 1.2.1 is available in both binary and source distributions: * http://myfaces.apache.org/trinidad/download.html Apache MyFaces Trinidad is available in the central Maven repository under Group ID org.apache.myfaces.trinidad. Release Notes: http://tinyurl.com/yttonw Enjoy! -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
Re: [Trinidad] tr:panelTabbed examples?
Thank you, your example is great.
However, how do you know what tab has been clicked, so you can act
accordingly on the actionListener?
On 7/2/07, Renzo Tomaselli [EMAIL PROTECTED] wrote:
Francisco,
component tr:navigationPane is an iterating component by itself - no
need for an explicit loop. I do it like this (using Facelets):
ui:component
c:if test=#{bean.visible}
t:saveState id=selected value=#{bean.selected}/
t:saveState id=tabs value=#{bean.tabs}/
tr:navigationPane id=tabber hint=tabs value=#{bean.tabModel}
var=tab styleClass=navigator
f:facet name=nodeStamp
tr:commandNavigationItem text=#{tab.label}
actionListener=#{bean.navigation}
id=tab selected=#{cx:isSelected(bean, tab)}
icon=#{tab.icon}/
/f:facet
/tr:navigationPane
cx:include src=#{bean.component} bean=#{bean.componentBean}
container=#{container}tabby:/
/c:if
/ui:component
Here everythings - from the tab list to the child component to appear
below the tabs - is dynamically taken from a bean.
Tab list and current selection are made persistent across requests by
means of saveState (my beans are only request-scoped).
Hope it helps.
-- Renzo
Francisco Passos wrote:
By the way, I'm trying to populate dinamically either a panelTabbed or a
navigationPane.
When using ui:repeat, panelTabbed renders incorrectly (no content appears)
and this is shown on the logs:
WARNING: Only tr:showDetailItem is allowed as child of tr:panelTabbed.
When using ui:repeat and navigationPane, an exception is thrown:
SEVERE: Warning: illegal component hierarchy detected, expected UIXCommand
but found another type of component instead.
java.lang.ClassCastException : com.sun.facelets.component.UIRepeat
I'm going to try my luck with JSTL now, nevertheless if you know of a
solution, do tell :)
--Francisco
On 7/2/07, * Francisco Passos* [EMAIL PROTECTED] wrote:
Simon and Matthias,
thank you for clearing my doubt. By the way, if I may leave the
suggestion, it would be cool if panelTabbed had alternative ways for
presentation, much like navigationPage.
As far as the wiki, I've added the missing entry to the page for
completeness, although obviously it may still be incomplete.
--Francisco
On 7/2/07, *Matthias Wessendorf* [EMAIL PROTECTED] wrote:
Francisco,
we started a wiki, containing infos like this, in the past,
but never updated it.
feel free to join ;-)
-M
On 7/2/07, Simon Lessard [EMAIL PROTECTED] wrote:
Hello Francisco,
No, menuTabs was replaced by navigationPane with hint attribute set to
tabs.
Regards,
~ Simon
On 7/2/07, Francisco Passos [EMAIL PROTECTED] wrote:
Thank you.
The correspondence I couldn't find in the wiki was for the component
af:menuTabs, but probably panelTabbed also replaces it.
On 6/29/07, Adam Winer [EMAIL PROTECTED] wrote:
Actually, the Wiki page shows the renaming:
panelTabbed was formerly called showOneTabs.
There's an example in trinidad-demo.
-- Adam
On 6/29/07, Francisco Passos [EMAIL PROTECTED] wrote:
Hello there.
I'm evaluating the usage of a panelTabbed. Are there any working
examples of
this component?
The only example I have is from an ADF Faces app, which uses
af:menuTabs,
but http://wiki.apache.org/myfaces/Trinidad_renaming
does
not mention any changes to this component.
Thanks,
Francisco
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
mail: matzew-at-apache-dot-org
Re: [Trinidad] tr:panelTabbed examples?
Renzo, yours is a cool solution, but it depends on the way the subcomponents
are stamped, which is an information I believe we theoretically shouldn't
depend on, unless we had some kind of control over the way the stamping
goes.
Simon, I'm trying your solution and here's what I've come to:
tr:navigationPane id=tabber hint=tabs value=#{
fichaBean.gruposAtributos} var=grupoAtributos
f:facet name=nodeStamp
tr:commandNavigationItem action=#{fichaBean.selectGroup}
id=tab text=#{grupoAtributos.ndenomin} partialSubmit=true selected=#{
grupoAtributos.igrupoid eq fichaBean.selectedGroupId}
tr:setActionListener from=#{grupoAtributos.igrupoid}
to=#{fichaBean.selectedGroupId} /
/tr:commandNavigationItem
/f:facet
/tr:navigationPane
tr:outputText value=#{fichaBean.selectedGroupId}
partialTriggers=tab /
I've checked that the selectedGroupId property is being updated when I click
on the tab, which is the good news :)
The bad news is that the tab isn't changing its aspect to show it is
selected. And the outputText below does not update either. I've tried
setting partialTriggers to tab as well as tabber. What am I still
missing?
On 7/4/07, Renzo Tomaselli [EMAIL PROTECTED] wrote:
I simply parse the component id. Being an iterating component - Tridindad
adds a progressive index while stamping out subcomponents:
public void navigation(ActionEvent event) {
FacesContext fc = FacesContext.getCurrentInstance();
UIComponent actionItem = event.getComponent();
String id = actionItem.getClientId(fc);
int i = id.lastIndexOf(NamingContainer.SEPARATOR_CHAR);
if (i = 0) {
id = id.substring(0, i);
i = id.lastIndexOf(NamingContainer.SEPARATOR_CHAR);
id = id.substring(i + 1);
int newSelected = Integer.parseInt(id);
.
This should work well for all Trinidad iterating components, provided that
stamping includesTrinidad components only. Otherwise, the index can be
easily forgotten by Trinidad (then duplicated id warnings), don't ask me
why.
-- Renzo
Francisco Passos wrote:
Thank you, your example is great.
However, how do you know what tab has been clicked, so you can act
accordingly on the actionListener?
On 7/2/07, * Renzo Tomaselli* [EMAIL PROTECTED] wrote:
Francisco,
component tr:navigationPane is an iterating component by itself - no
need for an explicit loop. I do it like this (using Facelets):
ui:component
c:if test=#{bean.visible}
t:saveState id=selected value=#{bean.selected}/
t:saveState id=tabs value=#{bean.tabs}/
tr:navigationPane id=tabber hint=tabs value=#{bean.tabModel}
var=tab styleClass=navigator
f:facet name=nodeStamp
tr:commandNavigationItem text=#{tab.label}
actionListener=#{bean.navigation}
id=tab selected=#{cx:isSelected(bean, tab)}
icon=#{tab.icon}/
/f:facet
/tr:navigationPane
cx:include src=#{bean.component} bean=#{bean.componentBean}
container=#{container}tabby:/
/c:if
/ui:component
Here everythings - from the tab list to the child component to appear
below the tabs - is dynamically taken from a bean.
Tab list and current selection are made persistent across requests by
means of saveState (my beans are only request-scoped).
Hope it helps.
-- Renzo
Francisco Passos wrote:
By the way, I'm trying to populate dinamically either a panelTabbed or a
navigationPane.
When using ui:repeat, panelTabbed renders incorrectly (no content appears)
and this is shown on the logs:
WARNING: Only tr:showDetailItem is allowed as child of tr:panelTabbed.
When using ui:repeat and navigationPane, an exception is thrown:
SEVERE: Warning: illegal component hierarchy detected, expected UIXCommand
but found another type of component instead.
java.lang.ClassCastException : com.sun.facelets.component.UIRepeat
I'm going to try my luck with JSTL now, nevertheless if you know of a
solution, do tell :)
--Francisco
On 7/2/07, * Francisco Passos* [EMAIL PROTECTED] wrote:
Simon and Matthias,
thank you for clearing my doubt. By the way, if I may leave the
suggestion, it would be cool if panelTabbed had alternative ways for
presentation, much like navigationPage.
As far as the wiki, I've added the missing entry to the page for
completeness, although obviously it may still be incomplete.
--Francisco
On 7/2/07, *Matthias Wessendorf* [EMAIL PROTECTED] wrote:
Francisco,
we started a wiki, containing infos like this, in the past,
but never updated it.
feel free to join ;-)
-M
On 7/2/07, Simon Lessard [EMAIL PROTECTED] wrote:
Hello Francisco,
No, menuTabs was replaced by navigationPane with hint attribute set to
tabs.
Regards,
~ Simon
On 7/2/07, Francisco Passos [EMAIL PROTECTED] wrote:
Thank you.
The correspondence I couldn't find in the wiki was for the component
af:menuTabs, but probably panelTabbed also replaces it.
On 6
Re: [Trinidad] tr:panelTabbed examples?
Just tried setting partialTriggers=tab on the panelPage. Same thing still.
On 7/4/07, Simon Lessard [EMAIL PROTECTED] wrote:
Hello Francisco,
Hmmm, strange... Did you try to set a partialTriggers on the
navigationPane?
Regards,
~ Simon
On 7/4/07, Francisco Passos [EMAIL PROTECTED] wrote:
Renzo, yours is a cool solution, but it depends on the way the
subcomponents are stamped, which is an information I believe we
theoretically shouldn't depend on, unless we had some kind of control over
the way the stamping goes.
Simon, I'm trying your solution and here's what I've come to:
tr:navigationPane id=tabber hint=tabs value=#{
fichaBean.gruposAtributos} var=grupoAtributos
f:facet name=nodeStamp
tr:commandNavigationItem action=#{fichaBean.selectGroup}
id=tab text=#{grupoAtributos.ndenomin} partialSubmit=true
selected=#{ grupoAtributos.igrupoid eq fichaBean.selectedGroupId}
tr:setActionListener from=#{grupoAtributos.igrupoid}
to=#{fichaBean.selectedGroupId} /
/tr:commandNavigationItem
/f:facet
/tr:navigationPane
tr:outputText value=#{fichaBean.selectedGroupId}
partialTriggers=tab /
I've checked that the selectedGroupId property is being updated when I
click on the tab, which is the good news :)
The bad news is that the tab isn't changing its aspect to show it is
selected. And the outputText below does not update either. I've tried
setting partialTriggers to tab as well as tabber. What am I still
missing?
On 7/4/07, Renzo Tomaselli [EMAIL PROTECTED] wrote:
I simply parse the component id. Being an iterating component -
Tridindad adds a progressive index while stamping out subcomponents:
public void navigation(ActionEvent event) {
FacesContext fc = FacesContext.getCurrentInstance();
UIComponent actionItem = event.getComponent();
String id = actionItem.getClientId(fc);
int i = id.lastIndexOf(NamingContainer.SEPARATOR_CHAR);
if (i = 0) {
id = id.substring(0, i);
i = id.lastIndexOf(NamingContainer.SEPARATOR_CHAR);
id = id.substring(i + 1);
int newSelected = Integer.parseInt(id);
.
This should work well for all Trinidad iterating components, provided
that stamping includesTrinidad components only. Otherwise, the index can be
easily forgotten by Trinidad (then duplicated id warnings), don't ask me
why.
-- Renzo
Francisco Passos wrote:
Thank you, your example is great.
However, how do you know what tab has been clicked, so you can act
accordingly on the actionListener?
On 7/2/07, * Renzo Tomaselli* [EMAIL PROTECTED] wrote:
Francisco,
component tr:navigationPane is an iterating component by itself -
no need for an explicit loop. I do it like this (using Facelets):
ui:component
c:if test=#{bean.visible}
t:saveState id=selected value=#{bean.selected}/
t:saveState id=tabs value=#{bean.tabs}/
tr:navigationPane id=tabber hint=tabs value=#{
bean.tabModel} var=tab styleClass=navigator
f:facet name=nodeStamp
tr:commandNavigationItem text=#{tab.label}
actionListener=#{bean.navigation}
id=tab selected=#{cx:isSelected(bean,
tab)} icon=#{tab.icon}/
/f:facet
/tr:navigationPane
cx:include src=#{bean.component} bean=#{bean.componentBean}
container=#{container}tabby:/
/c:if
/ui:component
Here everythings - from the tab list to the child component to appear
below the tabs - is dynamically taken from a bean.
Tab list and current selection are made persistent across requests by
means of saveState (my beans are only request-scoped).
Hope it helps.
-- Renzo
Francisco Passos wrote:
By the way, I'm trying to populate dinamically either a panelTabbed or
a navigationPane.
When using ui:repeat, panelTabbed renders incorrectly (no content
appears) and this is shown on the logs:
WARNING: Only tr:showDetailItem is allowed as child of tr:panelTabbed.
When using ui:repeat and navigationPane, an exception is thrown:
SEVERE: Warning: illegal component hierarchy detected, expected
UIXCommand but found another type of component instead.
java.lang.ClassCastException : com.sun.facelets.component.UIRepeat
I'm going to try my luck with JSTL now, nevertheless if you know of a
solution, do tell :)
--Francisco
On 7/2/07, * Francisco Passos* [EMAIL PROTECTED] wrote:
Simon and Matthias,
thank you for clearing my doubt. By the way, if I may leave the
suggestion, it would be cool if panelTabbed had alternative ways for
presentation, much like navigationPage.
As far as the wiki, I've added the missing entry to the page for
completeness, although obviously it may still be incomplete.
--Francisco
On 7/2/07, *Matthias Wessendorf* [EMAIL PROTECTED] wrote
Re: [Trinidad] tr:panelTabbed examples?
I meant panelTabbed, sorry.
On 7/4/07, Francisco Passos [EMAIL PROTECTED] wrote:
Just tried setting partialTriggers=tab on the panelPage. Same thing
still.
On 7/4/07, Simon Lessard [EMAIL PROTECTED] wrote:
Hello Francisco,
Hmmm, strange... Did you try to set a partialTriggers on the
navigationPane?
Regards,
~ Simon
On 7/4/07, Francisco Passos [EMAIL PROTECTED] wrote:
Renzo, yours is a cool solution, but it depends on the way the
subcomponents are stamped, which is an information I believe we
theoretically shouldn't depend on, unless we had some kind of control over
the way the stamping goes.
Simon, I'm trying your solution and here's what I've come to:
tr:navigationPane id=tabber hint=tabs value=#{
fichaBean.gruposAtributos} var=grupoAtributos
f:facet name=nodeStamp
tr:commandNavigationItem action=#{fichaBean.selectGroup}
id=tab text=#{grupoAtributos.ndenomin} partialSubmit=true
selected=#{ grupoAtributos.igrupoid eq fichaBean.selectedGroupId}
tr:setActionListener from=#{grupoAtributos.igrupoid}
to=#{fichaBean.selectedGroupId} /
/tr:commandNavigationItem
/f:facet
/tr:navigationPane
tr:outputText value=#{fichaBean.selectedGroupId}
partialTriggers=tab /
I've checked that the selectedGroupId property is being updated when I
click on the tab, which is the good news :)
The bad news is that the tab isn't changing its aspect to show it is
selected. And the outputText below does not update either. I've tried
setting partialTriggers to tab as well as tabber. What am I still
missing?
On 7/4/07, Renzo Tomaselli [EMAIL PROTECTED] wrote:
I simply parse the component id. Being an iterating component -
Tridindad adds a progressive index while stamping out subcomponents:
public void navigation(ActionEvent event) {
FacesContext fc = FacesContext.getCurrentInstance();
UIComponent actionItem = event.getComponent();
String id = actionItem.getClientId(fc);
int i = id.lastIndexOf(NamingContainer.SEPARATOR_CHAR);
if (i = 0) {
id = id.substring(0, i);
i = id.lastIndexOf(NamingContainer.SEPARATOR_CHAR);
id = id.substring(i + 1);
int newSelected = Integer.parseInt(id);
.
This should work well for all Trinidad iterating components,
provided that stamping includesTrinidad components only. Otherwise, the
index can be easily forgotten by Trinidad (then duplicated id warnings),
don't ask me why.
-- Renzo
Francisco Passos wrote:
Thank you, your example is great.
However, how do you know what tab has been clicked, so you can act
accordingly on the actionListener?
On 7/2/07, * Renzo Tomaselli* [EMAIL PROTECTED] wrote:
Francisco,
component tr:navigationPane is an iterating component by itself
- no need for an explicit loop. I do it like this (using Facelets):
ui:component
c:if test=#{bean.visible}
t:saveState id=selected value=#{bean.selected}/
t:saveState id=tabs value=#{bean.tabs}/
tr:navigationPane id=tabber hint=tabs value=#{
bean.tabModel} var=tab styleClass=navigator
f:facet name=nodeStamp
tr:commandNavigationItem text=#{tab.label}
actionListener=#{bean.navigation}
id=tab selected=#{cx:isSelected(bean,
tab)} icon=#{tab.icon}/
/f:facet
/tr:navigationPane
cx:include src=#{bean.component} bean=#{
bean.componentBean} container=#{container}tabby:/
/c:if
/ui:component
Here everythings - from the tab list to the child component to
appear below the tabs - is dynamically taken from a bean.
Tab list and current selection are made persistent across requests
by means of saveState (my beans are only request-scoped).
Hope it helps.
-- Renzo
Francisco Passos wrote:
By the way, I'm trying to populate dinamically either a panelTabbed
or a navigationPane.
When using ui:repeat, panelTabbed renders incorrectly (no content
appears) and this is shown on the logs:
WARNING: Only tr:showDetailItem is allowed as child of
tr:panelTabbed.
When using ui:repeat and navigationPane, an exception is thrown:
SEVERE: Warning: illegal component hierarchy detected, expected
UIXCommand but found another type of component instead.
java.lang.ClassCastException : com.sun.facelets.component.UIRepeat
I'm going to try my luck with JSTL now, nevertheless if you know of
a solution, do tell :)
--Francisco
On 7/2/07, * Francisco Passos* [EMAIL PROTECTED] wrote:
Simon and Matthias,
thank you for clearing my doubt. By the way, if I may leave the
suggestion, it would be cool if panelTabbed had alternative ways for
presentation, much like navigationPage
Re: [Trinidad] tr:panelTabbed examples?
programatically add the navigationPane as a partialTarget using
RequestContext
Sorry for asking, but how can I do this? Is there documentation on this?
Thank you for your support.
Francisco
On 7/4/07, Simon Lessard [EMAIL PROTECTED] wrote:
Hello Francisco,
your problem is with partialTriggers, you must not use tab the id of the
navigation item won't be simply that. since navigationPane is an
UIXIterator, it's also a NamingContainer, thus it will generated different
client ids including the rowKey. You might have to programatically add the
navigationPane as a partialTarget using RequestContext. You can then set the
partialTriggers value of your outputText to the navigationPane's id. I think
it will work.
Regards,
~ Simon
On 7/4/07, Francisco Passos [EMAIL PROTECTED] wrote:
I meant panelTabbed, sorry.
On 7/4/07, Francisco Passos [EMAIL PROTECTED] wrote:
Just tried setting partialTriggers=tab on the panelPage. Same thing
still.
On 7/4/07, Simon Lessard [EMAIL PROTECTED] wrote:
Hello Francisco,
Hmmm, strange... Did you try to set a partialTriggers on the
navigationPane?
Regards,
~ Simon
On 7/4/07, Francisco Passos [EMAIL PROTECTED] wrote:
Renzo, yours is a cool solution, but it depends on the way the
subcomponents are stamped, which is an information I believe we
theoretically shouldn't depend on, unless we had some kind of control
over
the way the stamping goes.
Simon, I'm trying your solution and here's what I've come to:
tr:navigationPane id=tabber hint=tabs value=#{
fichaBean.gruposAtributos} var=grupoAtributos
f:facet name=nodeStamp
tr:commandNavigationItem action=#{
fichaBean.selectGroup} id=tab text=#{grupoAtributos.ndenomin}
partialSubmit=true selected=#{ grupoAtributos.igrupoid eq
fichaBean.selectedGroupId}
tr:setActionListener from=#{
grupoAtributos.igrupoid} to=#{fichaBean.selectedGroupId} /
/tr:commandNavigationItem
/f:facet
/tr:navigationPane
tr:outputText value=#{fichaBean.selectedGroupId}
partialTriggers=tab /
I've checked that the selectedGroupId property is being updated
when I click on the tab, which is the good news :)
The bad news is that the tab isn't changing its aspect to show it
is selected. And the outputText below does not update either. I've tried
setting partialTriggers to tab as well as tabber. What am I still
missing?
On 7/4/07, Renzo Tomaselli [EMAIL PROTECTED] wrote:
I simply parse the component id. Being an iterating component -
Tridindad adds a progressive index while stamping out subcomponents:
public void navigation(ActionEvent event) {
FacesContext fc = FacesContext.getCurrentInstance();
UIComponent actionItem = event.getComponent();
String id = actionItem.getClientId(fc);
int i = id.lastIndexOf(NamingContainer.SEPARATOR_CHAR);
if (i = 0) {
id = id.substring(0, i);
i = id.lastIndexOf(NamingContainer.SEPARATOR_CHAR);
id = id.substring(i + 1);
int newSelected = Integer.parseInt(id);
.
This should work well for all Trinidad iterating components,
provided that stamping includesTrinidad components only. Otherwise,
the
index can be easily forgotten by Trinidad (then duplicated id
warnings),
don't ask me why.
-- Renzo
Francisco Passos wrote:
Thank you, your example is great.
However, how do you know what tab has been clicked, so you can
act accordingly on the actionListener?
On 7/2/07, * Renzo Tomaselli* [EMAIL PROTECTED]
wrote:
Francisco,
component tr:navigationPane is an iterating component by
itself - no need for an explicit loop. I do it like this (using
Facelets):
ui:component
c:if test=#{bean.visible}
t:saveState id=selected value=#{bean.selected}/
t:saveState id=tabs value=#{bean.tabs}/
tr:navigationPane id=tabber hint=tabs value=#{
bean.tabModel} var=tab styleClass=navigator
f:facet name=nodeStamp
tr:commandNavigationItem text=#{tab.label}
actionListener=#{bean.navigation}
id=tab selected=#{cx:isSelected(bean,
tab)} icon=#{tab.icon}/
/f:facet
/tr:navigationPane
cx:include src=#{bean.component} bean=#{
bean.componentBean} container=#{container}tabby:/
/c:if
/ui:component
Here everythings - from the tab list to the child component to
appear below the tabs - is dynamically taken from a bean.
Tab list and current selection are made persistent across
requests by means of saveState (my beans are only
Re: [Trinidad] tr:panelTabbed examples?
I'm on it. Having to create the binding is not dramatic :) I'm having this
exception though:
java.lang.NullPointerException
at
org.apache.myfaces.trinidad.component.UIXComponentBase.getClientId(
UIXComponentBase.java:261)
at
org.apache.myfaces.trinidadinternal.context.RequestContextImpl.addPartialTarget
(RequestContextImpl.java:488)
at pt.dgaiec.stp.beans.FichaBean.init(FichaBean.java:43)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(
NativeConstructorAccessorImpl.java:39)
Truncated. see log file for complete stacktrace
This is how I declared the reference:
private transient CoreNavigationPane navigationPane = new
CoreNavigationPane();
this is the xhtml now:
tr:navigationPane binding=#{fichaBean.navigationPane} id=tabber
hint=tabs value=#{fichaBean.gruposAtributos} var=grupoAtributos
f:facet name=nodeStamp
tr:commandNavigationItem action=#{fichaBean.selectGroup}
id=tab text=#{grupoAtributos.ndenomin} partialSubmit=true selected=#{
grupoAtributos.igrupoid eq fichaBean.selectedGroupId} partialTriggers=:
tr:setActionListener from=#{grupoAtributos.igrupoid}
to=#{fichaBean.selectedGroupId} /
/tr:commandNavigationItem
/f:facet
/tr:navigationPane
tr:outputText id=texty value=#{fichaBean.selectedGroupId}
partialTriggers=tabber /
and this is the action called when a tab is clicked:
public void selectGroup() {
RequestContext.getCurrentInstance().addPartialTarget(navigationPane);
}
I should mention that on the first render (before getting the exception), I
get this warning on the logs:
4/Jul/2007 19:27:40
org.apache.myfaces.trinidad.model.ViewIdPropertyMenuModel _addToMap
WARNING: The viewId property in ViewIdPropertyMenuModel is null. The viewId
property is needed to find the focus rowKey.
I understand there's an id missing. I just can't figure out where and
probably am going to start spreading ids all over the tags that don't have
one to see if anything changes.
It is probably a good time to thank you and the members here on the list
that have helped me out over the past weeks. So, thank you. I figure either
I'll get good at this or I'll get banned from the list :)
Francisco
On 7/4/07, Simon Lessard [EMAIL PROTECTED] wrote:
Hello again,
you can add a component to the list of component to refresh during a PPR
request by using the following code snippet:
RequestContext.getCurrentInstance ().addPartialTarget(componentToRefresh);
Sadly you'll have to use binding attribute on our navigationPane to get a
ref to the UIComponent.
Regards,
~ Simon
On 7/4/07, Francisco Passos [EMAIL PROTECTED] wrote:
programatically add the navigationPane as a partialTarget using
RequestContext
Sorry for asking, but how can I do this? Is there documentation on this?
Thank you for your support.
Francisco
On 7/4/07, Simon Lessard [EMAIL PROTECTED] wrote:
Hello Francisco,
your problem is with partialTriggers, you must not use tab the id of
the navigation item won't be simply that. since navigationPane is an
UIXIterator, it's also a NamingContainer, thus it will generated different
client ids including the rowKey. You might have to programatically add the
navigationPane as a partialTarget using RequestContext. You can then set the
partialTriggers value of your outputText to the navigationPane's id. I think
it will work.
Regards,
~ Simon
On 7/4/07, Francisco Passos [EMAIL PROTECTED] wrote:
I meant panelTabbed, sorry.
On 7/4/07, Francisco Passos [EMAIL PROTECTED] wrote:
Just tried setting partialTriggers=tab on the panelPage. Same
thing still.
On 7/4/07, Simon Lessard [EMAIL PROTECTED] wrote:
Hello Francisco,
Hmmm, strange... Did you try to set a partialTriggers on the
navigationPane?
Regards,
~ Simon
On 7/4/07, Francisco Passos [EMAIL PROTECTED] wrote:
Renzo, yours is a cool solution, but it depends on the way the
subcomponents are stamped, which is an information I believe we
theoretically shouldn't depend on, unless we had some kind of
control over
the way the stamping goes.
Simon, I'm trying your solution and here's what I've come to:
tr:navigationPane id=tabber hint=tabs value=#{
fichaBean.gruposAtributos} var=grupoAtributos
f:facet name=nodeStamp
tr:commandNavigationItem action=#{
fichaBean.selectGroup} id=tab text=#{
grupoAtributos.ndenomin} partialSubmit=true selected=#{
grupoAtributos.igrupoid eq fichaBean.selectedGroupId}
tr:setActionListener from=#{
grupoAtributos.igrupoid} to=#{fichaBean.selectedGroupId} /
/tr:commandNavigationItem
/f:facet
/tr:navigationPane
tr:outputText value
Re: [Trinidad] tr:panelTabbed examples?
Thank you. The correspondence I couldn't find in the wiki was for the component af:menuTabs, but probably panelTabbed also replaces it. On 6/29/07, Adam Winer [EMAIL PROTECTED] wrote: Actually, the Wiki page shows the renaming: panelTabbed was formerly called showOneTabs. There's an example in trinidad-demo. -- Adam On 6/29/07, Francisco Passos [EMAIL PROTECTED] wrote: Hello there. I'm evaluating the usage of a panelTabbed. Are there any working examples of this component? The only example I have is from an ADF Faces app, which uses af:menuTabs, but http://wiki.apache.org/myfaces/Trinidad_renaming does not mention any changes to this component. Thanks, Francisco
Re: [Trinidad] tr:panelTabbed examples?
Simon and Matthias, thank you for clearing my doubt. By the way, if I may leave the suggestion, it would be cool if panelTabbed had alternative ways for presentation, much like navigationPage. As far as the wiki, I've added the missing entry to the page for completeness, although obviously it may still be incomplete. --Francisco On 7/2/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Francisco, we started a wiki, containing infos like this, in the past, but never updated it. feel free to join ;-) -M On 7/2/07, Simon Lessard [EMAIL PROTECTED] wrote: Hello Francisco, No, menuTabs was replaced by navigationPane with hint attribute set to tabs. Regards, ~ Simon On 7/2/07, Francisco Passos [EMAIL PROTECTED] wrote: Thank you. The correspondence I couldn't find in the wiki was for the component af:menuTabs, but probably panelTabbed also replaces it. On 6/29/07, Adam Winer [EMAIL PROTECTED] wrote: Actually, the Wiki page shows the renaming: panelTabbed was formerly called showOneTabs. There's an example in trinidad-demo. -- Adam On 6/29/07, Francisco Passos [EMAIL PROTECTED] wrote: Hello there. I'm evaluating the usage of a panelTabbed. Are there any working examples of this component? The only example I have is from an ADF Faces app, which uses af:menuTabs, but http://wiki.apache.org/myfaces/Trinidad_renaming does not mention any changes to this component. Thanks, Francisco -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
Re: [Trinidad] Weblogic + Debug
(ExecuteThread.java:209) at weblogic.work.ExecuteThread.run(ExecuteThread.java:181) As previously, this happens when I start Weblogic in debug and try to access any page. --Francisco On 5/31/07, Francisco Passos [EMAIL PROTECTED] wrote: Tried today's nightly build and the error no longer appears. Thank you. Francisco On 5/30/07, Francisco Passos [EMAIL PROTECTED] wrote: Excellent news! Thank you, Francisco On 5/30/07, Adam Winer [EMAIL PROTECTED] wrote: http://issues.apache.org/jira/browse/TRINIDAD-44 Fixed. -- Adam On 5/29/07, Francisco Passos [EMAIL PROTECTED] wrote: Thank you. Are there plans to address this bug soon? On 5/29/07, Adam Winer [EMAIL PROTECTED] wrote: Looks like a (minor) bug in Trinidad. Code should be clearing RenderingContext.setCurrentClientId () but isn't, and the assert is catching that. We should be running our tests with asserts enabled, IMO, which I think would have caught this particular problem. -- Adam On 5/29/07, Francisco Passos [EMAIL PROTECTED] wrote: Good afternoon. I'm developing an application with Trinidad on Weblogic Application Server 9.2 . It works fine in normal circumstances, but whenever I start weblogic in debug mode (to attach by socket in Eclipse), pages cease to render and this error is presented instead. Error 500--Internal Server Error java.lang.AssertionError at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.CommandButtonRenderer.encodeAll (CommandButtonRenderer.java :75) at org.apache.myfaces.trinidad.render.CoreRenderer.encodeEnd( CoreRenderer.java:184) at org.apache.myfaces.trinidad.component.UIXComponentBase.encodeEnd( UIXComponentBase.java:701) at org.apache.myfaces.trinidad.render.CoreRenderer.encodeChild ( CoreRenderer.java:263) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelGroupLayoutRenderer.encodeChild (PanelGroupLayoutRenderer.java:177) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelGroupLayoutRenderer._encodeChildren (PanelGroupLayoutRenderer.java:143) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelGroupLayoutRenderer.encodeAll (PanelGroupLayoutRenderer.java:95) at org.apache.myfaces.trinidad.render.CoreRenderer.encodeEnd ( CoreRenderer.java:184) at org.apache.myfaces.trinidad.component.UIXComponentBase.encodeEnd (UIXComponentBase.java:701) at org.apache.myfaces.trinidadinternal.uinode.UIComponentUINode._renderComponent (UIComponentUINode.java:336) at org.apache.myfaces.trinidadinternal.uinode.UIComponentUINode.render (UIComponentUINode.java:278) at org.apache.myfaces.trinidadinternal.uinode.UIComponentUINode.render( UIComponentUINode.java:255) at org.apache.myfaces.trinidadinternal.ui.composite.ContextPoppingUINode$ContextPoppingRenderer.render (ContextPoppingUINode.java :235) at org.apache.myfaces.trinidadinternal.ui.BaseUINode.render ( BaseUINode.java:357) at org.apache.myfaces.trinidadinternal.ui.BaseUINode.render( BaseUINode.java :312) at org.apache.myfaces.trinidadinternal.ui.BaseRenderer.renderChild (BaseRenderer.java:424) at org.apache.myfaces.trinidadinternal.ui.BaseRenderer.renderNamedChild (BaseRenderer.java :396) at org.apache.myfaces.trinidadinternal.ui.laf.base.desktop.FooterRenderer.postrender (FooterRenderer.java :80) at org.apache.myfaces.trinidadinternal.ui.BaseRenderer.render ( BaseRenderer.java :94) at org.apache.myfaces.trinidadinternal.ui.laf.base.xhtml.XhtmlLafRenderer.render (XhtmlLafRenderer.java:83) at org.apache.myfaces.trinidadinternal.ui.BaseUINode.render (BaseUINode.java :357) at org.apache.myfaces.trinidadinternal.ui.BaseUINode.render( BaseUINode.java :312) at org.apache.myfaces.trinidadinternal.ui.BaseRenderer.renderChild( BaseRenderer.java:424) at org.apache.myfaces.trinidadinternal.ui.BaseRenderer.renderIndexedChild (BaseRenderer.java:342) at org.apache.myfaces.trinidadinternal.ui.BaseRenderer.renderIndexedChild (BaseRenderer.java:234) at org.apache.myfaces.trinidadinternal.ui.BaseRenderer.renderContent( BaseRenderer.java:141) at org.apache.myfaces.trinidadinternal.ui.BaseRenderer.render ( BaseRenderer.java:92) at org.apache.myfaces.trinidadinternal.ui.laf.base.xhtml.XhtmlLafRenderer.render (XhtmlLafRenderer.java:83) at org.apache.myfaces.trinidadinternal.ui.BaseUINode.render (BaseUINode.java :357
Re: [Trinidad] Weblogic + Debug
Btw, this happens on the trinidad-1.0.1 release. On 7/2/07, Francisco Passos [EMAIL PROTECTED] wrote: Sorry to break these bad news - again - but the assertion errors are back: java.lang.AssertionError at org.apache.myfaces.trinidadinternal.style.util.CSSUtils.getBaseSkinStyleSheetURI (CSSUtils.java:139) at org.apache.myfaces.trinidadinternal.skin.SkinStyleSheetParserUtils._createStyleSheetEntry(SkinStyleSheetParserUtils.java:191) at org.apache.myfaces.trinidadinternal.skin.SkinStyleSheetParserUtils.parseCSSSource (SkinStyleSheetParserUtils.java:122) at org.apache.myfaces.trinidadinternal.skin.StyleSheetEntry._createSkinStyleSheetFromCSS(StyleSheetEntry.java:249) at org.apache.myfaces.trinidadinternal.skin.StyleSheetEntry._createSkinStyleSheet (StyleSheetEntry.java:227) at org.apache.myfaces.trinidadinternal.skin.StyleSheetEntry.createEntry(StyleSheetEntry.java:73) at org.apache.myfaces.trinidadinternal.skin.SkinImpl._createStyleSheetDocument(SkinImpl.java :546) at org.apache.myfaces.trinidadinternal.skin.SkinImpl.getStyleSheetDocument(SkinImpl.java:417) at org.apache.myfaces.trinidadinternal.skin.SkinExtension.getStyleSheetDocument(SkinExtension.java:385) at org.apache.myfaces.trinidadinternal.skin.SkinStyleProvider.createStyleSheetDocument (SkinStyleProvider.java:152) at org.apache.myfaces.trinidadinternal.style.cache.FileSystemStyleCache._getStyleSheetDocument(FileSystemStyleCache.java:554) at org.apache.myfaces.trinidadinternal.style.cache.FileSystemStyleCache._getEntry (FileSystemStyleCache.java:365) at org.apache.myfaces.trinidadinternal.style.cache.FileSystemStyleCache.getStyleSheetURI(FileSystemStyleCache.java:150) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.StyleSheetRenderer.encodeAll (StyleSheetRenderer.java:91) at org.apache.myfaces.trinidad.render.CoreRenderer.delegateRenderer(CoreRenderer.java:318) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.HeadRenderer.encodeBegin(HeadRenderer.java :90) at org.apache.myfaces.trinidad.render.CoreRenderer.encodeBegin(CoreRenderer.java:185) at org.apache.myfaces.trinidad.component.UIXComponentBase.encodeBegin(UIXComponentBase.java:661) at com.sun.facelets.tag.jsf.ComponentSupport.encodeRecursive (ComponentSupport.java:232) at com.sun.facelets.tag.jsf.ComponentSupport.encodeRecursive(ComponentSupport.java:239) at com.sun.facelets.tag.jsf.ComponentSupport.encodeRecursive(ComponentSupport.java:239) at com.sun.facelets.FaceletViewHandler.renderView (FaceletViewHandler.java:580) at org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:181) at org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java :41) at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:132) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:140) at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run (StubSecurityHelper.java:225) at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:127) at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:283) at weblogic.servlet.internal.ServletStubImpl.execute (ServletStubImpl.java:175) at weblogic.servlet.internal.RequestDispatcherImpl.invokeServlet(RequestDispatcherImpl.java:496) at weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:245) at weblogic.servlet.jsp.PageContextImpl.forward(PageContextImpl.java:148) at jsp_servlet.__index._jspService(__index.java:101) at weblogic.servlet.jsp.JspBase.service(JspBase.java:34) at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run (StubSecurityHelper.java:225) at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:127) at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:283) at weblogic.servlet.internal.ServletStubImpl.onAddToMapException (ServletStubImpl.java:391) at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:309) at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:175) at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run (WebAppServletContext.java:3211) at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321) at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121) at weblogic.servlet.internal.WebAppServletContext.securedExecute (WebAppServletContext.java:1983) at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:1890
Re: [Trinidad] tr:panelTabbed examples?
By the way, I'm trying to populate dinamically either a panelTabbed or a navigationPane. When using ui:repeat, panelTabbed renders incorrectly (no content appears) and this is shown on the logs: WARNING: Only tr:showDetailItem is allowed as child of tr:panelTabbed. When using ui:repeat and navigationPane, an exception is thrown: SEVERE: Warning: illegal component hierarchy detected, expected UIXCommand but found another type of component instead. java.lang.ClassCastException: com.sun.facelets.component.UIRepeat I'm going to try my luck with JSTL now, nevertheless if you know of a solution, do tell :) --Francisco On 7/2/07, Francisco Passos [EMAIL PROTECTED] wrote: Simon and Matthias, thank you for clearing my doubt. By the way, if I may leave the suggestion, it would be cool if panelTabbed had alternative ways for presentation, much like navigationPage. As far as the wiki, I've added the missing entry to the page for completeness, although obviously it may still be incomplete. --Francisco On 7/2/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Francisco, we started a wiki, containing infos like this, in the past, but never updated it. feel free to join ;-) -M On 7/2/07, Simon Lessard [EMAIL PROTECTED] wrote: Hello Francisco, No, menuTabs was replaced by navigationPane with hint attribute set to tabs. Regards, ~ Simon On 7/2/07, Francisco Passos [EMAIL PROTECTED] wrote: Thank you. The correspondence I couldn't find in the wiki was for the component af:menuTabs, but probably panelTabbed also replaces it. On 6/29/07, Adam Winer [EMAIL PROTECTED] wrote: Actually, the Wiki page shows the renaming: panelTabbed was formerly called showOneTabs. There's an example in trinidad-demo. -- Adam On 6/29/07, Francisco Passos [EMAIL PROTECTED] wrote: Hello there. I'm evaluating the usage of a panelTabbed. Are there any working examples of this component? The only example I have is from an ADF Faces app, which uses af:menuTabs, but http://wiki.apache.org/myfaces/Trinidad_renaming does not mention any changes to this component. Thanks, Francisco -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
[Trinidad] tr:panelTabbed examples?
Hello there. I'm evaluating the usage of a panelTabbed. Are there any working examples of this component? The only example I have is from an ADF Faces app, which uses af:menuTabs, but http://wiki.apache.org/myfaces/Trinidad_renaming does not mention any changes to this component. Thanks, Francisco
Re: [Trinidad] Inner tr:table PPR problem
Just realized that the detailStamp facet serves exactly this purpose.
I'm going to try it out.
On 6/28/07, Francisco Passos [EMAIL PROTECTED] wrote:
Good afternoon.
I'm trying to get a particular component to render conditionally (with PPR)
inside a tr:table. Not having it work though.
I've tried a first solution without partialSubmit nor partialTriggers,
which works but without PPR.
This is my current attempt, where I added two commandLinks to the column
where I want the component to appear / disappear. Plus, I want to start out
with the component not rendered (on the first try). I really do not need to
do this with commandLinks if you tell me there's a better way.
Here it is:
tr:table value=#{myBean.attributes} var=attribute
rows=20 rowBandingInterval=1
partialTriggers=tableShow,tableHide
tr:column
tr:outputText value=#{attribute.attributeName}/
/tr:column
tr:column
!-- visibility controls --
tr:commandLink id=tableShow text=Show data action=#{
attribute.show} rendered=#{not attribute.visible and attribute.hasData}
partialSubmit=true /
tr:commandLink id=tableHide text=Hide data action=#{
attribute.hide} rendered=#{attribute.visible and attribute.hasData}
partialSubmit=true /
tr:table value=#{attribute.attributeData} var=attributeData
rendered=#{attribute.hasData and attribute.visible}
rows=10 partialTriggers=tableShow,tableHide
tr:column
tr:outputText value=#{attributeData.xvalor} /
/tr:column
/tr:table
/tr:column
/tr:table
For debug purposes (and although I intend the opposite), I'm starting out
with visible components. When I press Hide data, nothing changes in the
browser but this appears in the logs:
28/Jun/2007 17:15:49
org.apache.myfaces.trinidadinternal.context.RequestContextImpladdPartialTriggerListeners
WARNING: Could not find partial trigger tableHide,tableShow from
CoreTable[UIXFacesBeanImpl, id=_id124]
Surely there's a more standard way of doing this?
--Francisco
[Trinidad] Inner tr:table PPR problem
Good afternoon.
I'm trying to get a particular component to render conditionally (with PPR)
inside a tr:table. Not having it work though.
I've tried a first solution without partialSubmit nor partialTriggers, which
works but without PPR.
This is my current attempt, where I added two commandLinks to the column
where I want the component to appear / disappear. Plus, I want to start out
with the component not rendered (on the first try). I really do not need to
do this with commandLinks if you tell me there's a better way.
Here it is:
tr:table value=#{myBean.attributes} var=attribute
rows=20 rowBandingInterval=1
partialTriggers=tableShow,tableHide
tr:column
tr:outputText value=#{attribute.attributeName}/
/tr:column
tr:column
!-- visibility controls --
tr:commandLink id=tableShow text=Show data action=#{
attribute.show} rendered=#{not attribute.visible and attribute.hasData}
partialSubmit=true /
tr:commandLink id=tableHide text=Hide data action=#{
attribute.hide} rendered=#{attribute.visible and attribute.hasData}
partialSubmit=true /
tr:table value=#{attribute.attributeData} var=attributeData
rendered=#{attribute.hasData and attribute.visible}
rows=10 partialTriggers=tableShow,tableHide
tr:column
tr:outputText value=#{attributeData.xvalor} /
/tr:column
/tr:table
/tr:column
/tr:table
For debug purposes (and although I intend the opposite), I'm starting out
with visible components. When I press Hide data, nothing changes in the
browser but this appears in the logs:
28/Jun/2007 17:15:49
org.apache.myfaces.trinidadinternal.context.RequestContextImpladdPartialTriggerListeners
WARNING: Could not find partial trigger tableHide,tableShow from
CoreTable[UIXFacesBeanImpl, id=_id124]
Surely there's a more standard way of doing this?
--Francisco
Re: Skinning tr:inputText
Thanks for the cool tip!
I'm going to try it tomorrow to see how it goes... right now I feel I'm
using too many inlineStyle properties precisely because of situations like
this.
If you decide to post skinning tips, be sure to tell us where :)
--Francisco
On 6/28/07, Jeanne Waldman [EMAIL PROTECTED] wrote:
af|inputText.myStyleClass::label should parse in the css file to:
.af_inputText.myStyleClass .af_inputText_label {}
If it doesn't, I think it is a bug.
I'll submit a JIRA issue.
But, there is a simple workaround:
af|inputText.myStyleClass af|inputText::label {}
This is easier on the parser. :)
It parses to :
.af_inputText.myStyleClass .af_inputText_label {}
This says, Style the dom element with the styleclass af_inputText_label
which has a parent with styleclasses af_inputText AND myStyleClass.
Then you say this:
af:inputText styleClass=myStyleClass/
The 'myStyleClass' is what I call a 'marker' styleclass -- don't go
googling this, I made up the term. :)
It's a way to mark this particular inputText so you can use your style
definition for only the inputText's that have this marker.
I can post blogs for skinning with tips like this. Where should I put
these?
Thanks,
- Jeanne
Simon Lessard wrote:
H,
What about af|inputText.myStyleClass::label?
On 5/14/07, *Francisco Passos* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
That was it, thank you! Firefox tends to keep the css in cache, so
after clearing it works fine.
However your previous suggested solution for the initial problem I
presented:
af|inputText::label.myStyleClass {
font-weight : bold;
}
tr:inputText styleClass=myStyleClass/
does not seem to work, in that the label is not presented in bold.
On 5/14/07, * Simon Lessard* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Hello Francisco,
Hmmm it might be a browser cache problem. When working with
skin you have to clear your browser cache often else it will
use the cached CSS. I assume that, in your case, the last
change you made either triggered a filename change or your
browser cache expired thus loading the latest CSS and showing
all changes.
Regards,
~ Simon
On 5/14/07, *Francisco Passos* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Oddly enough, if I add
@platform windows, linux, solaris
{
/** for ie and gecko on windows, linux and solaris, make
the color pink **/
@agent ie, gecko
{
af|inputText::content {background-color:pink}
}
}
to the css, suddenly everything works - the text size, the
red background color, the bold font weight...
What should I make of this?
On 5/14/07, * Francisco Passos*
[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Thank you for your hint, I'll try it as soon as I can.
It seems that I'm not quite there yet, I'm two steps
behind.
I'm using a skin extending the simple-desktop:
skins xmlns= http://myfaces.apache.org/trinidad/skin;
skin
idstp.desktop /id
familystp/family
render-kit-id
org.apache.myfaces.trinidad.desktop/render-kit-id
style-sheet-name
resources/css/skin-stp.css
/style-sheet-name
extendssimple.desktop/extends
/skin
/skins
and in skin-stp.css I define some things, such as
.AFDefaultFont:alias {
font-size : 18px;
}
and
af|inputText::label {
background-color: red;
font-weight: bold;
}
And none of them is working. The text is overall very
small (nowhere near the 18px I put there to test) and
tr:inputText labels are neither red nor bold. It seems
like it is ignoring my skin-stp.css definitions. What
could cause this?
On 5/11/07, *Simon Lessard*
[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Hello Francisco,
You could try the following:
af|inputText:: label.myStyleClass {
font-weight : bold;
}
tr:inputText styleClass=myStyleClass/
I think it might work.
Regards,
~ Simon
Re: [Trinidad] Inner tr:table PPR problem
Problem solved painlessly with a tr:showDetail.
Sorry for the unnecessary post.
On 6/28/07, Francisco Passos [EMAIL PROTECTED] wrote:
Just realized that the detailStamp facet serves exactly this purpose.
I'm going to try it out.
On 6/28/07, Francisco Passos [EMAIL PROTECTED] wrote:
Good afternoon.
I'm trying to get a particular component to render conditionally (with
PPR) inside a tr:table. Not having it work though.
I've tried a first solution without partialSubmit nor partialTriggers,
which works but without PPR.
This is my current attempt, where I added two commandLinks to the column
where I want the component to appear / disappear. Plus, I want to start out
with the component not rendered (on the first try). I really do not need to
do this with commandLinks if you tell me there's a better way.
Here it is:
tr:table value=#{myBean.attributes} var=attribute
rows=20 rowBandingInterval=1
partialTriggers=tableShow,tableHide
tr:column
tr:outputText value=#{attribute.attributeName}/
/tr:column
tr:column
!-- visibility controls --
tr:commandLink id=tableShow text=Show data action=#{
attribute.show} rendered=#{not attribute.visible and attribute.hasData}
partialSubmit=true /
tr:commandLink id=tableHide text=Hide data action=#{
attribute.hide} rendered=#{attribute.visible and attribute.hasData}
partialSubmit=true /
tr:table value=#{attribute.attributeData} var=attributeData
rendered=#{attribute.hasData and attribute.visible }
rows=10 partialTriggers=tableShow,tableHide
tr:column
tr:outputText value=#{attributeData.xvalor} /
/tr:column
/tr: table
/tr:column
/tr:table
For debug purposes (and although I intend the opposite), I'm starting
out with visible components. When I press Hide data, nothing changes in
the browser but this appears in the logs:
28/Jun/2007 17:15:49
org.apache.myfaces.trinidadinternal.context.RequestContextImpladdPartialTriggerListeners
WARNING: Could not find partial trigger tableHide,tableShow from
CoreTable[UIXFacesBeanImpl, id=_id124]
Surely there's a more standard way of doing this?
--Francisco
Re: [Trinidad] Skinning from a war file
/resources/css/skin-stp.css did it Plus, I think there was a browser cache problem as well. Thank you, Francisco On 6/27/07, Danny Robinson [EMAIL PROTECTED] wrote: Did you try an absolute path to your css file (e.g. /resources or /WEB-INF/./resources). Danny On 6/27/07, Francisco Passos [EMAIL PROTECTED] wrote: I'm using a skin perfectly when the application is expanded. However when I generate a war file the skin isn't used for rendering... here's my trinidad-skins.xml: ?xml version=1.0 encoding=ISO-8859-1? skins xmlns=http://myfaces.apache.org/trinidad/skin; skin id stp.desktop /id family stp /family render-kit-id org.apache.myfaces.trinidad.desktop /render-kit-id style-sheet-name resources/css/skin-stp.css /style-sheet-name extends simple.desktop/extends /skin /skins When expanded, the skin-stp.css file is located in WEB-INF/../resources/css/skin-stp. Inside the war file, I've tried both in the same place and moving the resources dir into WEB-INF. None seems to work. Surely I'm missing something... -- Chordiant Software Inc. www.chordiant.com
Re: [Announce] Release of Apache MyFaces Trinidad 1.0.1
Is there any downside to using 1.0.1 with JSF 1.2? On 6/26/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Yes, currently the 1.2.1 plugins are on the vote. Once that vote is done, we start with the release procedure of 1.2.1, which is basically the JSF 1.2-version of 1.0.1. In the first week of July, that should become reality. -Matthias On 6/26/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Will there then be a 1.2.1 release soon? [EMAIL PROTECTED] wrote on 06/23/2007 11:27:49 AM: The Apache MyFaces Trinidad team is pleased to announce the release of Apache MyFaces Trinidad Core 1.0.1. Apache MyFaces Trinidad is a JavaServer(tm) Faces 1.1 component library. Trinidad Core 1.0.1 is available in both binary and source distributions: * http://myfaces.apache.org/trinidad/download.html Apache MyFaces Trinidad is available in the central Maven repository under Group ID org.apache.myfaces.trinidad. Release Notes: http://tinyurl.com/3ylxf2 Enjoy! -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
[Trinidad] Skinning from a war file
I'm using a skin perfectly when the application is expanded. However when I generate a war file the skin isn't used for rendering... here's my trinidad-skins.xml: ?xml version=1.0 encoding=ISO-8859-1? skins xmlns=http://myfaces.apache.org/trinidad/skin; skin id stp.desktop /id family stp /family render-kit-id org.apache.myfaces.trinidad.desktop /render-kit-id style-sheet-name resources/css/skin-stp.css /style-sheet-name extendssimple.desktop/extends /skin /skins When expanded, the skin-stp.css file is located in WEB-INF/../resources/css/skin-stp. Inside the war file, I've tried both in the same place and moving the resources dir into WEB-INF. None seems to work. Surely I'm missing something...
Re: Phase Listener execute only once ???
The way I solved a similar problem was putting into my bean onLoad method
the logic to decide whether or not it had already run or not (having a
private boolean and testing it before running whatever you have to run, plus
setting it on the first run to prevent it from running later).
Although this is a clunky solution if you intend to do it on many beans, you
can consider making your beans extend an abstract one and including this
rerun-prevention on the base class.
Francisco Passos
On 6/26/07, bansi [EMAIL PROTECTED] wrote:
We have Homegrown Authentication System which on successfull
authentication
returns EmployeeID in the form of Request Header Variables.
I am using afterPhase method of PhaseListener to call onPageLoad
method
of LoginBean by checking the viewId as shown below
if (viewId.endsWith(login.xhtml)) {
String managedBeanName = getManagedBeanNameFromView(viewId);
Object object = facesContext.getApplication
().createValueBinding(#{
+ managedBeanName + }).getValue(facesContext);
if (object == null)
logger.error(OnPageLoad cannot be executed, no such managed
bean:+
managedBeanName);
else {
Login loginBean = (Login) object;
loginBean.onPageLoad();
}
}
public String getManagedBeanNameFromView(String viewId) {
String pageName;
if (viewId.endsWith(login.xhtml)) {
pageName = viewId.substring(1, viewId.length() - 6);
}
else{
pageName = viewId.substring(1, viewId.length() - 10);
}
return pageName+Bean;
}
public PhaseId getPhaseId()
{
return PhaseId.RESTORE_VIEW;
}
The onPageLoad method of LoginBean retrieves employeeID from request
header variables and use employeeID to retrieve userID and userRoles from
database as shown below
public void onPageLoad() {
Map requestHeaderMap =
FacesContext.getCurrentInstance
().getExternalContext().getRequestHeaderMap();
String employeeID = (String) requestHeaderMap.get(EmployeeID);
userId = getUserId(Long.valueOf(employeeID )); // calls database
userRoles = getUserRoles(userId);// calls database
userInfo.setUserId(userId); //userInfo is pojo
userInfo.setUserRoles(userRoles);
/* Store Nams User Id in Session */
HttpSession userSession =
(HttpSession)
FacesContext.getCurrentInstance().getExternalContext()
.getSession(true);
userSession.setAttribute(userInfo, userInfo);
// UserInfoHolder is a Thread Local
UserInfoHolder.setUserInfo(userInfo);
}
The problem is whenever i navigate back forth between the pages , the
query is fired to retrieve userID and userRoles from database which i
wanna
happen only once i.e. how do i make getUserID() and getUserRoles() method
fire only once
Any pointers/suggestions will be highly appreciated
--
View this message in context:
http://www.nabble.com/Phase-Listener-execute-only-once-tf3983959.html#a11311025
Sent from the MyFaces - Users mailing list archive at Nabble.com.
[Trinidad] tr:spacer shortDesc does nothing
Good morning. I've noticed tr:spacer does not use shortDesc to present the usual tooltip that for instance a tr:outputText does. While it is not a critical feature at all, I believe that would be the intended behaviour and the documentation confirms that idea. Francisco
[Tomahawk] t:saveState - one step further
Good afternoon. I've been trying for some time to figure a way to properly use t:saveState. I've been able to easily use its core functionality of keeping state between successive requests. However, for beans which are supposed to carry information from a database to be presented on the screen, one must initialize its properties. And thus I'd like to have a specific method on my beans which would be called whenever such initialization is needed. For now, I'm using the setter of a managed-property on my bean - which is called everytime a new request is processed for that bean. Now comes the tricky part: I want to avoid going to the database and retrieving the data I've already collected. So I use t:saveState for that. And I've set a private boolean in the bean which is checked on the initialization method before going to the database once more... the problem is, it seems to me, that when my init method runs, t:saveState's bean restoration process has not yet occurred and so the private boolean that carries the information on whether the bean has already been initialized is still set to false - so it goes to the database once more (and later the restore takes place over the newly acquired data). As you can see I need to switch the order of these two steps... So what I'm looking for is a standard (or non-standard) way of invoking a method on my bean everytime a page uses that bean, but only after the t:saveState component has properly restored the bean. And obviously the solution I'm looking for must also call this method for the first access to the page, where there is no state for the component to restore. Is there already a solution for this? Thank you, Francisco Passos
Re: [Tomahawk] t:saveState - one step further
Thank you for your suggestions. I'm going to look into the first two, since I understand Shale requires a tight coupling between page and bean naming conventions, which is not completely suitable for what I intend to do. I'm using Trinidad and Facelets. I hope to find no restrictions to the use of these libraries. If I get this to work successfully, I'll report it here, so others can benefit as well. Thank you, Francisco Passos On 6/25/07, Andrew Robinson [EMAIL PROTECTED] wrote: Possibly use an on-load method for your page. The following libraries provide this functionality: JBoss-Seam jsf-comp on-load Shale view handler -Andrew On 6/25/07, Francisco Passos [EMAIL PROTECTED] wrote: Good afternoon. I've been trying for some time to figure a way to properly use t:saveState. I've been able to easily use its core functionality of keeping state between successive requests. However, for beans which are supposed to carry information from a database to be presented on the screen, one must initialize its properties. And thus I'd like to have a specific method on my beans which would be called whenever such initialization is needed. For now, I'm using the setter of a managed-property on my bean - which is called everytime a new request is processed for that bean. Now comes the tricky part: I want to avoid going to the database and retrieving the data I've already collected. So I use t:saveState for that. And I've set a private boolean in the bean which is checked on the initialization method before going to the database once more... the problem is, it seems to me, that when my init method runs, t:saveState's bean restoration process has not yet occurred and so the private boolean that carries the information on whether the bean has already been initialized is still set to false - so it goes to the database once more (and later the restore takes place over the newly acquired data). As you can see I need to switch the order of these two steps... So what I'm looking for is a standard (or non-standard) way of invoking a method on my bean everytime a page uses that bean, but only after the t:saveState component has properly restored the bean. And obviously the solution I'm looking for must also call this method for the first access to the page, where there is no state for the component to restore. Is there already a solution for this? Thank you, Francisco Passos
Re: [Tomahawk] t:saveState - one step further
Hello once again!
jsf-comp solved my problems beautifully.
So, as promised, for those who may be struggling with a 3-step solution to
keep request-scoped bean state between subsequent requests, without
repeating initialization (thus avoiding several unnecessary hits to a
database, for instance):
1. find a way to carry the bean state from one request to the next: use
Tomahawk's t:saveState [1], it's what it does and very well, provided your
bean is serializable or implements a particular interface
2. equip your bean with the way to know if it is already initialized or not
(to avoid repeating the same work)
private boolean initialized = false;
public final void initialize() {
if (!initialized) {
// do your initialization here
initialized = true;
}
}
You might consider creating an abstract bean class so many of your beans can
inherit this behaviour, as I have.
3. find a way to call initialize everytime you enter a page that requires
it:
I used jsf-comp [2] (actually a particular subproject named jsfExt which
contains only the specific component necessary for this), which contains a
mechanism for providing on-load functionality; simply put, it's a
PhaseListener and an XML file that indicates which bean methods (via EL
expressions) should be executed before the RENDER_PHASE. It's simple as hell
and that's why I love.
An example can explain it a lot better than just talking about it:
on the onload-config.xml (the configuration file for jsf-comp OnLoad
component):
navigation-rule
view-id/pages/ficha/myPage.xhtml/view-id
action#{myBean.initialize}/action
/navigation-rule
Having this ensures that everytime you access that particular view the
initialize method in myBean is called. That, in turn, ensures that either
the bean is already initialized (and won't be reinitialized, thus preventing
further database hits / heavy computation / etc.), or the bean is not yet
initialized and will then be, right before the page is presented. Of course,
this only works because Tomahawk's t:saveState has previously restored the
bean to a state where it contains the values previously obtained during
initialization, alongside the private boolean flag to indicate it.
So there you go, a simple egg-of-Columbus solution for a problem that has
bugged me for a while.
I hope many find this description useful.
Finally, I need to thank a lot of you that put up with me for a while on
this issue, both from the Tomahawk and the Trinidad projects.
Regards,
Francisco Passos
[1] http://myfaces.apache.org/tomahawk/uiSaveState.html
[2] http://jsf-comp.sourceforge.net/components/onload/index.html
On 6/25/07, Francisco Passos [EMAIL PROTECTED] wrote:
Thank you for your suggestions.
I'm going to look into the first two, since I understand Shale requires a
tight coupling between page and bean naming conventions, which is not
completely suitable for what I intend to do.
I'm using Trinidad and Facelets. I hope to find no restrictions to the use
of these libraries.
If I get this to work successfully, I'll report it here, so others can
benefit as well.
Thank you,
Francisco Passos
On 6/25/07, Andrew Robinson [EMAIL PROTECTED] wrote:
Possibly use an on-load method for your page. The following libraries
provide this functionality:
JBoss-Seam
jsf-comp on-load
Shale view handler
-Andrew
On 6/25/07, Francisco Passos [EMAIL PROTECTED] wrote:
Good afternoon.
I've been trying for some time to figure a way to properly use
t:saveState.
I've been able to easily use its core functionality of keeping state
between
successive requests.
However, for beans which are supposed to carry information from a
database
to be presented on the screen, one must initialize its properties. And
thus
I'd like to have a specific method on my beans which would be called
whenever such initialization is needed. For now, I'm using the setter
of a
managed-property on my bean - which is called everytime a new request
is
processed for that bean.
Now comes the tricky part: I want to avoid going to the database and
retrieving the data I've already collected. So I use t:saveState for
that.
And I've set a private boolean in the bean which is checked on the
initialization method before going to the database once more... the
problem
is, it seems to me, that when my init method runs, t:saveState's bean
restoration process has not yet occurred and so the private boolean
that
carries the information on whether the bean has already been
initialized is
still set to false - so it goes to the database once more (and later
the
restore takes place over the newly acquired data). As you can see I
need to
switch the order of these two steps...
So what I'm looking for is a standard (or non-standard) way of
invoking a
method on my bean everytime a page uses that bean, but only after the
t:saveState component has properly restored the bean. And obviously
Re: [Trinidad Tomahawk] t:jsCookMenu inside tr:form
Thank you and sorry for the confusion. On 6/22/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: works now moved and said dup of https://issues.apache.org/jira/browse/TOMAHAWK-1029 On 6/22/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: For some reasons I am currently NOT able to edit/move issues. Can somebody give me the rights back ... On 6/22/07, Adam Winer [EMAIL PROTECTED] wrote: It should be reported against TOMAHAWK, not TRINIDAD. -- Adam On 6/22/07, Francisco Passos [EMAIL PROTECTED] wrote: Just reported it. Thanks. On 6/22/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: add the bug to the jira at apaache (tomahawk has a separate) On 6/22/07, Francisco Passos [EMAIL PROTECTED] wrote: Hey Matthias, I'll gladly report it, but who should I report it to? Tomahawk to suggest not to require a naming container based form? Or Trinidad to suggest making one such environment available from tr:form? As for Adam's response, thank you for your suggestion. The solution you proposed is valid and I'm keeping it: using two separate forms, one h:form for jscookmenu and one tr:form for other purposes where I require the extended functionality. --Francisco On 6/22/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Francisco, I think it (jscookm.) requires a naming container based form (the jsCookMenu), so please file a bug against it. -M On 6/22/07, Adam Winer [EMAIL PROTECTED] wrote: You can use h:form with Trinidad, FWIW, so if jsCookMenu isn't working you could switch that way. -- Adam On 6/22/07, Francisco Passos [EMAIL PROTECTED] wrote: No errors, neither on the client, nor on the server... The page we're on just refreshes, like when returning a null navigation string from an action. On 6/22/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: do you get any errors ? on the client (javascript) or on the server ? the difference between h:form and tr:form is, for instance, that tr:form isn't a namingContainer. -M On 6/22/07, Francisco Passos [EMAIL PROTECTED] wrote: Good morning. It seems jsCookMenu entries do not navigate properly when placed inside a tr:form, whereas if we use a h:form if works fine. Is this a bug? Is there a known workaround? --Francisco -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
[Trinidad Tomahawk] t:jsCookMenu inside tr:form
Good morning. It seems jsCookMenu entries do not navigate properly when placed inside a tr:form, whereas if we use a h:form if works fine. Is this a bug? Is there a known workaround? --Francisco
Re: [Trinidad Tomahawk] t:jsCookMenu inside tr:form
No errors, neither on the client, nor on the server... The page we're on just refreshes, like when returning a null navigation string from an action. On 6/22/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: do you get any errors ? on the client (javascript) or on the server ? the difference between h:form and tr:form is, for instance, that tr:form isn't a namingContainer. -M On 6/22/07, Francisco Passos [EMAIL PROTECTED] wrote: Good morning. It seems jsCookMenu entries do not navigate properly when placed inside a tr:form, whereas if we use a h:form if works fine. Is this a bug? Is there a known workaround? --Francisco -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
Re: [Trinidad Tomahawk] t:jsCookMenu inside tr:form
Just reported it. Thanks. On 6/22/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: add the bug to the jira at apaache (tomahawk has a separate) On 6/22/07, Francisco Passos [EMAIL PROTECTED] wrote: Hey Matthias, I'll gladly report it, but who should I report it to? Tomahawk to suggest not to require a naming container based form? Or Trinidad to suggest making one such environment available from tr:form? As for Adam's response, thank you for your suggestion. The solution you proposed is valid and I'm keeping it: using two separate forms, one h:form for jscookmenu and one tr:form for other purposes where I require the extended functionality. --Francisco On 6/22/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Francisco, I think it (jscookm.) requires a naming container based form (the jsCookMenu), so please file a bug against it. -M On 6/22/07, Adam Winer [EMAIL PROTECTED] wrote: You can use h:form with Trinidad, FWIW, so if jsCookMenu isn't working you could switch that way. -- Adam On 6/22/07, Francisco Passos [EMAIL PROTECTED] wrote: No errors, neither on the client, nor on the server... The page we're on just refreshes, like when returning a null navigation string from an action. On 6/22/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: do you get any errors ? on the client (javascript) or on the server ? the difference between h:form and tr:form is, for instance, that tr:form isn't a namingContainer. -M On 6/22/07, Francisco Passos [EMAIL PROTECTED] wrote: Good morning. It seems jsCookMenu entries do not navigate properly when placed inside a tr:form, whereas if we use a h:form if works fine. Is this a bug? Is there a known workaround? --Francisco -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
Re: [Trinidad Tomahawk] t:jsCookMenu inside tr:form
Hey Matthias, I'll gladly report it, but who should I report it to? Tomahawk to suggest not to require a naming container based form? Or Trinidad to suggest making one such environment available from tr:form? As for Adam's response, thank you for your suggestion. The solution you proposed is valid and I'm keeping it: using two separate forms, one h:form for jscookmenu and one tr:form for other purposes where I require the extended functionality. --Francisco On 6/22/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Francisco, I think it (jscookm.) requires a naming container based form (the jsCookMenu), so please file a bug against it. -M On 6/22/07, Adam Winer [EMAIL PROTECTED] wrote: You can use h:form with Trinidad, FWIW, so if jsCookMenu isn't working you could switch that way. -- Adam On 6/22/07, Francisco Passos [EMAIL PROTECTED] wrote: No errors, neither on the client, nor on the server... The page we're on just refreshes, like when returning a null navigation string from an action. On 6/22/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: do you get any errors ? on the client (javascript) or on the server ? the difference between h:form and tr:form is, for instance, that tr:form isn't a namingContainer. -M On 6/22/07, Francisco Passos [EMAIL PROTECTED] wrote: Good morning. It seems jsCookMenu entries do not navigate properly when placed inside a tr:form, whereas if we use a h:form if works fine. Is this a bug? Is there a known workaround? --Francisco -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
Re: Skinning tr:inputText
Since I wanted my inputTexts to be - by default - not bold, and then some of
them I wanted bold, I ended up using inlineStyle to set font-weight: bold;
...
On 6/13/07, Petr Kotek [EMAIL PROTECTED] wrote:
Hello,
You must use in css:
.myStyleClass label {
font-weight: bold;
}
I check it in Firefox only, but I think in IE must be the same.
Eventually refresh page in browser by Ctrl+F5.
Beside class, You may use element ID as:
#inputID label { ...
Best regards,
Peter
Stéphane Molina wrote:
Hi all,
My problem is exactly the same ...
Did you find some solution ?
Francisco Passos wrote:
No luck either. I'm sure there must be a way, though.
On 5/14/07, Simon Lessard [EMAIL PROTECTED] wrote:
H,
What about af|inputText.myStyleClass::label?
On 5/14/07, Francisco Passos [EMAIL PROTECTED] wrote:
That was it, thank you! Firefox tends to keep the css in cache, so
after
clearing it works fine.
However your previous suggested solution for the initial problem I
presented:
af|inputText::label.myStyleClass {
font-weight : bold;
}
tr:inputText styleClass=myStyleClass/
does not seem to work, in that the label is not presented in bold.
On 5/14/07, Simon Lessard [EMAIL PROTECTED] wrote:
Hello Francisco,
Hmmm it might be a browser cache problem. When working with skin you
have to clear your browser cache often else it will use the cached
CSS. I
assume that, in your case, the last change you made either triggered
a
filename change or your browser cache expired thus loading the
latest
CSS
and showing all changes.
Regards,
~ Simon
On 5/14/07, Francisco Passos [EMAIL PROTECTED] wrote:
Oddly enough, if I add
@platform windows, linux, solaris
{
/** for ie and gecko on windows, linux and solaris, make the
color pink **/
@agent ie, gecko
{
af|inputText::content {background-color:pink}
}
}
to the css, suddenly everything works - the text size, the red
background color, the bold font weight...
What should I make of this?
On 5/14/07, Francisco Passos [EMAIL PROTECTED] wrote:
Thank you for your hint, I'll try it as soon as I can.
It seems that I'm not quite there yet, I'm two steps behind.
I'm using a skin extending the simple-desktop:
skins xmlns= http://myfaces.apache.org/trinidad/skin;
skin
idstp.desktop /id
familystp/family
render-kit-id org.apache.myfaces.trinidad.desktop
/render-kit-id
style-sheet-name
resources/css/skin-stp.css
/style-sheet-name
extendssimple.desktop/extends
/skin
/skins
and in skin-stp.css I define some things, such as
.AFDefaultFont:alias {
font-size : 18px;
}
and
af|inputText::label {
background-color: red;
font-weight: bold;
}
And none of them is working. The text is overall very small
(nowhere near the 18px I put there to test) and tr:inputText
labels are
neither red nor bold. It seems like it is ignoring my
skin-stp.cssdefinitions. What could cause this?
On 5/11/07, Simon Lessard [EMAIL PROTECTED] wrote:
Hello Francisco,
You could try the following:
af|inputText:: label.myStyleClass {
font-weight : bold;
}
tr:inputText styleClass=myStyleClass/
I think it might work.
Regards,
~ Simon
On 5/11/07, Francisco Passos [EMAIL PROTECTED]
wrote:
Hello there!
I'd like most of my inputTexts to be rendered as they are by
default.
However, I'd like a few of them to have a bold label.
I tried this:
af|inputText::label {
font-weight : bold;
}
But as you know this leads every inputText to have their
labels in bold.
Is there any way to reference ::label from within the
inlineStyle property and define this property on the spot?
--
Petr Kotek
CRC Data spol. s r.o.
U krčské vodárny 26 - vývojové pracoviště
140 00 Praha 4
tel: +420 241 442 464
fax: +420 241 442 645
GSM: +420 602 339 057
www.crcdata.cz
Re: [Trinidad] Changes to isPostback?
That's great news for me, I'm using facelets.
Back on topic, I've just tried switching back to JSF1.2 and it seems there's
good reason for you to be skeptic Adam.
It still doesn't work. Which is a major bore, since a couple of weeks back I
had a working version. Guess I'll have to go back to work on that area.
So this is what I want to do.
a) be able to initialize beans (retrieving data from database) - right now,
I'm calling initialization from a managed-property setter (I know, it's kind
of ugly)
b) be able to keep the retrieved data using only request-scoped beans - i'm
fond of Tomahawk's saveState component - and thus avoiding to hit the
database if the data's already here
The problem seems to be that the managed property setter is called BEFORE
the bean is restored by t:saveState. Otherwise the initialization logic
would detect the bean was already initialized and would not hit the
database.
So I'm looking for a way to ensure that the previous bean state is restored
before the managed-property setter is called.
Or if that is not possible, I'm looking for a way to satisfy a) and b) -
initializing a bean when it is not initialized, keeping it in request and
avoid reinitialization.
On 6/8/07, Adam Winer [EMAIL PROTECTED] wrote:
On 6/8/07, Francisco Passos [EMAIL PROTECTED] wrote:
I would too, if I hadn't lost several days trying to get proper bean
initialization and statekeeping to work :)
As soon as I get some time for this, I'm going back to 1.2 and check it.
I'll let you know.
One of my doubts prevails though: is it possible to run JSF 1.2 safely
on a
non J2EE 5 container such as weblogic 9.2? I believe it isn't, but
either
way, I'd like to know from someone that, unlike me, has a greater grasp
of
the implications.
With Facelets, yes, with JSP, no.
-- Adam
On 6/8/07, Adam Winer [EMAIL PROTECTED] wrote:
This certainly explains why it doesn't work now.
I've no idea why it worked in JSF 1.2 - I'm a bit
skeptical of that, to be honest.
-- Adam
On 6/8/07, Francisco Passos [EMAIL PROTECTED] wrote:
Placed this before calling isPostBack:
try {
throw new Exception(--when am i calling
isPostback?--);
} catch(Exception e) {
e.printStackTrace();
}
Here's the result:
java.lang.Exception: --when am i calling isPostback?--
at
pt.dgaiec.stp.beans.GenericBean.adfIsPostback
(GenericBean.java:59)
at
pt.dgaiec.stp.beans.GenericBean.isPostback(GenericBean.java
:40)
at
pt.dgaiec.stp.beans.GenericBean.setInitialization(GenericBean.java:110)
at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.commons.beanutils.PropertyUtils.setSimpleProperty
(PropertyUtils.java :1789)
at
com.sun.faces.config.ManagedBeanFactory.setPropertiesIntoBean(
ManagedBeanFactory.java:564)
at
com.sun.faces.config.ManagedBeanFactory.newInstance(
ManagedBeanFactory.java
:234)
at
com.sun.faces.application.ApplicationAssociate.createAndMaybeStoreManagedBeans
(ApplicationAssociate.java:253)
at
com.sun.faces.el.VariableResolverImpl.resolveVariable
(VariableResolverImpl.java:78)
at
org.apache.myfaces.trinidadinternal.el.TrinidadVariableResolver.resolveVariable
(TrinidadVariableResolver.java:54)
at
com.sun.facelets.el.LegacyELContext$LegacyELResolver.getType
(LegacyELContext.java
:107)
at
com.sun.el.parser.AstIdentifier.setValue(AstIdentifier.java:96)
at
com.sun.el.ValueExpressionImpl.setValue(ValueExpressionImpl.java:255)
at
com.sun.facelets.el.TagValueExpression.setValue
(TagValueExpression.java:93)
at
com.sun.facelets.el.LegacyValueBinding.setValue(LegacyValueBinding.java
:68)
at
org.apache.myfaces.custom.savestate.UISaveState.restoreState(
UISaveState.java:101)
at
javax.faces.component.UIComponentBase.processRestoreState(
UIComponentBase.java:999)
at
org.apache.myfaces.trinidad.component.TreeState.restoreState(
TreeState.java:96)
at
org.apache.myfaces.trinidad.component.UIXComponentBase.processRestoreState
(UIXComponentBase.java :816)
at
javax.faces.component.UIComponentBase.processRestoreState(
UIComponentBase.java:1011)
at
org.apache.myfaces.trinidad.component.TreeState.restoreState(
TreeState.java:96)
at
org.apache.myfaces.trinidad.component.UIXComponentBase.processRestoreState
(UIXComponentBase.java:816)
at
org.apache.myfaces.trinidad.component.TreeState.restoreState(
TreeState.java
:96
Re: [Trinidad] Changes to isPostback?
Furthermore, I'm aware of the existance of the @PostConstruct annotation,
but as you are aware, I'm limited to a non-J2EE 5 server.
Some weeks ago I tried using a PhaseListener and then through the
VariableResolver get to the beans to initialize them in the right moment.
This solution presented two problems. The first has to do with having to
know the bean names in advance. The second and most important is that the
variable resolver would instantiate beans if they did not exist, which would
then be initialized needlessly.
Probably I missed something in the PhaseListener solution?
I've also looked at some existing solutions that involve tight coupling
between the page names and the bean names. This would not be suitable for
the application I'm developing though.
Does anyone know of other solutions for this - or more proper forms of the
presented solutions?
On 6/11/07, Francisco Passos [EMAIL PROTECTED] wrote:
That's great news for me, I'm using facelets.
Back on topic, I've just tried switching back to JSF1.2 and it seems
there's good reason for you to be skeptic Adam.
It still doesn't work. Which is a major bore, since a couple of weeks back
I had a working version. Guess I'll have to go back to work on that area.
So this is what I want to do.
a) be able to initialize beans (retrieving data from database) - right
now, I'm calling initialization from a managed-property setter (I know, it's
kind of ugly)
b) be able to keep the retrieved data using only request-scoped beans -
i'm fond of Tomahawk's saveState component - and thus avoiding to hit the
database if the data's already here
The problem seems to be that the managed property setter is called BEFORE
the bean is restored by t:saveState. Otherwise the initialization logic
would detect the bean was already initialized and would not hit the
database.
So I'm looking for a way to ensure that the previous bean state is
restored before the managed-property setter is called.
Or if that is not possible, I'm looking for a way to satisfy a) and b) -
initializing a bean when it is not initialized, keeping it in request and
avoid reinitialization.
On 6/8/07, Adam Winer [EMAIL PROTECTED] wrote:
On 6/8/07, Francisco Passos [EMAIL PROTECTED] wrote:
I would too, if I hadn't lost several days trying to get proper bean
initialization and statekeeping to work :)
As soon as I get some time for this, I'm going back to 1.2 and check
it.
I'll let you know.
One of my doubts prevails though: is it possible to run JSF 1.2 safely
on a
non J2EE 5 container such as weblogic 9.2? I believe it isn't, but
either
way, I'd like to know from someone that, unlike me, has a greater
grasp of
the implications.
With Facelets, yes, with JSP, no.
-- Adam
On 6/8/07, Adam Winer [EMAIL PROTECTED] wrote:
This certainly explains why it doesn't work now.
I've no idea why it worked in JSF 1.2 - I'm a bit
skeptical of that, to be honest.
-- Adam
On 6/8/07, Francisco Passos [EMAIL PROTECTED] wrote:
Placed this before calling isPostBack:
try {
throw new Exception(--when am i calling
isPostback?--);
} catch(Exception e) {
e.printStackTrace();
}
Here's the result:
java.lang.Exception: --when am i calling isPostback?--
at
pt.dgaiec.stp.beans.GenericBean.adfIsPostback
(GenericBean.java:59)
at
pt.dgaiec.stp.beans.GenericBean.isPostback (GenericBean.java
:40)
at
pt.dgaiec.stp.beans.GenericBean.setInitialization(GenericBean.java
:110)
at
sun.reflect.NativeMethodAccessorImpl.invoke0 (Native
Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.commons.beanutils.PropertyUtils.setSimpleProperty
(PropertyUtils.java :1789)
at
com.sun.faces.config.ManagedBeanFactory.setPropertiesIntoBean(
ManagedBeanFactory.java:564)
at
com.sun.faces.config.ManagedBeanFactory.newInstance(
ManagedBeanFactory.java
:234)
at
com.sun.faces.application.ApplicationAssociate.createAndMaybeStoreManagedBeans(
ApplicationAssociate.java:253)
at
com.sun.faces.el.VariableResolverImpl.resolveVariable
(VariableResolverImpl.java:78)
at
org.apache.myfaces.trinidadinternal.el.TrinidadVariableResolver.resolveVariable
(TrinidadVariableResolver.java:54)
at
com.sun.facelets.el.LegacyELContext$LegacyELResolver.getType
(LegacyELContext.java
:107)
at
com.sun.el.parser.AstIdentifier.setValue(AstIdentifier.java:96)
at
com.sun.el.ValueExpressionImpl.setValue(ValueExpressionImpl.java:255
Re: [Trinidad] Changes to isPostback?
)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:181)
Does this help?
Anyway, it worked with JSF1.2. Can I use JSF 1.2 safely in a container that
doesn't support JSP 2.1 - weblogic 9.2? Is there any way (context params,
etc.) to tell JSF that it is in such a container? Or is there a way I can
program safely around unsupported calls?
On 6/5/07, Adam Winer [EMAIL PROTECTED] wrote:
I'd suggest seeing a stacktrace to find out what phase this is
being invoked in. RequestContext.isPostback() doesn't work
until the end of Restore View phase, and I suspect your
code is being called during Restore View.
-- Adam
On 6/4/07, Francisco Passos [EMAIL PROTECTED] wrote:
Actually yes, I was using JSF 1.2 but since my application server
(Weblogic 9.2) doesn't support J2EE 5, I decided to switch to 1.1 for
full compatibility.
The full scenario is this: I have request-scoped beans that need to be
initialized (load properties from database). I'm using t:saveState to keep
the values between subsequent requests.
In order for my init method to be called for these beans, I created an
abstract bean (which my concrete beans extend) with the following:
protected boolean initialized = false;
public abstract void init() throws Exception;
public final void setInitialization(String value) {
if (!isPostback()) {
initialize();
}
}
public final void initialize() {
if (!initialized) {
try {
init();
initialized = true;
} catch (Exception e) {
...
}
}
}
protected final boolean isPostback() {
RequestContext context = RequestContext.getCurrentInstance();
if (context == null) {
return false;
}
return context.isPostback();
}
The entry point is the setInitialization method. To ensure it gets
called, I created a managed-property in each of my beans (in
faces-config.xml).
I don't know which phase it gets called in, but a while ago it worked
extremely well and in conjunction with Tomahawk's saveState, for subsequent
requests only the first would be initialized, whereas now, all of them are
:(
Should I switch back to 1.2? Is there anything I can do to use 1.2 in a
non-J2EE compliant app-server with any degree of confidence?
Thank you,
Francisco
On 6/1/07, Adam Winer [EMAIL PROTECTED] wrote:
I don't think there've been any changes in Trinidad. Have
you changed the version of JSF you're using? At
what point in the JSF lifecycle are you calling
isPostback()?
-- Adam
On 6/1/07, Francisco Passos [EMAIL PROTECTED] wrote:
Good afternoon.
Have there been any changes to the underlying mechanism of
RequestContext.isPostback since version 1.0.0-incubating?
I've noticed that returning null after executing an action triggered
by a
button, for instance, is no longer considered a postback. Is this
true and
if true, is it intended?
By the way, having a tr:commandButton text=simulate postback /
is no
longer detected as one :S and it doesn't even define the action...
Thank you,
Francisco
Re: [Trinidad] Changes to isPostback?
I would too, if I hadn't lost several days trying to get proper bean
initialization and statekeeping to work :)
As soon as I get some time for this, I'm going back to 1.2 and check it.
I'll let you know.
One of my doubts prevails though: is it possible to run JSF 1.2 safely on a
non J2EE 5 container such as weblogic 9.2? I believe it isn't, but either
way, I'd like to know from someone that, unlike me, has a greater grasp of
the implications.
On 6/8/07, Adam Winer [EMAIL PROTECTED] wrote:
This certainly explains why it doesn't work now.
I've no idea why it worked in JSF 1.2 - I'm a bit
skeptical of that, to be honest.
-- Adam
On 6/8/07, Francisco Passos [EMAIL PROTECTED] wrote:
Placed this before calling isPostBack:
try {
throw new Exception(--when am i calling isPostback?--);
} catch(Exception e) {
e.printStackTrace();
}
Here's the result:
java.lang.Exception: --when am i calling isPostback?--
at
pt.dgaiec.stp.beans.GenericBean.adfIsPostback(GenericBean.java:59)
at
pt.dgaiec.stp.beans.GenericBean.isPostback(GenericBean.java
:40)
at
pt.dgaiec.stp.beans.GenericBean.setInitialization(GenericBean.java:110)
at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.commons.beanutils.PropertyUtils.setSimpleProperty
(PropertyUtils.java:1789)
at
com.sun.faces.config.ManagedBeanFactory.setPropertiesIntoBean(
ManagedBeanFactory.java:564)
at
com.sun.faces.config.ManagedBeanFactory.newInstance(
ManagedBeanFactory.java:234)
at
com.sun.faces.application.ApplicationAssociate.createAndMaybeStoreManagedBeans
(ApplicationAssociate.java:253)
at
com.sun.faces.el.VariableResolverImpl.resolveVariable(
VariableResolverImpl.java:78)
at
org.apache.myfaces.trinidadinternal.el.TrinidadVariableResolver.resolveVariable
(TrinidadVariableResolver.java:54)
at
com.sun.facelets.el.LegacyELContext$LegacyELResolver.getType(
LegacyELContext.java
:107)
at
com.sun.el.parser.AstIdentifier.setValue(AstIdentifier.java:96)
at
com.sun.el.ValueExpressionImpl.setValue(ValueExpressionImpl.java:255)
at com.sun.facelets.el.TagValueExpression.setValue
(TagValueExpression.java:93)
at
com.sun.facelets.el.LegacyValueBinding.setValue(LegacyValueBinding.java
:68)
at
org.apache.myfaces.custom.savestate.UISaveState.restoreState(
UISaveState.java:101)
at
javax.faces.component.UIComponentBase.processRestoreState(
UIComponentBase.java:999)
at
org.apache.myfaces.trinidad.component.TreeState.restoreState(
TreeState.java:96)
at
org.apache.myfaces.trinidad.component.UIXComponentBase.processRestoreState
(UIXComponentBase.java:816)
at
javax.faces.component.UIComponentBase.processRestoreState(
UIComponentBase.java:1011)
at
org.apache.myfaces.trinidad.component.TreeState.restoreState(
TreeState.java:96)
at
org.apache.myfaces.trinidad.component.UIXComponentBase.processRestoreState
(UIXComponentBase.java:816)
at
org.apache.myfaces.trinidad.component.TreeState.restoreState(
TreeState.java:96)
at
org.apache.myfaces.trinidad.component.UIXComponentBase.processRestoreState
(UIXComponentBase.java:816)
at
javax.faces.component.UIComponentBase.processRestoreState(
UIComponentBase.java:1011)
at
org.apache.myfaces.trinidadinternal.application.StateManagerImpl.restoreView
(StateManagerImpl.java:486)
at
com.sun.faces.application.ViewHandlerImpl.restoreView(
ViewHandlerImpl.java:246)
at
com.sun.facelets.FaceletViewHandler.restoreView(FaceletViewHandler.java
:317)
at
org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl.restoreView
(ViewHandlerImpl.java:265)
at
com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java
:157)
at com.sun.faces.lifecycle.LifecycleImpl.phase
(LifecycleImpl.java:200)
at
com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:90)
at
javax.faces.webapp.FacesServlet.service(FacesServlet.java:197)
at
weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run
(StubSecurityHelper.java:225)
at
weblogic.servlet.internal.StubSecurityHelper.invokeServlet(
StubSecurityHelper.java:127)
at
weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java
:283)
at
weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:26)
at
weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java
:42)
at
org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter
(ExtensionsFilter.java:147
Re: [Trinidad] Changes to isPostback?
Actually yes, I was using JSF 1.2 but since my application server (Weblogic
9.2) doesn't support J2EE 5, I decided to switch to 1.1 for full
compatibility.
The full scenario is this: I have request-scoped beans that need to be
initialized (load properties from database). I'm using t:saveState to keep
the values between subsequent requests.
In order for my init method to be called for these beans, I created an
abstract bean (which my concrete beans extend) with the following:
protected boolean initialized = false;
public abstract void init() throws Exception;
public final void setInitialization(String value) {
if (!isPostback()) {
initialize();
}
}
public final void initialize() {
if (!initialized) {
try {
init();
initialized = true;
} catch (Exception e) {
...
}
}
}
protected final boolean isPostback() {
RequestContext context = RequestContext.getCurrentInstance();
if (context == null) {
return false;
}
return context.isPostback();
}
The entry point is the setInitialization method. To ensure it gets called, I
created a managed-property in each of my beans (in faces-config.xml).
I don't know which phase it gets called in, but a while ago it worked
extremely well and in conjunction with Tomahawk's saveState, for subsequent
requests only the first would be initialized, whereas now, all of them are
:(
Should I switch back to 1.2? Is there anything I can do to use 1.2 in a
non-J2EE compliant app-server with any degree of confidence?
Thank you,
Francisco
On 6/1/07, Adam Winer [EMAIL PROTECTED] wrote:
I don't think there've been any changes in Trinidad. Have
you changed the version of JSF you're using? At
what point in the JSF lifecycle are you calling
isPostback()?
-- Adam
On 6/1/07, Francisco Passos [EMAIL PROTECTED] wrote:
Good afternoon.
Have there been any changes to the underlying mechanism of
RequestContext.isPostback since version 1.0.0-incubating?
I've noticed that returning null after executing an action triggered by
a
button, for instance, is no longer considered a postback. Is this true
and
if true, is it intended?
By the way, having a tr:commandButton text=simulate postback / is no
longer detected as one :S and it doesn't even define the action...
Thank you,
Francisco
Re: Issue with Tomahawk Menu
You say the problem is intermitent. I assume you mean some of the time it
works, and some it doesn't.
Since your bean is session-scoped, could it be that the session expired and
your bean has been discarded?
On 6/1/07, Anupama Dande [EMAIL PROTECTED] wrote:
Hi Mike,
Maybe both issues (NavigationMenuItem and the binding) are related. I
wasn't able to troubleshoot much.
I hope to fix it with help from u guys. This is my first topic on this
forum. It is great to get the replies so prompt.
Thanks to all of you,
Anu
On 6/1/07, Mike Kienenberger [EMAIL PROTECTED] wrote:
This looks to me like the same issue as with Problem with Binding in
tr:table -- your managed beans aren't being initialized.
I think Andrew is probably farther along with helping you on that line
than I am.
On 6/1/07, Anupama Dande [EMAIL PROTECTED] wrote:
Both.
--Anu
On 6/1/07, Mike Kienenberger [EMAIL PROTECTED] wrote:
Is it umenu.menu = null or is it umenu = null?
On 6/1/07, Anupama Dande [EMAIL PROTECTED] wrote:
Hi Mike,
Method Signature : public ListNavigationMenuItem getMenu()
This problem is intermittent. Every time this happens I have
to
create a
new workspace in Eclipse... and that solves the issue, maybe there
is
some
Caching issue with Eclipse. I am deploying my web application from
Eclipse
IDE.
Actually i should say the menu is returning null when this
error
occurs
if I try to print
MENU ITEM VALUE : h:outputText value=#{ umenu.menu
}/
I tried to debug, it is not breaking at getMenu() method ..
for some
reason. Do you think it is some caching problem?
Thanks,
Anu
On 6/1/07, Mike Kienenberger [EMAIL PROTECTED] wrote:
What is the method signature of myPackage.TestMenu.getMenu()?
What is the contents of getMenu()?
I don't see that the scope will matter provided that umenu is
non-null.
On 6/1/07, Anupama Dande [EMAIL PROTECTED] wrote:
Hi Mike,
It is NavigationMenuItem
(org.apache.myfaces.custom.navmenu.NavigationMenuItem)
Collection.
I am using Tomahawk JSCookMenu in test.xhtml as
t:jscookMenu layout=hbr
theme=ThemeOffice
t:navigationMenuItems
value=#{
umenu.menu} /
/t:jscookMenu
input type=hidden name=jscook_action /
and in the faces_config.xml file the entry is
managed-bean
descriptionUser Menu/description
managed-bean-nameumenu/managed-bean-name
managed-bean-class
myPackage.TestMenu/managed-bean-class
managed-bean-scopesession/managed-bean-scope
/managed-bean
I tried changing the scope from session to none .. but the
error
just
keeps coming.
I am using Facelets, Trinidad, Tomahawk for the
Presentation.
If you need more information please let me know.
Thanks,
Anu
On 6/1/07, Mike Kienenberger [EMAIL PROTECTED] wrote:
Seems pretty straight forward -- what's the value binding of
the
_id14
component bound to? Apparently not a NavigationMenuItem or
collection
of NavigationMenuItems.
On 6/1/07, Anupama Dande [EMAIL PROTECTED] wrote:
Hi,
I am getting the following error
SEVERE: Error Rendering
View[/common/xhtml/jcm/createChangeOrder/manageChangeOrders.xhtml]
java.lang.IllegalArgumentException: Value
binding
of
UINavigationMenuItems with id menuForm:_id14 does not
reference
an
Object of
type NavigationMenuItem, NavigationMenuItem[], Collection
or Map
Any help is highly appreciated.
Thanks,
Anu
[Trinidad] Changes to isPostback?
Good afternoon. Have there been any changes to the underlying mechanism of RequestContext.isPostback since version 1.0.0-incubating? I've noticed that returning null after executing an action triggered by a button, for instance, is no longer considered a postback. Is this true and if true, is it intended? By the way, having a tr:commandButton text=simulate postback / is no longer detected as one :S and it doesn't even define the action... Thank you, Francisco
Re: [Trinidad] Weblogic + Debug
Tried today's nightly build and the error no longer appears. Thank you. Francisco On 5/30/07, Francisco Passos [EMAIL PROTECTED] wrote: Excellent news! Thank you, Francisco On 5/30/07, Adam Winer [EMAIL PROTECTED] wrote: http://issues.apache.org/jira/browse/TRINIDAD-44 Fixed. -- Adam On 5/29/07, Francisco Passos [EMAIL PROTECTED] wrote: Thank you. Are there plans to address this bug soon? On 5/29/07, Adam Winer [EMAIL PROTECTED] wrote: Looks like a (minor) bug in Trinidad. Code should be clearing RenderingContext.setCurrentClientId () but isn't, and the assert is catching that. We should be running our tests with asserts enabled, IMO, which I think would have caught this particular problem. -- Adam On 5/29/07, Francisco Passos [EMAIL PROTECTED] wrote: Good afternoon. I'm developing an application with Trinidad on Weblogic Application Server 9.2. It works fine in normal circumstances, but whenever I start weblogic in debug mode (to attach by socket in Eclipse), pages cease to render and this error is presented instead. Error 500--Internal Server Error java.lang.AssertionError at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.CommandButtonRenderer.encodeAll (CommandButtonRenderer.java :75) at org.apache.myfaces.trinidad.render.CoreRenderer.encodeEnd( CoreRenderer.java:184) at org.apache.myfaces.trinidad.component.UIXComponentBase.encodeEnd( UIXComponentBase.java:701) at org.apache.myfaces.trinidad.render.CoreRenderer.encodeChild ( CoreRenderer.java:263) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelGroupLayoutRenderer.encodeChild (PanelGroupLayoutRenderer.java:177) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelGroupLayoutRenderer._encodeChildren (PanelGroupLayoutRenderer.java:143) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelGroupLayoutRenderer.encodeAll (PanelGroupLayoutRenderer.java:95) at org.apache.myfaces.trinidad.render.CoreRenderer.encodeEnd ( CoreRenderer.java:184) at org.apache.myfaces.trinidad.component.UIXComponentBase.encodeEnd (UIXComponentBase.java:701) at org.apache.myfaces.trinidadinternal.uinode.UIComponentUINode._renderComponent (UIComponentUINode.java:336) at org.apache.myfaces.trinidadinternal.uinode.UIComponentUINode.render (UIComponentUINode.java:278) at org.apache.myfaces.trinidadinternal.uinode.UIComponentUINode.render( UIComponentUINode.java:255) at org.apache.myfaces.trinidadinternal.ui.composite.ContextPoppingUINode$ContextPoppingRenderer.render (ContextPoppingUINode.java :235) at org.apache.myfaces.trinidadinternal.ui.BaseUINode.render ( BaseUINode.java:357) at org.apache.myfaces.trinidadinternal.ui.BaseUINode.render( BaseUINode.java :312) at org.apache.myfaces.trinidadinternal.ui.BaseRenderer.renderChild (BaseRenderer.java:424) at org.apache.myfaces.trinidadinternal.ui.BaseRenderer.renderNamedChild( BaseRenderer.java :396) at org.apache.myfaces.trinidadinternal.ui.laf.base.desktop.FooterRenderer.postrender (FooterRenderer.java :80) at org.apache.myfaces.trinidadinternal.ui.BaseRenderer.render ( BaseRenderer.java :94) at org.apache.myfaces.trinidadinternal.ui.laf.base.xhtml.XhtmlLafRenderer.render (XhtmlLafRenderer.java:83) at org.apache.myfaces.trinidadinternal.ui.BaseUINode.render (BaseUINode.java :357) at org.apache.myfaces.trinidadinternal.ui.BaseUINode.render( BaseUINode.java :312) at org.apache.myfaces.trinidadinternal.ui.BaseRenderer.renderChild( BaseRenderer.java:424) at org.apache.myfaces.trinidadinternal.ui.BaseRenderer.renderIndexedChild (BaseRenderer.java:342) at org.apache.myfaces.trinidadinternal.ui.BaseRenderer.renderIndexedChild (BaseRenderer.java:234) at org.apache.myfaces.trinidadinternal.ui.BaseRenderer.renderContent( BaseRenderer.java:141) at org.apache.myfaces.trinidadinternal.ui.BaseRenderer.render ( BaseRenderer.java:92) at org.apache.myfaces.trinidadinternal.ui.laf.base.xhtml.XhtmlLafRenderer.render (XhtmlLafRenderer.java:83) at org.apache.myfaces.trinidadinternal.ui.BaseUINode.render (BaseUINode.java :357) at org.apache.myfaces.trinidadinternal.ui.BaseUINode.render( BaseUINode.java:312) at org.apache.myfaces.trinidadinternal.ui.composite.UINodeRenderer.renderWithNode (UINodeRenderer.java :103) at org.apache.myfaces.trinidadinternal.ui.composite.UINodeRenderer.render (UINodeRenderer.java:49) at org.apache.myfaces.trinidadinternal.uinode.UIXComponentUINode.renderInternal (UIXComponentUINode.java:191
Re: [Tomahawk] t:dataTable with dynamic columns
They were both filled :/
Nevertheless I opted for having a fixed set of columns and rendering them
conditionally. I haven't tested it thoroughly yet, but at least the tables
are being displayed.
On 5/29/07, Mike Kienenberger [EMAIL PROTECTED] wrote:
Well, if the table isn't being rendered, there's only two reasonable
possibilities.
1) your rendered condition is false
2) your backing list (value attribute target) is empty.
You should be able to check both of these situations by outputing the
contents of both attributes with h:outputText above your table.
On 5/28/07, Francisco Passos [EMAIL PROTECTED] wrote:
Unfortunately, placing the bean in session didn't solve the problem.
I've also checked the rendered attribute values and they're ok.
I should say that I'm iterating over a tr:table and on a specific column
I'd
like to render this t:dataTable (to use with t:columns).
I really need to get this going and don't know what I might be doing
wrong.
Is there anything else I might provide that could shed light on this
problem?
On 5/25/07, Mike Kienenberger [EMAIL PROTECTED] wrote:
No, facelets doesn't change anything provided you've defined the tags
in your taglib.xml file correctly. Is #{attribute.tableAttributeData}
request-scoped? As a test, try making this bean session-scoped
temporarily and see if everything suddenly works as expected.
If so, then you need to preserve the state of that list. You might
also want to test it without the rendered attributes to be sure that
the problem doesn't lie there.
On 5/25/07, Francisco Passos [EMAIL PROTECTED] wrote:
I've tried using just h:outputText and just t:outputText.
Plus I tried this:
t:dataTable value=#{attribute.tableAttributeData}
var=lineAttributeData
rendered=#{attribute.xtipdado eq 'T'}
t:columns value=#{lineAttributeData} var=attributeData
style=padding: 0px; headerstyle=padding: 0px; background-color:
#dd;
t:column
f:facet name=header
t:outputText value=#{attributeData.inomcol}
style=font-size : 10px;/
/f:facet
t:outputText value=#{lineAttributeData}
style=font-size:
10px; /
/t:column
/t:columns
/t:dataTable
I also tried it with the facet in t:columns but outside t:column.
Still, the dataTable doesn't show.
I've had t:dataTable components rendering (even within a tr:table
component), so I can't understand what is wrong.
I'm using facelets, does change anything?
On 5/24/07, Mike Kienenberger [EMAIL PROTECTED] wrote:
You need to have
t:dataTable
t:columns
t:column/
t:column/
t:columns
t:column/
t:column/
t:column/
t:dataTable
On 5/24/07, Francisco Passos [EMAIL PROTECTED] wrote:
Good day to all.
I have a ListListMyType ( attribute.tableAttributeData) and
am
trying to
present it in a table like this:
t: dataTable value=#{attribute.tableAttributeData}
var=lineAttributeData
t:columns value=#{lineAttributeData} var=attributeData
f:facet name=header
t:outputText value=#{ attributeData.inomcol} /
/f:facet
h:outputText value=#{ attributeData.xvalor} /
/t:columns
/t:dataTable
However the table does not appear at all. Did I miss something?
Francisco Passos
