Re: [announcement] JTK: An Ajax JSF Component Development Framework
On 10/31/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: On 10/31/07, noah [EMAIL PROTECTED] wrote: On 10/31/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, did a quick look and found these two statements: -Apache Trinidad requires that the developer create the tag library file and a renderer. = you write meta-data and a renderer. The meta-data is used to *generate* TLD/the components. Metadata is also useful for tools. Sorry, I must have misunderstood. I wrote most of that six months ago, and there wasn't any documentation about how it works/how to use it. -Components developed with Trinidad only work properly with the Trinidad view root. = there is no TrinidadViewRoot class. Sorry if I misunderstood, but there wasn't any documentation about it when I wrote that. Am I wrong that Trinidad generated components will only work with Trinidad? I'm not trying to spread misinformation, that is just my understanding of the way things worked a few months ago. there is a tr:document OR trh:html / body that render the links to the required source like CSS / JavaScript, but you can mix Trinidad with Tomahawk, for instance. ... and even these aren't really necessary. You can get by with a simple trh:styleSheet to pull in the CSS. (It used to be necessary to use one of tr:document, tr:panelPartialRoot, or trh:body for PPR to work, but that restriction went away back in 1.0.2.) -- Adam The big issue general is that lot's of component libs don't work 100% with others, I hope that JSF2 will provide a better integration mechanism
Re: [Trinidad 1.0.3] returnListener is broken
Interesting idea - I could go for that... Not 100% thrilled about adding a new EL variable, but OTOH I could also question why we'd ever want varStatus set to the selected row (which happens if you tie currency to selection). -- Adam On 10/23/07, max.starets [EMAIL PROTECTED] wrote: Good point, Adam. I submitted a new patch for JIRA-771 that completely reverts changes made for JIRA-737. Regarding concerns raised in JIRA-737: would it make sense to provide an EL variable for selected row (add a selectedVar property for table)? This would allow declarative code to refer to the selected row (which I always thought was lacking in table) without us having to do something ugly with the client IDs. Thanks, Max Adam Winer wrote: On 10/17/07, max.starets [EMAIL PROTECTED] wrote: Thanks, Adam. I like your suggestion. The only exception I see is that we would still establish currency for selection events. Agreed? Wouldn't that still mean that if you launch a dialog during a selection event, the return will fail?. Or that PPR'ing a facet of the table in response to a selection event will likely fail? I'm wondering if we want something much uglier here: a way to still establish currency (and do it for all events), but without mucking with client IDs. -- Adam -- View this message in context: http://www.nabble.com/-Trinidad-1.0.3--returnListener-is-broken-tf4594019.html#a13365888 Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: [Trinidad] org.apache.myfaces.trinidadinternal.io.DebugResponseWriter _logDuplicateId
On 10/19/07, Martin Ahrer [EMAIL PROTECTED] wrote:
Trinidad is warning about duplicate id attributes even though I do NOT have
used duplicate ids. So, I'm concerned if something can be done to avoid them
or at least I'd like to know if any troubles can result from them?
Both of these cases are coming from not recognizing that tr:inputText
has built-in label and message support unless you set simple=true.
In this special case I was able to produced these warning either this way
tr:panelLabelAndMessage for=typeInput label=Type
tr:inputText id=typeInput
value=#{queryByExampleController.example.type}/
/tr:panelLabelAndMessage
This should generally just be:
tr:inputText id=typeInput label=Type
value=#{queryByExampleController.example.type}/
--
19.10.2007 16:27:43
org.apache.myfaces.trinidadinternal.io.DebugResponseWriter _logDuplicateId
WARNUNG: The id typeInput::icon is used more than once.
19.10.2007 16:27:43
org.apache.myfaces.trinidadinternal.io.DebugResponseWriter _logDuplicateId
WARNUNG: The id typeInput::msg is used more than once.
or even here
tr:inputText id=typeInput value=xxx/tr:message for=typeInput/
... and here, the tr:message is unnecessary (unless you set
simple=true on the inputText).
-- Adam
--
19.10.2007 16:27:43
org.apache.myfaces.trinidadinternal.io.DebugResponseWriter _logDuplicateId
WARNUNG: The id typexxx::msg is used more than once.
with the later case the warning disappears as the tr:message is removed!
--
View this message in context:
http://www.nabble.com/-Trinidad--org.apache.myfaces.trinidadinternal.io.DebugResponseWriter-_logDuplicateId-tf4653676.html#a13295836
Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: [Trinidad 1.0.3] returnListener is broken
On 10/17/07, max.starets [EMAIL PROTECTED] wrote: Thanks, Adam. I like your suggestion. The only exception I see is that we would still establish currency for selection events. Agreed? Wouldn't that still mean that if you launch a dialog during a selection event, the return will fail?. Or that PPR'ing a facet of the table in response to a selection event will likely fail? I'm wondering if we want something much uglier here: a way to still establish currency (and do it for all events), but without mucking with client IDs. -- Adam I will submit a new patch for review. Sorry for introducing the bug in a first place. Max Adam Winer wrote: The fix, I think, is to not set the currency, but instead merely set up the EL state as if currency were set, e.g. going from - set row key to first selected row - process the event - restore row key ... to the more verbose: - get original values var and varStatus off the request map - set row key to first selected row - grab new var and varStatus off the request map - restore row key - set new var and varStatus onto the request map - process the event - restore var and varStatus to original values For now, you can work around this (significant) bug by moving the panelButtonBar to after the table, and out of the footer. But we should roll a 1.0.4 fairly soon to fix this regression, and any others if they get found soon. -- View this message in context: http://www.nabble.com/-Trinidad-1.0.3--returnListener-is-broken-tf4594019.html#a13254310 Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: [Trinidad] Force Trinidad to display disabled text field rather than plain text?
There's no skinning property. IMO, Trinidad is absolutely doing the right thing here. In user interfaces, disabled state should only be used when there is some way for the user to re-enable the field; in this case, that is not possible, so plain text is giving the user exactly the right feedback. -- Adam On 10/12/07, Stephen Friedrich [EMAIL PROTECTED] wrote: My requirements demand some read-only fields that show detail data of a selected table row.. Currently I have found no other solution than to create setters for these fields in my backing bean, even though business logic demands that those values will never be changed. If I omit the setters Trinidad always renders the values as plain text. Am I missing some magic skinning property?
Re: [Trinidad 1.0.3] backward compatibility
Yeah, we really could use info on whether it was 1.0.2 or 1.0.3 that causes the problems. And, since obviously we wouldn't have released anything if the whole thing was broken, it's important to make some attempt to say exactly what is failing and how, and to provide a minimal testcase of something that does not work. -- Adam On 10/9/07, Simon Lessard [EMAIL PROTECTED] wrote: Hello Andrew, It should be backward compatible, yes. However there was some big changes from 1.0.1 to 1.0.2, true AJAX PPR mainly. Do you get any exception stack trace or is it just the components refusing to work? Also, what happen if you use 1.0.2? Regards, ~ Simon On 10/9/07, Andrew Richards [EMAIL PROTECTED] wrote: Hello all. Can anyone tell me if Trinidad 1.0.3 is backward compatible with Trinidad 1.0.1? I have a reasonably complex legacy JSF application which I have tried porting to 1.0.3 for a number of reasons. Unfortunately the application fails miserably. Just taking a quick glance I can see MenuModel, PanelAccordian, TreeTable etc etc all fail in my application? Are there any major configuration changes I need to make to port to Trinidad 1.0.3 ? Currently all I have done is changed the dependency in my maven pom. Many thanks Andy
Re: [Trinidad 1.0.3] returnListener is broken
OK, it's not a general issue with returnListener; it's returnListener
inside a facet of the table. Nice job analyzing this down to
TRINIDAD-737 - makes it easy to discern the problem.
The problem is that we've started setting currency by calling
setRowKey() on the table, but that means that the clientId of
the contents start changing... which is wrong. Shoulda thought
of that when I reviewed this. There'll be other things that break
(for instance, PPR within a facet of the table).
The fix, I think, is to not set the currency, but instead merely
set up the EL state as if currency were set, e.g. going from
- set row key to first selected row
- process the event
- restore row key
... to the more verbose:
- get original values var and varStatus off the request map
- set row key to first selected row
- grab new var and varStatus off the request map
- restore row key
- set new var and varStatus onto the request map
- process the event
- restore var and varStatus to original values
For now, you can work around this (significant) bug by
moving the panelButtonBar to after the table, and
out of the footer. But we should roll a 1.0.4 fairly
soon to fix this regression, and any others if they get
found soon.
-- Adam
On 10/8/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hi,
if i add a returnListener to my commandButton, which is defined in a facet
from a table, the returnListener is not called anymore. He is a short example:
tr:table var=row value=#{backing.allRows}
f:facet name=footer
tr:panelButtonBar
tr:commandButton text=Hit me partialSubmit=true useWindow=true
immediate=true action=dialog:openHitMeDialog
returnListener=#{backing.handleReturn} /
/tr:panelButtonBar
/f:facet
tr:column
f:facet name=header
af:outputText value=Header 1
/f:facet
tr:outputText value=#{row.data} /
/tr:column
/tr:table
I have tested this scenario with trinidad 1.0.2 and it works fine. The
difference between these releases is amongst others the jira issue
TRINIDAD-737. I have removed this changes from my trinidad 1.0.3 source and
started a new build and now the returnListener is called again.
Is it a problem how i defined the commandButton in my page or is it a bug
that comes with TRINIDAD-737???
Hope anybody can help me...
Cheers Sven
--
Pt! Schon vom neuen GMX MultiMessenger gehört?
Der kanns mit allen: http://www.gmx.net/de/go/multimessenger
Re: [Trinidad]Dialog framework restricted to faces servlet path mapping ???
It's not a Trinidad issue per se - it's a problem with
some JSF implementations. Specifically,
it's broken in MyFaces 1.2.0 and early revs of
the Sun RI, but works in the most recent Sun
RI releases.
-- Adam
On 10/1/07, Martin Ahrer [EMAIL PROTECTED] wrote:
Im facing a strange behaviour with popping up dialog windows when using
extension mapping for the servlet.
I have a servlet mapping like:
servlet-mapping
servlet-namefaces/servlet-name
url-pattern*.faces/url-pattern
/servlet-mapping
and a navigation rule
navigation-rule
from-view-id/application/reportviewer/reportviewer.jspx/from-view-id
navigation-case
from-action#{reportViewerController.run}/from-action
from-outcomedialog:success/from-outcome
to-view-id/application/reportviewer/report.jspx/to-view-id
/navigation-case
/navigation-rule
The managed bean method run returns dialog:success but the view as
implemented in the to-view-id does not get called!
Instead a popup window shows up with some error message saying that the
requested URL does not exist
The requested resource (/birt-web-0.2.4-SNAPSHOT/__ADFv__.jspx) is not
available.
So it seems something creates a URL that is totally screwed up!
As soon as I switch to wildcard mapping
servlet
servlet-namefaces/servlet-name
servlet-classjavax.faces.webapp.FacesServlet/servlet-class
load-on-startup1/load-on-startup
/servlet
servlet-mapping
servlet-namefaces/servlet-name
url-pattern/faces/*/url-pattern
/servlet-mapping
the dialog popup works as expected!
Is there any known requirement regarding the faces servlet mapping with
trinidad? Thanks for your hints!
--
View this message in context:
http://www.nabble.com/-Trinidad-Dialog-framework-restricted-to-faces-servlet-path-mapping-tf4549427.html#a12982682
Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: [Trinidad] Help or Links to documentation on Trinidads's conversation and context mechanism
The doc we've got is: http://myfaces.apache.org/trinidad/devguide/communicatingBetweenPages.html -- Adam On 10/2/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi, Regarding a couple of issues with Seam 2.0 RC 1 , possibly because of the combination with Trinidad and other tag libraries, we are looking for some information on the way Trinidad's conversation and context mechanism works, some links on documentation or also some hints on the mechanism would be helpful. Many thanks, Wolfgang.
Re: [Trinidad] div/ after tr:image/ - possible to remove?
Wrap the two images in an af:group or af:panelGroupLayout. -- Adam On 9/28/07, Chris Hane [EMAIL PROTECTED] wrote: I have a column that displays two images in it. I would like the images to be displayed side/by side. However, a div/ element is being inserted between the images. Thoughts on how I can format this so that the div is not displayed? Thanks, Chris Here is the XHTML (facelets): tr:column headerText=Status noWrap=true tr:image source=/img/status/good.png/ tr:image source=img/status/recommended.png /tr:column ...And this is the html produced: td class=af_column_cell-text OraTableBorder nowrap= img src=/learn-local/img/status/thumbup.png/ div/ img src=img/status/greexlclaim.png/ /td
Re: [Trinidad] panelPopup: how to avoid full page refreshing
On 9/25/07, Andrew Robinson [EMAIL PROTECTED] wrote:
If I am right, a trinidad component can trigger if one of its children
have an event, so the following should work:
No, this example below means repaint the panelBox 'popupContents'
if the component itself has an event. This is basically an example
of the how do I PPR contents that I don't control issue you pointed
out.
tr:panelPopup
tr:panelBox id=popupContents background=transparent
partialTrigger=popupContents
// your include here
/tr:panelBox
/tr:panelPopup
You can use any trinidad component that produces a client ID in the
HTML page, not necessarily panelBox. I am not aware of an equivalent
to h:panelGroup in Trinidad that can be used as a simple SPAN/DIV,
but if you find one, that would be best.
tr:panelGroupLayout.
-- Adam
I didn't test this, but it should work from what I know.
-Andrew
On 9/25/07, Renzo Tomaselli [EMAIL PROTECTED] wrote:
This means that if my panelPopup specifies the id of its contained
component as a partialTrigger target, all I need is to generalize the
contents to provide a single id to the container. Then *any* action
occurring inside that contained component would lead to a container PPR ?
Unfortunately, a container component like a panelPopup does not know its
contents (which is dynamically included), but this is an architectural issue
I can work around somehow, using the panel bean as a bridge to let the
containee communicating its id to the container, and having this retrieving
partialTrigger value through a bean property.
Oh well, it's worth to try.
-- Renzo
Andrew Robinson wrote:
Why can't you just put a component in the top level of the included
page that has partialTriggers for your event generating components?
There is no need to re-render the entire page. The PPR works on client
IDs, so it doesn't matter if the component is in the DIV tag of a
popup (the popup is nothing special when it comes to HTML, it just has
some CSS positioning on it).
On 9/25/07, Renzo Tomaselli [EMAIL PROTECTED] wrote:
Danny, assume a panelPopup holds a Facelets ui:included component. Thus in
general it can be anything. All actions originated by panel contents can
either to close the panel or to change its contents. In the latter case,
refreshing should not affect the overall page.
My actual modal panel xhtml component is:
ui:component
c:if test=#{bean.visible}
t:saveState id=component value=#{bean.component}/
t:saveState id=componentBeanName
value=#{bean.componentBeanName}/
tr:panelPopup id=modal alignment=center modal=true
f:facet name=trigger
tr:commandButton id=modalTrigger text=d
inlineStyle=visibility: hidden onclick=return false;/
/f:facet
cx:include src=#{bean.component}
bean=#{bean.componentBean} container=#{container}/
/tr:panelPopup
/c:if
/ui:component
This component is included in the app. page but in turn it can contain any
other panel (see cx:include, just some sugar to replace ui:include).
This inclusion is runtime-defined by #{bean.component}. When such component
changes (think about a multi-panel wizard hosting next/previous widgets),
there is no reason to refresh the entire page, unless the popup panel itself
has to disappear (!visible). The popup panel is activated by an onload
script which clicks modalTrigger, since till now this component misses any
other activation way.
Btw, such PPR would be a nice effect on the overall page as well: in my
app. there is only one single page, where a number of facelets components
act as containers, even in nesting mode. In all cases where a single panel
(e.g. xhtml component) is replaced, there is no reason to redraw all others.
Concerning dialogs - so far I thought they lead to rendering pages, an
effect I wanted to avoid. But maybe lightweight leads to something
different, I miss a clear picture about when using either popup panels or
dialogs.
-- Renzo
Danny Robinson wrote:
Renzo,
Do you have a small test-case you can post, you certainly should be able to
use PPR inside a model panelPopup. Although it may be a better option to
use lightweight dialogs for what you're suggesting.
Danny
On 9/25/07, Renzo Tomaselli [EMAIL PROTECTED] wrote:
Hi, I'm using tr:panelPopup in modal mode only. It works well, but since
it can host alternative panels (e.g. components in the Facelets sense),
the entire page is refreshed whenever a panel is replaced by another
one. Not a nice effect.
Panel navigation occurs from user actions (next/previous) inside the
panel itself.
AFAIK PPR is there just to avoid this effect, e.g. I should be able
somehow to force panel contents refresh only.
But I don't know how to do it.
Suggestions are welcome.
-- Renzo
--
Chordiant Software Inc.
www.chordiant.com
Re: [Trinidad] tr:tree expansion warning after upgrading to 1.02
The previous PPR strategy wrote out complete HTML documents
into an IFRAME. The new PPR strategy is pure XMLHttp,
and therefore there is no BODY or HEAD. This is 100%
intentional.
We'd need to talk to someone who knows the DefaultAddResource
code to describe how that code should work during AJAX
requests.
-- Adam
On 9/25/07, Renzo Tomaselli [EMAIL PROTECTED] wrote:
Adam, indeed the warning comes from Myfaces
(org.apache.myfaces.renderkit.html.util.DefaultAddResource
writeWithFullHeader).
Sorry, I lost this line while pasting.
I see it on the Eclipse console at any node click.
From some net browsing, I noticed that this is a known topic due to
MyFaces/Tomahawk filters: they might need to insert resources into the page
and they cannot find its head/body.
I'm referring to Trinidad since this issue appeared just after upgrading to
1.02, never seen it before. I guess previous versions emitted well-formed
PPR responses.
-- Renzo
Adam Winer wrote:
I don't think that's a warning coming from Trinidad code. At
least, I can't find that string anywhere in our codebase!
Is that really a logged Java warning?
-- Adam
On 9/24/07, Renzo Tomaselli [EMAIL PROTECTED] wrote:
Hi, since I had troubles while upgrading Trinidad from 1.01 to 1.02
(tr:tree branches did not expand anymore), and my app. was a mixup with
Trinidad-Tomahawk-Ajax4jsf, I removed all refs to Ajax4jsf/Richfaces.
However, tree node expansion now raises a warning all the times I click
on a node:
WARNING: Response has no head or body tag:
?xml version=1.0 ?
?Tr-XHR-Response-Type ?
content action=/AxxBrowser/startPage.faces
fragment![CDATA[div
id=browser:splitty0:navvy:dbTree style=white-space:
nowraptable
cellpadding=0 cellspacing=0 border=0 summary=tr
td width=16 title=Select to collapse
class=p_OraTreeDisclosedSymbola href=#
onclick=_adftreebrowser_splitty0_navvy_dbTree.treeState.action('hide','0',this);return
false;#9660;/a/td
...
although node expansion appears succeeding.
Any suggestion ?
Re: No component message shown after PPR?!
See http://issues.apache.org/jira/browse/TRINIDAD-697 As a partial workaround, if you have tr:messages on the page, that should get updated with the message. -- Adam On 9/25/07, Stephen Friedrich [EMAIL PROTECTED] wrote: I just used PPR for the first time and it was incredibly easy. However there's an issue I can't resolve: If, on the server, I add a faces warning message to a specific inputText component, I just don't see it after the request. (I do see any new value I set on the inputText, so PPR is working ok.) Any idea?
Re: [Trinidad] InstantiationException: PanelPartialRootRenderer
Sure looks like you have two versions of Trinidad in your classpath! file:/D:/bin/jboss-4.0.5.GA/server/default/./tmp/deploy/tmp41715plato.ear-contents/plato-exp.war/WEB-INF/lib/trinidad-impl-1.0.2-SNAPSHOT.jar and file:/D:/bin/jboss-4.0.5.GA/server/default/lib/trinidad-impl.jar Make sure you have only one (and preferably not a snapshot). -- Adam On 9/24/07, tartaruga [EMAIL PROTECTED] wrote: Sorry, the post went out a little bit too early. I wanted to ask if someone has an idea if I'm missing something in my configuration(s). I added the full stack trace at the end of the post. I appreciate any hints. Thanks Hi, I'm trying to upgrade to Trinidad 1.0.2. Currently I'm using Trinidad 1.0.1 with - Seam 1.2.1.GA - Facelets (the .jar delivered with Seam) - MyFaces 1.1.5 - Ajax4Jsf 1.1.1 - Richfaces 3.0.1 - JBoss 4.0.5 When upgrading to Trinidad 1.0.2 I get the exception below. After trying several web.xml and faces-config.xml I ended up using the one posted on this wiki: http://wiki.apache.org/myfaces-data/attachments/TrinidadSeamAjax4JsfFaceletDetail/attachments/sample-web.xml I also inspected the trindad code a little bit and noticed a code change in the affected class (PanelPartialRootRender): The constructor changed from public in version 1.0.1 to protected ni version 1.0.2. so 14:34:48,859 ERROR [ClassUtils] org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelPartialRootRenderer java.lang.InstantiationException: org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelPartialRootRenderer at java.lang.Class.newInstance0(Class.java:340) at java.lang.Class.newInstance(Class.java:308) at org.apache.myfaces.shared_impl.util.ClassUtils.newInstance(ClassUtils.java:277) at org.apache.myfaces.shared_impl.util.ClassUtils.newInstance(ClassUtils.java:268) at org.apache.myfaces.config.FacesConfigurator.configureRenderKits(FacesConfigurator.java:754) at org.apache.myfaces.config.FacesConfigurator.configure(FacesConfigurator.java:149) at org.apache.myfaces.webapp.StartupServletContextListener.initFaces(StartupServletContextListener.java:68) ... 14:34:48,859 ERROR [FacesConfigurator] failed to configure class org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelPartialRootRenderer javax.faces.FacesException: java.lang.InstantiationException: org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelPartialRootRenderer at org.apache.myfaces.shared_impl.util.ClassUtils.newInstance(ClassUtils.java:287) at org.apache.myfaces.shared_impl.util.ClassUtils.newInstance(ClassUtils.java:268) at org.apache.myfaces.config.FacesConfigurator.configureRenderKits(FacesConfigurator.java:754) at org.apache.myfaces.config.FacesConfigurator.configure(FacesConfigurator.java:149) 14:34:45,625 INFO [Initialization] done initializing Seam 14:34:45,625 INFO [FacesConfigurator] Reading standard config org/apache/myfaces/resource/standard-faces-config.xml 14:34:45,703 INFO [FacesConfigurator] Reading config jar:file:/D:/bin/jboss-4.0.5.GA/server/default/tmp/deploy/tmp41715plato.ear-contents/jboss-seam.jar!/META-INF/faces-config.xml 14:34:45,718 INFO [FacesConfigurator] Reading config jar:file:/D:/bin/jboss-4.0.5.GA/server/default/lib/trinidad-impl.jar!/META-INF/faces-config.xml 14:34:46,093 INFO [FacesConfigurator] Reading config jar:file:/D:/bin/jboss-4.0.5.GA/server/default/./tmp/deploy/tmp41715plato.ear-contents/plato-exp.war/WEB-INF/lib/ajax4jsf-1.1.1.jar!/META-INF/faces-config.xml 14:34:46,125 INFO [FacesConfigurator] Reading config jar:file:/D:/bin/jboss-4.0.5.GA/server/default/./tmp/deploy/tmp41715plato.ear-contents/plato-exp.war/WEB-INF/lib/jboss-seam-debug.jar!/META-INF/faces-config.xml 14:34:46,125 INFO [FacesConfigurator] Reading config jar:file:/D:/bin/jboss-4.0.5.GA/server/default/./tmp/deploy/tmp41715plato.ear-contents/plato-exp.war/WEB-INF/lib/jboss-seam-ui.jar!/META-INF/faces-config.xml 14:34:46,156 INFO [FacesConfigurator] Reading config jar:file:/D:/bin/jboss-4.0.5.GA/server/default/./tmp/deploy/tmp41715plato.ear-contents/plato-exp.war/WEB-INF/lib/jsf-facelets.jar!/META-INF/faces-config.xml 14:34:46,156 INFO [FacesConfigurator] Reading config jar:file:/D:/bin/jboss-4.0.5.GA/server/default/./tmp/deploy/tmp41715plato.ear-contents/plato-exp.war/WEB-INF/lib/richfaces-3.0.1.jar!/META-INF/faces-config.xml 14:34:46,234 INFO [FacesConfigurator] Reading config jar:file:/D:/bin/jboss-4.0.5.GA/server/default/./tmp/deploy/tmp41715plato.ear-contents/plato-exp.war/WEB-INF/lib/trinidad-impl-1.0.2-SNAPSHOT.jar!/META-INF/faces-config.xml 14:34:46,609 INFO [FacesConfigurator] Reading config /WEB-INF/faces-config.xml 14:34:46,656 INFO [FacesConfigurator] Starting up MyFaces-package : myfaces-api in version : 1.1.5 from path : file:/D:/bin/jboss-4.0.5.GA/server/default/tmp/deploy/tmp41658myfaces-api-1.1.5.jar
Re: [Trinidad] AssertionError including commandLink within panelLabelAndMessage
It's a bug - the assertion is catching a faulty assumption,
which is what they're supposed to do. I think it'll repro
any time you put a commandLink inside of a
panelLabelAndMessage.
-- Adam
On 9/24/07, Fred Davis [EMAIL PROTECTED] wrote:
I'm using JSF 1.2, Facelets 1.1.12, Trinidad 1.2.1 and am trying to include
a commandLink within a panelLabelAndMessage component, but am getting an
AssertionError. Is this a bug or am I doing something wrong?
The JSF snippet in question is:
tr:panelLabelAndMessage label=Supplier
tr:selectOneChoice simple=true
id=supplier
value=#{pageFlowScope.expenditureBean.supplier }
showRequired=true
requiredMessageDetail=Supplier must be specified.
disabled=#{pageFlowScope.expenditureBean.fieldReadOnly }
f:selectItems
value=#{listOfValuesFactoryBean.supplierLOVBean.selectItems}/
/tr:selectOneChoice
ui:include
src=/home/expenditure/supplierLink.xhtml /
tr:commandLink action=dialog:supplierDialog
useWindow=false
partialSubmit=false windowHeight=300 windowWidth=400
id=createSupplierCommand immediate=true
shortDesc=Create a new supplier record.
tr:image
source=/skins/tn/images/ico_new.gif /
tr:setActionListener
from=#{generalActionsBean.newSupplierBean}
to=#{pageFlowScope.supplierBean} /
tr:setActionListener from=#{'create'}
to=#{pageFlowScope.supplierBean.operation} /
/tr:commandLink
/tr:panelLabelAndMessage
The exception stack trace is as below.
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.CommandLinkRenderer.encodeBegin(CommandLinkRenderer.java:102)
at
org.apache.myfaces.trinidad.render.CoreRenderer.encodeBegin(CoreRenderer.java
:185)
at
org.apache.myfaces.trinidad.component.UIXComponentBase.encodeBegin(UIXComponentBase.java:700)
at
org.apache.myfaces.trinidad.render.CoreRenderer.encodeChild(CoreRenderer.java:271)
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:208)
at
org.apache.myfaces.trinidad.component.UIXComponentBase.encodeEnd(UIXComponentBase.java
:733)
at
org.apache.myfaces.trinidad.render.CoreRenderer.encodeChild(CoreRenderer.java:287)
at
org.apache.myfaces.trinidad.render.CoreRenderer.encodeAllChildren(CoreRenderer.java:304)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelLabelAndMessageRenderer.renderFieldCellContents
(PanelLabelAndMessageRenderer.java:105)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.LabelAndMessageRenderer._renderFieldCell(LabelAndMessageRenderer.java:375)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.LabelAndMessageRenderer.encodeAll
(LabelAndMessageRenderer.java:270)
at
org.apache.myfaces.trinidad.render.CoreRenderer.encodeEnd(CoreRenderer.java:208)
at
org.apache.myfaces.trinidad.component.UIXComponentBase.encodeEnd(UIXComponentBase.java
:733)
at
org.apache.myfaces.trinidad.render.CoreRenderer.encodeChild(CoreRenderer.java:287)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelFormLayoutRenderer._encodeFormItem(PanelFormLayoutRenderer.java
:746)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelFormLayoutRenderer._encodeFormColumns(PanelFormLayoutRenderer.java:672)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelFormLayoutRenderer._encodeChildren
(PanelFormLayoutRenderer.java:313)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelFormLayoutRenderer.encodeAll(PanelFormLayoutRenderer.java:199)
at
org.apache.myfaces.trinidad.render.CoreRenderer.encodeEnd
(CoreRenderer.java:208)
at
org.apache.myfaces.trinidad.component.UIXComponentBase.encodeEnd(UIXComponentBase.java:733)
at
org.apache.myfaces.trinidad.render.CoreRenderer.encodeChild(CoreRenderer.java:287)
at
org.apache.myfaces.trinidad.render.CoreRenderer.encodeAllChildren(CoreRenderer.java:304)
at
org.apache.myfaces.trinidadinternal.renderkit.html.CellFormatRenderer.encodeAll(CellFormatRenderer.java:96)
at
org.apache.myfaces.trinidad.render.CoreRenderer.encodeEnd(CoreRenderer.java:208)
at
org.apache.myfaces.trinidad.component.UIXComponentBase.encodeEnd(UIXComponentBase.java:733)
at
Re: [Trinidad] tr:tree expansion warning after upgrading to 1.02
I don't think that's a warning coming from Trinidad code. At
least, I can't find that string anywhere in our codebase!
Is that really a logged Java warning?
-- Adam
On 9/24/07, Renzo Tomaselli [EMAIL PROTECTED] wrote:
Hi, since I had troubles while upgrading Trinidad from 1.01 to 1.02
(tr:tree branches did not expand anymore), and my app. was a mixup with
Trinidad-Tomahawk-Ajax4jsf, I removed all refs to Ajax4jsf/Richfaces.
However, tree node expansion now raises a warning all the times I click
on a node:
WARNING: Response has no head or body tag:
?xml version=1.0 ?
?Tr-XHR-Response-Type ?
content action=/AxxBrowser/startPage.faces fragment![CDATA[div
id=browser:splitty0:navvy:dbTree style=white-space: nowraptable
cellpadding=0 cellspacing=0 border=0 summary=tr
td width=16 title=Select to collapse
class=p_OraTreeDisclosedSymbola href=#
onclick=_adftreebrowser_splitty0_navvy_dbTree.treeState.action('hide','0',this);return
false;#9660;/a/td
...
although node expansion appears succeeding.
Any suggestion ?
Re: [Trinidad] AssertionError including commandLink within panelLabelAndMessage
The site you're looking for is http://issues.apache.org/jira/browse/TRINIDAD
-- Adam
On 9/24/07, Paolo Fragapane [EMAIL PROTECTED] wrote:
Adam - Thanks for the response. Is this already logged as a bug or do I need
to do something? If the latter can you point me in the right direction as
I'm (unashamedly!) new to the open source game.
thanks.
On 24/09/2007, Adam Winer [EMAIL PROTECTED] wrote:
It's a bug - the assertion is catching a faulty assumption,
which is what they're supposed to do. I think it'll repro
any time you put a commandLink inside of a
panelLabelAndMessage.
-- Adam
On 9/24/07, Fred Davis [EMAIL PROTECTED] wrote:
I'm using JSF 1.2, Facelets 1.1.12 , Trinidad 1.2.1 and am trying to
include
a commandLink within a panelLabelAndMessage component, but am getting an
AssertionError. Is this a bug or am I doing something wrong?
The JSF snippet in question is:
tr:panelLabelAndMessage label=Supplier
tr:selectOneChoice simple=true
id=supplier
value=#{pageFlowScope.expenditureBean.supplier }
showRequired=true
requiredMessageDetail=Supplier must be specified.
disabled=#{pageFlowScope.expenditureBean.fieldReadOnly
}
f:selectItems
value=#{listOfValuesFactoryBean.supplierLOVBean.selectItems}/
/tr:selectOneChoice
ui:include
src=/home/expenditure/supplierLink.xhtml /
tr:commandLink action=dialog:supplierDialog
useWindow=false
partialSubmit=false windowHeight=300
windowWidth=400
id=createSupplierCommand immediate=true
shortDesc=Create a new supplier record.
tr:image
source=/skins/tn/images/ico_new.gif /
tr:setActionListener
from=#{generalActionsBean.newSupplierBean}
to=#{pageFlowScope.supplierBean} /
tr:setActionListener from=#{'create'}
to=#{pageFlowScope.supplierBean.operation} /
/tr:commandLink
/tr:panelLabelAndMessage
The exception stack trace is as below.
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.CommandLinkRenderer.encodeBegin(CommandLinkRenderer.java:102)
at
org.apache.myfaces.trinidad.render.CoreRenderer.encodeBegin
(CoreRenderer.java
:185)
at
org.apache.myfaces.trinidad.component.UIXComponentBase.encodeBegin(UIXComponentBase.java:700)
at
org.apache.myfaces.trinidad.render.CoreRenderer.encodeChild
(CoreRenderer.java:271)
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:208)
at
org.apache.myfaces.trinidad.component.UIXComponentBase.encodeEnd(UIXComponentBase.java
:733)
at
org.apache.myfaces.trinidad.render.CoreRenderer.encodeChild
(CoreRenderer.java:287)
at
org.apache.myfaces.trinidad.render.CoreRenderer.encodeAllChildren(CoreRenderer.java:304)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelLabelAndMessageRenderer.renderFieldCellContents
(PanelLabelAndMessageRenderer.java:105)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.LabelAndMessageRenderer._renderFieldCell(LabelAndMessageRenderer.java:375)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.LabelAndMessageRenderer.encodeAll
(LabelAndMessageRenderer.java:270)
at
org.apache.myfaces.trinidad.render.CoreRenderer.encodeEnd(
CoreRenderer.java :208)
at
org.apache.myfaces.trinidad.component.UIXComponentBase.encodeEnd(UIXComponentBase.java
:733)
at
org.apache.myfaces.trinidad.render.CoreRenderer.encodeChild(CoreRenderer.java
:287)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelFormLayoutRenderer._encodeFormItem(PanelFormLayoutRenderer.java
:746)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelFormLayoutRenderer._encodeFormColumns
(PanelFormLayoutRenderer.java:672)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelFormLayoutRenderer._encodeChildren
(PanelFormLayoutRenderer.java:313)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelFormLayoutRenderer.encodeAll(PanelFormLayoutRenderer.java:199)
at
org.apache.myfaces.trinidad.render.CoreRenderer.encodeEnd
(CoreRenderer.java :208
Re: Trinidad 404 error: requested resource (/tutoring/__ADFv__.jsp) is not available
On 9/23/07, Gregg Leichtman [EMAIL PROTECTED] wrote:
I'm getting a 404 error as follows:
HTTP Status 404 - /tutoring/__ADFv__.jsp
type Status report
message /tutoring/__ADFv__.jsp
description The requested resource (/tutoring/__ADFv__.jsp) is not
available.
Apache Tomcat/6.0.13
whenever I try to select the popup of an inputColor or inputDate component
_without_ a supporting chooseColor or chooseDate component respectively. If
I use a supporting chooseColor or chooseDate component all is well. I found
the following forum conversation below from the 12th of this month and it
might apply, but unlike Mr. Bertrand, I have no evidence that the
__ADFv__.jsp file has been generated. I did a find from the top of my
deployed Tomcat 6.0.13 distribution and there just doesn't seem to be any
such jsp or class file anywhere. In fact there is no file whose name
contains ADF. The components themselves do render, just the popups fail.
I have not tried to change the faces mapping as described below, since the
resource doesn't seem to be generated and there would be nothing to link to.
That logic aside, try changing the faces mapping as described below.
It's precisely *because* the resource isn't generated that you run into
this problem. It's handled entirely from code.
-- Adam
I'm using the following:
INFO: Initializing Sun's JavaServer Faces implementation (1.2_04-b16-p02)
for context '/tutoring'
Trinidad 1.2.1
Tiles 2.0.4
Shale snapshot 1.1.0 from 20070717
[EMAIL PROTECTED]:~ uname -a
Linux aragorn 2.6.11.4-21.13-default #1 Mon Jul 17 09:21:59 UTC 2006 i686
i686 i386 GNU/Linux
Here is a snippet of the jsp file:
...
tr:panelGroupLayout layout=horizontal
tr:inputColor shortDesc=Set color of new message.
columns=6 value=#{list.newMessageColor}
f:facet name=help
tr:outputText value=(#RRGGBB) or (r,g,b)/
/f:facet
/tr:inputColor
tr:inputDate id=insertDate columns=8 maximumLength=8
shortDesc=Insert a date into a new message at the cursor./
/tr:panelGroupLayout
...
Any help would be appreciated.
-= Gregg =-
Yeah, that sounds like the issue. Older versions of the RI,as well as
MyFaces 1.2 don't support *.faces mappings well
enough for this scenario (I haven't looked into why).
-- Adam
On 9/12/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Is it possible, that you are
using myfaces 1.2 ?
and *.faces mapping ?
try, /faces/* as your mapping
On 9/12/07, Bertrand, Shawn R [EMAIL PROTECTED] wrote:
Thanks for the clarification.
Unfortunately, it isn't working in Trinidad as it did in ADF Faces.
FredJSP.getRedirectURL generates a baseURL of
/nas/__ADFv__.faces?_afPfm=497604ee_t=fred and
arguments
of {_vir, /jsp/SnmpSsMacDetail.jsp, loc, en-US, _minWidth,
_minHeight,}. The second argument is correct and that resource is
definitely present in the deployed application.
The separate browser window does appear as it used to but it contains an
HTTP 404 error with the description The requested resource
(/__ADFv__.jsp)
is not available..
Thanks again,
Shawn Bertrand
Tyco Electronics Corporation
From: Adam Winer [EMAIL PROTECTED]
Sent: Tuesday, September 11, 2007 4:32 PM
To: MyFaces Discussion
Subject: Re: Dialog issue during ADF-Trinidad migration
There's two separate flags here:
- useWindow
- usePopup
If useWindow is false, that means we navigate the whole page
to the dialog. Simple enough.
If useWindow is true, then we look at usePopup: if it's false,
we want to show the dialog in a new browser window.
We use FredJSP so that we have a frameset around the
dialog view, needed to make sure that context is not lost
when you navigate within the dialog.
If usePopup is true, we use a DHTML dialog. We don't
need FredJSP, since we're putting the dialog in an iframe,
and can directly navigate to the page.
Does this make sense?
What you're describing - uses the URL returned from FredJSP.
getRedirectURL - is intentional (and was the way things
worked back in ADF, FWIW). What should be happening next
is that a frameset gets generated where the frame's source
is the URL of the desired page - so your dialog does show up.
Is that not working?
-- Adam
On 9/11/07, Bertrand, Shawn R
[EMAIL PROTECTED] wrote:
(Trinidad 1.0.2 – build from July – the current one).
I've migrated our application to use Trinidad, and see some PPR issues
that
are likely ours, but for the most part everything is working as
expected.
Except….
We use the dialog framework extensively, and every time we attempt
Re: [TRINIDAD] find PPR source from StateChangeListener
On 9/19/07, Simon Lessard [EMAIL PROTECTED] wrote: Or... I assume the listener will only be called once, when the first request is sent, if there's queued events? If so even JavaScript trick won't do the trick. Currently, if you queue an event while another is already processing, you don't get any status changed notification. Now, we could change that. Nothing says the API can't be that we give you both a new status and an old status, and everytime a new request is queued, you just get BUSY/BUSY, instead of READY/BUSY or BUSY/READY. That'd handle the cleanup end of this, but not the launching end. We could wrap this up into a non-crappy event object, with getOldStatus(), getNewStatus(), and *also* getParameters(), pass that to the status listener, and then you have pretty much everything you want. -- Adam On 9/19/07, Simon Lessard [EMAIL PROTECTED] wrote: Hello Adam, See comments inline. Thanks, ~ Simon On 9/19/07, Adam Winer [EMAIL PROTECTED] wrote: A couple problems: - It'd be easy enough to list the replaced targets when going from busy-ready, but on ready-busy, we don't know what is going to be replaced (the server will figure that out). Yeah, that's why we want to place the icon beside the source, not the replaced items. Not as intuitive, but at least tell the user there's something going on. We want that mainly for some dynamic LoV that sometimes requires a database query requiring a 1~2 second delay, and the marketing somehow does not like GMail style that much, although I might be able to have it accepted if the other solution is not possible. - If you have a series of queued events, you don't get busy-ready until all are completed, so if we had this, you'd see a series of icons show up one by one, and none would go away until all the requests completed. Ah, that's indeed a show stopper. Unless I do some little JavaScript trick in the listener to make sure only one icon is visible at a time. -- Adam On 9/19/07, Simon Lessard [EMAIL PROTECTED] wrote: Hello all, Is there a way to get the PPR source node form a JS StateChangeListener? Maybe from TrPage or from TrRequestQueue? The use case would be an icon (status indicator like) placed beside input fields and showing only when the input sent a PPR request. Regards, ~ Simon
Re: [Trinidad] Menu component
A real menu would be nice. I'd love to see a new hint for navigationPane (or, more likely, navigationTree?) that provides this UI. -- Adam On 9/19/07, Kito D. Mann [EMAIL PROTECTED] wrote: Yeah, I took a look at tr:navigationPane, and it won't quite cut it . Hopefully I'm not the only one that could use this in Trinidad – I think it'd be a welcome addition for projects that are using Trinidad without Tomahawk. ~~~ Kito D. Mann - Author, JavaServer Faces in Action http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info phone: +1 203-653-2989 fax: +1 203-653-2988 * Sign up for the JSF Central newsletter! http://oi.vresp.com/?fid=ac048d0e17 * From: Simon Lessard [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 19, 2007 12:18 PM To: MyFaces Discussion; [EMAIL PROTECTED] Subject: Re: [Trinidad] Menu component Hello Kito, Check tr:navigationPane using a list hint to see if it's good enough for you. If Tomahawk menu style is really wanted by the community, I already ported it to Trinidad architecture in a project and I'm pretty sure the client wouldn't mind giving it to Trinidad. ~ Simon On 9/18/07, Kito D. Mann [EMAIL PROTECTED] wrote: Are there any plans to add a Menu component to the Trinidad core (as specified in [1]) soon? I'm basically talking about something similar to what Tomahawk currently has. [1] http://issues.apache.org/jira/browse/TRINIDAD-414 ~~~ Kito D. Mann - Author, JavaServer Faces in Action http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info * Sign up for the JSF Central newsletter! http://oi.vresp.com/?fid=ac048d0e17 *
Re: [Trinidad] Double-Rendering-Problem
On 9/20/07, Björn Thalheim [EMAIL PROTECTED] wrote: Hi, thanks for your reply. Judged by the log, you are using sjsas or glassfish, It's Glassfish Version 9.1 (build b58g-fcs). which have jsf-ri 1.2 bundled. That might be just a severe lack in my knowledge. I should probably read more about getting Trinidad to work with Glassfish/JSF RI. Does anybody know any good documentation on this issue? Maybe the whole problem is just a clinch of Glassfish (with its included JSF RI) and MyFaces (Trinidad). you can try to remove myfaces-*.jar from the webapp. My Eclipse vetoes against this action by telling me, that it can't find the classes FacesContext and SelectItem, e.g.. I have tried this, but it didn't help me. You have to compile with them, yes - but don't deploy them to your .war. -- Adam Is there any further advice from anybody? Regards, Björn PS: Sorry for causing trouble in some people's threading, I had to copy this quote from the Web-based archive, because I was not on the list on 09/18 yet.
Re: [TRINIDAD] find PPR source from StateChangeListener
A couple problems: - It'd be easy enough to list the replaced targets when going from busy-ready, but on ready-busy, we don't know what is going to be replaced (the server will figure that out). - If you have a series of queued events, you don't get busy-ready until all are completed, so if we had this, you'd see a series of icons show up one by one, and none would go away until all the requests completed. -- Adam On 9/19/07, Simon Lessard [EMAIL PROTECTED] wrote: Hello all, Is there a way to get the PPR source node form a JS StateChangeListener? Maybe from TrPage or from TrRequestQueue? The use case would be an icon (status indicator like) placed beside input fields and showing only when the input sent a PPR request. Regards, ~ Simon
Re: Trinidad validateLength
I haven't looked into it, but I think this is a bug with
the inline client-side validation code that triggers
when you're inside of a table. I'm sure it's got
nothing to do with tr:validateLength per se. This
should get fixed for 1.0.3...
-- Adam
On 9/18/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Hi,
IMO that shouldn't happen, can you file an issue:
https://issues.apache.org/jira/browse/TRINIDAD
-Matthias
On 9/18/07, pdt_p [EMAIL PROTECTED] wrote:
Hi...
I just wonder about tr:validateLength.
I have a table with 2 columns. 1 column for label and the other column
containing tr:inputText.
I have validate the input text value with tr:ValidateLength and specify the
minimum and maximum.
I just relize that every time I submit the form, there is a new line
generated in the next line after input text. So my table heights become
longer. That happens in both cases either the value is valid or is not
valid. if the value entered is not valid then the error message will be
display in that new line. I think that new line is reserve for error
message.
How to remove that new line if the value entered is valid?
I get this issue only in IE. In Firefox, the new line is not display.
tr:inputText value=#{MyBean.value}
binding=#{MyBean.inputTextOne}
rendered=#{MyBean.renderInputTextOne
tr:validateLength minimum=#{MyBean.min}
maximum=#{MyBean.max}/
/tr:inputText
Thank you very mich
Pdt
--
View this message in context:
http://www.nabble.com/Trinidad-validateLength-tf4471579.html#a12749801
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] maven-faces-plugin tag-handler custom for one component?
On 9/18/07, Andrew Robinson [EMAIL PROTECTED] wrote: It doesn't appear that GenerateFaceletsTaglibsMojo supports facelet component handlers (tag handler) specific to a component. I would propose support for a new tag. Proposed changes: 1) Add new property tagHandler to org.apache.myfaces.trinidadbuild.plugin.faces.parse.ComponentBean 2) New tag for the *.xml files as a component-extension mpf:tag-handler[class]/mfp:tag-handler 3) Change parser to parse the new XML element in org.apache.myfaces.trinidadbuild.plugin.faces.parse.FacesConfigParser (tag-handler to tagHandler) 4) Change mojo class to see if componet.getTagHandler() != null and use it instead of the global value if provided. org.apache.myfaces.trinidadbuild.plugin.faces.GenerateFaceletsTaglibsMojo I wanted to propose this in case I missed something or it is possible before creating a JIRA issue. Looks good - JIRA issue and a checkin sounds great! Ditto for the other problems you've found with the Facelets plugin, though I'm curious about the lack of a renderer-type; I'm guessing that all of the Trinidad components are setting their own renderer types automatically and not relying on Facelets to do it for them. -- Adam
Re: [Trinidad] maven-faces-plugin tag-lib generation not working
Ech. You shouldn't need a tag-class, as those are for JSP. But the Facelets generator re-uses the same ComponentTagLibraryFilter inner class of AbstractFacesMojo that the JSP generator uses, so it's checking that there is a tag-class. And therefore (incorrectly) skipping over your metadata that (correctly) doesn't have a tag-class. -- Adam On 9/17/07, Andrew Robinson [EMAIL PROTECTED] wrote: I tried that, but it didn't do anything. Tag classes are for JSP aren't they anyway? On 9/17/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Andrew- looks like in component-extension/ you're no specifying the tag-class mfp:tag-classcom.BlahTag/mfp:tag-class -Matthias On 9/16/07, Andrew Robinson [EMAIL PROTECTED] wrote: I have the faces-config.xml generating, but the taglib.xml file is empty. What are the required properties to get a component included in the taglib.xml? cw-base.taglib.xml: ... DOCTYPE .. facelet-taglib namespacehttp://christws.com/components/namespace /facelet-taglib HtmlHelpIcon.xml: ?xml version=1.0 encoding=utf-8? faces-config version=1.2 xmlns=http://java.sun.com/xml/ns/javaee; xmlns:cw=http://christws.com/; xmlns:xi=http://www.w3.org/2001/XInclude; xmlns:mfp=http://myfaces.apache.org/maven-faces-plugin; xmlns:xhtml=http://www.w3.org/1999/xhtml; component description ![CDATA[Help icon link]] /description component-typecom.christws.HelpIcon/component-type component-classcom.christws.faces.component.help.HtmlHelpIcon/component-class ... properties ... component-extension mfp:component-familycom.christws.HelpIcon/mfp:component-family mfp:component-supertype org.apache.myfaces.trinidad.CoreCommandLink /mfp:component-supertype mfp:component-superclass org.apache.myfaces.trinidad.component.core.nav.CoreCommandLink /mfp:component-superclass mfp:renderer-typecom.christws.HelpIcon/mfp:renderer-type mfp:tag-namecw:helpIcon/mfp:tag-name mfp:component-metadata mfp:favorite-propertymessageId/mfp:favorite-property /mfp:component-metadata /component-extension /component /faces-config pom.xml: ... plugin groupIdorg.apache.myfaces.trinidadbuild/groupId artifactIdmaven-faces-plugin/artifactId configuration taglibs cwhttp://christws.com/components/cw /taglibs faceletHandlerClasscom.christws.faces.component.BaseComponentHandler/faceletHandlerClass typePrefixcom.christws/typePrefix renderKitPrefixcom.christws/renderKitPrefix packageContainscom.christws/packageContains removeRendererstrue/removeRenderers forcefalse/force /configuration executions execution goals goalgenerate-faces-config/goal !--goalgenerate-jsp-taglibs/goal-- goalgenerate-facelets-taglibs/goal goalgenerate-renderer-map/goal /goals /execution /executions /plugin ... What am I missing? -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
Re: [Trinidad] maven-faces-plugin tag-lib generation not working
I just updated the version number to 1.2.3-SNAPSHOT an hour ago or so, so I'm not surprised it isn't up there yet. But the 1.0.3-SNAPSHOT is more than a month old, so I suspect our continuum build is not deploying correctly. @Matthias, do you know what's going on? And do you know how I can get an account on the new continuum server? -- Adam On 9/17/07, Andrew Robinson [EMAIL PROTECTED] wrote: BTW, is there a 1.2.3-SNAPSHOT of the plugin in Maven? It is not located at: http://people.apache.org/repo/m2-snapshot-repository/org/apache/myfaces/trinidadbuild/maven-faces-plugin/ On 9/17/07, Andrew Robinson [EMAIL PROTECTED] wrote: Decided to keep trying to get this to work, hate to quit! I added in the tag and added in the goal, and I am still getting no TLD files or taglib.xml file content (cw.taglib.xml simply has what I put in the cw-base.taglib.xml) To the HtmlHelpIcon.xml I added: mfp:tag-classcom.christws.faces.component.help.HtmlHelpIconTag/mfp:tag-class To the pom.xml in my faces-impl project I uncommented: goalgenerate-jsp-taglibs/goal The HtmlHelpIconTag.java was created, but the TLD file was not created and as mentioned, the cw.taglib.xml doesn't contain any information on the HtmlHelpIcon component. Any ideas to what I am missing that needs to be done to generate the taglib.xml? BTW - here is my project structure: faces-shared (code I use in the generated components, the renderers as well as my business classes in the web project) faces-generated-config (the XML files for the maven-faces-plugin, has the generate-master-faces-config goal. References the shared project) faces-generated (contains the java-templates and the maven-faces-plugin generate-components goal, references the above projects) faces-impl (has the goals: generate-faces-config, generate-jsp-taglibs, enerate-facelets-taglibs, generate-renderer-map. Depends on the above projects) web (my war-project, has my EJB3 classes, backing beans, XHTML files, etc. No maven-faces-plugin here. References the other projects as dependencies). Important files: faces-generated-config/src/main/resources/META-INF/maven-faces-plugin/components/HtmlHelpIcon.xml faces-generated/src/main/java-templates/com/christws/faces/component/help/ HtmlHelpIconTemplate.java faces-impl/src/main/conf/META-INF/cw-base.taglib.xml faces-impl/src/main/conf/META-INF/faces-config-base.xml Any ideas? -Andrew On 9/17/07, Adam Winer [EMAIL PROTECTED] wrote: Ech. You shouldn't need a tag-class, as those are for JSP. But the Facelets generator re-uses the same ComponentTagLibraryFilter inner class of AbstractFacesMojo that the JSP generator uses, so it's checking that there is a tag-class. And therefore (incorrectly) skipping over your metadata that (correctly) doesn't have a tag-class. -- Adam On 9/17/07, Andrew Robinson [EMAIL PROTECTED] wrote: I tried that, but it didn't do anything. Tag classes are for JSP aren't they anyway? On 9/17/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Andrew- looks like in component-extension/ you're no specifying the tag-class mfp:tag-classcom.BlahTag/mfp:tag-class -Matthias On 9/16/07, Andrew Robinson [EMAIL PROTECTED] wrote: I have the faces-config.xml generating, but the taglib.xml file is empty. What are the required properties to get a component included in the taglib.xml? cw-base.taglib.xml: ... DOCTYPE .. facelet-taglib namespacehttp://christws.com/components/namespace /facelet-taglib HtmlHelpIcon.xml: ?xml version=1.0 encoding=utf-8? faces-config version=1.2 xmlns=http://java.sun.com/xml/ns/javaee; xmlns:cw=http://christws.com/; xmlns:xi=http://www.w3.org/2001/XInclude; xmlns:mfp=http://myfaces.apache.org/maven-faces-plugin; xmlns:xhtml=http://www.w3.org/1999/xhtml; component description ![CDATA[Help icon link]] /description component-typecom.christws.HelpIcon/component-type component-classcom.christws.faces.component.help.HtmlHelpIcon/component-class ... properties ... component-extension mfp:component-familycom.christws.HelpIcon/mfp:component-family mfp:component-supertype org.apache.myfaces.trinidad.CoreCommandLink /mfp:component-supertype mfp:component-superclass org.apache.myfaces.trinidad.component.core.nav.CoreCommandLink /mfp:component-superclass mfp:renderer-typecom.christws.HelpIcon/mfp:renderer-type mfp:tag-namecw:helpIcon/mfp:tag-name mfp:component-metadata mfp:favorite-propertymessageId/mfp:favorite-property /mfp:component
Re: tr:inputDate
I still strongly suspect this is a daylight savings time issue, or at least a time zone issue, where one part of the system is interpreting the date with one time zone, and another part of the system is doing so with a different time zone. Because of how java.util.Date is misdesigned, that means that something entered as midnight of 16/09/2007 can end up as 23:00 of 15/09/2007 when re-displayed. -- Adam On 9/16/07, Simon Lessard [EMAIL PROTECTED] wrote: I just checked demo files and we don't use a TimeZone setting in trinidad-config.xml, so my hunch wasn't good. On 9/16/07, Simon Lessard [EMAIL PROTECTED] wrote: If that's the sole issue, then yes it should fix it. On 9/16/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi, Sounds like that could be it -seeing as it affects all instances. Not to sound too stupid, but i take it that this can be addressed by applying a timezone object to the inputDate through the use of the convertDateTime tag? Regards, Andrew - Original Message From: Simon Lessard [EMAIL PROTECTED] To: MyFaces Discussion users@myfaces.apache.org Sent: Sunday, 16 September, 2007 4:36:45 PM Subject: Re: tr:inputDate My hunch would be the timezone setting. I don't have access to SVN and source right now to check, but if the TimeZone use the 3-char format ( i.e. EST or PST), then daylight saving is ignored (and we're currently under daylight saving), resulting in hour hour lost. Since we set the date using midnight (0:00:00,000), losing 1 hours means going back one day. I plan to check out on that while fixing the first day of week issue to see if there's a way to prevent such issues. Regards, ~ Simon On 9/16/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: It also happens with the live demos, which is weird... - Original Message From: Leonardo Uribe [EMAIL PROTECTED] To: MyFaces Discussion users@myfaces.apache.org Sent: Sunday, 16 September, 2007 12:00:19 AM Subject: Re: tr:inputDate and also if i click the first available date (in this case 16/09/2007), it populates the field with 15/09/2007. I remember this issue. Are you using java.sql.Date as the type for the property in the bean? I just changed it for java.util.Date and all works well for me. Regards Leonardo Uribe
Re: [Trinidad] integrating maven-faces-plugin into maven war project
On 9/15/07, Andrew Robinson [EMAIL PROTECTED] wrote: I have been making a war project. It is currently just one maven2 project. Up to now, my components have been hand built. Since I am using Trinidad, I have been either extending UIX/Core components or creating my own with Type support. Since maven-faces-plugin was available, I though I would try to integrate it into my project. I have it technically working, but there are problems and I have some questions. Hopefully someone has some solutions. 1) I have to run maven 2 times. The first time the XML files are put into the target. The second time the components are actually generated and compiled. I think this is because I have just one project. Yeah, I believe the maven-faces-plugin requires two passes - one to generate a master faces-config plugin with all the includes, and later passes run off of that master. The Trinidad build works that way. 2) I have code that was using one of the components. Here was the structure: UIInclude : UIXComponentBase references UINavigableRoot UINavigableRoot : UIViewRoot references UIInclude CustomViewHandler : FaceletsViewHandler references UIInclude IncludeHandler : TrinidadComponentHandler references UIInclude The obvious problems in making UIInclude generated is that the code that currently refer to it won't compile until the code generator has built the class. For the time being, I created a public abstract class UIIncludeBase that has all the methods and properties stubbed out that the other classes need, but I'm not sure if there isn't a better way. In the Trinidad codebase we just live with this - the maven build generates the code before the compilation, so no biggie, though it is a mild irritant when developing with an IDE (needing to jump back out to Maven to rebuild code instead of doing it all within the IDE). 3) The annotations on my UIIncludeTemplate are not carried to the generated UIInclude. I can do without this, but it would be really good to have this functionality. I agree, that'd be an important enhancement. -- Adam 4) If I move UIInclude to a new project, I have to move all the classes that it references, which is a very large refactoring step. Are there any recommendations on how to minimize my refactoring, fixing the compile twice problem and be able to use the Trinidad plugin? Thank you, Andrew
Re: [Trinidad] PPR logic with non-rendered components (was: Console is undefined)
On 9/14/07, Bertrand, Shawn R [EMAIL PROTECTED] wrote: We have some situations where we set up PPR between components, and some of the components which should trigger an update may not be rendered based on some value binding. What is the policy with respect to this? If a button, for instance, isn't rendered but is expected to trigger an update on a table, would I expect this sort of error? 14:35:46,377 ERROR [STDERR] Sep 14, 2007 2:35:46 PM org.apache.myfaces.trinidadinternal.context.RequestContextImpladdPartialTriggerListeners WARNING: Could not find partial trigger genTable:modify from CoreTable[UIXFacesBeanImpl, id=genTable] This warning means that your partialTrigger syntax is wrong; it's not that something isn't rendered. I'm also thinking there might be problem with situations where an action is triggered on a command button, a PPR update occurs that disables a button, and the focus method call at the bottom of TrPage.prototype._handlePprResponseFragment fails because the button can't be focused upon. Under this situation, I'm getting this javascript error in IE (but not in Firefox): Can't move focus to the control because it is invisible, not enabled, or of a type that does not accept the focus. A simple test case would be handy. Looks like there's some problems with the PPR code that tries to restore focus. -- Adam This
Re: [Trinidad] retain focus after PPR
What version of Trinidad are you using? -- Adam On 9/14/07, Abhi [EMAIL PROTECTED] wrote: Hi, I have been trying to create drag and drop on my application. There is one table that i have generated using JSTL forEach loop (as it is kind of table inside table). Now the problem is when i drag a record and drop it to a new row the whole table refresh itself using PPR with new structure of data. But focus is jumping to the top of table. I need to retain the focus because sometimes there is large amount of data with a long vertical scroll. Its annoying to the user when he is not able to see where he has dropped the record and to verify he has to scroll down. Please help me out with this problem. Thanks, Abhishek
Re: [Trinidad] tr:outputText font size in IE6
IE 6 CSS support is atrocious, and that's being generous.
outputText is explicitly and intentionally not skinned. Like other text, it
is
not directly skinned, but has its font size determined by the container
element/tag. If it were directly skinned, there'd be no possibility for
container tags to affect their content's styling.
-- Adam
On 9/14/07, Francisco Passos [EMAIL PROTECTED] wrote:
I've just tried this example.
In IE 7 it works fine, but in IE 6 it presents the behaviour you
described.
Sorry I don't have a solution to recommend.
On 9/14/07, Pedro Calcao [EMAIL PROTECTED] wrote:
Greetings,
I have been developing several pages using Trinidad, I have done all the
development using Firefox to test the application.
Today I got to running the app in IE6, and I see that the default
font-size of all outputText values are alot larger then in FF, I see no
reason for this to happen, and I'm using a skin that explicitly sets the
font-size to 10, using:
.AFDefaultFont:alias {
font-size : 10px;
}
Shouldn't the above code set all text in my application to 10px
font-size unless overwritten by other css specifications?
Is there a way to set the font properties of all outputText's without
setting their inlineStyle or styleClass one by one?
Thank you for any answers,
Pedro Calção
Re: [Trinidad] tr:table PPR failing
On 9/13/07, Andrew Robinson [EMAIL PROTECTED] wrote:
Timothy,
I stripped the page and the AJAX down to the ID attributes only
(FYI I used this set of commands with VIM to do this:
%s//\r/g | %s/^.\+\(id=[^]\+\).*/\1/ | %s/^[^i].\+\n// | sort
)
Can I get you on permanent retainer for VIM-editing? :)
Here are the results:
Page:
id=acctPage:acctTable
id=acctPage:acctTable:j_id_jsp_1566647018_17
id=acctPage:acctTable:j_id_jsp_1566647018_19
id=acctPage:acctTable:j_id_jsp_1566647018_21
id=acctPage:acctTable__xc_ha
id=acctPage:acctTable__xc_sa
id=acctPage:acctTabledd0
id=j_id0
AJAX response:
id=_acctForm_Postscript
id=acctPage:acctTable
id=acctPage:acctTable:0:j_id_jsp_1566647018_33
id=acctPage:acctTable:j_id_jsp_1566647018_17
id=acctPage:acctTable:j_id_jsp_1566647018_19
id=acctPage:acctTable:j_id_jsp_1566647018_21
id=acctPage:acctTable__xc_ha
id=acctPage:acctTabledd0
id=j_id0
As you can see, the following items in the AJAX were not in the page:
id=_acctForm_Postscript
id=acctPage:acctTable:0:j_id_jsp_1566647018_33
Looking at your page source, there is no form element. The form is
required AFAIK. This may be just because you didn't provide the full
source though.
I suspect so... the submission wouldn't have gotten far at all
without a form element. The postscript in the PPR reply
is in fact part of the form.
It looks as though the issue is exactly related to trying to get that
expanded row to show up, since the one missing ID is :0:
(that is, the first row of the table). Lemme try this locally.
-- Adam
Have you tried to set a break point in the error log method and use
the call stack to get back up to the generator of the error and then
determine what is causing it?
On 9/12/07, Timothy M. Braun [EMAIL PROTECTED] wrote:
Andrew,
I compared the AJAX response to the html source and I can't
seem to find anything out of place. I have included the two below, maybe I
missed something. I added id's to most of the jsf components so that it is
a little easier to parse.
On a side note, I found that it was interesting that input
elements are rendered differently in the AJAX response then the initial HTML
output. In the html output, the input elements are not terminated, but they
are in the AJAX response.
Thanks again,
Tim
HTML Source (I added line breaks to make reading it easier):
div id=acctPage:acctTable
table cellpadding=0 cellspacing=0 border=0 width=90% summary=
tr
td
table cellpadding=0 cellspacing=0 border=0 width=100% summary=
class=x6m
tr
td(Actions)/td
td width=100%/td
/tr
/table
/td
/tr
tr
td
table cellpadding=0 cellspacing=0 border=0 width=100% summary=
class=x6q
tr
td nowrap valign=middle
script type=text/javascriptfunction _submitHideShow(a,v,b,c,l,d) {var o
= {event:b,source:c};if (d!=(void 0))
o.value=d;_setRequestedFocusNode(document,l,false,window);_submitPartialChange(a,v,o);return
false;}/script
a onclick=return
_submitHideShow('acctForm',1,'show','acctPage:acctTable','acctPage:acctTable__xc_sa','all')
href=# id=acctPage:acctTable__xc_sa class=xiShow All Details/a
nbsp;|nbsp;
a onclick=return
_submitHideShow('acctForm',1,'hide','acctPage:acctTable','acctPage:acctTable__xc_ha','all')
href=# id=acctPage:acctTable__xc_ha class=xiHide All Details/a
/td
/tr
/table
/td
/tr
tr
td
table class=x6k cellpadding=1 cellspacing=0 border=0 width=100%
tr
th id=j_id0 width=1% nowrap class=x75Details/th
th id=acctPage:acctTable:j_id_jsp_1566647018_17
class=x75 xafName/th
th id=acctPage:acctTable:j_id_jsp_1566647018_19
class=x75 xafActive/th
th id=acctPage:acctTable:j_id_jsp_1566647018_21
class=x75 xafActions/th
/tr
tr
td headers=j_id0 class=x6v xat nowrap
div
a onclick=return
_submitHideShow('acctForm',1,'show','acctPage:acctTable','acctPage:acctTabledd0','0')
href=# id=acctPage:acctTabledd0
span title=Select to show information class=x9q#9658;/span
/a
a onclick=return
_submitHideShow('acctForm',1,'show','acctPage:acctTable','acctPage:acctTabledd0','0')
href=# class=xiShow/a
/div
/td
td headers=acctPage:acctTable:j_id_jsp_1566647018_17
class=x6v xat[Name Removed for privacy]/td
td headers=acctPage:acctTable:j_id_jsp_1566647018_19
class=x6v xattrue/td
td headers=acctPage:acctTable:j_id_jsp_1566647018_21
class=x6v xat(Actions)/td
/tr
/table
/td
/tr
/table
script type=text/javascript_uixt_acctPage_acctTable=new
CollectionComponent('acctForm','acctPage:acctTable');/script
input type=hidden name=acctPage:acctTable:rangeStart
value=0
/div
AJAX Response:
content
action=/vbm/faces/pages/secure/telephony/accountSearch.jspx
fragment![CDATA[div id=acctPage:acctTabletable
Re: [Trinidad] Exception with XMLMenuModel usage
I had a quick look at the code to see if there was
a simple way to resolve:
http://issues.apache.org/jira/browse/TRINIDAD-708
... and, ouch, not really. The problem's not so much
on the XMLMenuModel side of things, but the
MenuContentHandlerImpl and MenuNode code,
where we have:
- A singleton MenuContentHandlerImpl that is
storing a requestMap key to pass it onto the MenuNode
- MenuNodes that use that key to go back and locate the
root menu model.
Fixing the one-XMLMenuModel-per-page limitation is going
to require rethinking this odd design.
-- Adam
On 9/12/07, Adam Winer [EMAIL PROTECTED] wrote:
On 9/12/07, Andrew Robinson [EMAIL PROTECTED] wrote:
I changed the managed-bean-scope to request for both, seeing that in
the developer guide, but it doesn't affect this code.
Is there some odd requirement that there can only be one XmlMenuModel
per application?
There definitely shouldn't be any such requirement. I
don't know the code well enough to know why this might
go wrong.
-- Adam
-Andrew
On 9/12/07, Andrew Robinson [EMAIL PROTECTED] wrote:
I have 2 controls backed by an XmlMenuModel, a main menu and a help
context menu. When I only had one menu, my code was working. When I
introduced the 2nd model, I started getting this exception:
java.lang.NullPointerException
at
org.apache.myfaces.trinidad.model.XMLMenuModel.getFocusRowKey(XMLMenuModel.java:292)
at
org.apache.myfaces.trinidad.component.UIXNavigationHierarchy.getFocusRowKey(UIXNavigationHierarchy.java:79)
at
org.apache.myfaces.trinidad.component.HierarchyUtils.__handleEncodeBegin(HierarchyUtils.java:88)
at
org.apache.myfaces.trinidad.component.UIXNavigationTree.__encodeBegin(UIXNavigationTree.java:153)
at
org.apache.myfaces.trinidad.component.UIXCollection.encodeBegin(UIXCollection.java:515)
at
org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils.renderChild(RendererUtils.java:435)
at
org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils.renderChildren(RendererUtils.java:423)
at
org.apache.myfaces.custom.roundeddiv.HtmlRoundedDivRenderer.encodeChildren(HtmlRoundedDivRenderer.java:319)
at
javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:527)
at
org.apache.myfaces.trinidadinternal.uinode.UIComponentUINode._renderComponent(UIComponentUINode.java:320)
at
org.apache.myfaces.trinidadinternal.uinode.UIComponentUINode.render(UIComponentUINode.java:279)
at
org.apache.myfaces.trinidadinternal.uinode.UIComponentUINode.render(UIComponentUINode.java:256)
at
org.apache.myfaces.trinidadinternal.ui.BaseRenderer.renderChild(BaseRenderer.java:425)
at
org.apache.myfaces.trinidadinternal.ui.BaseRenderer.renderIndexedChild(BaseRenderer.java:343)
at
org.apache.myfaces.trinidadinternal.ui.BaseRenderer.renderIndexedChild(BaseRenderer.java:235)
at
org.apache.myfaces.trinidadinternal.ui.BaseRenderer.renderContent(BaseRenderer.java:142)
at
org.apache.myfaces.trinidadinternal.ui.laf.base.desktop.PanelTabbedRenderer.renderContent(PanelTabbedRenderer.java:112)
at
org.apache.myfaces.trinidadinternal.ui.BaseRenderer.render(BaseRenderer.java:93)
at
org.apache.myfaces.trinidadinternal.ui.laf.base.xhtml.XhtmlLafRenderer.render(XhtmlLafRenderer.java:84)
at
org.apache.myfaces.trinidadinternal.uinode.UIXComponentUINode.renderInternal(UIXComponentUINode.java:192)
at
org.apache.myfaces.trinidadinternal.uinode.UINodeRendererBase.encodeEnd(UINodeRendererBase.java:70)
at
org.apache.myfaces.trinidad.component.UIXComponentBase.encodeEnd(UIXComponentBase.java:710)
faces-config.xml:
managed-bean
managed-bean-namemainMenuModel/managed-bean-name
managed-bean-classorg.apache.myfaces.trinidad.model.XMLMenuModel/managed-bean-class
managed-bean-scopeapplication/managed-bean-scope
managed-property
property-namesource/property-name
value/WEB-INF/mainMenu.xml/value
/managed-property
/managed-bean
managed-bean
managed-bean-namehelpContextMenuModel/managed-bean-name
managed-bean-classorg.apache.myfaces.trinidad.model.XMLMenuModel/managed-bean-class
managed-bean-scopeapplication/managed-bean-scope
managed-property
property-namesource/property-name
value/WEB-INF/helpContents.xml/value
/managed-property
/managed-bean
The problem seems to be a result of:
if (this == _getRootModel())
{
_viewIdFocusPathMap =
_contentHandler.getViewIdFocusPathMap(_mdSource);
_nodeFocusPathMap =
_contentHandler.getNodeFocusPathMap(_mdSource);
_idNodeMap = _contentHandler.getIdNodeMap(_mdSource
Re: [Trinidad] tr:table PPR failing
On 9/13/07, Adam Winer [EMAIL PROTECTED] wrote: On 9/13/07, Andrew Robinson [EMAIL PROTECTED] wrote: Timothy, I stripped the page and the AJAX down to the ID attributes only (FYI I used this set of commands with VIM to do this: %s//\r/g | %s/^.\+\(id=[^]\+\).*/\1/ | %s/^[^i].\+\n// | sort ) Can I get you on permanent retainer for VIM-editing? :) Here are the results: Page: id=acctPage:acctTable id=acctPage:acctTable:j_id_jsp_1566647018_17 id=acctPage:acctTable:j_id_jsp_1566647018_19 id=acctPage:acctTable:j_id_jsp_1566647018_21 id=acctPage:acctTable__xc_ha id=acctPage:acctTable__xc_sa id=acctPage:acctTabledd0 id=j_id0 AJAX response: id=_acctForm_Postscript id=acctPage:acctTable id=acctPage:acctTable:0:j_id_jsp_1566647018_33 id=acctPage:acctTable:j_id_jsp_1566647018_17 id=acctPage:acctTable:j_id_jsp_1566647018_19 id=acctPage:acctTable:j_id_jsp_1566647018_21 id=acctPage:acctTable__xc_ha id=acctPage:acctTabledd0 id=j_id0 As you can see, the following items in the AJAX were not in the page: id=_acctForm_Postscript id=acctPage:acctTable:0:j_id_jsp_1566647018_33 Looking at your page source, there is no form element. The form is required AFAIK. This may be just because you didn't provide the full source though. I suspect so... the submission wouldn't have gotten far at all without a form element. The postscript in the PPR reply is in fact part of the form. It looks as though the issue is exactly related to trying to get that expanded row to show up, since the one missing ID is :0: (that is, the first row of the table). Lemme try this locally. Ech, ignore that commentary. Diffing the full set of IDs isn't really relevant here: PPR can, of course, introduce new IDs. It just can't introduce new *top* IDs - each fragment has to point to an existing ID. We've got two fragments in here: div id=acctPage:acctTable span id=_acctForm_Postscript And these do seem to be in the page already. But even if they weren't, it seems that the current JS code would simply drop them and move on. Tim, could you by any chance use FireBug's JS debugger to step through TrPage.prototype._handlePprResponse()? It's not clear where this JS error is coming from. (FWIW, the basic table row-disclosure demo seems to be working fine for me, at least on FF (haven't tested IE)). -- Adam
Re: [Trinidad] console is undefined?
I'd love to get some much better logging in Trinidad.
http://ajaxpatterns.org/Javascript_Logging_Frameworks
lists some more. Both the ones you mention are
Apache 2.0 licensed, as is log4javascript, so from
that standpoint we're OK.
The major concern is that we don't start bloating
our JS size with logging calls + logging messages.
Getting the logging calls trimmed from our non-debug
JS would be an important enhancement for our JS
plugin.
-- Adam
On 9/13/07, Andrew Robinson [EMAIL PROTECTED] wrote:
I put a comment on the bug to possibly enhance Trinidad's logging to
use log4js. There are two projects with that name, one at sourceforge
and one at berlios. I think either may be work looking at. They should
both work in any browser that I am aware of.
What do you think Adam?
-Andrew
On 9/13/07, Bertrand, Shawn R [EMAIL PROTECTED] wrote:
The error dialog indeed doesn't appear in Firefox, though would it if
Firebug wasn't installed? There doesn't appear to be any sort of error when
running in Firefox – all I see in the Firebug console are POST messages as
expected.
I haven't looked at the current 1.0.2 codebase, but does it contain the
change as outlined by Andrew for this? I guess I'd like to update to it if
possible, because I can't see our users having to put up with dismissing
this error.
Alternately, how might I go about finding the cause of the error message in
IE?
Shawn
From: Adam Winer [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 12, 2007 2:08 PM
To: MyFaces Discussion
Subject: Re: [Trinidad] console is undefined?
This is indeed an attempt to call the firebug console (if
it exists), and Andrew's totally right that the syntax here
is wrong. FWIW, this should only be called if an error
has occurred, not in ordinary execution, so there's a more
essential problem elsewhere.
-- Adam
On 9/12/07, Andrew Robinson [EMAIL PROTECTED] wrote:
Yes, I get this all of the time to. I believe console is the firebug
globally installed window variable (plug-in for firefox)
I think the following code may be more IE friendly:
if (window.console window.console.error) {
...
}
On 9/12/07, Bertrand, Shawn R
[EMAIL PROTECTED] wrote:
I'm getting error generated from the first line of the following function
in
Common1_0_2.js:
TrRequestQueue._logError=function(a118)
{
if(consoleconsole.error)
console.error(arguments);
}
This is running in IE 6. Is this console object related to the Acrobat
console window?
Thanks,
Shawn
Re: [Trinidad] Exception with XMLMenuModel usage
On 9/13/07, Andrew Robinson [EMAIL PROTECTED] wrote: That was what I thought too. When I saw the code, my first reaction was uh-oh. Perhaps the key can be changed to be based on the source instead of a request-global key? Easy enough from the XMLMenuModel side - but how well does that work with the content handler, which is a shared static instance and has that stored as an instance variable!?! Bleh. -- Adam On 9/13/07, Adam Winer [EMAIL PROTECTED] wrote: I had a quick look at the code to see if there was a simple way to resolve: http://issues.apache.org/jira/browse/TRINIDAD-708 ... and, ouch, not really. The problem's not so much on the XMLMenuModel side of things, but the MenuContentHandlerImpl and MenuNode code, where we have: - A singleton MenuContentHandlerImpl that is storing a requestMap key to pass it onto the MenuNode - MenuNodes that use that key to go back and locate the root menu model. Fixing the one-XMLMenuModel-per-page limitation is going to require rethinking this odd design. -- Adam On 9/12/07, Adam Winer [EMAIL PROTECTED] wrote: On 9/12/07, Andrew Robinson [EMAIL PROTECTED] wrote: I changed the managed-bean-scope to request for both, seeing that in the developer guide, but it doesn't affect this code. Is there some odd requirement that there can only be one XmlMenuModel per application? There definitely shouldn't be any such requirement. I don't know the code well enough to know why this might go wrong. -- Adam -Andrew On 9/12/07, Andrew Robinson [EMAIL PROTECTED] wrote: I have 2 controls backed by an XmlMenuModel, a main menu and a help context menu. When I only had one menu, my code was working. When I introduced the 2nd model, I started getting this exception: java.lang.NullPointerException at org.apache.myfaces.trinidad.model.XMLMenuModel.getFocusRowKey(XMLMenuModel.java:292) at org.apache.myfaces.trinidad.component.UIXNavigationHierarchy.getFocusRowKey(UIXNavigationHierarchy.java:79) at org.apache.myfaces.trinidad.component.HierarchyUtils.__handleEncodeBegin(HierarchyUtils.java:88) at org.apache.myfaces.trinidad.component.UIXNavigationTree.__encodeBegin(UIXNavigationTree.java:153) at org.apache.myfaces.trinidad.component.UIXCollection.encodeBegin(UIXCollection.java:515) at org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils.renderChild(RendererUtils.java:435) at org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils.renderChildren(RendererUtils.java:423) at org.apache.myfaces.custom.roundeddiv.HtmlRoundedDivRenderer.encodeChildren(HtmlRoundedDivRenderer.java:319) at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:527) at org.apache.myfaces.trinidadinternal.uinode.UIComponentUINode._renderComponent(UIComponentUINode.java:320) at org.apache.myfaces.trinidadinternal.uinode.UIComponentUINode.render(UIComponentUINode.java:279) at org.apache.myfaces.trinidadinternal.uinode.UIComponentUINode.render(UIComponentUINode.java:256) at org.apache.myfaces.trinidadinternal.ui.BaseRenderer.renderChild(BaseRenderer.java:425) at org.apache.myfaces.trinidadinternal.ui.BaseRenderer.renderIndexedChild(BaseRenderer.java:343) at org.apache.myfaces.trinidadinternal.ui.BaseRenderer.renderIndexedChild(BaseRenderer.java:235) at org.apache.myfaces.trinidadinternal.ui.BaseRenderer.renderContent(BaseRenderer.java:142) at org.apache.myfaces.trinidadinternal.ui.laf.base.desktop.PanelTabbedRenderer.renderContent(PanelTabbedRenderer.java:112) at org.apache.myfaces.trinidadinternal.ui.BaseRenderer.render(BaseRenderer.java:93) at org.apache.myfaces.trinidadinternal.ui.laf.base.xhtml.XhtmlLafRenderer.render(XhtmlLafRenderer.java:84) at org.apache.myfaces.trinidadinternal.uinode.UIXComponentUINode.renderInternal(UIXComponentUINode.java:192) at org.apache.myfaces.trinidadinternal.uinode.UINodeRendererBase.encodeEnd(UINodeRendererBase.java:70) at org.apache.myfaces.trinidad.component.UIXComponentBase.encodeEnd(UIXComponentBase.java:710) faces-config.xml: managed-bean managed-bean-namemainMenuModel/managed-bean-name managed-bean-classorg.apache.myfaces.trinidad.model.XMLMenuModel/managed-bean-class managed-bean-scopeapplication/managed-bean-scope managed-property property-namesource/property-name value/WEB-INF/mainMenu.xml/value /managed-property /managed-bean managed-bean managed-bean
Re: [Trinidad] console is undefined?
One thing we could do is come up with a REALLY trivial
API like TrLog.error(), TrLog.severe(), TrLog.warning(),
write one version that delegates to a quality JS logging
implementation and load that in the debug Trinidad JS,
and have the non-debug libraries contain just:
TrLog.error = TrLog.severe = TrLog.warning = function() {}
We do have absolute control over what gets into non-debug
vs. debug via the ResourceLoader implementation, so this
sort of switching is easy.
If we wanted to be a bit more skimpy on codesize, we could also
store string constants on the non-debug TrLog, like:
TrLog.E0 = Could not find element;
... and used as
if (!element) { TrLog.error(E0, element); return; }
-- Adam
On 9/13/07, Andrew Robinson [EMAIL PROTECTED] wrote:
I can't say as I have used either, they just came up with some google
searching. I definitely think some research is in order and hopefully
some opinions from the community for any that people have used. I know
that A4J uses some of them.
Perhaps the suggestion for firebug lite may be good. It could be
injected on an as-need basis, and therefore would be faster for users
that already have firebug.
Another sickening thought is to have Trinidad with its own logging
solution, that delegates to something like firebug lite or log4js,
etc. The script could be loaded only when needed. This could be
possibly flagged in the web.xml as a context param (enabled javascript
logging). If the script is not loaded, the Trinidad's API would simply
be a black hole.
Syntax could be something like:
Log.level(obj)
In this example, Log.error('hello world); would call Log
library.error log method('hello world');
If logging was turned off (default), Log.error() would have no method
body. This way the extra javascript would simply be a few extra empty
functions.
Just a thought.
-Andrew
On 9/13/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
the sf.net project hasn't been touched since 17 month.
The berlin-os is shipping a larger file.
Perhaps some more testing/evaluating needs to be done.
-M
On 9/13/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Hi Andrew,
I think enhancing the logging in Trinidad's JS is valuable. Both have
a very good license.
The question is now, which is the best of the two ?
Greetings,
Matthias
On 9/13/07, Andrew Robinson [EMAIL PROTECTED] wrote:
I put a comment on the bug to possibly enhance Trinidad's logging to
use log4js. There are two projects with that name, one at sourceforge
and one at berlios. I think either may be work looking at. They should
both work in any browser that I am aware of.
What do you think Adam?
-Andrew
On 9/13/07, Bertrand, Shawn R [EMAIL PROTECTED] wrote:
The error dialog indeed doesn't appear in Firefox, though would it if
Firebug wasn't installed? There doesn't appear to be any sort of
error when
running in Firefox – all I see in the Firebug console are POST
messages as
expected.
I haven't looked at the current 1.0.2 codebase, but does it contain
the
change as outlined by Andrew for this? I guess I'd like to update to
it if
possible, because I can't see our users having to put up with
dismissing
this error.
Alternately, how might I go about finding the cause of the error
message in
IE?
Shawn
From: Adam Winer [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 12, 2007 2:08 PM
To: MyFaces Discussion
Subject: Re: [Trinidad] console is undefined?
This is indeed an attempt to call the firebug console (if
it exists), and Andrew's totally right that the syntax here
is wrong. FWIW, this should only be called if an error
has occurred, not in ordinary execution, so there's a more
essential problem elsewhere.
-- Adam
On 9/12/07, Andrew Robinson [EMAIL PROTECTED] wrote:
Yes, I get this all of the time to. I believe console is the firebug
globally installed window variable (plug-in for firefox)
I think the following code may be more IE friendly:
if (window.console window.console.error) {
...
}
On 9/12/07, Bertrand, Shawn R
[EMAIL PROTECTED] wrote:
I'm getting error generated from the first line of the following
function
in
Common1_0_2.js:
TrRequestQueue._logError=function(a118)
{
if(consoleconsole.error)
console.error(arguments);
}
This is running in IE 6. Is this console object related
Re: [Trinidad] error: No RenderingContext has been created
We could really use a stack trace to help narrow this down;any chance you could put a Thread.dumpStack() at this logged method? This presumably means that A4J is failing to invoke the Trinidad ViewHandler while rendering. -- Adam On 9/12/07, Renzo Tomaselli [EMAIL PROTECTED] wrote: Hi, one more issue after upgrading from 1.01 to 1.02. During the very first postback of a page containing a tr:tree, I saw the log message twice: SEVERE: No RenderingContext has been created. After some searches I noticed that this error occurred to someone else while using Tiles - but I don't do it - although my application uses ajax4jsf/richfaces. Is there any link ? Besides the logs themselves, I saw nothing else, however my tr:tree does not expand nodes properly (see my previous posting). Any suggestion ? Thanks, -- Renzo
Re: Dialog issue during ADF-Trinidad migration
Yeah, that sounds like the issue. Older versions of the RI,as well as
MyFaces 1.2 don't support *.faces mappings well
enough for this scenario (I haven't looked into why).
-- Adam
On 9/12/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Is it possible, that you are
using myfaces 1.2 ?
and *.faces mapping ?
try, /faces/* as your mapping
On 9/12/07, Bertrand, Shawn R [EMAIL PROTECTED] wrote:
Thanks for the clarification.
Unfortunately, it isn't working in Trinidad as it did in ADF Faces.
FredJSP.getRedirectURL generates a baseURL of
/nas/__ADFv__.faces?_afPfm=497604ee_t=fred and arguments
of {_vir, /jsp/SnmpSsMacDetail.jsp, loc, en-US, _minWidth,
_minHeight,}. The second argument is correct and that resource is
definitely present in the deployed application.
The separate browser window does appear as it used to but it contains an
HTTP 404 error with the description The requested resource
(/__ADFv__.jsp)
is not available..
Thanks again,
Shawn Bertrand
Tyco Electronics Corporation
From: Adam Winer [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 11, 2007 4:32 PM
To: MyFaces Discussion
Subject: Re: Dialog issue during ADF-Trinidad migration
There's two separate flags here:
- useWindow
- usePopup
If useWindow is false, that means we navigate the whole page
to the dialog. Simple enough.
If useWindow is true, then we look at usePopup: if it's false,
we want to show the dialog in a new browser window.
We use FredJSP so that we have a frameset around the
dialog view, needed to make sure that context is not lost
when you navigate within the dialog.
If usePopup is true, we use a DHTML dialog. We don't
need FredJSP, since we're putting the dialog in an iframe,
and can directly navigate to the page.
Does this make sense?
What you're describing - uses the URL returned from FredJSP.
getRedirectURL - is intentional (and was the way things
worked back in ADF, FWIW). What should be happening next
is that a frameset gets generated where the frame's source
is the URL of the desired page - so your dialog does show up.
Is that not working?
-- Adam
On 9/11/07, Bertrand, Shawn R
[EMAIL PROTECTED] wrote:
(Trinidad 1.0.2 – build from July – the current one).
I've migrated our application to use Trinidad, and see some PPR issues
that
are likely ours, but for the most part everything is working as
expected.
Except….
We use the dialog framework extensively, and every time we attempt to
display one a popup appears but uses the URL returned from
FredJSP.getRedirectURL. This happens because the code in CoreRenderKit,
when constructing a DialogRequest object, calls usePopupForDialog to
determine if the popup is supported. Why wouldn't the passed-in
usePopup
setting be used? Fortunately for me (at least for now), I added the
org.apache.myfaces.trinidadinternal.renderkit.USE_DIALOG_POPUP
context parameter to my web.xml and popups are now appearing (though
they
appear in a dhtml-looking layer instead of the traditional popup dialog
(probably a good thing).
Note: the Trinidad demo doesn't seem to need this context parameter to
display dialogs.
Thanks in advance,
Shawn Bertrand
Tyco Electronics Corporation
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
mail: matzew-at-apache-dot-org
Re: [Trinidad] console is undefined?
This is indeed an attempt to call the firebug console (if
it exists), and Andrew's totally right that the syntax here
is wrong. FWIW, this should only be called if an error
has occurred, not in ordinary execution, so there's a more
essential problem elsewhere.
-- Adam
On 9/12/07, Andrew Robinson [EMAIL PROTECTED] wrote:
Yes, I get this all of the time to. I believe console is the firebug
globally installed window variable (plug-in for firefox)
I think the following code may be more IE friendly:
if (window.console window.console.error) {
...
}
On 9/12/07, Bertrand, Shawn R [EMAIL PROTECTED] wrote:
I'm getting error generated from the first line of the following
function in
Common1_0_2.js:
TrRequestQueue._logError=function(a118)
{
if(consoleconsole.error)
console.error(arguments);
}
This is running in IE 6. Is this console object related to the Acrobat
console window?
Thanks,
Shawn
Re: [Trinidad] panelPopup in 1.0.3 SNAPSHOT
On 9/12/07, Danny Robinson [EMAIL PROTECTED] wrote:
I noticed the style attributes were not being output as they should a few
days ago. I've put a fix together, just wanted to test a few other bits.
Certainly triggerStyle was totally unecessary. I'll make the necessary
tweaks as per Adam's suggestions.
The original reason for 3 divs was to keep seperate the skin styles that a
developer could tweak from those required by the component. Hence, the
outer div controlled the show/hide and couldn't easily be modified though
bad style entries.
I get the outer div with the show/hide styles. I don't get why we
need two more divs inside it - I only see a need for one more div
(two total).
-- Adam
On 9/11/07, Adam Winer [EMAIL PROTECTED] wrote:
Good question
In general, they go on the root element. In this case,
that's the span. However, the primary purpose of this
component is definitely the popup itself, , so you could
very reasonably argue that it ought to go there.
Looking at the content, I have more questions:
- Why do we need three divs - one with an ID and
the visibility:hidden, as well as the container and
content style classes? IMO, we should only need two,
and the middle one would be unnecessary.
- There's no styleclass on the outer span.
I think what I'd recommend is deleting the middle DIV,
renaming af|panelPopup::content to just af|panelPopup,
rendering styleclass on that content DIV, and finally
adding an af|panelPopup::trigger class onto the outer
span.
Oh, and also doc the styles in the skin-selectors page. :)
-- Adam
On 9/11/07, Andrew Robinson [EMAIL PROTECTED] wrote:
Before filing a bug, I was wondering what the intended result of this
was:
tr:panelPopup text=test styleClass=testclass
test
/tr:panelPopup
from what I can see of 1.0.3-SNAPSHOT the testclass style class is
ignored. Is it supposed to render on the trigger, the popup content,
the popup outer element or the element that contains the content for
the entire control?
Here is the HTML from the above example:
span id_popuptrigger=_id45
a href=# class=OraLink
onclick= TrPanelPopup.showPopup('_id45_popupContainer', '_id45',
event, 'click','null',false,0,0,0,0); return false; name=_id45
id=_id45test/a
div style=position: absolute; top: 0px; left: 0px; visibility:
hidden; id=_id45_popupContainer
div class=af_panelPopup_container
div class=af_panelPopup_content
test/div
/div
/div
/span
--
Chordiant Software Inc.
www.chordiant.com
Re: [Trinidad] tr:tree non expanding nodes anymore
Do you see any logged warnings whatsoever? You apparently are using A4J -
what happens if you remove A4J from
the picture? There's not enough to go on just in this report.
-- Adam
On 9/12/07, Renzo Tomaselli [EMAIL PROTECTED] wrote:
Hi, just upgraded from 1.01 to 1.02 and tr:tree does not expand nodes
anymore. Node linking is ok.
More exactly - expanding a node renders the same view without any
visible effect, but any other following refresh shows expanded branches
correctly.
I had no problems till 1.01. I guess something changed in the component
logics, but how can I follow it ?
Component is included as:
tr:tree id=dbTree value=#{bean.treeModel} var=node
immediate=true
rowDisclosureListener=#{bean.expand}
binding=#{bean.component}
disclosedRowKeys=#{bean.disclosed}
inlineStyle=white-space: nowrap
using my own tree model.
-- Renzo
Re: Trinidad jar - too many open files Exception
On 9/12/07, Steve [EMAIL PROTECTED] wrote: Hi Adam, I've since tried the 1.0.2-SNAPSHOT version and the problem is still there. In the mean time I'm running garbage collection periodically to mop up the unwanted file descriptors Check modification is false and I'm pretty sure we don't have any debug flags on. The application is running on Tomcat 5.5 on Linux. I'm not sure whether it's relevant but the trinidad jars are in Tomcat's shared directory (shared/lib). I've recently moved a skin (including images) to a shared jar file which is also producing open file descriptors. The images are accessed through the Trinidad's ResourceServlet. Could it be the ResourceServlet that's causing the problem? That's good info! It certainly suggests ResourceServlet is at least part of the problem. Let me know if there's anything else I can do. Any chance of setting some breakpoints? Especially on FileInputStream constructors, to see when it's cracking open your skinning JAR? -- Adam Thanks, Steve Adam Winer wrote: Yeah, it was before 1.0.2. The big problem was calls to java.net.URLConnection.lastModified() that didn't close the input stream. (Bizarrely, an input stream gets opened on the File just to retrieve lastModified when you go through java.net.URL, at least for a typical JAR URLConnection implementation.) I'm not aware of a second cause for file descriptors to be created on the impl JAR - or if, perhaps, some servers have problematic URLConnection implementations that lead to file descriptor leaks. So, I could use (a lot of) help tracking down why there's still a problem here. BTW, do you have any debug or check modification flags set in web.xml or trinidad-config.xml? -- Adam On 9/11/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: the commit by Adam, was before we released 1.0.2, as far as I know. Greetings, Matthias On 9/11/07, Steve [EMAIL PROTECTED] wrote: Hi, Yes I'm using the 1.0.2 release. I've just had a look at the thread you mentioned: http://www.mail-archive.com/users@myfaces.apache.org/msg39055.html So is this fixed in the latest SNAPSHOT? Cheers, Steve Matthias Wessendorf wrote: Hi, we had something, mentioned with a SNAPSHOT of 1.0.2. Adam fixed something related to this. My guess is, you are using the release, isn't it ? Peter, is this still an issue for you guys ? Thanks! Matthias On 9/11/07, Steve [EMAIL PROTECTED] wrote: I've been getting the following exception: java.net.SocketException: Too many open files on a Tomcat server running on Linux. I ran lsof - p tomcat_pid to see what was going on and it seems that the trinidad jar file is being opened far too many times: . java3693 tomcat 1004r REG3,5 3646899 5359580 /usr/local/tomcat/shared/lib/trinidad-impl-1.0.2.jar java3693 tomcat 1005r REG3,5 3646899 5359580 /usr/local/tomcat/shared/lib/trinidad-impl-1.0.2.jar java3693 tomcat 1006r REG3,5 3646899 5359580 /usr/local/tomcat/shared/lib/trinidad-impl-1.0.2.jar java3693 tomcat 1007r REG3,5 3646899 5359580 /usr/local/tomcat/shared/lib/trinidad-impl-1.0.2.jar java3693 tomcat 1008r REG3,5 3646899 5359580 /usr/local/tomcat/shared/lib/trinidad-impl-1.0.2.jar java3693 tomcat 1009r REG3,5 3646899 5359580 /usr/local/tomcat/shared/lib/trinidad-impl-1.0.2.jar There seem to be around a 1000 file descriptors open for the trinidad jar before the exception gets thrown. It's referenced much earlier in the list along with other jars: ... java3693 tomcat memREG3,524432 5360898 /usr/local/tomcat/shared/lib/el-api-1.0.jar java3693 tomcat memREG3,5 3646899 5359580 /usr/local/tomcat/shared/lib/trinidad-impl-1.0.2.jar java3693 tomcat memREG3,5 1279296 5360913 /usr/local/tomcat/shared/lib/tomahawk-1.1.3.jar ... Does anyone know why the trinidad jar would be opened so many times? Thanks, Steve -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
Re: [Trinidad] Exception with XMLMenuModel usage
On 9/12/07, Andrew Robinson [EMAIL PROTECTED] wrote:
I changed the managed-bean-scope to request for both, seeing that in
the developer guide, but it doesn't affect this code.
Is there some odd requirement that there can only be one XmlMenuModel
per application?
There definitely shouldn't be any such requirement. I
don't know the code well enough to know why this might
go wrong.
-- Adam
-Andrew
On 9/12/07, Andrew Robinson [EMAIL PROTECTED] wrote:
I have 2 controls backed by an XmlMenuModel, a main menu and a help
context menu. When I only had one menu, my code was working. When I
introduced the 2nd model, I started getting this exception:
java.lang.NullPointerException
at
org.apache.myfaces.trinidad.model.XMLMenuModel.getFocusRowKey(XMLMenuModel.java:292)
at
org.apache.myfaces.trinidad.component.UIXNavigationHierarchy.getFocusRowKey(UIXNavigationHierarchy.java:79)
at
org.apache.myfaces.trinidad.component.HierarchyUtils.__handleEncodeBegin(HierarchyUtils.java:88)
at
org.apache.myfaces.trinidad.component.UIXNavigationTree.__encodeBegin(UIXNavigationTree.java:153)
at
org.apache.myfaces.trinidad.component.UIXCollection.encodeBegin(UIXCollection.java:515)
at
org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils.renderChild(RendererUtils.java:435)
at
org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils.renderChildren(RendererUtils.java:423)
at
org.apache.myfaces.custom.roundeddiv.HtmlRoundedDivRenderer.encodeChildren(HtmlRoundedDivRenderer.java:319)
at
javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:527)
at
org.apache.myfaces.trinidadinternal.uinode.UIComponentUINode._renderComponent(UIComponentUINode.java:320)
at
org.apache.myfaces.trinidadinternal.uinode.UIComponentUINode.render(UIComponentUINode.java:279)
at
org.apache.myfaces.trinidadinternal.uinode.UIComponentUINode.render(UIComponentUINode.java:256)
at
org.apache.myfaces.trinidadinternal.ui.BaseRenderer.renderChild(BaseRenderer.java:425)
at
org.apache.myfaces.trinidadinternal.ui.BaseRenderer.renderIndexedChild(BaseRenderer.java:343)
at
org.apache.myfaces.trinidadinternal.ui.BaseRenderer.renderIndexedChild(BaseRenderer.java:235)
at
org.apache.myfaces.trinidadinternal.ui.BaseRenderer.renderContent(BaseRenderer.java:142)
at
org.apache.myfaces.trinidadinternal.ui.laf.base.desktop.PanelTabbedRenderer.renderContent(PanelTabbedRenderer.java:112)
at
org.apache.myfaces.trinidadinternal.ui.BaseRenderer.render(BaseRenderer.java:93)
at
org.apache.myfaces.trinidadinternal.ui.laf.base.xhtml.XhtmlLafRenderer.render(XhtmlLafRenderer.java:84)
at
org.apache.myfaces.trinidadinternal.uinode.UIXComponentUINode.renderInternal(UIXComponentUINode.java:192)
at
org.apache.myfaces.trinidadinternal.uinode.UINodeRendererBase.encodeEnd(UINodeRendererBase.java:70)
at
org.apache.myfaces.trinidad.component.UIXComponentBase.encodeEnd(UIXComponentBase.java:710)
faces-config.xml:
managed-bean
managed-bean-namemainMenuModel/managed-bean-name
managed-bean-classorg.apache.myfaces.trinidad.model.XMLMenuModel/managed-bean-class
managed-bean-scopeapplication/managed-bean-scope
managed-property
property-namesource/property-name
value/WEB-INF/mainMenu.xml/value
/managed-property
/managed-bean
managed-bean
managed-bean-namehelpContextMenuModel/managed-bean-name
managed-bean-classorg.apache.myfaces.trinidad.model.XMLMenuModel/managed-bean-class
managed-bean-scopeapplication/managed-bean-scope
managed-property
property-namesource/property-name
value/WEB-INF/helpContents.xml/value
/managed-property
/managed-bean
The problem seems to be a result of:
if (this == _getRootModel())
{
_viewIdFocusPathMap =
_contentHandler.getViewIdFocusPathMap(_mdSource);
_nodeFocusPathMap = _contentHandler.getNodeFocusPathMap(_mdSource);
_idNodeMap = _contentHandler.getIdNodeMap(_mdSource);
}
For the 2nd component, the if evaluates to false, so the three
member variables are null, and the exception is because
_viewIdFocusPathMap is null.
Am I doing something wrong or is this a bug in 1.0.3-SNAPSHOT?
Usage of main menu
tr:navigationPane
id=mainMenuPanel
partialTriggers=mainMenuPanel
hint=list
var=_node
value=#{mainMenuModel}
f:facet name=detailStamp
tr:commandNavigationItem
actionListener=#{menuBean.onMainAction}
partialSubmit=true
immediate=true
f:param name=conversationPropagation value=#{'none'} /
/tr:commandNavigationItem
Re: Trinidad jar - too many open files Exception
Yeah, it was before 1.0.2. The big problem was calls to java.net.URLConnection.lastModified() that didn't close the input stream. (Bizarrely, an input stream gets opened on the File just to retrieve lastModified when you go through java.net.URL, at least for a typical JAR URLConnection implementation.) I'm not aware of a second cause for file descriptors to be created on the impl JAR - or if, perhaps, some servers have problematic URLConnection implementations that lead to file descriptor leaks. So, I could use (a lot of) help tracking down why there's still a problem here. BTW, do you have any debug or check modification flags set in web.xml or trinidad-config.xml? -- Adam On 9/11/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: the commit by Adam, was before we released 1.0.2, as far as I know. Greetings, Matthias On 9/11/07, Steve [EMAIL PROTECTED] wrote: Hi, Yes I'm using the 1.0.2 release. I've just had a look at the thread you mentioned: http://www.mail-archive.com/users@myfaces.apache.org/msg39055.html So is this fixed in the latest SNAPSHOT? Cheers, Steve Matthias Wessendorf wrote: Hi, we had something, mentioned with a SNAPSHOT of 1.0.2. Adam fixed something related to this. My guess is, you are using the release, isn't it ? Peter, is this still an issue for you guys ? Thanks! Matthias On 9/11/07, Steve [EMAIL PROTECTED] wrote: I've been getting the following exception: java.net.SocketException: Too many open files on a Tomcat server running on Linux. I ran lsof - p tomcat_pid to see what was going on and it seems that the trinidad jar file is being opened far too many times: . java3693 tomcat 1004r REG3,5 3646899 5359580 /usr/local/tomcat/shared/lib/trinidad-impl-1.0.2.jar java3693 tomcat 1005r REG3,5 3646899 5359580 /usr/local/tomcat/shared/lib/trinidad-impl-1.0.2.jar java3693 tomcat 1006r REG3,5 3646899 5359580 /usr/local/tomcat/shared/lib/trinidad-impl-1.0.2.jar java3693 tomcat 1007r REG3,5 3646899 5359580 /usr/local/tomcat/shared/lib/trinidad-impl-1.0.2.jar java3693 tomcat 1008r REG3,5 3646899 5359580 /usr/local/tomcat/shared/lib/trinidad-impl-1.0.2.jar java3693 tomcat 1009r REG3,5 3646899 5359580 /usr/local/tomcat/shared/lib/trinidad-impl-1.0.2.jar There seem to be around a 1000 file descriptors open for the trinidad jar before the exception gets thrown. It's referenced much earlier in the list along with other jars: ... java3693 tomcat memREG3,524432 5360898 /usr/local/tomcat/shared/lib/el-api-1.0.jar java3693 tomcat memREG3,5 3646899 5359580 /usr/local/tomcat/shared/lib/trinidad-impl-1.0.2.jar java3693 tomcat memREG3,5 1279296 5360913 /usr/local/tomcat/shared/lib/tomahawk-1.1.3.jar ... Does anyone know why the trinidad jar would be opened so many times? Thanks, Steve -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
Re: Dialog issue during ADF-Trinidad migration
There's two separate flags here: - useWindow - usePopup If useWindow is false, that means we navigate the whole page to the dialog. Simple enough. If useWindow is true, then we look at usePopup: if it's false, we want to show the dialog in a new browser window. We use FredJSP so that we have a frameset around the dialog view, needed to make sure that context is not lost when you navigate within the dialog. If usePopup is true, we use a DHTML dialog. We don't need FredJSP, since we're putting the dialog in an iframe, and can directly navigate to the page. Does this make sense? What you're describing - uses the URL returned from FredJSP. getRedirectURL - is intentional (and was the way things worked back in ADF, FWIW). What should be happening next is that a frameset gets generated where the frame's source is the URL of the desired page - so your dialog does show up. Is that not working? -- Adam On 9/11/07, Bertrand, Shawn R [EMAIL PROTECTED] wrote: (Trinidad 1.0.2 – build from July – the current one). I've migrated our application to use Trinidad, and see some PPR issues that are likely ours, but for the most part everything is working as expected. Except…. We use the dialog framework extensively, and every time we attempt to display one a popup appears but uses the URL returned from FredJSP.getRedirectURL. This happens because the code in CoreRenderKit, when constructing a DialogRequest object, calls usePopupForDialog to determine if the popup is supported. Why wouldn't the passed-in usePopup setting be used? Fortunately for me (at least for now), I added the org.apache.myfaces.trinidadinternal.renderkit.USE_DIALOG_POPUP context parameter to my web.xml and popups are now appearing (though they appear in a dhtml-looking layer instead of the traditional popup dialog (probably a good thing). Note: the Trinidad demo doesn't seem to need this context parameter to display dialogs. Thanks in advance, Shawn Bertrand Tyco Electronics Corporation
Re: [Trinidad] panelPopup in 1.0.3 SNAPSHOT
Good question
In general, they go on the root element. In this case,
that's the span. However, the primary purpose of this
component is definitely the popup itself, , so you could
very reasonably argue that it ought to go there.
Looking at the content, I have more questions:
- Why do we need three divs - one with an ID and
the visibility:hidden, as well as the container and
content style classes? IMO, we should only need two,
and the middle one would be unnecessary.
- There's no styleclass on the outer span.
I think what I'd recommend is deleting the middle DIV,
renaming af|panelPopup::content to just af|panelPopup,
rendering styleclass on that content DIV, and finally
adding an af|panelPopup::trigger class onto the outer
span.
Oh, and also doc the styles in the skin-selectors page. :)
-- Adam
On 9/11/07, Andrew Robinson [EMAIL PROTECTED] wrote:
Before filing a bug, I was wondering what the intended result of this was:
tr:panelPopup text=test styleClass=testclass
test
/tr:panelPopup
from what I can see of 1.0.3-SNAPSHOT the testclass style class is
ignored. Is it supposed to render on the trigger, the popup content,
the popup outer element or the element that contains the content for
the entire control?
Here is the HTML from the above example:
span id_popuptrigger=_id45
a href=# class=OraLink
onclick=TrPanelPopup.showPopup('_id45_popupContainer', '_id45',
event, 'click','null',false,0,0,0,0); return false; name=_id45
id=_id45test/a
div style=position: absolute; top: 0px; left: 0px; visibility:
hidden; id=_id45_popupContainer
div class=af_panelPopup_container
div class=af_panelPopup_content
test/div
/div
/div
/span
Re: [Trinidad] panelPopup in 1.0.3 SNAPSHOT
Good question
In general, they go on the root element. In this case,
that's the span. However, the primary purpose of this
component is definitely the popup itself, , so you could
very reasonably argue that it ought to go there.
Looking at the content, I have more questions:
- Why do we need three divs - one with an ID and
the visibility:hidden, as well as the container and
content style classes? IMO, we should only need two,
and the middle one would be unnecessary.
- There's no styleclass on the outer span.
I think what I'd recommend is deleting the middle DIV,
renaming af|panelPopup::content to just af|panelPopup,
rendering styleclass on that content DIV, and finally
adding an af|panelPopup::trigger class onto the outer
span.
Oh, and also doc the styles in the skin-selectors page. :)
-- Adam
On 9/11/07, Andrew Robinson [EMAIL PROTECTED] wrote:
Before filing a bug, I was wondering what the intended result of this was:
tr:panelPopup text=test styleClass=testclass
test
/tr:panelPopup
from what I can see of 1.0.3-SNAPSHOT the testclass style class is
ignored. Is it supposed to render on the trigger, the popup content,
the popup outer element or the element that contains the content for
the entire control?
Here is the HTML from the above example:
span id_popuptrigger=_id45
a href=# class=OraLink
onclick=TrPanelPopup.showPopup('_id45_popupContainer', '_id45',
event, 'click','null',false,0,0,0,0); return false; name=_id45
id=_id45test/a
div style=position: absolute; top: 0px; left: 0px; visibility:
hidden; id=_id45_popupContainer
div class=af_panelPopup_container
div class=af_panelPopup_content
test/div
/div
/div
/span
Re: [Trinidad] FrameBorderLayout
frameBorderLayout cannot be used inside of a tr:document page. Check the HTML spec - you get to choose frameset or body, not both. Once you're inside a body, you need to use iframe. -- Adam On 9/10/07, Okan Cetin [EMAIL PROTECTED] wrote: I realized that if the facet name will be set as center , it works. But I want to use it for left, innerLeft, right, top, bottom etc. On 10/09/2007, Okan Çetin [EMAIL PROTECTED] wrote: Hi all; I'm trying to use frameborder component in trinidad My code is below: f:view tr:document title=Index Page tr:form id=form1 trh:frameBorderLayout id=frameid f:facet name=left trh:frame source=left.jsp name=left width=100% height=50pt / /f:facet /trh:frameBorderLayout /tr:form /tr:document /f:view But i am getting blank page. Here is the rendered version: frameset id= frameid rows=100%,* frameset title = cols=100%,*!--Start: org.apache.myfaces.trinidad.Frame [_idJsp1]-- frame frameborder=0 noresize src=left.jsp /frameset /frameset -- ~ otomatik oluşturuldu: http://ocetin.net/log -- ~ otomatik oluşturuldu: http://ocetin.net/log
Re: [Trinidad] tr:selectManyShuttle
Do you see any Javascript errors? (Also, you generally want a tr:document around the form, inside of the f:view). -- Adam On 9/10/07, Reza Samoody [EMAIL PROTECTED] wrote: I'm trying to use a simple selectManyShuttle. It does not transfer the items between the lists. Do I need to define any backing bean or component for selectManyShuttle. here is the code: html xmlns= http://www.w3.org/1999/xhtml; xmlns:f=http://java.sun.com/jsf/core; xmlns:h= http://java.sun.com/jsf/html; xmlns:tr=http://myfaces.apache.org/trinidad; f:view tr:form tr:selectManyShuttle id=shuttle1 leadingHeader=l-header Available values: trailingHeader=t-header Selected values: label=label-Selected Values tr:selectItem shortDesc=short desc The First Item label=label First value=value foo/ tr:selectItem label=Second value=bar/ tr:selectItem label=Third value=baz/ /tr:selectManyShuttle /tr:form /f:view /html
Re: [[Trinidad] tr:selectManyShuttle
selectManyShuttle needs to be inside of a tr:form or h:form.
-- Adam
On 9/10/07, Reza Samoody [EMAIL PROTECTED] wrote:
Hi,
I'm trying to use a very simple selectManyShuttle as below:
tr:selectManyShuttle id=serviceTypeSelection value=#{
providerBean.serviceTypes}
leadingHeader=#{
mapMsg.availableServiceTypes}
trailingHeader=#{
mapMsg.assignedServiceTypes}
tr:selectItem label=a value=A /
tr:selectItem label=b value=B /
tr:selectItem label=c value=C /
/tr:selectManyShuttle
But I'm getting a null pointer exception:
java.lang.NullPointerException
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.SelectManyShuttleRenderer$ShuttleList.getOndblclick(SelectManyShuttleRenderer.java
:901)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.XhtmlRenderer.renderEventHandlers(XhtmlRenderer.java:446)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.FormElementRenderer.renderEventHandlers
(FormElementRenderer.java:193)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.XhtmlRenderer.renderAllAttributes(XhtmlRenderer.java:302)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.FormInputRenderer.renderAllAttributes
(FormInputRenderer.java:109)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.SimpleSelectManyListboxRenderer.encodeElementContent(SimpleSelectManyListboxRenderer.java:79)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.SimpleSelectManyRenderer.encodeAllAsElement
(SimpleSelectManyRenderer.java:368)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.FormElementRenderer.encodeAll(FormElementRenderer.java:109)
at org.apache.myfaces.trinidad.render.CoreRenderer.delegateRenderer
(CoreRenderer.java:330)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.SelectManyShuttleRenderer$Box.encodeAllChildren(SelectManyShuttleRenderer.java:1115)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelBoxRenderer.renderContent
(PanelBoxRenderer.java:413)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelBoxRenderer.renderBody(PanelBoxRenderer.java:340)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelBoxRenderer._renderMiddleRow
(PanelBoxRenderer.java:267)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelBoxRenderer.encodeAll(PanelBoxRenderer.java:115)
at
org.apache.myfaces.trinidad.render.CoreRenderer.delegateRenderer(CoreRenderer.java
:330)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.SelectManyShuttleRenderer._renderContainerRow(SelectManyShuttleRenderer.java:577)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.SelectManyShuttleRenderer.encodeElementContent
(SelectManyShuttleRenderer.java:312)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.SimpleSelectManyRenderer.encodeAllAsElement(SimpleSelectManyRenderer.java:368)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.FormElementRenderer.encodeAll
(FormElementRenderer.java:109)
at
org.apache.myfaces.trinidad.render.CoreRenderer.encodeEnd(CoreRenderer.java:220)
at
org.apache.myfaces.trinidad.component.UIXComponentBase.encodeEnd(UIXComponentBase.java:710)
at
com.sun.facelets.tag.jsf.ComponentSupport.encodeRecursive(ComponentSupport.java:252)
at
com.sun.facelets.tag.jsf.ComponentSupport.encodeRecursive(ComponentSupport.java:249)
at com.sun.facelets.FaceletViewHandler.renderView
(FaceletViewHandler.java:573)
at
org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:182)
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 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
(ApplicationFilterChain.java:269)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:210)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:174)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke
(ErrorReportValve.java:117)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151)
at org.apache.coyote.http11.Http11Processor.process
(Http11Processor.java:870)
at
Re: [Trinidad] PPR/ReturnEvent not queued after many nested dialogs
I've made some major impropvements in these areas, especially in keeping the state of the parent window alive while dialogs are up. So I suspect the problems are resolved in Trinidad. -- Adam On 9/7/07, Bertrand, Shawn R [EMAIL PROTECTED] wrote: I'm at a loss on this one, and am hoping for some help. While I'm using Trinidad in development, this is a problem with the latest ADF Faces (haven't tried a reproducible case for Trinidad at this point) and being that one derived from the other, I'm hoping some of the experts can comment. I'm not sure I'd get the same level of exposure on the Oracle JDeveloper forum. My situation is this: I have a commandButton on the main page which launches a dialog through the dialog framework (i.e. with a dialog:action navigation rule). In the dialog (call it dialog1), there is an ADF table which has a commandButton in the footer. That commandButton launches another dialog (either with navigation rule or via launchDialog). The secondary dialog (call it dialog2) gets some data and populates rows in the ADF table on dialog1 (PPR is used here as well). Clicking OK in dialog1 updates a table and some buttons on the main page through PPR. My problem is this: If I enter dialog1 and consequently enter and leave dialog2 more than 4 times (whether clicking OK or cancel), the ADF table and buttons on the main page do not get updated and the ReturnListener I've registered on the commandButton that spawned dialog1 does not get fired. I've verified that the returnListener is in place when dialog1 is closed (via returnFromDialog), but it just doesn't get queued for some reason. Again this only happens when entering and leaving dialog2 more than 4 times – any less and the main page's table and buttons update via PPR beautifully. My apologies for putting an ADF question up here, but it may just be a problem in Trinidad as well. Thanks in advance for your time, Shawn Bertrand Tyco Electronics Corporation
Re: Trinidad: Missing script type=text/javascript src=/trinidad-demo/adf/jsLibs/Common1_0_2.js in html-head
Yep, indeed. Also looks like body has a stray onload
handler too.
-- Adam
On 9/7/07, Martin Marinschek [EMAIL PROTECTED] wrote:
Hi Martin,
you should still create an issue for the fact that the command-button
still renders a call to a javascript-function which isn't there on the
page.
regards,
Martin
On 9/6/07, Martin Hinterndorfer [EMAIL PROTECTED] wrote:
Hi!
Problem with the missing javaScript link is solved! - Yeah!
Stupid, but:
In the file trinidad-config.xml
the output-mode was set to:
output-modeprintable/output-mode
And this means no script - tags are rendered in the head of the html!
Therefor no actions are performed...
Thanx for the engagement!
Martin Hinterndorfer
2007/9/6, Matthias Wessendorf [EMAIL PROTECTED]:
yesterday, Thomas asked me the same.
I updated my trunk version of Trinidad.
run the build (mvn clean install) and deployed the demo.
Everything is fine.
(it renders 1_0_3 instead of 1_0_2 on trunk, since we updated the
trinidad-version.txt file, once we release the bits of Trinidad 1.0.2)
-Matthias
On 9/6/07, Martin Hinterndorfer [EMAIL PROTECTED] wrote:
Hi!
I have troubles setting up a demo application with tomahawk and myfaces.
When I want to show a simple page like this:
?xml version=1.0 encoding=UTF-8?
tr:document
xmlns:ui= http://java.sun.com/jsf/facelets;
xmlns:h=http://java.sun.com/jsf/html;
xmlns:f= http://java.sun.com/jsf/core
xmlns:tr=http://myfaces.apache.org/trinidad;
title=Facelets
tr:form
tr:inputText label=Your name id=input1 value=#{ user.name}
/
#{user.name}tintifax
tr:commandButton id=button1 text=press me
action=#{ user.myAction} /
/tr:form
/tr:document
The page does not get rendered correctly.
It looks fine, but when I click the button, the according action will
not
be triggered.
This is because there is the script tag missing in the html head tag
(compared to the trinidad examples) .
script type=text/javascript
src=/trinidad-demo/adf/jsLibs/Common1_0_2.js
So the source-code of the rendered html-document looks like this:
?xml version=1.0 encoding=UTF-8?
!DOCTYPE HTML PUBLIC -//W3C//DTD HTML
4.01//EN
http://www.w3.org/TR/html4/loose.dtd;!--Start:
org.apache.myfaces.trinidad.Document[_id1]--
html dir=ltr lang=de
head
titleFacelets/title
meta
name=generator content=Apache Trinidad
link
rel=stylesheet charset=UTF-8
type=text/css
href=/jsfpoc-local/adf/styles/cache/airplus-desktop-1549033220-gecko.css
/head
!--Start: org.apache.myfaces.trinidad.Document
[_id1]--
body
onload=_checkLoadNoPPR()a name=top/
a
noscriptDiese Seite verwendet JavaScript und benouml;tigt einen
JavaScript-fauml;higen Browser. Ihr Browser unterstuuml;tzt JavaScript
nicht./
noscript
!--Start: org.apache.myfaces.trinidad.Form[_id2]--
form
id=_id2 name=_id2 style=
margin:0px method=POST onkeypress=return
_submitOnEnter(event,'_id2');
action=/jsfpoc-local/trinidad- sample.jsf!--Start:
org.apache.myfaces.trinidad.Input[input1]--
table id=input1__xc_ class=af_inputText
cellpadding=0 cellspacing=0
border=0 summary=tr
td class=af_inputText_label nowrapYour name/
td
td valign=top nowrap
class=AFContentCell!--Start:
org.apache.myfaces.trinidad.Input[input1]--div
id=input1 name=input1 class=
af_inputText_contentHarald/div/td
/tr!--Start: org.apache.myfaces.trinidad.Input
[input1]--tr
td/td
td class=AFComponentMessageCell!--Start:
org.apache.myfaces.trinidad.Input[input1]--
/td
/tr/table
Haraldtintifax!--Start:
org.apache.myfaces.trinidad.Command
[button1]--input id=button1 name=
button1 type=submit
onclick=submitForm('_id2',1,{source:'button1'});return
false;
class=af_commandButton value=press me
input type=hidden
name=org.apache.myfaces.trinidad.faces.FORM
value=_id2input type=
hidden name=org.apache.myfaces.trinidad.faces.STATE
value=
!4e98d331/form
/body
!--Created by Apache Trinidad (Apache MyFaces Trinidad API -
1.0.2/Apache
MyFaces Trinidad Impl -
1.0.2 ), skin:airplus.desktop (airplus)--/html
I have no idea why, and no clue where I can find any further info
regarding
this matter.
Which Component is responsible for that?
Can anyone help?
best regards
Martin Hinterndorfer
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
mail: matzew-at-apache-dot-org
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: [Trinidad] Internet Explorer 5.5 ?
Short answer: if you can submit patches that improveIE 5 compatibility without harming other browsers, we'd be happy to incorporate them. I doubt you'll find any committers interested in tackling this problem on their own, and like the page says, Trinidad has not been tested against IE 5, so there are no guarantees that you'd be able to make it work at all. -- Adam On 9/6/07, Nebinger, David [EMAIL PROTECTED] wrote: Stephen Friedrich wrote: Now I have two choices: I either fulfill this requirement or I try and pick a fight. devils_advocate And apparently, since everyone in your organization is equally lazy, the guidelines will stay fixed forever. :) /devils_advocate I think you folks are being way to hard on this guy. Browser version support typically is driven by outside forces... You need to know who your user base is and what kind of browsers they have. I'm part of a 3PL, one that works with many mom-n-pop trucking companies. I count myself lucky if those folks have a computer at all, let alone a modern one with a 6.0 or greater IE. Sure, I could say to them 'you need to upgrade', but they could turn around and tell me they don't want my business, something that I need to have. I'd love to tell everyone to use firefox (as it is more modern and secure), but the choice is not mine to make, it is the end users' choice. Oh, and don't overlook the fact that many govt sites still require IE 5.5 (some even list 5.01 as the required version)...
Re: [Trinidad] how to avoid loading tr:table rows twice
In theory, the table could detect that it contains no EditableValueHolders,
no ShowDetails, and no ActionSource components, and decline to run decode(),
etc. - but that'd break any third-party components that wanted to go into
the table, had events, and weren't one of these known types.
-- Adam
On 9/6/07, Vadim Dmitriev [EMAIL PROTECTED] wrote:
Hi, Renzo.
I don't think any component would do such a thing internally. After all,
component just evaluate EL and can't figure out, when it is undesired.
As a solution I can recommend you to use
FacesContext.getCurrentInstance().getRenderResponse() to detect, when
getter is called during renderResponse phase:
public Object getSomeVal()
{
if( _someField != null
FacesContext.getCurrentInstance().getRenderResponse() )
{
_someField = getDataFromSlowExternalSource();
}
return _someField;
}
In the following code snippet, request to some external data source will
be issued only once in the renderResponse phase.
Renzo Tomaselli wrote:
Hi all, in all cases where a readonly tr:table is involved - and
needed data are to be loaded from the business layer - then this
occurs twice.
Once during restore view (decode) and again during rendering (encode).
The first time is fairly useless for a readonly component, but the
overall doubling can be expensive while loading from a complex
business layer (e.i. a db).
AFAIK this is a JSF side-effect which should affect all components,
not a Trinidad issue. Trees are affected by the same problem as they
are typically readonly.
I just wonder if anybody else got the same conclusion and there is any
workaround.
The only one I can think about concerns detecting current phase and
skipping loading while restoring a view (e .g. returning null as a
value attribute, or at least an empty collection).
Any better suggestion ?
Re: [Trinidad] Warning: Illegal HTML... should be reported?
Indeed - you can't put the subform there. It also seems extremely odd that
you'd want each input component to be in its own subform.
-- Adam
On 9/6/07, Matt Cooper [EMAIL PROTECTED] wrote:
If possible, I would suggest swapping the order of the tr:panelFormLayout
and tr:subform tags. That should correct the invalid HTML problems since I
suspect the inputText components are expecting to be direct children of the
panelFormLayout.
Thank you,
Matt
On 9/6/07, Vadim Dmitriev [EMAIL PROTECTED] wrote:
Fair enough :)
Seems that each component in tr:subform that is placed into
tr:panelFormLayout produces two html warnings.
Here is jsf page:
f:view
tr:form
tr:panelFormLayout
tr:subform
tr:inputText /
/tr:subform
/tr:panelFormLayout
/tr:form
/f:view
Produces (inline; i think it's necessary to send it as an attachment):
!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01//EN
http://www.w3.org/TR/html4/loose.dtd;!--Start:
org.apache.myfaces.trinidad.Document [_idJsp0]--html dir=ltr
lang=en
head
meta name=generator content=Apache Trinidad
link rel=stylesheet charset=UTF-8 type=text/css
href=/ru.bpc.sandbox.trinidad/adf/styles/cache/rast-
desktop-1349468388-en-gecko.cssscript
type=text/javascriptvar _AdfWindowOpenError='A popup window blocker
has been detected in your browser. Popup blockers interfere with the
operation of this application. Please disable your popup blocker or
allow popups from this site.';/scriptscript type=text/javascript
src=/ru.bpc.sandbox.trinidad/adf/jsLibs/DebugCommon1_0_2.js/scriptscript
type=text/javascript_defaultTZ()/script/head
!--Start: org.apache.myfaces.trinidad.Document[_idJsp0]--
body onload=_checkLoad() onunload=_checkUnload(event)div
id=_pprBlockingDiv onclick=return _pprConsumeClick(event);
style=position:absolute;left:0;top:0;width:0;height:0;cursor:wait;
onkeydown=return false; onkeyup=return false; onmousedown=return
false; onmouseup=return false; onkeypress=return false;/diva
name=top/a
noscriptThis page uses JavaScript and requires a JavaScript
enabled browser.Your browser is not JavaScript enabled./noscript
!--Start: org.apache.myfaces.trinidad.Form[_idJsp1]--
form id=_idJsp1 name=_idJsp1 style=margin:0px method=POST
onkeypress=return _submitOnEnter(event,'_idJsp1');
action=/ru.bpc.sandbox.trinidad/faces/applicationform1.jsp!--Start:
org.apache.myfaces.trinidad.Panel[_idJsp2]--div
class=af_panelFormLayouttable cellpadding=0 cellspacing=0
border=0 summary= style=width: autotbodytr
td class=af_panelFormLayout_column colspan=1table
cellpadding=0 cellspacing=0 border=0 width=100%
summary=tbodytr
td/td
td/td
/trtr
td/td
td
class=af_panelFormLayout_content-cell!--INVALID HTML:--!--Start:
org.apache.myfaces.trinidad.Input[_idJsp4]--tr
id=_idJsp3:_idJsp4__xc_
td class=af_inputText_label nowrapspan
id=_idJsp3:_idJsp4::icon style=display:none;a
name=_msgAnc__idJsp3:_idJsp4 title=Error
class=AFErrorIconStyleX/a/span/td
td valign=top nowrap
class=AFContentCell!--Start:
org.apache.myfaces.trinidad.Input[_idJsp4]--input
id=_idJsp3:_idJsp4 name=_idJsp3:_idJsp4 class=af_inputText_content
size=30 type=text/td
/tr!--INVALID HTML:--!--Start:
org.apache.myfaces.trinidad.Input[_idJsp4]--tr
td/td
td class=AFComponentMessageCell!--Start:
org.apache.myfaces.trinidad.Input[_idJsp4]--span
class=OraInlineInfoTextspan id=_idJsp3:_idJsp4::msg
style=display:none; class=OraInlineErrorText/span/span/td
/tr/td
/tr/tbody/table/td
/tr/tbody/table/divinput type=hidden
name=org.apache.myfaces.trinidad.faces.FORM value=_idJsp1!--Start:
org.apache.myfaces.trinidad.Form--span id=__idJsp1_Postscriptinput
type=hidden name= org.apache.myfaces.trinidad.faces.STATE
value=!1script type=text/javascriptfunction
__idJsp1Validator(){return true;}var
_idJsp1_SF={_idJsp3:1};/script/spanscript
type=text/javascript_submitFormCheck();/script/form
/body
!--Created by Apache Trinidad (Apache MyFaces Trinidad API -
1.0.2/Apache MyFaces Trinidad Impl - 1.0.2 ), skin:rast.desktop
(rast)--/html
Thanks.
Danny Robinson wrote:
If you can supply the source page snippet and the rendered output we
should be able to figure out if there's a problem to report.
Thx,
Danny
On 9/6/07, * Vadim Dmitriev* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Hi.
I was making up yet another page when noticed that when i open it
in the
browser about 10-15 warning got printed to console:
Re: Trinidad 1.2.1: SelectOrderShuttle leading/trailingDescShown Fails For Me
No, it will not be in 1.2.2. It'll be in 1.0.3 and 1.2.3.
-- Adam
On 9/4/07, Gregg Leichtman [EMAIL PROTECTED] wrote:
Agreed. The port to Trinidad did _not_ cause this problem. My initial
diagnosis was incorrect and your point on Tiles demonstrating the problem is
the correct diagnosis.
Are you in a position to say if this fix will make it into 1.2.2?
-= Gregg =-
Adam Winer wrote:
Oh, absolutely, it's a bug, and we'll apply the fix you've provided.
I'm just pointing out that it's a really long-standing one, and that:
'This worked fine in ADF Faces before
porting to Trinidad where the listName was just shuttle1:leading.
Note, however, that Trinidad now adds an additional content prefix'
... isn't quite right, since the bug existed in ADF Faces too,
and Trinidad doesn't add the content prefix itself.
-- Adam
On 9/4/07, Gregg Leichtman [EMAIL PROTECTED] wrote:
Having thought about this following your FYI (thank you for the hint), I
realized that Tiles must indeed be adding a tiles name prefix to the
name and ID attributes. The shuttle component is in a tile whose
definition name is, not surprisingly, content.
Given this, however, I still would classify this behavior in Trinidad as
a bug based on the following reasoning. The component code that is
generating the JavaScript variables:
content_shuttle1_leading_desc
content_shuttle1_trailing_desc
appears to use a global replace of underscore for colon (I didn't check
the Java code for this, but it seems reasonable based upon the generated
ID); however, the code in the generated JavaScript function
TrShuttleProxy._getDescArray that searches for an element match via ID
uses a single or first replace of underscore for colon. This
inconsistency in the handling of the modification of element IDs will
always cause a problem for any code, Tiles or otherwise that adds
something with a colon to the ID.
Therefore, I would re-categorize this as an integration bug instead of a
general Trinidad bug, but I would suggest that it is still a bug in
Trinidad that should be fixed. If nothing else, I will need to,
hopefully temporarily, create a duplicate TrShuttleProxy._getDescArray
function with the suggested patch in order to get this functionality to
work with Tiles or alternatively modify the Java generation code,
something I would rather not do, since the latter interferes with easy
upgrades.
Do you agree that this is a bug and that it should be fixed?
-= Gregg
=-
Adam Winer wrote:
Gregg,
FYI, I don't think Trinidad is adding the content:. Perhaps
Tiles 2.0 is (I've not looked at the newer version).
-- Adam
On 9/3/07, Gregg Leichtman [EMAIL PROTECTED] wrote:
I have found a bug in the generated JavaScript for the
Select*Shuttle
components. A patch follows:
TrShuttleProxy._getDescArray = function(listName) {
// var descArray = window[listName.replace(':','_') + '_desc'];
var descArray = window[listName.replace (/:/g,'_') + '_desc']; //
gsl fix
return descArray;
}
where listName is content:shuttle1:leading.
The problem is that the listName is not using a global replace;
therefore
only the first ':' is being replaced. This worked fine in ADF Faces
before
porting to Trinidad where the listName was just shuttle1:leading.
Note,
however, that Trinidad now adds an additional content prefix to the
generated inline JavaScript variables:
content_shuttle1_leading_desc=new Array('The First Item
Desc',
'The Second Item Desc',
'The Third Item Desc','');
content_shuttle1_trailing_desc=new Array('');
This means that a global replace needs to be done to create the
proper
variable name for matching in the JavaScript code. I will report this
on
Jira for the Trinidad project.
I don't have access to the latest snapshots. The last one I see is
from
July 11th at:
http://people.apache.org/repo/m2-snapshot-repository/org/apache/myfaces/trinidad/trinidad-impl/1.2.1-SNAPSHOT/
If this has been fixed already, then please clear my bug report
which
should have the side benefit of letting people know that the bug has
been
found and fixed already.
-= Gregg =-
Re: Trinidad 1.2.1: SelectOrderShuttle leading/trailingDescShown Fails For Me
Or, rather, it will if we get a JIRA issue on it...
-- Adam
On 9/5/07, Adam Winer [EMAIL PROTECTED] wrote:
No, it will not be in 1.2.2. It'll be in 1.0.3 and 1.2.3.
-- Adam
On 9/4/07, Gregg Leichtman [EMAIL PROTECTED] wrote:
Agreed. The port to Trinidad did _not_ cause this problem. My initial
diagnosis was incorrect and your point on Tiles demonstrating the problem is
the correct diagnosis.
Are you in a position to say if this fix will make it into 1.2.2?
-= Gregg =-
Adam Winer wrote:
Oh, absolutely, it's a bug, and we'll apply the fix you've provided.
I'm just pointing out that it's a really long-standing one, and that:
'This worked fine in ADF Faces before
porting to Trinidad where the listName was just shuttle1:leading.
Note, however, that Trinidad now adds an additional content prefix'
... isn't quite right, since the bug existed in ADF Faces too,
and Trinidad doesn't add the content prefix itself.
-- Adam
On 9/4/07, Gregg Leichtman [EMAIL PROTECTED] wrote:
Having thought about this following your FYI (thank you for the hint),
I
realized that Tiles must indeed be adding a tiles name prefix to the
name and ID attributes. The shuttle component is in a tile whose
definition name is, not surprisingly, content.
Given this, however, I still would classify this behavior in Trinidad
as
a bug based on the following reasoning. The component code that is
generating the JavaScript variables:
content_shuttle1_leading_desc
content_shuttle1_trailing_desc
appears to use a global replace of underscore for colon (I didn't
check
the Java code for this, but it seems reasonable based upon the
generated
ID); however, the code in the generated JavaScript function
TrShuttleProxy._getDescArray that searches for an element match via ID
uses a single or first replace of underscore for colon. This
inconsistency in the handling of the modification of element IDs will
always cause a problem for any code, Tiles or otherwise that adds
something with a colon to the ID.
Therefore, I would re-categorize this as an integration bug instead of
a
general Trinidad bug, but I would suggest that it is still a bug in
Trinidad that should be fixed. If nothing else, I will need to,
hopefully temporarily, create a duplicate TrShuttleProxy._getDescArray
function with the suggested patch in order to get this functionality
to
work with Tiles or alternatively modify the Java generation code,
something I would rather not do, since the latter interferes with easy
upgrades.
Do you agree that this is a bug and that it should be fixed?
-=
Gregg =-
Adam Winer wrote:
Gregg,
FYI, I don't think Trinidad is adding the content:. Perhaps
Tiles 2.0 is (I've not looked at the newer version).
-- Adam
On 9/3/07, Gregg Leichtman [EMAIL PROTECTED] wrote:
I have found a bug in the generated JavaScript for the
Select*Shuttle
components. A patch follows:
TrShuttleProxy._getDescArray = function(listName) {
// var descArray = window[listName.replace(':','_') + '_desc'];
var descArray = window[listName.replace (/:/g,'_') + '_desc'];
// gsl fix
return descArray;
}
where listName is content:shuttle1:leading.
The problem is that the listName is not using a global replace;
therefore
only the first ':' is being replaced. This worked fine in ADF Faces
before
porting to Trinidad where the listName was just shuttle1:leading.
Note,
however, that Trinidad now adds an additional content prefix to
the
generated inline JavaScript variables:
content_shuttle1_leading_desc=new Array('The First Item
Desc',
'The Second Item Desc',
'The Third Item Desc','');
content_shuttle1_trailing_desc=new Array('');
This means that a global replace needs to be done to create the
proper
variable name for matching in the JavaScript code. I will report
this on
Jira for the Trinidad project.
I don't have access to the latest snapshots. The last one I see is
from
July 11th at:
http://people.apache.org/repo/m2-snapshot-repository/org/apache/myfaces/trinidad/trinidad-impl/1.2.1-SNAPSHOT/
If this has been fixed already, then please clear my bug report
which
should have the side benefit of letting people know that the bug
has been
found and fixed already.
-= Gregg =-
Re: [Trinidad] Large difference in generated ID between UIXComponentBase and UIComponentBase
I don't see how or why this is wrong... _genId should get state
saved, so I don't understand why you're having problems unless
your custom component has overridden state saving incorrectly.
I've never seen a problem like this with any of our Trinidad components.
-- Adam
On 9/5/07, Andrew Robinson [EMAIL PROTECTED] wrote:
I am wondering if this is a bug or planned with UIXComponentBase:
I was noticing that my custom component that extended CoreCommandLink
stopped working after a partial update. When trying to figure out why,
I noticed that the ID of the link changed between rendering and
therefore the decode no longer worked.
On first page rendering, the link ID was _id44. During decode, it was
still _id44. During encode, it was _id108. It failed partial update
because the ID changed, and therefore all further decodes failed since
the client was now out of sync from the server.
In UIComponentBase.getClientId, if the getId() returns null, a new ID
is created and then setId is called. UIXComponentBase never calls
setId, but instead caches it in a _genId property using the
FacesBean.
Therefore, anything extending UIComponentBase and has a generated ID
will never have its ID change between requests on the same view.
However, it seems that UIXComponentBase does not guarantee that a
component with a generated ID will have a consistent ID.
Here is my code:
tr:panelLabelAndMessage
label=Test help
tr:inputText id=testHelp value=#{testHelpText}
simple=true /
f:facet name=end
cw:helpIcon for=testHelp
messageId=test_help /
/f:facet
/tr:panelLabelAndMessage
The cw:helpIcon extends CoreCommandLink
If I give the helpIcon a hard coded ID, it works fine.
Is this a bug, a shortcoming, or just not supported with UIXComponentBase?
I seems like it could be a very big source of problems if IDs change
between requests, as decodes will have a lot of problems. Should
UIXComponentBase be calling setId after generating an ID in the
getClientId function?
This was found on 1.0.3-SNAPSHOT
Any ideas?
Thanks,
Andrew
Re: [Trinidad] Large difference in generated ID between UIXComponentBase and UIComponentBase
On 9/5/07, Andrew Robinson [EMAIL PROTECTED] wrote: Last notes on the night. I have been trying many different configurations and debugging more. I eventually got the client state to save correctly and the view to restore correctly by using: context-param param-nameorg.apache.myfaces.trinidad.CLIENT_STATE_METHOD/param-name param-valueall/param-value /context-param This is not likely relevant. context-param param-nameorg.apache.myfaces.trinidad.CACHE_VIEW_ROOT/param-name param-valuefalse/param-value /context-param This second one is likely the relevant one. This disables an optimization that gives Facelets some problems, though generally only when transient components are in the page - specifically, Facelets template text. The problem is that facelets then kept re-building the view between the execution of my action and the rendering of the view, which is very odd since my action and outcome were null. Indeed odd, and suggestive of something else going seriously wrong that's leading you down this path. So I tried the following parameter, as that is where the facelets code was switching on its value to rebuild the view: context-param param-namefacelets.BUILD_BEFORE_RESTORE/param-name param-valuetrue/param-value /context-param Once I did that I keep getting this exception: Don't set this - it's an experimental flag, and just sending you further from the issue. (No idea why it's generating this exception). -- Adam 22:53:59,902 ERROR [DebugPageHandler] redirecting to debug page java.lang.ClassCastException: [Ljava.lang.Object; cannot be cast to java.lang.String at org.apache.myfaces.trinidad.bean.util.StateUtils.restoreKey(StateUtils.java:73) at org.apache.myfaces.trinidad.bean.util.StateUtils.restoreState(StateUtils.java:142) at org.apache.myfaces.trinidad.bean.util.FlaggedPropertyMap.restoreState(FlaggedPropertyMap.java:194) at org.apache.myfaces.trinidad.bean.FacesBeanImpl.restoreState(FacesBeanImpl.java:327) at org.apache.myfaces.trinidad.component.UIXComponentBase.restoreState(UIXComponentBase.java:860) at org.apache.myfaces.trinidad.component.UIXComponentBase.processRestoreState(UIXComponentBase.java:838) at javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:722) at org.apache.myfaces.trinidad.component.TreeState.restoreState(TreeState.java:96) at org.apache.myfaces.trinidad.component.UIXComponentBase.processRestoreState(UIXComponentBase.java:832) at org.apache.myfaces.trinidad.component.TreeState.restoreState(TreeState.java:96) at org.apache.myfaces.trinidad.component.UIXComponentBase.processRestoreState(UIXComponentBase.java:832) at org.apache.myfaces.trinidad.component.TreeState.restoreState(TreeState.java:96) at org.apache.myfaces.trinidad.component.UIXComponentBase.processRestoreState(UIXComponentBase.java:832) at javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:722) at org.apache.myfaces.trinidadinternal.application.StateManagerImpl.restoreView(StateManagerImpl.java:550) at com.sun.facelets.FaceletViewHandler.restoreView(FaceletViewHandler.java:345) at org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl.restoreView(ViewHandlerImpl.java:266) at org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:81) at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:95) at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:70) There seems to be some power struggle between facelets 1.1.11 and Trinidad 1.0.3, but I haven't yet been able to figure out what is going on that is causing all the issues. I have to give up for tonight. Hopefully the morning will shed some light, but I think at this point I need help from the Trinidad and Facelets team. On 9/5/07, Andrew Robinson [EMAIL PROTECTED] wrote: Okay, I could really use some help, and I am confused on the Trinidad code and how it is supposed to work. I stepped through the code on a PPR partial submit restore view. And the code that starts to seem fishy is the StateManagerImpl$PageState.popRoot(FacesContext) function. Code as follows: UIViewRoot newRoot = (UIViewRoot) fc.getApplication().createComponent(UIViewRoot.COMPONENT_TYPE); // must call restoreState so that we setup attributes, listeners, // uniqueIds, etc ... newRoot.restoreState(fc, viewRootState); // we need to use a temp list because as a side effect of // adding a child to a UIComponent, that child is removed from // the parent UIComponent. So the following will break: // newRoot.getChildren().addAll(root.getChildren()); // because root's
Re: [Trinidad] Large difference in generated ID between UIXComponentBase and UIComponentBase
On 9/5/07, Andrew Robinson [EMAIL PROTECTED] wrote:
Okay, I could really use some help, and I am confused on the Trinidad
code and how it is supposed to work.
I stepped through the code on a PPR partial submit restore view. And
the code that starts to seem fishy is the
StateManagerImpl$PageState.popRoot(FacesContext) function.
Code as follows:
UIViewRoot newRoot = (UIViewRoot)
fc.getApplication().createComponent(UIViewRoot.COMPONENT_TYPE);
// must call restoreState so that we setup attributes, listeners,
// uniqueIds, etc ...
newRoot.restoreState(fc, viewRootState);
// we need to use a temp list because as a side effect of
// adding a child to a UIComponent, that child is removed from
// the parent UIComponent. So the following will break:
// newRoot.getChildren().addAll(root.getChildren());
// because root's child List is being mutated as the List
// is traversed.
ListUIComponent temp = new
ArrayListUIComponent(root.getChildCount());
temp.addAll(root.getChildren());
newRoot.getChildren().addAll(temp);
return newRoot;
As you can see, the state of the new UIViewRoot is restored, then the
children are added to the view root before this function returns, but
neither the restoreState nor the processRestoreState functions are
ever called on the children.
This is the CACHE_VIEW_ROOT optimization. BTW, this
optimization *has* been tested with Facelets, though not
intensively with especially recent versions.
As a result the view is never restored fully. That is where I am
getting the problem.
No, it should be fully restored - all the children from the prior
request should still be there.
My configuration:
Facelets 1.1.11
Trinidad 1.0.3-SNAPSHOT
Seam 1.2.1
MyFaces 1.1.5
View root: the one Trinidad installs
ALTERNATE_VIEW_HANDLER: my own custom view handler that extends
SeamFaceletViewHandler which in tern extends FaceletViewHandler.
State saving method is client.
Using *.jsf view mapping with .xhtml file suffixes.
Trinidad's USE_APPLICATION_VIEW_CACHE parameter set to false.
setting the facelets BUILD_BEFORE_RESTORE parameter to true actually
fixes the error, but that is simply because the simple view I am in
really has no real state to store. But even with this set, the
children of UIViewRoot never have their state restored.
My custom view handler creates my on view root that extends
UIViewRoot, but I don't touch any of the state methods.
Looking in the client HTML, it gets a bit fishy as well. This is what I found:
span id=_mainForm_Postscript
input type=hidden value=!-1f9a06ef
name=org.apache.myfaces.trinidad.faces.STATE/
That value seems incredible small for a view state.
That's because its a token. Not the full state.
I have tried server side state saving and have gotten the same result.
The code that seems very wrong in terms of it shouldn't be executed
ins in StateManagerImpl.java:
UIViewRoot root = viewState.popRoot(context); // bug 4712492
if (root != null)
{
_LOG.finer(UIViewRoot for token {0} already exists. Bypassing
restoreState, token);
return root;
}
This always is true on my PPR requests and seems to be the cause of
the state never being restored.
It's actually a really valuable optimization, especially for PPR.
-- Adam
While in debug mode, if I force the root to be null, then everything
works. I really don't know for sure, but the above code seems to
completely break the restoring of the view state with the
configuration I have.
On 9/5/07, Andrew Robinson [EMAIL PROTECTED] wrote:
TreeState.saveState(FacesContext, UIXComponentBase) is being called, but
TreeState.restoreState(FacesContext, UIXComponentBase) is never called.
I'll have to look into this to see if it is something I caused or not.
Does Trinidad depend on a custom UIViewRoot implementation (I have my
own and a custom view handler that are worth looking into as the
source of the issue)?
On 9/5/07, Andrew Robinson [EMAIL PROTECTED] wrote:
It works fine outside of the facet,
Broken:
tr:panelLabelAndMessage
label=Test help
tr:inputText id=testHelp value=#{testHelpText}
simple=true /
f:facet name=end
cw:helpIcon for=testHelp
messageId=test_help /
/f:facet
/tr:panelLabelAndMessage
Works:
tr:panelLabelAndMessage
label=Test help
tr:inputText id=testHelp value=#{testHelpText}
simple=true /
/tr:panelLabelAndMessage
cw:helpIcon for=testHelp
messageId=test_help /
Looks like a possible bug in the state saving of facets or at least in
the panelLabelAndMessage. Any ideas?
Re: [TRINIDAD] Proposal - fieldset/legend component
Yep, I agree that the Layout suffix shouldn't be there. I'm wondering if we want a name more abstracted from the HTML fieldset concept, though none really come to mind. Or, as a perhaps more radical suggestion, could this be something embedded inside panelFormLayout? Like if we supported caption on af:group? af:panelFormLayout af:group caption=Personal Details af:inputText.../ /af:group /af:panelFormLayout This has some major disadvantages, though. It's probably significantly harder to implement (more grunge in the already grungy PanelFormLayout code) and no way to use it outside of panelFormLayout. So I've probably just talked myself out of this suggestion. :) -- Adam On 8/30/07, Simon Lessard [EMAIL PROTECTED] wrote: Hello Danny, True, panelBox does not include the Layout suffix (a fact I somehow forgotten / overlooked), so stripping the Layout suffix is fine with me. I like the attribute shortcut for the legend as well. ~ Simon On 8/30/07, Danny Robinson [EMAIL PROTECTED] wrote: I knocked together this component to see what it would look like and what skin selectors would be required. Here's some tag examples and an attached screenshot. FWIW while Simon's name suggestion was better, I'm not fan of the 'Layout' suffix, as it doesn't actually perform layout, and is therefore closer in functionality to panelBox. tr:panelFieldsetLayout captionText=Personal Details tr:panelFormLayout tr:inputText label=First Name / tr:inputText label=Middle Initial columns=1/ tr:inputText label=Family Name / tr:selectOneChoice label=Suffix / /tr:panelFormLayout /tr:panelFieldsetLayout OR tr:panelFieldsetLayout captionText=This shouldn't appear f:facet name=caption tr:icon name=error / /f:facet tr:inputDate label=Date of Birth / /tr:panelFieldsetLayout Thoughts anyone, D. On 8/29/07, Simon Lessard [EMAIL PROTECTED] wrote: Hello Danny, I would prefer something along the lines of tr:panelFieldSetLayout with a legend facet. Regards, ~ Simon On 8/29/07, Danny Robinson [EMAIL PROTECTED] wrote: Would there be interest in a skinnable/ajaxified component that rendered output using html fieldset/legend. We'd like to include this in our applications and I'm keen to keep our users away from introducing other component libraries just for the odd extra component. I'm struggling to think of a nice sounding tag name, other than tr:panelBoxAndLegend but it could look something like: tr:panelBoxAndLegend title=The legend ... /tr:panelBoxAndLegend Thanks, Danny -- Chordiant Software Inc. www.chordiant.com -- Chordiant Software Inc. www.chordiant.com
Re: trinidad outputFormat and f:param support
-0.5; outputText performance is really critical to overall performance,
and even adding a boolean attribute slows it down a bit.
-- Adam
On 9/4/07, Danny Robinson [EMAIL PROTECTED] wrote:
Should we look at providing this variable replacement functionality into
outputText. Although I'm against just parsing the text by default, as this
would just add unnecessary parsing in 99% of the cases. Should we instead
look at an extra attribute that forces parsing of the string for variable
substitution.
Danny
On 9/4/07, Adam Winer [EMAIL PROTECTED] wrote:
BTW, for all of these examples, you should just use tr:outputText
instead of tr:outputFormatted.
outputFormatted really has nothing to do with outputFormat.
What tr:outputFormatted gives you is support for (a subset of)
HTML formatting without opening the security hole of
escape=false.
-- Adam
On 8/30/07, Andrew Robinson [EMAIL PROTECTED] wrote:
Well you could do:
tr:outputFormatted value=#{myfunc:format2(str, arg1, arg2)} /
where you could write format1, format2, etc. EL functions to do the
work.
You could also do:
t:buffer into=#{formattedString}
h:outputFormat value=#{message.key}
f:param value=param1 /
/h:outputFormat
/t:buffer
tr:outputFormatted value=#{formattedString} /
On 8/30/07, Paul Mander [EMAIL PROTECTED] wrote:
Andrew Robinson-5 wrote:
Well, that is not localizable
I think the use case that he means is more like:
tr:outputFormatted value=#{messages.str}
f:param value=#{myarg} /
/tr:outputFormatted
messages.properties
str = Test {0} param
That's a better example.
--
View this message in context:
http://www.nabble.com/trinidad-outputFormat-and-f%3Aparam-support-tf4347417.html#a12401317
Sent from the MyFaces - Users mailing list archive at Nabble.com.
--
Chordiant Software Inc.
www.chordiant.com
Re: [Trinidad] Trinidad 1.2.1 demo on Tomcat 6.0.13
It is missing, but the bug is that the TLD claims it's required. That got fixed in 1.0.2/1.2.2. -- Adam On 9/4/07, Gregg Leichtman [EMAIL PROTECTED] wrote: The text attribute is indeed missing for the panelHeader tag on line 106 of the progressSteps.jspx file. Fixing this might fix the entire problem. -= Gregg =- Gregg Leichtman wrote: I happen to have the Trinidad 1.2.1 demo running in Tomcat 6.0.13. I had not looked at the Progress Steps demo before. When I did, I got the following: org.apache.jasper.JasperException: /demos/progressSteps.jspx(106,30) According to the TLD or the tag file, attribute text is mandatory for tag panelHeader org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:40) org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:407) org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:236) org.apache.jasper.compiler.Validator$ValidateVisitor.visit(Validator.java:802) org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1507) org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2336) org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2386) org.apache.jasper.compiler.Validator$ValidateVisitor.visit(Validator.java:838) ... I did things a little differently than described below. I opened the war and inserted the same JSF version files as described below along with JSTL 1.1.2 into the WEB-INF/libs folder, jarred up the contents into a new war and dropped this into the Tomcat webapps folder. The result is as stated above. Maybe the difference in error output will be helpful. -= Gregg =- Adam Winer wrote: This doesn't make much sense to me. That line is a tr:forEach element. In 1.2.1, the tld for forEach has attribute description the ending index /description nameend/name deferred-value typejava.lang.Integer/type /deferred-value /attribute ... so end absolutely supports EL. Whether there's a Tomcat bug or a setup issue here, I don't know. -- Adam On 8/30/07, Thai Dang Vu [EMAIL PROTECTED] wrote: Hi everybody, I dropped the trinidad 1.2.1 demo war file in the webapps folder of Tomcat 6, run tomcat so that it deployed that war file, stopped tomcat to dropped jsf-impl-1.2_04-p02.jar, jsf-api-1.2_04-p02.jar and jstl-1.2.jar in the trinidad-1.2.1-demo/WEB-INF/lib folder, started tomcat again and the Component Guide worked, but the Progress Step Demo didn't. This is the error: org.apache.jasper.JasperException: /demos/progressSteps.jspx(68,58) According to TLD or attribute directive in tag file, attribute end does not accept any expressions org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHand ler.java:40) org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java :407) org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java :148) org.apache.jasper.compiler.Validator$ValidateVisitor.checkXmlAttributes( Validator.java:1119) org.apache.jasper.compiler.Validator$ValidateVisitor.visit(Validator.jav a:819) org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1507) org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2336) org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2386) org.apache.jasper.compiler.Validator$ValidateVisitor.visit(Validator.jav a:838) org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1507) org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2336) org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2386) org.apache.jasper.compiler.Validator$ValidateVisitor.visit(Validator.jav a:838) org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1507) org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2336) org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2386) org.apache.jasper.compiler.Validator$ValidateVisitor.visit(Validator.jav a:838) org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1507) org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2336) org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2386) org.apache.jasper.compiler.Validator$ValidateVisitor.visit(Validator.jav a:838) org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1507) org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2336) org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2386) org.apache.jasper.compiler.Validator$ValidateVisitor.visit(Validator.jav a:838) org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1507) org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2336) org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2386) org.apache.jasper.compiler.Validator$ValidateVisitor.visit(Validator.jav a:838) org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1507) org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2336
Re: [Trinidad] force reload and add message for partial update request and view has expired?
View expiry generally stinks in JSF 1.1; in 1.2, there's a ViewExpiredException, so the user should currently see an alert. That's not great - ideally, the main page would refresh or redirect automatically. I'm disinclined to tackle view expiry in JSF 1.1, as it's generally just badly broken there. -- Adam On 8/31/07, Andrew Robinson [EMAIL PROTECTED] wrote: Correct me if I am wrong, but it seems that if a view has expired, and someone initiates a partial update, the page is just updated as if it hadn't. This is quite confusing to the user as nothing happens when they click on a link. What I would like to have happen, is the user redirected to the requested view and be able to add a FacesMessage stating that the view had expired. Has anyone done this or is it built in somewhere and I have just missed it? Example: Go to the trinidad demo, go into the component demo. Walk away from it for a while. Click one of the links (like the component demo link). Nothing happens. A second click works (since now the user has a view in the back-end). Thanks, Andrew
Re: Trinidad 1.2.1: SelectOrderShuttle leading/trailingDescShown Fails For Me
Gregg,
FYI, I don't think Trinidad is adding the content:. Perhaps
Tiles 2.0 is (I've not looked at the newer version).
-- Adam
On 9/3/07, Gregg Leichtman [EMAIL PROTECTED] wrote:
I have found a bug in the generated JavaScript for the Select*Shuttle
components. A patch follows:
TrShuttleProxy._getDescArray = function(listName) {
// var descArray = window[listName.replace(':','_') + '_desc'];
var descArray = window[listName.replace(/:/g,'_') + '_desc']; // gsl fix
return descArray;
}
where listName is content:shuttle1:leading.
The problem is that the listName is not using a global replace; therefore
only the first ':' is being replaced. This worked fine in ADF Faces before
porting to Trinidad where the listName was just shuttle1:leading. Note,
however, that Trinidad now adds an additional content prefix to the
generated inline JavaScript variables:
content_shuttle1_leading_desc=new Array('The First Item
Desc',
'The Second Item Desc',
'The Third Item Desc','');
content_shuttle1_trailing_desc=new Array('');
This means that a global replace needs to be done to create the proper
variable name for matching in the JavaScript code. I will report this on
Jira for the Trinidad project.
I don't have access to the latest snapshots. The last one I see is from
July 11th at:
http://people.apache.org/repo/m2-snapshot-repository/org/apache/myfaces/trinidad/trinidad-impl/1.2.1-SNAPSHOT/
If this has been fixed already, then please clear my bug report which
should have the side benefit of letting people know that the bug has been
found and fixed already.
-= Gregg =-
Gregg Leichtman wrote:
I am trying to get the leadingDescShown and trailingDescShown attributes
to work for the Trinidad v1.2.1 SelectOrderShuttle. I have the shuttle
working for everything except for displaying the description of a
selected item in the textarea below the leading or trailing shuttle. I'm
running under Linux and Eclipse 3.3 Europa using J2EE5 with JSF 1.2 and
Tiles 2.0.4. I have a tile as follows:
%@ taglib uri=http://java.sun.com/jsf/core; prefix=f %
%@ taglib uri=http://java.sun.com/jsf/html; prefix=h %
%@ taglib uri=http://tiles.apache.org/tags-tiles;
prefix=tiles %
%@ taglib uri=http://myfaces.apache.org/tomahawk;
prefix=t %
%@ taglib uri=http://myfaces.apache.org/trinidad;
prefix=tr%
tr:form
tr:panelGroupLayout layout=vertical
f:facet name=separator
tr:separator /
/f:facet
tr:messages/
tr:selectOrderShuttle id=shuttle1
label=Selected Values
leadingHeader=Available values:
leadingDescShown=true
trailingHeader=Selected values:
trailingDescShown=true
binding=#{editor.component}
valueChangeListener=#{list.valueChanged}
value=#{list.stringArray}
tr:selectItem shortDesc=The First Item Desc
longDesc=Long Desc 1 label=First value=foo/
tr:selectItem shortDesc=The Second Item Desc
longDesc=Long Desc 2 label=Second value=bar/
tr:selectItem shortDesc=The Third Item Desc
longDesc=Long Desc 3 label=Third value=baz/
/tr:selectOrderShuttle
tr:message for=shuttle1/
tr:commandButton text=Submit/
/tr:panelGroupLayout
/tr:form
The layout page uses f:view wrapping trh:html, trh:head and trh:body.
The trh:body element wraps one of several subviews which wrap several
tiles one of which is the above tile.
An excerpt from the generated page looks like this:
...
form id=content:j_id_jsp_709084578_0pc4
name=content:j_id_jsp_709084578_0pc4 style=margin:0px
method=POST onkeypress=return
_submitOnEnter(event,'content:j_id_jsp_709084578_0pc4');
action=/tutoring/tickerManagerPage.do!--Start:
org.apache.myfaces.trinidad.Panel[j_id_jsp_709084578_1pc4]--div!--Start:
org.apache.myfaces.trinidad.Messages[j_id_jsp_709084578_3pc4]--span
id=content:j_id_jsp_709084578_3pc4/spandiv!--Start:
org.apache.myfaces.trinidad.Object[j_id_jsp_709084578_2pc4]--
hr class=af_separator
/divscriptvar _shuttle_no_items='There are no items to move.';var
_shuttle_no_items_selected='Please select the items to move
first.';/script!--Start:
org.apache.myfaces.trinidad.SelectOrder[shuttle1]--table
cellpadding=0 cellspacing=0 border=0 width=10% summary=
id=content:shuttle1 class=af_selectManyShuttletr
td class=x9u valign=bottomAvailable values:/td
td/td
td class=x9u valign=bottomSelected values:/td
/trtr
td!--Start:
org.apache.myfaces.trinidad.SelectOrder[shuttle1]--table
class=af_selectOrderShuttle_box style=width:100%
cellpadding=0 cellspacing=0 border=0 summary=tbodytr
td class=af_selectOrderShuttle_box-top-start/td
td class=af_selectOrderShuttle_box-top/td
td class=af_selectOrderShuttle_box-top-end/td
/trtr
td class=af_selectOrderShuttle_box-start/td
td class=x59div class=x55table cellpadding=0 border=0
summary=tr
td nowrap valign=middle!--Start:
org.apache.myfaces.trinidad.SelectOrder[shuttle1]--span
class=x1i
select multiple id=content:shuttle1:leading
Re: trinidad outputFormat and f:param support
I'm again at a sorta -0.5 on this; in JSF 1.2, I'd rather provide
EL functions to do formatting, since that gives you format
functionality in all components instead of just one. (ADF Faces
does just this in JDev 11). That still leaves JSF 1.1 users with
just h:outputFormat, which isn't great.
-- Adam
On 9/4/07, Andrew Robinson [EMAIL PROTECTED] wrote:
What about tr:outputFormat? This would be a direct extension of the
core h:outputFormat with the skinning, partialTriggers and other
functionality that Trinidad provides added to it?
On 9/4/07, Adam Winer [EMAIL PROTECTED] wrote:
-0.5; outputText performance is really critical to overall performance,
and even adding a boolean attribute slows it down a bit.
-- Adam
On 9/4/07, Danny Robinson [EMAIL PROTECTED] wrote:
Should we look at providing this variable replacement functionality into
outputText. Although I'm against just parsing the text by default, as
this
would just add unnecessary parsing in 99% of the cases. Should we instead
look at an extra attribute that forces parsing of the string for variable
substitution.
Danny
On 9/4/07, Adam Winer [EMAIL PROTECTED] wrote:
BTW, for all of these examples, you should just use tr:outputText
instead of tr:outputFormatted.
outputFormatted really has nothing to do with outputFormat.
What tr:outputFormatted gives you is support for (a subset of)
HTML formatting without opening the security hole of
escape=false.
-- Adam
On 8/30/07, Andrew Robinson [EMAIL PROTECTED] wrote:
Well you could do:
tr:outputFormatted value=#{myfunc:format2(str, arg1, arg2)} /
where you could write format1, format2, etc. EL functions to do the
work.
You could also do:
t:buffer into=#{formattedString}
h:outputFormat value=#{message.key}
f:param value=param1 /
/h:outputFormat
/t:buffer
tr:outputFormatted value=#{formattedString} /
On 8/30/07, Paul Mander [EMAIL PROTECTED] wrote:
Andrew Robinson-5 wrote:
Well, that is not localizable
I think the use case that he means is more like:
tr:outputFormatted value=#{messages.str}
f:param value=#{myarg} /
/tr:outputFormatted
messages.properties
str = Test {0} param
That's a better example.
--
View this message in context:
http://www.nabble.com/trinidad-outputFormat-and-f%3Aparam-support-tf4347417.html#a12401317
Sent from the MyFaces - Users mailing list archive at Nabble.com.
--
Chordiant Software Inc.
www.chordiant.com
Re: [TRINIDAD] Proposal - fieldset/legend component
On 9/4/07, Danny Robinson [EMAIL PROTECTED] wrote: Yeah, I initially went with the enhanced panelFormLayout approach and decided against it. The name is also frustrating, so how about tr:panelCaptionGroup ...? I think I like that name. -- Adam I'll give it 24hrs for other people to chime in, then I'll go with the above. Thanks, Danny On 9/4/07, Adam Winer [EMAIL PROTECTED] wrote: Yep, I agree that the Layout suffix shouldn't be there. I'm wondering if we want a name more abstracted from the HTML fieldset concept, though none really come to mind. Or, as a perhaps more radical suggestion, could this be something embedded inside panelFormLayout? Like if we supported caption on af:group? af:panelFormLayout af:group caption=Personal Details af:inputText.../ /af:group /af:panelFormLayout This has some major disadvantages, though. It's probably significantly harder to implement (more grunge in the already grungy PanelFormLayout code) and no way to use it outside of panelFormLayout. So I've probably just talked myself out of this suggestion. :) -- Adam On 8/30/07, Simon Lessard [EMAIL PROTECTED] wrote: Hello Danny, True, panelBox does not include the Layout suffix (a fact I somehow forgotten / overlooked), so stripping the Layout suffix is fine with me. I like the attribute shortcut for the legend as well. ~ Simon On 8/30/07, Danny Robinson [EMAIL PROTECTED] wrote: I knocked together this component to see what it would look like and what skin selectors would be required. Here's some tag examples and an attached screenshot. FWIW while Simon's name suggestion was better, I'm not fan of the 'Layout' suffix, as it doesn't actually perform layout, and is therefore closer in functionality to panelBox. tr:panelFieldsetLayout captionText=Personal Details tr:panelFormLayout tr:inputText label=First Name / tr:inputText label=Middle Initial columns=1/ tr:inputText label=Family Name / tr:selectOneChoice label=Suffix / /tr:panelFormLayout /tr:panelFieldsetLayout OR tr:panelFieldsetLayout captionText=This shouldn't appear f:facet name=caption tr:icon name=error / /f:facet tr:inputDate label=Date of Birth / /tr:panelFieldsetLayout Thoughts anyone, D. On 8/29/07, Simon Lessard [EMAIL PROTECTED] wrote: Hello Danny, I would prefer something along the lines of tr:panelFieldSetLayout with a legend facet. Regards, ~ Simon On 8/29/07, Danny Robinson [EMAIL PROTECTED] wrote: Would there be interest in a skinnable/ajaxified component that rendered output using html fieldset/legend. We'd like to include this in our applications and I'm keen to keep our users away from introducing other component libraries just for the odd extra component. I'm struggling to think of a nice sounding tag name, other than tr:panelBoxAndLegend but it could look something like: tr:panelBoxAndLegend title=The legend ... /tr:panelBoxAndLegend Thanks, Danny -- Chordiant Software Inc. www.chordiant.com -- Chordiant Software Inc. www.chordiant.com -- Chordiant Software Inc. www.chordiant.com
Re: [Trinidad] documentation plugin
That'd be a very useful option for the tagdoc plugin - it'd certainly make it much easier to navigate between components. -- Adam On 9/4/07, Andrew Robinson [EMAIL PROTECTED] wrote: It is really nice to have the functionality of the Trinidad plugin that generates the tag documentation, but I was wondering if it would be possible to have it generate a frames-based documentation like the TLD documentation: http://myfaces.apache.org/tomahawk/tlddoc/index.html Currently the trinidad site is very informative with the tag documentation, but it is hard to navigate between components. The frame-based approach would make it much easier to switch between documentation for different components
Re: [TRINIDAD] Proposal - fieldset/legend component
On 9/4/07, Matt Cooper [EMAIL PROTECTED] wrote: I like that name too. Should the text for it be text like on other components or caption? We already have an example of convenience-attribute+facet on column; there it's header and headerText. So perhaps the facet should be caption and the attribute captionText. -- Adam Regarding this example mentioned earlier: tr:panelFormLayout tr:panelCaptionGroup caption=Personal Details tr:inputText.../ /tr:panelCaptionGroup /tr:panelFormLayout this could potentially be supported but without the lines drawn along the sides. I'm thinking that when placed directly inside of a panelFormLayout, it could have the simple separator lines (exactly like tr:group today) but with the caption appearing on top of the upper separator line, e.g.: label1field1 -- Caption - label2field2 label3field3 label4field4 and when outside of a panelFormLayout (as in your proposal) where you don't have to play well with the table structure of the form layout, the PanelCaptionGroupRenderer will use the normal fieldset elements. Regards, Matt On 9/4/07, Adam Winer [EMAIL PROTECTED] wrote: On 9/4/07, Danny Robinson [EMAIL PROTECTED] wrote: Yeah, I initially went with the enhanced panelFormLayout approach and decided against it. The name is also frustrating, so how about tr:panelCaptionGroup ...? I think I like that name. -- Adam I'll give it 24hrs for other people to chime in, then I'll go with the above. Thanks, Danny On 9/4/07, Adam Winer [EMAIL PROTECTED] wrote: Yep, I agree that the Layout suffix shouldn't be there. I'm wondering if we want a name more abstracted from the HTML fieldset concept, though none really come to mind. Or, as a perhaps more radical suggestion, could this be something embedded inside panelFormLayout? Like if we supported caption on af:group? af:panelFormLayout af:group caption=Personal Details af:inputText.../ /af:group /af:panelFormLayout This has some major disadvantages, though. It's probably significantly harder to implement (more grunge in the already grungy PanelFormLayout code) and no way to use it outside of panelFormLayout. So I've probably just talked myself out of this suggestion. :) -- Adam On 8/30/07, Simon Lessard [EMAIL PROTECTED] wrote: Hello Danny, True, panelBox does not include the Layout suffix (a fact I somehow forgotten / overlooked), so stripping the Layout suffix is fine with me. I like the attribute shortcut for the legend as well. ~ Simon On 8/30/07, Danny Robinson [EMAIL PROTECTED] wrote: I knocked together this component to see what it would look like and what skin selectors would be required. Here's some tag examples and an attached screenshot. FWIW while Simon's name suggestion was better, I'm not fan of the 'Layout' suffix, as it doesn't actually perform layout, and is therefore closer in functionality to panelBox. tr:panelFieldsetLayout captionText=Personal Details tr:panelFormLayout tr:inputText label=First Name / tr:inputText label=Middle Initial columns=1/ tr:inputText label=Family Name / tr:selectOneChoice label=Suffix / /tr:panelFormLayout /tr:panelFieldsetLayout OR tr:panelFieldsetLayout captionText=This shouldn't appear f:facet name=caption tr:icon name=error / /f:facet tr:inputDate label=Date of Birth / /tr:panelFieldsetLayout Thoughts anyone, D. On 8/29/07, Simon Lessard [EMAIL PROTECTED] wrote: Hello Danny, I would prefer something along the lines of tr:panelFieldSetLayout with a legend facet. Regards, ~ Simon On 8/29/07, Danny Robinson [EMAIL PROTECTED] wrote: Would there be interest in a skinnable/ajaxified component that rendered output using html fieldset/legend. We'd like to include this in our applications and I'm keen to keep our users away from introducing other component libraries just for the odd extra component. I'm struggling to think of a nice sounding tag name, other than tr:panelBoxAndLegend but it could look something like: tr:panelBoxAndLegend title=The legend ... /tr:panelBoxAndLegend Thanks, Danny
Re: How to navigate on DisclosureEvent using a tr:showDetailItem
Remove from-action. There is no action here (you passed
null to the NavigationHandler!), just an outcome.
-- Adam
On 9/4/07, Rakesh Patnaik [EMAIL PROTECTED] wrote:
Hi,
my application has a panel accordion component and I need to navigate to
different pages on disclosure of each of the showDetailItem's that it holds.
For example:
tr:panelAccordion discloseNone=true
tr:showDetailItem text=PA1
disclosureListener=#{backingBean.navigateToAppPage}
tr:outputText value=detail1/
/tr:showDetailItem
tr:showDetailItem text=PA2
disclosureListener=#{backingBean.navigateToMgmtPage}
tr:outputText value=detail2/
/tr:showDetailItem
/tr:panelAccordion
I tried using NavigationHandler code in the backing bean methods as follows:
public void navigate(DisclosureEvent de){
try{
NavigationHandler navigator =
FacesContext.getCurrentInstance().getApplication().getNavigationHandler();
navigator.handleNavigation ( FacesContext.getCurrentInstance(),
null, xyz );
FacesContext.getCurrentInstance().renderResponse();
}
catch(Exception e){.}
xyz is a navigation outcome definition:
navigation-rule
navigation-case
from-outcomexyz/from-outcome
from-actionxyz/from-action
to-view-id/TestNavigation.jsp/to-view-id
redirect/
/navigation-case
/navigation-rule
but this doesnot work.
Any suggestions as to how to achieve this navigation?
Re: [Trinidad] panelLabelAndMessage still needs extra message tag?!
On 9/4/07, Stephen Friedrich [EMAIL PROTECTED] wrote:
Thanks for the info, Andrew!
Adam, will 1.2.2 contain this fix, too?
Or will you strictly only transfer fixes from 1.0._2_?
1.2.2 is exactly 1.0.2 + 1.2 changes.
Depending on how many changes there were in between 1.0.2 and 1.0.3
maybe it would make sense to skip 1.0.2 and directly go to 1.2.3?
Well, 1.2.3 really makes for a nicer version number anyhow ;-
Also releases and corresponding downloads seem to be a little mixed
up currently:
http://myfaces.apache.org/ has latest news about 1.0._1_ and 1.2.1
If you follow the download link from that main page you'll find
core, tomahawk, tobago, but no trinidad.
If you first select trinidad project then go to downloads you'll
find only 1.0.2 even though the release notes available on the
trinidad project page talk about 1.0.3.
The trinidad download page has a link to nightly builds, but I haven't
found any when following that link.
Matthias, can you look at these?
-- Adam
Andrew Robinson wrote:
Fixed in 1.0.3-SNAPSHOT
On 9/4/07, Stephen Friedrich [EMAIL PROTECTED] wrote:
After reading the tag doc for panelLabelAndMessage I would have
thought that in the following example the tr:message would not
be needed.
However if I omit the tr:message then on validation failure it
fails silently without ever showing a message.
(Trinidad 1.2.1)
tr:panelLabelAndMessage styleClass=inputLabel_10 label=#{
Output.BRANCH} showRequired=true
tr:selectOneChoice id=employeeBranchId
value=#{_employeeList.employeeBranchId} required=true unselectedLabel=
simple=true
f:selectItems
value=#{_employeeList.employeeBranchItems}/
/tr:selectOneChoice
tr:message for=employeeBranchId/
/tr:panelLabelAndMessage
Re: [Trinidad] panelLabelAndMessage still needs extra message tag?!
On 9/4/07, Stephen Friedrich [EMAIL PROTECTED] wrote: Andrew Robinson wrote: No, it requires a for attribute. That is the component that the label and the message are for. Also in 1.0.3 the code will automatically use the first EditableValueHolder it finds if the for is not given, but it still only supports one component. To get multiple components, you have to have multiple panelLabelAndMessage components. Hm, that kind of defeats the purpose of panelLabelAndMessage: I nested firstName and lastName fields in a single panelLabelAndMessage to have them shown in a single row of a form managed by panelFormLayout. Of course I'd like to show messages for both of them. How can I do that? The simplest way I can think of is to use panelLabelAndMessage containing a panelHorizontalLayout with two non-simple fields, where you haven't set the label on either (but do set the shortDesc attribute for accessibility). -- Adam Can I switch the automatic message part OFF and then add two tr:message tag (one for each input field)? Then again that would require some additional layout to get the messages to appear under the correct field. It really would be easiest to be able to have a semi-simple where the component does not manage its label, but manages its own message. simple=message-only ? BTW: The same structure repeats in my app with other pairs with other pairs (zip/city, start/end date, street/no, ...).
Re: Trinidad 1.2.1: SelectOrderShuttle leading/trailingDescShown Fails For Me
Oh, absolutely, it's a bug, and we'll apply the fix you've provided.
I'm just pointing out that it's a really long-standing one, and that:
'This worked fine in ADF Faces before
porting to Trinidad where the listName was just shuttle1:leading.
Note, however, that Trinidad now adds an additional content prefix'
... isn't quite right, since the bug existed in ADF Faces too,
and Trinidad doesn't add the content prefix itself.
-- Adam
On 9/4/07, Gregg Leichtman [EMAIL PROTECTED] wrote:
Having thought about this following your FYI (thank you for the hint), I
realized that Tiles must indeed be adding a tiles name prefix to the
name and ID attributes. The shuttle component is in a tile whose
definition name is, not surprisingly, content.
Given this, however, I still would classify this behavior in Trinidad as
a bug based on the following reasoning. The component code that is
generating the JavaScript variables:
content_shuttle1_leading_desc
content_shuttle1_trailing_desc
appears to use a global replace of underscore for colon (I didn't check
the Java code for this, but it seems reasonable based upon the generated
ID); however, the code in the generated JavaScript function
TrShuttleProxy._getDescArray that searches for an element match via ID
uses a single or first replace of underscore for colon. This
inconsistency in the handling of the modification of element IDs will
always cause a problem for any code, Tiles or otherwise that adds
something with a colon to the ID.
Therefore, I would re-categorize this as an integration bug instead of a
general Trinidad bug, but I would suggest that it is still a bug in
Trinidad that should be fixed. If nothing else, I will need to,
hopefully temporarily, create a duplicate TrShuttleProxy._getDescArray
function with the suggested patch in order to get this functionality to
work with Tiles or alternatively modify the Java generation code,
something I would rather not do, since the latter interferes with easy
upgrades.
Do you agree that this is a bug and that it should be fixed?
-= Gregg
=-
Adam Winer wrote:
Gregg,
FYI, I don't think Trinidad is adding the content:. Perhaps
Tiles 2.0 is (I've not looked at the newer version).
-- Adam
On 9/3/07, Gregg Leichtman [EMAIL PROTECTED] wrote:
I have found a bug in the generated JavaScript for the Select*Shuttle
components. A patch follows:
TrShuttleProxy._getDescArray = function(listName) {
// var descArray = window[listName.replace(':','_') + '_desc'];
var descArray = window[listName.replace(/:/g,'_') + '_desc']; // gsl
fix
return descArray;
}
where listName is content:shuttle1:leading.
The problem is that the listName is not using a global replace;
therefore
only the first ':' is being replaced. This worked fine in ADF Faces
before
porting to Trinidad where the listName was just shuttle1:leading.
Note,
however, that Trinidad now adds an additional content prefix to the
generated inline JavaScript variables:
content_shuttle1_leading_desc=new Array('The First Item
Desc',
'The Second Item Desc',
'The Third Item Desc','');
content_shuttle1_trailing_desc=new Array('');
This means that a global replace needs to be done to create the proper
variable name for matching in the JavaScript code. I will report this
on
Jira for the Trinidad project.
I don't have access to the latest snapshots. The last one I see is
from
July 11th at:
http://people.apache.org/repo/m2-snapshot-repository/org/apache/myfaces/trinidad/trinidad-impl/1.2.1-SNAPSHOT/
If this has been fixed already, then please clear my bug report which
should have the side benefit of letting people know that the bug has
been
found and fixed already.
-= Gregg =-
Re: [Trinidad] Working with large tables
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
Re: [TRINIDAD] - IMPORTANT - Custom Skin Developers
The old parameter was trinidadinternal, and therefore was never officially supported. If we were changing from one supported name to another, I'd agree that we should keep the old name around, but supporting backwards compatibility for anything trinidadinternal is a precedent I don't think we should set... -- Adam On 8/31/07, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Danny, eventually we could additionally support also the old name for the configuration parameter, and only phase this out in a major release? regards, Martin On 8/28/07, Danny Robinson [EMAIL PROTECTED] wrote: In the hope of pre-empting some emails, be aware that the trunk has switched to now use the following config setting for disabling skin compression. org.apache.myfaces.trinidadinternal.DISABLE_CONTENT_COMPRESSION became org.apache.myfaces.trinidad.DISABLE_CONTENT_COMPRESSION The docs and release notes in trunk also mention this. Thanks, Danny -- Chordiant Software Inc. www.chordiant.com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [Trinidad] Bug in XMLMenuModel / ItemNode ?
On 8/28/07, Stephen Friedrich [EMAIL PROTECTED] wrote: Should I file a jira issue? Please do. BTW: Is there a time line for 1.2.2 containing recent fixes from head? No, not really. That'll be 1.2.3, not 1.2.2. -- Adam Adam Winer wrote: Stephen, You're correct. The bug is in ItemNode.doAction(), which calls a MenuUtils.getBoundValue() function, which in turn tries to process this as a ValueBinding/ValueExpression. It's not - it's a MethodBinding/MethodExpression. -- Adam
Re: [Trinidad] - Javascript errors Integrating with JSF 1.2 RI / Facelets
servlet-mapping servlet-nameresources/servlet-name url-pattern*.jsf/url-pattern /servlet-mapping ... is wrong. It needs to be: servlet-mapping servlet-nameresources/servlet-name url-pattern/adf/*/url-pattern /servlet-mapping ... like it says at : http://myfaces.apache.org/trinidad/installation.html -- Adam On 8/29/07, Rich Schramm [EMAIL PROTECTED] wrote: Adam, See below for my web.xml as per your request. Any feedback appreciated. Rich ?xml version=1.0 encoding=UTF-8? web-app version=2.4 xmlns=http://java.sun.com/xml/ns/j2ee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd; descriptionFacelets StarterKit/description display-namemyapp/display-name context-param param-namejavax.faces.DEFAULT_SUFFIX/param-name param-value.jspx/param-value /context-param context-param param-namefacelets.REFRESH_PERIOD/param-name param-value2/param-value /context-param context-param param-namefacelets.DEVELOPMENT/param-name param-valuetrue/param-value /context-param context-param param-namejavax.faces.STATE_SAVING_METHOD/param-name param-valueserver/param-value /context-param context-param param-namecom.sun.faces.validateXml/param-name param-valuetrue/param-value /context-param context-param param-namecom.sun.faces.verifyObjects/param-name param-valuetrue/param-value /context-param context-param param-nameorg.ajax4jsf.SKIN/param-name param-valueclassic/param-value /context-param context-param param-namecom.exadel.vcp.trialKey/param-name param-valuetrial_key_goes_here/param-value /context-param !-- Trinidad Mappings -- context-param param-nameorg.apache.myfaces.trinidad.ALTERNATE_VIEW_HANDLER/param-name param-valuecom.sun.facelets.FaceletViewHandler/param-value /context-param context-param param-namefacelets.VIEW_MAPPINGS/param-name param-value*.jspx/param-value /context-param filter filter-nametrinidad/filter-name filter-classorg.apache.myfaces.trinidad.webapp.TrinidadFilter/filter-class /filter filter-mapping filter-nametrinidad/filter-name servlet-nameFaces Servlet/servlet-name dispatcherREQUEST/dispatcher dispatcherFORWARD/dispatcher dispatcherINCLUDE/dispatcher /filter-mapping servlet servlet-nameresources/servlet-name servlet-classorg.apache.myfaces.trinidad.webapp.ResourceServlet/servlet-class /servlet servlet-mapping servlet-nameresources/servlet-name url-pattern*.jsf/url-pattern /servlet-mapping !-- End Trinidad Mapping -- filter display-nameAjax4jsf Filter/display-name filter-nameajax4jsf/filter-name filter-classorg.ajax4jsf.Filter/filter-class /filter filter-mapping filter-nameajax4jsf/filter-name servlet-nameFaces Servlet/servlet-name dispatcherREQUEST/dispatcher dispatcherFORWARD/dispatcher dispatcherINCLUDE/dispatcher /filter-mapping servlet servlet-nameFaces Servlet/servlet-name servlet-classjavax.faces.webapp.FacesServlet/servlet-class load-on-startup1/load-on-startup /servlet servlet-mapping servlet-nameFaces Servlet/servlet-name url-pattern*.jsf/url-pattern /servlet-mapping /web-app From: Adam Winer [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 29, 2007 8:01 PM To: MyFaces Discussion Subject: Re: [Trinidad] - Javascript errors Integrating with JSF 1.2 RI / Facelets Could we see your web.xml? -- Adam On 8/29/07, Rich Schramm [EMAIL PROTECTED] wrote: Hi, I would like to use the color picker and calendar components in Trinidad. I am currently running JSF 1.2 RI with facelets and richfaces. I have configured the installation as per the instructions. When I display a page with the choosecolor component, it renders the table, but the transparent image is shows an error (a box with a broken image) and the javascript shows an error TrColorConverter is undefined. Additionally, when I use the requestContext palette, instead of showing the colors, it causes an exception in the page showing that the long list of AWT color elements is a string and not a list. Thinking maybe it was interference with the RichFaces tags, I created a very simple page using the demo chooseColor page in demo war. It looks like: jsp:root xmlns:jsp=http://java.sun.com/JSP/Page; version=2.0 xmlns:f=http://java.sun.com
Re: [Trinidad] ppr: partialTriggers doesn't work if there are validation messages?
This all seems like enormous overkill *just* to get messages sent down. We have Javascript that can insert messages on the client. All we need to do is lean slightly on that code to reuse it for inserting server-side messages, and this'll work fine without any architectural changes at all. -- Adam On 8/29/07, Andrew Robinson [EMAIL PROTECTED] wrote: After thinking it on some more and researching how Trinidad is handling the PPR triggers more, I thought that maybe the best solution is just a new component. I am already using such a component in my own project for a site I own. I just posted the code to JIRA so that you all can see it, comment on it and decide if you would like to have it as a core component of Trinidad. The issue: https://issues.apache.org/jira/browse/TRINIDAD-663 -Andrew
Re: [Trinidad] tr:messages - EL expressions in components' labels are not evaluated
I see what's going on: this looks like a recent bug introduced in the
new MessageBoxRenderer. I've filed:
https://issues.apache.org/jira/browse/TRINIDAD-679
-- Adam
On 9/3/07, Vadim Dmitriev [EMAIL PROTECTED] wrote:
Small follow-up: seems that labels are displayed correctly while client-side
validation processes errors. When server-side validation kicks in -
tr:messages labels turn to EL
Hi.
tr:messages by default outputs messages in form label - massage. In my
application I actively use EL expressions in components labels. Problem is
that these labels got printed by tr:messages like this EL expressions are
simple strings.
For example #{resourceBundle['some.label']} - value required instead of
Some label - value required.
I tried different properties files locales/faces-config locale
configuration and somehow it began to work. When i was searching for exact
step that managed to fix that error, i broke it again and now it doesn't
work at all.
Have anybody experienced such problems? Maybe I miss some required
configuration?
Thanks.
Re: [Trinidad] Trinidad 1.2.1 demo on Tomcat 6.0.13
This doesn't make much sense to me. That line is a tr:forEach element. In 1.2.1, the tld for forEach has attribute description the ending index /description nameend/name deferred-value typejava.lang.Integer/type /deferred-value /attribute ... so end absolutely supports EL. Whether there's a Tomcat bug or a setup issue here, I don't know. -- Adam On 8/30/07, Thai Dang Vu [EMAIL PROTECTED] wrote: Hi everybody, I dropped the trinidad 1.2.1 demo war file in the webapps folder of Tomcat 6, run tomcat so that it deployed that war file, stopped tomcat to dropped jsf-impl-1.2_04-p02.jar, jsf-api-1.2_04-p02.jar and jstl-1.2.jar in the trinidad-1.2.1-demo/WEB-INF/lib folder, started tomcat again and the Component Guide worked, but the Progress Step Demo didn't. This is the error: org.apache.jasper.JasperException: /demos/progressSteps.jspx(68,58) According to TLD or attribute directive in tag file, attribute end does not accept any expressions org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHand ler.java:40) org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java :407) org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java :148) org.apache.jasper.compiler.Validator$ValidateVisitor.checkXmlAttributes( Validator.java:1119) org.apache.jasper.compiler.Validator$ValidateVisitor.visit(Validator.jav a:819) org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1507) org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2336) org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2386) org.apache.jasper.compiler.Validator$ValidateVisitor.visit(Validator.jav a:838) org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1507) org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2336) org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2386) org.apache.jasper.compiler.Validator$ValidateVisitor.visit(Validator.jav a:838) org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1507) org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2336) org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2386) org.apache.jasper.compiler.Validator$ValidateVisitor.visit(Validator.jav a:838) org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1507) org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2336) org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2386) org.apache.jasper.compiler.Validator$ValidateVisitor.visit(Validator.jav a:838) org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1507) org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2336) org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2386) org.apache.jasper.compiler.Validator$ValidateVisitor.visit(Validator.jav a:838) org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1507) org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2336) org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2386) org.apache.jasper.compiler.Validator$ValidateVisitor.visit(Validator.jav a:838) org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1507) org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2336) org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2386) org.apache.jasper.compiler.Validator$ValidateVisitor.visit(Validator.jav a:838) org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1507) org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2336) org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2386) org.apache.jasper.compiler.Validator$ValidateVisitor.visit(Validator.jav a:515) org.apache.jasper.compiler.Node$JspRoot.accept(Node.java:566) org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2336) org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2386) org.apache.jasper.compiler.Node$Visitor.visit(Node.java:2392) org.apache.jasper.compiler.Node$Root.accept(Node.java:489) org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2336) org.apache.jasper.compiler.Validator.validate(Validator.java:1737) org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:178) org.apache.jasper.compiler.Compiler.compile(Compiler.java:306) org.apache.jasper.compiler.Compiler.compile(Compiler.java:286) org.apache.jasper.compiler.Compiler.compile(Compiler.java:273) org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.ja va:566) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.ja va:317) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:320) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:266) javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
Re: trinidad outputFormat and f:param support
BTW, for all of these examples, you should just use tr:outputText
instead of tr:outputFormatted.
outputFormatted really has nothing to do with outputFormat.
What tr:outputFormatted gives you is support for (a subset of)
HTML formatting without opening the security hole of
escape=false.
-- Adam
On 8/30/07, Andrew Robinson [EMAIL PROTECTED] wrote:
Well you could do:
tr:outputFormatted value=#{myfunc:format2(str, arg1, arg2)} /
where you could write format1, format2, etc. EL functions to do the work.
You could also do:
t:buffer into=#{formattedString}
h:outputFormat value=#{message.key}
f:param value=param1 /
/h:outputFormat
/t:buffer
tr:outputFormatted value=#{formattedString} /
On 8/30/07, Paul Mander [EMAIL PROTECTED] wrote:
Andrew Robinson-5 wrote:
Well, that is not localizable
I think the use case that he means is more like:
tr:outputFormatted value=#{messages.str}
f:param value=#{myarg} /
/tr:outputFormatted
messages.properties
str = Test {0} param
That's a better example.
--
View this message in context:
http://www.nabble.com/trinidad-outputFormat-and-f%3Aparam-support-tf4347417.html#a12401317
Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: [Trinidad] ppr: partialTriggers doesn't work if there are validation messages?
If I understand it correctly, your concern here is basically that we're not displaying validation errors correctly after an event is submitted? (We do, or at least should, re-display tr:messages during PPR, but not the messages next to the individual components. If your page doesn't have a tr:messages on it, I'd recommend adding one.) If that's the issue, then we should tackle that, which is a clear functionality gap that doesn't require architectural changes, and shouldn't require any end developer code - those messages should just get displayed on the client. -- Adam On 8/28/07, Andrew Robinson [EMAIL PROTECTED] wrote: Yes, I fully understand the JSF lifecycle, but that doesn't address my problem. The problem is that the partialTriggers functionality of the UIXCommand components depends on the broadcasting of the ActionEvent. This event's phase cannot be changed without drastically affecting the application. The question is this: How can an web application developer re-render a component as a result of a validation or conversion error during a partial submission of a UIXCommand component without writing a custom component or custom renderer? -Andrew On 8/28/07, Gary VanMatre [EMAIL PROTECTED] wrote: From: Andrew Robinson [EMAIL PROTECTED] It is a simple case of showing the effects of the failed validation. Take the following use case as an example: User clicks on a register button to create a user account for a web site. The user enters a username that is already in use and hits the register/save button A unique validator on the username field fails its validation and adds a validation message to the faces context using the component. All message components that are for this component as well as any messages components that are not global have to be re-rendered to show the user the validation error. This is just one use case to illustrate the fact that at the very least, message and messages components need to be re-rendered when validation errors and conversion errors are thrown on the se rver. This doesn't include any components that need to be re-rendered as a result. For example, the panelLabelAndMessage component renders an error icon in the label when there is an error message for the input component. It is also common for people to style components different (red border for example) when their validation fails. The way Trinidad components are written, there is no way out of the box to accomplish this. The commandLink and commandButton will only run the partial trigger functionality if the action event is broadcast. Therefore, there is a large gap in the PPR functionality to allow code to trigger rendering when the renderResponse method is called before the broadcasting of the event. My take on it is that Trinidad uses the JSF lifecycle to achieve PPR. In the JSF Lifecycle, the UIViewRoot processes queued events for each phase by calling the broadcast on the source component for all phases except render response. The components queue events in the decode (apply request values) and can specify the phase they should be invoked in. I believe the default phaseId for the FacesEvent is ANY. In all of these cases, events are processed prior to checking if the response is completed or render response has be set to true. Take a look at the following methods in the UIViewRoot [1]. processDecodes - apply request values processValidators - process validators processUpdates- update model processApplication - invoke application [1] http://svn.apache.org/viewvc/myfaces/core/branches/1_1_5/api/src/main/java/javax/faces/component/UIViewRoot.java?view=markup Now, doesn't it make sense for a message component to be triggered on the fact that the command was executed (meaning the button was clicked, form was submitted) but not necessarily that the JSF action was run? Even if you don't agree, you have to realize that the PPR currently makes re-rendering impossible if renderResponse is called, shortening the JSF lifecycle. I realize that many people use client side validation with Trinidad and therefore are less likely to have this issue, but there are several reasons that client side validation is not a complete solution. With custom components and integration with the Tridindad APIs this functionality is definitely possible, but it really should be provided out of the box. So to answer your question, there is absolutely no point in re-rendering a message component if there isn't a validation error or conversion error. -Andrew Gary On 8/28/07, Adam Winer wrote: I don't understand that sentence... You're saying that you *do* want validation to fire, but want the components to re-render just the same? This seems odd... If validation fails, what
Re: [Trinidad] ppr: partialTriggers doesn't work if there are validation messages?
On 8/28/07, Adam Winer [EMAIL PROTECTED] wrote: If I understand it correctly, your concern here is basically that we're not displaying validation errors correctly after an event is submitted? (We do, or at least should, re-display tr:messages during PPR, but not the messages next to the individual components. If your page doesn't have a tr:messages on it, I'd recommend adding one.) If that's the issue, then we should tackle that, which is a clear functionality gap that doesn't require architectural changes, and shouldn't require any end developer code - those messages should just get displayed on the client. ... and so there's no confusion, I mean that those *server-side* messages should get just displayed on the client. As long as we have inline client-side validation in general, our Javascript is easily smart enough to deal with inserting error messages on the client, so we'd just need to update our rendering code to include a Javascript payload of all the per-component FacesMessages. -- Adam -- Adam On 8/28/07, Andrew Robinson [EMAIL PROTECTED] wrote: Yes, I fully understand the JSF lifecycle, but that doesn't address my problem. The problem is that the partialTriggers functionality of the UIXCommand components depends on the broadcasting of the ActionEvent. This event's phase cannot be changed without drastically affecting the application. The question is this: How can an web application developer re-render a component as a result of a validation or conversion error during a partial submission of a UIXCommand component without writing a custom component or custom renderer? -Andrew On 8/28/07, Gary VanMatre [EMAIL PROTECTED] wrote: From: Andrew Robinson [EMAIL PROTECTED] It is a simple case of showing the effects of the failed validation. Take the following use case as an example: User clicks on a register button to create a user account for a web site. The user enters a username that is already in use and hits the register/save button A unique validator on the username field fails its validation and adds a validation message to the faces context using the component. All message components that are for this component as well as any messages components that are not global have to be re-rendered to show the user the validation error. This is just one use case to illustrate the fact that at the very least, message and messages components need to be re-rendered when validation errors and conversion errors are thrown on the se rver. This doesn't include any components that need to be re-rendered as a result. For example, the panelLabelAndMessage component renders an error icon in the label when there is an error message for the input component. It is also common for people to style components different (red border for example) when their validation fails. The way Trinidad components are written, there is no way out of the box to accomplish this. The commandLink and commandButton will only run the partial trigger functionality if the action event is broadcast. Therefore, there is a large gap in the PPR functionality to allow code to trigger rendering when the renderResponse method is called before the broadcasting of the event. My take on it is that Trinidad uses the JSF lifecycle to achieve PPR. In the JSF Lifecycle, the UIViewRoot processes queued events for each phase by calling the broadcast on the source component for all phases except render response. The components queue events in the decode (apply request values) and can specify the phase they should be invoked in. I believe the default phaseId for the FacesEvent is ANY. In all of these cases, events are processed prior to checking if the response is completed or render response has be set to true. Take a look at the following methods in the UIViewRoot [1]. processDecodes - apply request values processValidators - process validators processUpdates- update model processApplication - invoke application [1] http://svn.apache.org/viewvc/myfaces/core/branches/1_1_5/api/src/main/java/javax/faces/component/UIViewRoot.java?view=markup Now, doesn't it make sense for a message component to be triggered on the fact that the command was executed (meaning the button was clicked, form was submitted) but not necessarily that the JSF action was run? Even if you don't agree, you have to realize that the PPR currently makes re-rendering impossible if renderResponse is called, shortening the JSF lifecycle. I realize that many people use client side validation with Trinidad and therefore are less likely to have this issue, but there are several reasons that client side validation is not a complete solution. With custom components
Re: [Trinidad] Howto enable scollbars on tr:table
Created a JIRA issue: https://issues.apache.org/jira/browse/TRINIDAD-656 which would I think resolve this problem. -- Adam On 8/27/07, Christian Klocker [EMAIL PROTECTED] wrote: actually i simple use a css-style like (height:400px;overflow:auto) to get a vertical scrollbar on tr:table. the problem withit is, that now the header is also scrolling ... at http://www.oracle.com/technology/products/adf/adffaces/11/doc/multiproject/adf-richclient-api/enhanced-tagdoc.html i saw the table-component with scollbars ... is there a solution for trinidad? thanks christian
Re: [Trinidad] Bug in XMLMenuModel / ItemNode ?
Stephen,
You're correct. The bug is in ItemNode.doAction(), which calls
a MenuUtils.getBoundValue() function, which in turn tries to
process this as a ValueBinding/ValueExpression. It's not -
it's a MethodBinding/MethodExpression.
-- Adam
On 8/28/07, Stephen Friedrich [EMAIL PROTECTED] wrote:
Seems to me an action attribute is mistakenly interpreted as containing a
property rather than an action method:
I am trying to convert from lots of hard coded navigation items like this:
tr:commandNavigationItem id=users action=#{_userList.go}
text=#{Output.USER} /
to a single
tr:commandNavigationItem text=#{node.label} action=#{node.doAction}/
using a menu model containing definitions like this:
itemNode id=users action=#{_userList.go} label=#{Output.USER}
focusViewId=/benutzer.jsf/
My _userList bean has this method:
public String go() { ...
The navigation bar displays just fine, but when I click on the link/button
all I get is this exception:
23:15:56,234 ERROR [STDERR] 28.08.2007 23:15:56
org.apache.myfaces.trinidadinternal.menu.MenuUtils getBoundValue
SEVERE: javax.el.PropertyNotFoundException: Property 'go' not found on
type com.fortis.texas.client.UserList_$$_javassist_13
at javax.el.BeanELResolver$BeanProperties.get(BeanELResolver.java:193)
at javax.el.BeanELResolver.property(BeanELResolver.java:267)
at javax.el.BeanELResolver.getValue(BeanELResolver.java:60)
at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:53)
at
com.sun.faces.el.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:64)
at
org.jboss.el.parser.AstPropertySuffix.getValue(AstPropertySuffix.java:53)
Adding this method to _userList makes it work, but is an ugly workaround:
public String getGo() {
return go();
}
Is it a bug or am I using something incorrectly here?
(Trinidad 1.2.1, JBoss Seam 2.0.0-Beta)
Re: SEVERE: No RenderingContext has been created.
The problem is that the JspTilesViewHandlerImpl is running without the TrinidadViewHandlerImpl ever getting a chance. See http://www.nabble.com/-Trinidad--Integration-with-Tiles-t4244805.html where pdt_p answered this question. -- Adam On 8/28/07, Edward Dowgiallo [EMAIL PROTECTED] wrote: I would greatly appreciate any advice on how to correct this or at least what might be causing it. Environment is MyFaces 1.1.5, Trinidad 1.0.2, Tomahawk 1.1.6, Struts Tiles 1.3.5, JDK 1.5.0_11 Thank you, Ed Aug 28, 2007 7:04:25 PM org.apache.myfaces.trinidadinternal.renderkit.core.CoreRenderKit createResponseWriter SEVERE: No RenderingContext has been created. Aug 28, 2007 7:04:25 PM org.apache.catalina.core.ApplicationDispatcher invoke SEVERE: Servlet.service() for servlet jsp threw exception java.lang.IllegalStateException: No RenderingContext at org.apache.myfaces.trinidad.render.CoreRenderer.encodeEnd(CoreRenderer.java:214) at org.apache.myfaces.trinidad.component.UIXComponentBase.encodeEnd(UIXComponentBase.java:710) at javax.faces.webapp.UIComponentTag.encodeEnd(UIComponentTag.java:498) at javax.faces.webapp.UIComponentTag.doEndTag (UIComponentTag.java:366) at org.apache.myfaces.trinidad.webapp.UIXComponentTag.doEndTag(UIXComponentTag.java:118) at org.apache.jsp.page.layout_jspx._jspx_meth_tr_005fdocument_005f0(layout_jspx.java:159) at org.apache.jsp.page.layout_jspx._jspx_meth_f_005fview_005f0(layout_jspx.java:126) at org.apache.jsp.page.layout_jspx._jspService(layout_jspx.java:77) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java :70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:393) at org.apache.jasper.servlet.JspServlet.serviceJspFile (JspServlet.java:320) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:266) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java :654) at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:445) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:379) at org.apache.catalina.core.ApplicationDispatcher.forward (ApplicationDispatcher.java:292) at org.apache.myfaces.context.servlet.ServletExternalContextImpl.dispatch(ServletExternalContextImpl.java:419) at org.apache.myfaces.trinidad.context.ExternalContextDecorator.dispatch (ExternalContextDecorator.java:43) at org.apache.myfaces.trinidad.context.ExternalContextDecorator.dispatch(ExternalContextDecorator.java:43) at org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl$OverrideDispatch.dispatch (FacesContextFactoryImpl.java:260) at org.apache.myfaces.trinidad.context.ExternalContextDecorator.dispatch(ExternalContextDecorator.java:43) at org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl$OverrideDispatch.dispatch (FacesContextFactoryImpl.java:260) at org.apache.myfaces.tomahawk.application.jsp.JspTilesViewHandlerImpl.dispatch(JspTilesViewHandlerImpl.java:236) at org.apache.myfaces.tomahawk.application.jsp.JspTilesViewHandlerImpl.renderView (JspTilesViewHandlerImpl.java:222) 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 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter (ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104) at org.apache.catalina.core.StandardEngineValve.invoke (StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:261) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process (Http11Protocol.java:581) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:595)
Re: [Trinidad] ppr: partialTriggers doesn't work if there are validation messages?
On 8/28/07, Andrew Robinson [EMAIL PROTECTED] wrote:
I got it to work with a custom component. I created a component that
doesn't render, that simply houses children. In the queueEvent method
of that component, if the type of the event is ActionEvent, I then use
it to add components as partial targets.
It just would be nice to have this supported by Trinidad out of the
box. A4J creates AjaxEvents that have their phase ID set to ANY, so
they fire almost immediately, and thus work regardless of what phases
are run.
I'm just wondering if there would be any harm to moving the code from
the broadcast method to the queue method.
Yes, there would be! It'd break the semantics of partialTriggers.
If you want your action event to fire in the ANY phase, just set
immediate=true.
-- Adam
On 8/28/07, Simon Lessard [EMAIL PROTECTED] wrote:
Hello Andrew,
To my knowledge, this is the desired behavior since PPR requests does not
use a different lifecycle than a normal requests. However, since I had to
deal with that with every single ADF Faces/Trinidad projects I was on, I
made a new lifecycle that alter the behavior with PPR request by skipping
required check validations and running validation and update model phases
only on the PPR source then I restore the model value after the render to
make sure the model does not stay polluted. Finally, I have to save all
values that were pushed from PPR that way so that in further PPR requests
(in case there's more than one PPR active element in the page), I push the
value back to the model from the previous PPR requests. This last part is
the source of most of the complexity but is required when populating a
selectOneMenu's list of values from the value of two other fields for
example.
Regards,
~ Simon
On 8/27/07, Andrew Robinson [EMAIL PROTECTED] wrote:
I have a login form with a login command link. The form is a
panelFormLayout with panelLabelAndMessage components with inputText
components (username and password).
I have:
tr:panelFormLayout partialTriggers=login
...
f:facet name=footer
tr:group
tr:commandLink
id=login
partialSubmit=true
action=#{identity.login}
text=#{messages.page_login_login} /
...
Now the panel is not updated because the code to trigger the PPR is in
the broadcast method of the UIXCommand (parent of the command link).
The validation error causes the ActionEvent to not be broadcast, and
thus the PPR is not properly triggered.
Should this be considered a bug?
Should the adfContext.partialUpdateNotify(component); call be made
from the queueEvent method rather than the broadcast method?
Or is there a different way to do this that I am missing?
Another nice feature would be to automatically have the
panelLabelAndMessage and panelFormLayout components automatically get
re-rendered if there is a validation or conversion error in one of
their nested children components.
Thanks,
Andrew
Re: [Trinidad] Looking for client-side partial page validation
On 8/28/07, Vadim Dmitriev [EMAIL PROTECTED] wrote: Hi! As far as I know ADF had some limitation regarding client-side validation with subforms. Suppose we have following block in a page: tr:form tr:inputText required=true / tr:subform tr:inputText / tr:commandButton / /tr:subform /tr:form In that case if we will try to submit that page via commandButton with outer input field empty - validation error will occur on client, while with client-side validation disabled this request will be absolutely valid (i.e. no server-side validation exceptions will be thrown). In fact, that's false. Server-side validation will fire for the inputText, as components outside subforms always execute. There should be no cases whatsoever where client-side validation is stricter than server-side. Any such cases are major bugs, as they open security holes in any application that relies on the client-side validation. -- Adam Yesterday i faced that problem with trinidad. Maybe there is some quick workaround? I really don't want to take immediate/binding/submitted value way. Not to mention that that method leads to skipping subform validation :) I took a quick look into trinidad's client-side validation implementation and found interesting block of code in the _multiValidation() function related to skipping all subform's fields validators if user submitted outer form. Maybe it will be easier for me (if at all possible) to modify that filtering process to skip outer form validators if subform is submitted? Thank you in advance! P.S. I understand that AJAX-enabled server-side validation is actually fast and consumes very little of traffic, but my boss stands for if we can do it on client-side - we'll do it on client. So I have choice of either fixing said problem in trinidad itself or writing all client-side validation from scratch.
Re: [Trinidad] ppr: partialTriggers doesn't work if there are validation messages?
I don't understand that sentence... You're saying that you
*do* want validation to fire, but want the components to
re-render just the same? This seems odd... If validation
fails, what state has changed such that you need updated
content?
-- Adam
On 8/28/07, Andrew Robinson [EMAIL PROTECTED] wrote:
But the action should not be immediate, only the effect of the re-rendering
On 8/28/07, Adam Winer [EMAIL PROTECTED] wrote:
On 8/28/07, Andrew Robinson [EMAIL PROTECTED] wrote:
I got it to work with a custom component. I created a component that
doesn't render, that simply houses children. In the queueEvent method
of that component, if the type of the event is ActionEvent, I then use
it to add components as partial targets.
It just would be nice to have this supported by Trinidad out of the
box. A4J creates AjaxEvents that have their phase ID set to ANY, so
they fire almost immediately, and thus work regardless of what phases
are run.
I'm just wondering if there would be any harm to moving the code from
the broadcast method to the queue method.
Yes, there would be! It'd break the semantics of partialTriggers.
If you want your action event to fire in the ANY phase, just set
immediate=true.
-- Adam
On 8/28/07, Simon Lessard [EMAIL PROTECTED] wrote:
Hello Andrew,
To my knowledge, this is the desired behavior since PPR requests does
not
use a different lifecycle than a normal requests. However, since I had
to
deal with that with every single ADF Faces/Trinidad projects I was on, I
made a new lifecycle that alter the behavior with PPR request by
skipping
required check validations and running validation and update model
phases
only on the PPR source then I restore the model value after the render
to
make sure the model does not stay polluted. Finally, I have to save all
values that were pushed from PPR that way so that in further PPR
requests
(in case there's more than one PPR active element in the page), I push
the
value back to the model from the previous PPR requests. This last part
is
the source of most of the complexity but is required when populating a
selectOneMenu's list of values from the value of two other fields for
example.
Regards,
~ Simon
On 8/27/07, Andrew Robinson [EMAIL PROTECTED] wrote:
I have a login form with a login command link. The form is a
panelFormLayout with panelLabelAndMessage components with inputText
components (username and password).
I have:
tr:panelFormLayout partialTriggers=login
...
f:facet name=footer
tr:group
tr:commandLink
id=login
partialSubmit=true
action=#{identity.login}
text=#{messages.page_login_login} /
...
Now the panel is not updated because the code to trigger the PPR is in
the broadcast method of the UIXCommand (parent of the command link).
The validation error causes the ActionEvent to not be broadcast, and
thus the PPR is not properly triggered.
Should this be considered a bug?
Should the adfContext.partialUpdateNotify(component); call be made
from the queueEvent method rather than the broadcast method?
Or is there a different way to do this that I am missing?
Another nice feature would be to automatically have the
panelLabelAndMessage and panelFormLayout components automatically get
re-rendered if there is a validation or conversion error in one of
their nested children components.
Thanks,
Andrew
Re: SEVERE: No RenderingContext has been created.
I can't really say. I've never recommended the use of Tiles with JSF at all - Trinidad, Tomahawk, A4J, standard spec components, none of them really work that well with Tiles. I'd recommend getting jsp:include working first. *Then* try mixing in Tiles if you really must. -- Adam On 8/28/07, Edward Dowgiallo [EMAIL PROTECTED] wrote: Thank you Adam. This now has the Tiles 1.3.5 partially functioning. layout.jspx is now being processed correctly. The contents of body.jspf, however, appear unprocessed at the beginning of the response. Do I need a servlet or filter mapping for *.jspf? tiles-defs.xml: tiles-definitions definitionname=/test.tilespath=/page/layout.jspx putname=bodyvalue=/tile/body.jspf/ /definition /tiles-definitions layout.jspx: jsp:rootversion=2.0 xmlns:f=http://java.sun.com/jsf/core xmlns:jsp=http://java.sun.com/JSP/Page; xmlns:tiles=http://struts.apache.org/tags-tiles xmlns:tr=http://myfaces.apache.org/trinidad; jsp:directive.page contentType=text/html;charset=UTF-8 / tiles:importAttributescope=request / f:view tr:document title=Library Home Page tr:form tr:panelPageid=library-home-page f:verbatimdivhtml/div/f:verbatim tr:outputTextvalue=Before... / tiles:insertattribute=bodyflush=false/ tr:outputTextvalue=...After / /tr:panelPage /tr:form /tr:document /f:view /jsp:root body.jspf: jsp:rootversion=2.0 xmlns:f=http://java.sun.com/jsf/core; xmlns:jsp= http://java.sun.com/JSP/Page; xmlns:tiles=http://struts.apache.org/tags-tiles; xmlns:tr= http://myfaces.apache.org/trinidad; f:verbatimdivAlpha/div/f:verbatim tr:panelBorderLayout tr:outputText value=Tiles 101 body content. / /tr:panelBorderLayout /jsp:root On 8/28/07, Adam Winer [EMAIL PROTECTED] wrote: The problem is that the JspTilesViewHandlerImpl is running without the TrinidadViewHandlerImpl ever getting a chance. See http://www.nabble.com/-Trinidad--Integration-with-Tiles-t4244805.html where pdt_p answered this question. -- Adam On 8/28/07, Edward Dowgiallo [EMAIL PROTECTED] wrote: I would greatly appreciate any advice on how to correct this or at least what might be causing it. Environment is MyFaces 1.1.5, Trinidad 1.0.2, Tomahawk 1.1.6, Struts Tiles 1.3.5, JDK 1.5.0_11 Thank you, Ed Aug 28, 2007 7:04:25 PM org.apache.myfaces.trinidadinternal.renderkit.core.CoreRenderKit createResponseWriter SEVERE: No RenderingContext has been created. Aug 28, 2007 7:04:25 PM org.apache.catalina.core.ApplicationDispatcher invoke SEVERE: Servlet.service() for servlet jsp threw exception java.lang.IllegalStateException: No RenderingContext at org.apache.myfaces.trinidad.render.CoreRenderer.encodeEnd(CoreRenderer.java:214) at org.apache.myfaces.trinidad.component.UIXComponentBase.encodeEnd (UIXComponentBase.java:710) at javax.faces.webapp.UIComponentTag.encodeEnd(UIComponentTag.java:498) at javax.faces.webapp.UIComponentTag.doEndTag (UIComponentTag.java:366) at org.apache.myfaces.trinidad.webapp.UIXComponentTag.doEndTag(UIXComponentTag.java:118) at org.apache.jsp.page.layout_jspx._jspx_meth_tr_005fdocument_005f0(layout_jspx.java:159) at org.apache.jsp.page.layout_jspx._jspx_meth_f_005fview_005f0(layout_jspx.java:126) at org.apache.jsp.page.layout_jspx._jspService(layout_jspx.java:77) at org.apache.jasper.runtime.HttpJspBase.service (HttpJspBase.java :70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:393) at org.apache.jasper.servlet.JspServlet.serviceJspFile (JspServlet.java:320) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:266) at javax.servlet.http.HttpServlet.service (HttpServlet.java:803) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter (ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java :654) at org.apache.catalina.core.ApplicationDispatcher.processRequest (ApplicationDispatcher.java:445) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:379) at org.apache.catalina.core.ApplicationDispatcher.forward (ApplicationDispatcher.java:292) at org.apache.myfaces.context.servlet.ServletExternalContextImpl.dispatch
Re: [Trinidad] panelLabelAndMessage doesn't render message?
Huh. That's WEIRD.
-- Adam
On 8/27/07, Andrew Robinson [EMAIL PROTECTED] wrote:
I presume this is a bug, but wanted to make sure before reporting it.
Code from PanelLabelAndMessageRenderer in 1.0.2:
@Override
protected boolean hasMessage(
FacesContextcontext,
RenderingContext arc,
UIComponent component,
FacesBean bean)
{
return false;
}
As you can see, a message will never be rendered. The red X appears in
the label, but the message is never rendered as a result of the above
code.
The LabelAndMessage renderer seems to have the correct code, but is
overridden by the above code.
Anyone know the purpose, if any, of this?
Thanks,
Andrew
Re: [Trinidad] Upgrading to 1.0.2
A JIRA issue + a patch would make it more likely. :)
-- Adam
On 8/27/07, Perkins, Nate-P63196 [EMAIL PROTECTED] wrote:
Can this be expected in 1.0.3?
Nate Perkins
480-441-3667
[EMAIL PROTECTED]
This email message is for the sole use of the intended recipient(s) and
may contain GDC4S
confidential or privileged information. Any unauthorized review, use,
disclosure or distribution
is prohibited. If you are not an intended recipient, please contact
the sender by reply email and
destroy all copies of the original message.
-Original Message-
From: Adam Winer [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 23, 2007 8:00 PM
To: MyFaces Discussion
Subject: Re: [Trinidad] Upgrading to 1.0.2
I'm getting the feeling that we really need to add a flag
to at least trh:html or both trh:html and tr:document
that supports forcing quirks mode.
Thoughts?
-- Adam
On 8/23/07, Andrew Robinson [EMAIL PROTECTED] wrote:
You can use IE6 in quirks mode and firefox in standards mode by
subclassing the tr:document renderer.
If a comment appears before the doc type, IE will not go into
standards mode.
Here is some code if you want to do it this way to force only IE into
quirks mode while using tr:document:
public class DocumentRenderer
extends
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.DocumentRendere
r
{
/**
*
*/
public DocumentRenderer()
{}
/**
* @param type
*/
public DocumentRenderer(Type type)
{
super(type);
}
/**
* @see
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.DocumentRendere
r#encodeAll(javax.faces.context.FacesContext,
org.apache.myfaces.trinidad.context.RenderingContext,
javax.faces.component.UIComponent,
org.apache.myfaces.trinidad.bean.FacesBean)
*/
@Override
protected void encodeAll(FacesContext context, RenderingContext arc,
UIComponent component, FacesBean bean) throws IOException
{
if (Agent.AGENT_IE.equals(arc.getAgent().getAgentName()))
{
context.getResponseWriter().write(!-- force quirks mode --);
}
super.encodeAll(context, arc, component, bean);
}
}
On 8/23/07, Perkins, Nate-P63196 [EMAIL PROTECTED] wrote:
I put a lot of time into this problem, albeit a while ago, but I
could not
find a way to satisfy my requirements for IE6 in standard mode, I
would love
to be able to, but I have not found a way. I'll post the general
structure
and the css and perhaps you can help?
The basic structure is this:
div id=top_bar
spanSome necessary banner text/span
/div
div id=main_content
Whatever the particular page requires
/div
div id=bottom_bar
spanAgain, some necessary banner text/span
/div
The requirement is that the top_bar and the bottom_bar are always
visible
and in the same position (at the top and the bottom, respectively :)
) but
not covering the main_content while main_content can scroll as
necessary.
Here's the css that I used to accomplish this, this works properly
in
Firefox regardless of the doc-type, but again, in IE6 it only works
in
quirks mode.
body {
border: 0pt none;
margin: 0;
padding 0;
height: 100%;
max-height: 100%;
width: 100%;
max-width: 100%;
overflow: hidden;
}
* html body {
padding: 5px 0pt 55px;
}
#main_content {
bottom: 30px;
left: 0px;
overflow: auto;
position: fixed;
right: 0;
top: 25px;
}
* html #main_content {
height: 100%;
position: relative;
width: 100%;
}
#top_bar {
height: 25px;
position: absolute;left: 0;
top: 0;
width: 100%;
}
#bottom_bar {
height: 25px;
position: absolute;left: 0;
bottom: 0;
width: 100%;
}
Nate Perkins
480-441-3667
[EMAIL PROTECTED]
This email message is for the sole use of the intended recipient(s)
and may
contain GDC4S
confidential or privileged information. Any unauthorized review,
use,
disclosure or distribution
is prohibited. If you are not an intended recipient, please contact
the
sender by reply email and
destroy all copies of the original message.
From: Simon Lessard [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 23, 2007 8:21 AM
To: MyFaces Discussion
Subject: Re: [Trinidad] Upgrading to 1.0.2
Hello Nate,
So what you're saying is that your application will only ever work
in quirk
mode? There's always a solution in standard mode as well, sometimes
a bit
more complicated though.
Regards,
~ Simon
On 8/23/07, Perkins, Nate-P63196 [EMAIL PROTECTED] wrote:
I commented out the jsp:output and that fixed the problem.
Unfortunately I can not live with that solution as it is mandatory
for
my project's pages. We have
Re: [Trinidad] XMLMenuModel bug
Looks like a generic (and very simple) issue with some of the
client-side validation changes I've made. I'll fix this.
-- Adam
On 8/24/07, Luka Surija [EMAIL PROTECTED] wrote:
Actually nothing happens, I've found that Firebug is displaying this
error message:
validatorArray has no properties:
_multiValidate(form#j_id1 index.xhtml, j_id5:0:j_id6, [j_id28, 0,
undefined, 17 more...])Common1_0_3.js (line 5248)
_validateInline(form#j_id1 index.xhtml, j_id5:0:j_id6, [j_id28, 0,
undefined, 17 more...])Common1_0_3.js (line 4589)
_j_id1Validator(form#j_id1 index.xhtml, j_id5:0:j_id6)index.xhtml
(line 245)
_validateForm(form#j_id1 index.xhtml, j_id5:0:j_id6)Common1_0_3.js
(line 4508)
submitForm(form#j_id1 index.xhtml, 1, Object source=j_id5:0:j_id6,
undefined)Common1_0_3.js (line 4765)
onclick(click clientX=0, clientY=0)index.xhtml (line 1)
for(var j=0;jvalidatorArray.length;j=j+1)
Luka Surija wrote:
If found pretty dummy bug in XMLMenuModel.
If I call an action method trough XMLMenuModel then the method is
executed, but no navigation is executed.
WorkingTaskAdmin:
public String addNewWorkingTask(){
sessionBean.addNewWorkingTask();
return service:workingTaskWizard; -- invoking in
tr:commandMenuItem act as where return null;
}
menu-model.xml:
itemNode id=menu241 label=#{mnl.newWorkingTask}
action=#{WorkingTaskAdmin.addNewWorkingTask}
focusViewId=/service/workingTaskWizard.xhtml /
but if i press this button then everything works as expected.
tr:commandButton text=#{msg.new_label}
action=#{WorkingTaskAdmin.addNewWorkingTask} /
I'm using trinidad 1.0.3-core trunk.
Re: [Trinidad] XMLMenuModel bug
Looking at it again, I've no idea how this could happen.
validatorArray should always be non-null. I'll add some
defensive code, but I can't imagine why you're seeing
this.
-- Adam
On 8/24/07, Adam Winer [EMAIL PROTECTED] wrote:
Looks like a generic (and very simple) issue with some of the
client-side validation changes I've made. I'll fix this.
-- Adam
On 8/24/07, Luka Surija [EMAIL PROTECTED] wrote:
Actually nothing happens, I've found that Firebug is displaying this
error message:
validatorArray has no properties:
_multiValidate(form#j_id1 index.xhtml, j_id5:0:j_id6, [j_id28, 0,
undefined, 17 more...])Common1_0_3.js (line 5248)
_validateInline(form#j_id1 index.xhtml, j_id5:0:j_id6, [j_id28, 0,
undefined, 17 more...])Common1_0_3.js (line 4589)
_j_id1Validator(form#j_id1 index.xhtml, j_id5:0:j_id6)index.xhtml
(line 245)
_validateForm(form#j_id1 index.xhtml, j_id5:0:j_id6)Common1_0_3.js
(line 4508)
submitForm(form#j_id1 index.xhtml, 1, Object source=j_id5:0:j_id6,
undefined)Common1_0_3.js (line 4765)
onclick(click clientX=0, clientY=0)index.xhtml (line 1)
for(var j=0;jvalidatorArray.length;j=j+1)
Luka Surija wrote:
If found pretty dummy bug in XMLMenuModel.
If I call an action method trough XMLMenuModel then the method is
executed, but no navigation is executed.
WorkingTaskAdmin:
public String addNewWorkingTask(){
sessionBean.addNewWorkingTask();
return service:workingTaskWizard; -- invoking in
tr:commandMenuItem act as where return null;
}
menu-model.xml:
itemNode id=menu241 label=#{mnl.newWorkingTask}
action=#{WorkingTaskAdmin.addNewWorkingTask}
focusViewId=/service/workingTaskWizard.xhtml /
but if i press this button then everything works as expected.
tr:commandButton text=#{msg.new_label}
action=#{WorkingTaskAdmin.addNewWorkingTask} /
I'm using trinidad 1.0.3-core trunk.
Re: [Trinidad] Upgrading to 1.0.2
FWIW, in Tomcat 5.0, the PPR code has no issues
stripping the doctype. Pretty sure it works in OC4J
too. Going to test Glassfish now.
-- Adam
On 8/23/07, Adam Winer [EMAIL PROTECTED] wrote:
trh:head doesn't output the doctype - it's trh:html and/or
tr:document.
I don't think it's that the PPR code is stripping only 1 doctype.
I think it's that the two doctypes are written out through different
mechanisms (ResponseWriter or straight to the serlvet response),
and PPR is for some reason only catching one of them.
I'd need to test this out to see exactly what's happening.
-- Adam
On 8/23/07, Perkins, Nate-P63196 [EMAIL PROTECTED] wrote:
Adam,
I've noticed that the combination of the trh:head tag (which outputs a
doctype) and my jsp:output (which also outputs a doctype), creates 2
doctypes in the response. Firefox strips out the 2nd doctype but IE
does not. So perhaps the PPR code is stripping out only 1 of the
doctypes?
Nate Perkins
480-441-3667
[EMAIL PROTECTED]
This email message is for the sole use of the intended recipient(s) and
may contain GDC4S
confidential or privileged information. Any unauthorized review, use,
disclosure or distribution
is prohibited. If you are not an intended recipient, please contact
the sender by reply email and
destroy all copies of the original message.
-Original Message-
From: Adam Winer [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 22, 2007 10:57 PM
To: MyFaces Discussion
Subject: Re: [Trinidad] Upgrading to 1.0.2
If you remove the doctype-root-element, doctype-system,
and doctype-public off of jsp:output, does the problem
go away? It looks as though that doctype is getting
pushed straight into the content stream. There's code
in Trinidad to trim out the doctype (XmlHttpServletResponse
and XmlOutput) during an XMLHttp request - don't know
why it's not functioning here.
-- Adam
On 8/22/07, Perkins, Nate-P63196 [EMAIL PROTECTED] wrote:
Ok,
Here's the simplest example I could muster, this results in the same
problem. I am deploying to JBoss-4.0.5 using Trinidad 1.0.2 and using
the RI 1.1
Test.jspx:
?xml version=1.0 encoding=UTF-8?
jsp:root
xmlns:jsp=http://java.sun.com/JSP/Page;
version=2.0
xmlns:f=http://java.sun.com/jsf/core;
xmlns:trh=http://myfaces.apache.org/trinidad/html;
xmlns:tr=http://myfaces.apache.org/trinidad;
xmlns:h=http://java.sun.com/jsf/html;
f:view
trh:html
jsp:output
omit-xml-declaration=false
doctype-root-element=html
doctype-system=http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
doctype-public=-//W3C//DTD XHTML 1.0
Strict//EN /
jsp:scriptlet
response.addHeader(pragma, no-store,no-cache);
response.setHeader(cache-control, no-cache, no-store, must
re-validate,max-age=-1);
response.addHeader(cache-control, pre-check=0,
post-check=0);
response.setDateHeader(expires, 0);
/jsp:scriptlet
jsp:directive.page
contentType=text/html;charset=UTF-8 /
trh:head title=Trinidad 1.0.2 PPR Test
meta
http-equiv=Content-Type
content=text/html; charset=UTF-8 /
t:stylesheet
path=#{NMSPanelPageUtil.cssLocation} /
/trh:head
trh:body
tr:form id=theForm
tr:panelPage
!--jsp:directive.include
file=/menu.jspx /--
tr:panelHeader text=Partial
Submit Test
tr:inputText
id=input
value=#{testBB.input}
label=Input:
partialTriggers=partialTestButton /
tr:commandButton
id=partialTestButton
text=PPR
Test
action=#{testBB.action}
partialSubmit=true /
tr:outputText
id=partialOutput
value=#{testBB.output}
partialTriggers=partialTestButton /
tr:commandButton
id=fullTestButton
text=Full
Submission Test
action=#{testBB.action}/
tr:outputText
id=fullOutput
value=#{testBB.output}/
/tr:panelHeader
Re: [Trinidad] tr:icon missing properties?
Yep, looks like a bug.
-- Adam
On 8/22/07, Andrew Robinson [EMAIL PROTECTED] wrote:
I am trying to use tr:icon. The tag documentation shows support for
events like onclick and properties like inlineStyle. I have created
the icon in my skin:
.AFExpandPanelIcon:alias {
content: url(/skins/standard/images/icon_expand.png);
}
And then referred to it:
tr:icon
id=messageHeaderToggleIconExpand
name=expandPanel
onclick=expandMessages();
inlineStyle=display: none; /
But this is what gets rendered:
img border=0 src=/context/skins/standard/images/icon_expand.png
id=messageHeaderToggleIconExpand/
This looks like a bug, but before reporting it, wanted to check
Version 1.0.2
-Andrew
Re: [Trinidad] Upgrading to 1.0.2
On 8/23/07, Perkins, Nate-P63196 [EMAIL PROTECTED] wrote:
Hi Adam,
I was able to replace my trh:html/ (which renders a doctype) with just
a html/, that removed the second doctype (so there is only one on the
page, the quirks mode one), but the behaviour is still the same. Is the
PPR code, looking for a particular doctype and stripping it?
The PPR code should in fact be looking for the ?xml version=1.0?,
and stripping out everything before that - doctype, whitespace, raw HTML,
everything.
-- Adam
Nate Perkins
480-441-3667
[EMAIL PROTECTED]
This email message is for the sole use of the intended recipient(s) and
may contain GDC4S
confidential or privileged information. Any unauthorized review, use,
disclosure or distribution
is prohibited. If you are not an intended recipient, please contact
the sender by reply email and
destroy all copies of the original message.
-Original Message-
From: Perkins, Nate-P63196 [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 23, 2007 9:56 AM
To: MyFaces Discussion
Subject: RE: [Trinidad] Upgrading to 1.0.2
Adam,
I've noticed that the combination of the trh:head tag (which outputs a
doctype) and my jsp:output (which also outputs a doctype), creates 2
doctypes in the response. Firefox strips out the 2nd doctype but IE
does not. So perhaps the PPR code is stripping out only 1 of the
doctypes?
Nate Perkins
480-441-3667
[EMAIL PROTECTED]
This email message is for the sole use of the intended recipient(s) and
may contain GDC4S
confidential or privileged information. Any unauthorized review, use,
disclosure or distribution
is prohibited. If you are not an intended recipient, please contact
the sender by reply email and
destroy all copies of the original message.
-Original Message-
From: Adam Winer [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 22, 2007 10:57 PM
To: MyFaces Discussion
Subject: Re: [Trinidad] Upgrading to 1.0.2
If you remove the doctype-root-element, doctype-system,
and doctype-public off of jsp:output, does the problem
go away? It looks as though that doctype is getting
pushed straight into the content stream. There's code
in Trinidad to trim out the doctype (XmlHttpServletResponse
and XmlOutput) during an XMLHttp request - don't know
why it's not functioning here.
-- Adam
On 8/22/07, Perkins, Nate-P63196 [EMAIL PROTECTED] wrote:
Ok,
Here's the simplest example I could muster, this results in the same
problem. I am deploying to JBoss-4.0.5 using Trinidad 1.0.2 and using
the RI 1.1
Test.jspx:
?xml version=1.0 encoding=UTF-8?
jsp:root
xmlns:jsp=http://java.sun.com/JSP/Page;
version=2.0
xmlns:f=http://java.sun.com/jsf/core;
xmlns:trh=http://myfaces.apache.org/trinidad/html;
xmlns:tr=http://myfaces.apache.org/trinidad;
xmlns:h=http://java.sun.com/jsf/html;
f:view
trh:html
jsp:output
omit-xml-declaration=false
doctype-root-element=html
doctype-system=http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
doctype-public=-//W3C//DTD XHTML 1.0
Strict//EN /
jsp:scriptlet
response.addHeader(pragma, no-store,no-cache);
response.setHeader(cache-control, no-cache, no-store, must
re-validate,max-age=-1);
response.addHeader(cache-control, pre-check=0,
post-check=0);
response.setDateHeader(expires, 0);
/jsp:scriptlet
jsp:directive.page
contentType=text/html;charset=UTF-8 /
trh:head title=Trinidad 1.0.2 PPR Test
meta
http-equiv=Content-Type
content=text/html; charset=UTF-8 /
t:stylesheet
path=#{NMSPanelPageUtil.cssLocation} /
/trh:head
trh:body
tr:form id=theForm
tr:panelPage
!--jsp:directive.include
file=/menu.jspx /--
tr:panelHeader text=Partial
Submit Test
tr:inputText
id=input
value=#{testBB.input}
label=Input:
partialTriggers=partialTestButton /
tr:commandButton
id=partialTestButton
text=PPR
Test
action=#{testBB.action}
partialSubmit=true /
tr:outputText
id=partialOutput
value=#{testBB.output}
partialTriggers=partialTestButton /
tr:commandButton
id=fullTestButton
Re: [Trinidad] PPR with script tags
It would be good to filter CDATA during PPR. I'd be happy to apply a patch to the PPRResponseWriter that handles this, but would also rather that component authors stop trying to out-clever the ResponseWriter! The best way to write out script contents is to just use ResponseWriter.writeText(), not write(), and let the ResponseWriter handle the details of making sure it's properly escaped or not if unnecessary (which the Trinidad ResponseWriters do). -- Adam On 8/23/07, Andrew Robinson [EMAIL PROTECTED] wrote: I have a component I was outputting script using the following code: RenderingContext arc = RenderingContext.getCurrentInstance(); ResponseWriter writer = context.getResponseWriter(); writer.startElement(XhtmlConstants.SCRIPT_ELEMENT, null); XhtmlRenderer.renderScriptDeferAttribute(context, arc); XhtmlRenderer.renderScriptTypeAttribute(context, arc); writer.write(\n//![CDATA[\n); writer.write(script.toString()); writer.write(\n//]]\n); writer.endElement(XhtmlConstants.SCRIPT_ELEMENT); This code works fine when the page is rendered the first time, but fails for a PPR request. The reason is the embedded CDATA block. As it is legal to have these blocks in the script tag, this code should work. Instead Trinidad is adding additional CDATA tags around the code, which causes an error. I removed the CDATA code from my renderer, but I am afraid this could break 3rd party components. Shouldn't the PPR engine check for the presence of the CDATA element in a script tag?
Re: [Trinidad] Upgrading to 1.0.2
trh:head doesn't output the doctype - it's trh:html and/or
tr:document.
I don't think it's that the PPR code is stripping only 1 doctype.
I think it's that the two doctypes are written out through different
mechanisms (ResponseWriter or straight to the serlvet response),
and PPR is for some reason only catching one of them.
I'd need to test this out to see exactly what's happening.
-- Adam
On 8/23/07, Perkins, Nate-P63196 [EMAIL PROTECTED] wrote:
Adam,
I've noticed that the combination of the trh:head tag (which outputs a
doctype) and my jsp:output (which also outputs a doctype), creates 2
doctypes in the response. Firefox strips out the 2nd doctype but IE
does not. So perhaps the PPR code is stripping out only 1 of the
doctypes?
Nate Perkins
480-441-3667
[EMAIL PROTECTED]
This email message is for the sole use of the intended recipient(s) and
may contain GDC4S
confidential or privileged information. Any unauthorized review, use,
disclosure or distribution
is prohibited. If you are not an intended recipient, please contact
the sender by reply email and
destroy all copies of the original message.
-Original Message-
From: Adam Winer [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 22, 2007 10:57 PM
To: MyFaces Discussion
Subject: Re: [Trinidad] Upgrading to 1.0.2
If you remove the doctype-root-element, doctype-system,
and doctype-public off of jsp:output, does the problem
go away? It looks as though that doctype is getting
pushed straight into the content stream. There's code
in Trinidad to trim out the doctype (XmlHttpServletResponse
and XmlOutput) during an XMLHttp request - don't know
why it's not functioning here.
-- Adam
On 8/22/07, Perkins, Nate-P63196 [EMAIL PROTECTED] wrote:
Ok,
Here's the simplest example I could muster, this results in the same
problem. I am deploying to JBoss-4.0.5 using Trinidad 1.0.2 and using
the RI 1.1
Test.jspx:
?xml version=1.0 encoding=UTF-8?
jsp:root
xmlns:jsp=http://java.sun.com/JSP/Page;
version=2.0
xmlns:f=http://java.sun.com/jsf/core;
xmlns:trh=http://myfaces.apache.org/trinidad/html;
xmlns:tr=http://myfaces.apache.org/trinidad;
xmlns:h=http://java.sun.com/jsf/html;
f:view
trh:html
jsp:output
omit-xml-declaration=false
doctype-root-element=html
doctype-system=http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
doctype-public=-//W3C//DTD XHTML 1.0
Strict//EN /
jsp:scriptlet
response.addHeader(pragma, no-store,no-cache);
response.setHeader(cache-control, no-cache, no-store, must
re-validate,max-age=-1);
response.addHeader(cache-control, pre-check=0,
post-check=0);
response.setDateHeader(expires, 0);
/jsp:scriptlet
jsp:directive.page
contentType=text/html;charset=UTF-8 /
trh:head title=Trinidad 1.0.2 PPR Test
meta
http-equiv=Content-Type
content=text/html; charset=UTF-8 /
t:stylesheet
path=#{NMSPanelPageUtil.cssLocation} /
/trh:head
trh:body
tr:form id=theForm
tr:panelPage
!--jsp:directive.include
file=/menu.jspx /--
tr:panelHeader text=Partial
Submit Test
tr:inputText
id=input
value=#{testBB.input}
label=Input:
partialTriggers=partialTestButton /
tr:commandButton
id=partialTestButton
text=PPR
Test
action=#{testBB.action}
partialSubmit=true /
tr:outputText
id=partialOutput
value=#{testBB.output}
partialTriggers=partialTestButton /
tr:commandButton
id=fullTestButton
text=Full
Submission Test
action=#{testBB.action}/
tr:outputText
id=fullOutput
value=#{testBB.output}/
/tr:panelHeader
/tr:panelPage
/tr:form
/trh:body
/trh:html
/f:view
/jsp:root
Backing Bean:
import org.apache.myfaces.trinidad.context.RequestContext;
public class TestBb
{
private RequestContext rc = RequestContext.getCurrentInstance();
public
