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 OR 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 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] 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
>
>
> value="#{queryByExampleController.example.type}"/>
>
This should generally just be:
>
> -->>
> 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
>
>
... 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 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] 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] 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:
>
>
>
>
>immediate="true" action="dialog:openHitMeDialog"
> returnListener="#{backing.handleReturn}" />
>
>
>
>
>
>
>
>
>
> 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 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] 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]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:
>
> faces
> *.faces
>
>
> and a navigation rule
>
>
>
> /application/reportviewer/reportviewer.jspx
>
>
> #{reportViewerController.run}
> dialog:success
>
> /application/reportviewer/report.jspx
>
>
>
> The managed bean method "run" returns "dialog:success" but the view as
> implemented in the 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
>
>
> faces
> javax.faces.webapp.FacesServlet
> 1
>
>
> faces
> /faces/*
>
>
> 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] after - 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 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): > > > > > > > ...And this is the html produced: > > > > > > > >
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] 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 or tag: > > > >
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.
>
>
> partialTrigger="popupContents">
>
> // your include here
>
>
>
>
>
> 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:
> >
> >
> >
> >
> > > value="#{bean.componentBeanName}"/>
> >
> >
> > > inlineStyle="visibility: hidden" onclick="return false;"/>
> >
> > > bean="#{bean.componentBean}" container="#{container}"/>
> >
> >
> >
> >
> > 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] 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:
> > >
> > >
> > > > > id="supplier"
> > > value="#{pageFlowScope.expenditureBean.supplier }"
> > > showRequired="true"
> > > requiredMessageDetail="Supplier must be specified."
> > >
> > > disabled="#{pageFlowScope.expenditureBean.fieldReadOnly
> }">
> > >> >
> value="#{listOfValuesFactoryBean.supplierLOVBean.selectItems}"/>
> > >
> > > > > src="/home/expenditure/supplierLink.xhtml" />
> > >
> > > > > useWindow="false"
> > > partialSubmit="false" windowHeight="300"
> windowWidth="400"
> > > id="createSupplierCommand" immediate="true"
> > > shortDesc="Create a new supplier record.">
> > >> > source="/skins/tn/images/ico_new.gif" />
> > >> > from="#{generalActionsBean.newSupplierBean}"
> > > to="#{pageFlowScope.supplierBean}" />
> > >> >
> > > to="#{pageFlowScope.supplierBean.operation}" />
> > >
> > >
> > >
> > > 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.Label
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 or tag: > > >
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:
>
>
>id="supplier"
> value="#{pageFlowScope.expenditureBean.supplier }"
> showRequired="true"
> requiredMessageDetail="Supplier must be specified."
>
> disabled="#{pageFlowScope.expenditureBean.fieldReadOnly }">
>value="#{listOfValuesFactoryBean.supplierLOVBean.selectItems}"/>
>
> src="/home/expenditure/supplierLink.xhtml" />
>
> useWindow="false"
> partialSubmit="false" windowHeight="300" windowWidth="400"
> id="createSupplierCommand" immediate="true"
> shortDesc="Create a new supplier record.">
>source="/skins/tn/images/ico_new.gif" />
>from="#{generalActionsBean.newSupplierBean}"
> to="#{pageFlowScope.supplierBean}" />
>
> to="#{pageFlowScope.supplierBean.operation}" />
>
>
>
> 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
> org.apache.myfaces.trinidad.render.CoreRenderer.encodeChild
> (CoreRenderer.java:287)
> at
> org.apache.myfaces.trinidadinternal.renderkit.html.RowLayoutRenderer.encodeChi
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-packa
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:
>
> ...
>
>columns="6" value="#{list.newMessageColor}">
>
>
>
>
>shortDesc="Insert a date into a new message at the cursor."/>
>
> ...
>
> 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
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] 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] 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 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.
> >
> > > binding="#{MyBean.inputTextOne}"
> > rendered="#{MyBean.renderInputTextOne">
> > > maximum="#{MyBean.max}"/>
> >
> >
> > 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] 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] 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 > [class] > > 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
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: > > > > com.christws.faces.component.help.HtmlHelpIconTag > > > > To the pom.xml in my faces-impl project I uncommented: > > generate-jsp-taglibs > > > > 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 you're no specifying the > > > > > tag-class > > > > > com.BlahTag > > > > > > > > > > -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 .. > > > > > > > > > > > > http://christws.com/components > > > > > > > > > > > > > > > > > > HtmlHelpIcon.xml: > > > > > > > > > > > > > > > > > > > > > > > xmlns="http://java.sun.co
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 you're no specifying the tag-class > > com.BlahTag > > > > -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 .. > > > > > > http://christws.com/components > > > > > > > > > HtmlHelpIcon.xml: > > > > > > > > > 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";> > > > > > > > > > > > > > > > com.christws.HelpIcon > > > > > > com.christws.faces.component.help.HtmlHelpIcon > > > ... properties ... > > > > > > > > > com.christws.HelpIcon > > > > > > org.apache.myfaces.trinidad.CoreCommandLink > > > > > > > > > org.apache.myfaces.trinidad.component.core.nav.CoreCommandLink > > > > > > com.christws.HelpIcon > > > cw:helpIcon > > > > > > messageId > > > > > > > > > > > > > > > > > > pom.xml: > > > ... > > > > > > org.apache.myfaces.trinidadbuild > > > maven-faces-plugin > > > > > > > > > http://christws.com/components > > > > > > > > > com.christws.faces.component.BaseComponentHandler > > > com.christws > > > com.christws > > > com.christws > > > true > > > false > > > > > > > > > > > > > > > generate-faces-config > > > > > > generate-facelets-taglibs > > > generate-renderer-map > > > > > > > > > > > > > > > ... > > > > > > What am I missing? > > > > > > > > > -- > > Matthias Wessendorf > > > > further stuff: > > blog: http://matthiaswessendorf.wordpress.com/ > > mail: matzew-at-apache-dot-org > > >
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 > > > > > > 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 > > > > 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] 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] 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] 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] "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.()
>
> In this example, Log.error('hello world); would call library>.('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]
>
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.trinidadinterna
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(console&&console.error)
> > >
> > > console.error(arguments);
> > >
> > > }
> > >
> > >
> > >
> > > This is running in IE 6. Is this console object related to the Acrobat
> > > console window?
> > >
> > >
> > >
> > > Thanks,
> > >
> > >
> > >
> > > Shawn
> > >
> > >
> >
> >
>
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 > ) > > 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: 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] 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: > > > > > > mainMenuModel > > > > > > org.apache.myfaces.trinidad.model.XMLMenuModel > > > application > > > > > > source > > > /WEB-INF/mainMenu.xml > > > > > > > > > > > >
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 )
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):
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > > class="x6m">
> >
> >
> >
> > (Actions)
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > > class="x6q">
> >
> >
> >
> >
> >
> > function _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;}
> >
> > > href="#" id="acctPage:acctTable__xc_sa" class="xi">Show All Details
> >
> > |
> >
> > > href="#" id="acctPage:acctTable__xc_ha" class="xi">Hide All Details
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Details
> >
> > > class="x75 xaf">Name
> >
> > > class="x75 xaf">Active
> >
> > > class="x75 xaf">Actions
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > > href="#" id="acctPage:acctTabledd0">
> >
> > ►
> >
> >
> >
> > > href="#" class="xi">Show
> >
> >
> >
> >
> >
> > > class="x6v xat">[Name Removed for privacy]
> >
> > > class="x6v xat">true
> >
> > > class="x6v xat">(Actions)
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > _uixt_acctPage_acctTable=new
> > CollectionComponent('acctForm','acctPage:acctTable');
> >
> > > value="0">
> >
> >
> >
> >
> >
> > AJAX Response:
> >
> >
> >
> > > action="/vbm/faces/pages/secure/telephony/accountSearch.jspx">
> >
>
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:
> >
> > mainMenuModel
> >
> > org.apache.myfaces.trinidad.model.XMLMenuModel
> > application
> >
> > source
> > /WEB-INF/mainMenu.xml
> >
> >
> >
> > helpContextMenuModel
> >
> > org.apache.myfaces.trinidad.model.XMLMenuModel
> > application
> >
> > source
> > /WEB-INF/helpContents.xml
> >
> >
> >
> >
> > 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
> >> id="mainMenuPanel"
> > partialTriggers="mainMenuPanel"
> > hint="list"
> > var="_node"
> > value="#{mainMenuModel}">
> >
> >> actionListener="#{menuBean.onMainAction}"
> > partialSubmit="true"
> > immediate="true">
> >
> >
> >
> >
> >
> > Usage of contents model:
> >
> > > id="helpContextTree"
> > var="_item"
> > value="#{helpContextMenuModel}">
> >
> > > text="#{_item.label}"
>
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 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] 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:
>
> immediate="true"
> rowDisclosureListener="#{bean.expand}"
> binding="#{bean.component}"
> disclosedRowKeys="#{bean.disclosed}"
> inlineStyle="white-space: nowrap">
>
> using my own tree model.
>
> -- Renzo
>
>
>
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 . 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 - 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:
> > >
> > >
> > > test
> > >
> > >
> > > 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:
> > >
> > >
> > > > > onclick=" TrPanelPopup.showPopup('_id45_popupContainer', '_id45',
> > > event, 'click','null',false,0,0,0,0); return false;" name="_id45"
> > > id="_id45">test
> > >
> > >
> > >
> > > test
> > >
> > >
> > >
> > >
> >
>
>
>
> --
> Chordiant Software Inc.
> www.chordiant.com
Re: [Trinidad] Table and PPR of action components
This should work; you should just be able to write:
panelGroupLayout.setPartialTriggers(new String[]{"genTable});
... though this will, of course, redraw the buttons for every action
on the table, not just selection. If you just want selection, you'd
have to add a selectionListener and explicitly call
RequestContext.addPartialTarget(table.getFacet("actions"));
-- Adam
On 9/12/07, Bertrand, Shawn R <[EMAIL PROTECTED]> wrote:
>
> My table looks like this:
>
>
>
>
> binding="#{TableFactoryBean.genTable}"
>
> value="#{HelperHolderBean.helper.tmpTable}"
>
> rows="#{HelperHolderBean.helper.tmpTableSize}"
>
> first="0" var="row" rowBandingInterval="1"
> rowSelection="single"
>
> selectionListener="#{HelperHolderBean.helper
> .selectionListener}"
>
> emptyText="(no entries)">
>
>
>
>
>
> In my backing bean, I call my CoreTable's setActions() with a
> CorePanelGroupLayout component, and I add various CoreCommandButtons to said
> component. I'd like to, on the selection of rows, make the buttons in the
> actions component update but I can't seem to make that happen. This worked
> fine in ADF Faces when we had a CoreTableSelectOne to key the partial update
> on. One interesting note: we have a poll on the same page that, when it
> polls, updates those buttons without any partialTriggers set for the actions
> component.
>
>
>
> Thanks in advance,
>
>
>
> Shawn Bertrand
>
> Tyco Electronics Corporation
>
>
>
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(console&&console.error)
> >
> > console.error(arguments);
> >
> > }
> >
> >
> >
> > This is running in IE 6. Is this console object related to the Acrobat
> > console window?
> >
> >
> >
> > Thanks,
> >
> >
> >
> > Shawn
> >
> >
>
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] 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: [Trinidad] panelPopup in 1.0.3 SNAPSHOT
Good question
In general, they go on the root element. In this case,
that's the . 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 - 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:
>
>
> test
>
>
> 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:
>
>
> onclick="TrPanelPopup.showPopup('_id45_popupContainer', '_id45',
> event, 'click','null',false,0,0,0,0); return false;" name="_id45"
> id="_id45">test
>
>
>
> test
>
>
>
>
Re: [Trinidad] panelPopup in 1.0.3 SNAPSHOT
Good question
In general, they go on the root element. In this case,
that's the . 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 - 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:
>
>
> test
>
>
> 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:
>
>
> onclick="TrPanelPopup.showPopup('_id45_popupContainer', '_id45',
> event, 'click','null',false,0,0,0,0); return false;" name="_id45"
> id="_id45">test
>
>
>
> test
>
>
>
>
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 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 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] tr:selectManyShuttle
selectManyShuttle needs to be inside of a or .
-- Adam
On 9/10/07, Reza Samoody <[EMAIL PROTECTED]> wrote:
>
> Hi,
> I'm trying to use a very simple selectManyShuttle as below:
>
> leadingHeader="#{
> mapMsg.availableServiceTypes}"
> trailingHeader="#{
> mapMsg.assignedServiceTypes}">
>
>
>
>
>
> 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
> org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.
Re: [Trinidad] tr:selectManyShuttle
Do you see any Javascript errors? (Also, you generally want a tr:document around the form, inside of the ). -- 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: > > > 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";> > > > > >leadingHeader="l-header Available > values:" > trailingHeader="t-header Selected > values:" > label="label-Selected Values" > > > label="label First" value="value foo"/> > > > > > > >
Re: [Trinidad] FrameBorderLayout
frameBorderLayout cannot be used inside of a tr:document page. Check the HTML spec - you get to choose or , not both. Once you're inside a , you need to use . -- 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: > > > > > > > > > > > > > > > > > width="100%" > > height="50pt" /> > > > > > > > > > > > > > > > > But i am getting blank page. > > > > Here is the rendered version: > > > > > "frameid" rows="100%,*"> > > > ="" cols="100%,*"> > > > >> src="left.jsp"> > > > > > > > > > > > > > > -- > > ~ > > otomatik oluşturuldu: > > http://ocetin.net/log > > > > > -- > ~ > otomatik oluşturuldu: > http://ocetin.net/log >
Re: Trinidad: Missing
Yep, indeed. Also looks like 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: > > > > printable > > > > And this means no
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: 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] 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:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Produces (inline; i think it's necessary to send it as an attachment):
> >
> > > "http://www.w3.org/TR/html4/loose.dtd";> > lang="en">
> >
> >
> >
> > > href="/ru.bpc.sandbox.trinidad/adf/styles/cache/rast-
> > desktop-1349468388-en-gecko.css"> > type="text/javascript">var _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.'; > src="/ru.bpc.sandbox.trinidad/adf/jsLibs/DebugCommon1_0_2.js"> >
> > type="text/javascript">_defaultTZ()
> >
> >
> >> 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;"> > name="top">
> > This page uses JavaScript and requires a JavaScript
> > enabled browser.Your browser is not JavaScript enabled.
> >
> > > onkeypress="return _submitOnEnter(event,'_idJsp1');"
> > action="/ru.bpc.sandbox.trinidad/faces/applicationform1.jsp"> > class="af_panelFormLayout"> > border="0" summary="" style="width: auto">
> >> cellpadding="0" cellspacing="0" border="0" width="100%"
> > summary="">
> >
> >
> >
> >
> >
> >
> >
> >> class="af_panelFormLayout_content-cell"> > id="_idJsp3:_idJsp4__xc_">
> >> id="_idJsp3:_idJsp4::icon" style="display:none;"> > name="_msgAnc__idJsp3:_idJsp4" title="Error"
> > class="AFErrorIconStyle">X
> >
> >> class="AFContentCell"> > id="_idJsp3:_idJsp4" name="_idJsp3:_idJsp4" class="af_inputText_content"
> > size="30" type="text">
> >
> >
> >
> >> class="OraInlineInfoText"> > style="display:none;" class="OraInlineErrorText">
> >
> >
> >
> > > name="org.apache.myfaces.trinidad.faces.FORM" value="_idJsp1"> > type="hidden" name=" org.apache.myfaces.trinidad.faces.STATE"
> > value="!1">function
> > __idJsp1Validator(){return true;}var
> > _idJsp1_SF={"_idJsp3":1}; > type="text/javascript">_submitFormCheck();
> >
> >
> >
> >
> > 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]
> > > > 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:
> > >
> > > "07.09.2007 0:18:07
> > > org.apache.myfaces.trinidadinternal.io.DebugHtmlResponseWriter
> > > _errorWithComment
> > > WARNING: Illegal HTML: cannot put a element in a
> > element."
> > >
> > > I checked HTML and there are really some strange ""
> > > blocks.
> > > My question is should those warnings be reported? Or I just have
> > > to set
> > > logger threshold a little higher in production? :)
> > >
> > > Thanks.
> > >
> > >
> > >
> > >
> > > --
> > > Chordiant Software Inc.
> > > www.chordiant.com
> >
>
>
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. > > > > And apparently, since everyone in your organization is > > equally lazy, the guidelines will stay fixed forever. :) > > > > 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] 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.
> List temp = new
> ArrayList(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:
>
>
> 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:
> > >
> > > > > label="Test help">
> > > > >simple="true" />
> > >
> > > > > messageId="test_help" />
> > >
> > >
> > >
> > > Works:
> > >
> > > > > label="Test help">
> > > > >simple="true" />
> > >
> > > > >messageId="test_help" />
> > >
> > > Looks like a possible bug in the state saving of facets or at least in
> > > the panelLabelAndMessage. Any ideas?
> > >
> >
>
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: > > > org.apache.myfaces.trinidad.CLIENT_STATE_METHOD > all > This is not likely relevant. > > org.apache.myfaces.trinidad.CACHE_VIEW_ROOT > false > 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: > > > facelets.BUILD_BEFORE_RESTORE > true > > > 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 child List is being mutated as the List > > // is traversed. > > List te
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: > >label="Test help"> >simple="true" /> > >messageId="test_help" /> > > > > 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 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
>
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] 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] - 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] 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 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] 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] 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)
> >>
> >>
> >> value="#{_employeeList.employeeBranchId}" required="true" unselectedLabel=""
> simple="true">
> >> value="#{_employeeList.employeeBranchItems}"/>
> >>
> >>
> >>
> >>
> >>
> >>
>
>
Re: How to navigate on DisclosureEvent using a tr:showDetailItem
Remove . 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:
>
>
> disclosureListener="#{backingBean.navigateToAppPage}">
>
>
>
> disclosureListener="#{backingBean.navigateToMgmtPage}">
>
>
>
>
>
> 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:
>
>
> xyz
> xyz
> /TestNavigation.jsp
>
>
>
>
>
> but this doesnot work.
>
> Any suggestions as to how to achieve this navigation?
>
>
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: > > > > > > > > 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 ? > > > > 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? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> > columns="1"/> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > OR > > > > > > > > > > >
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, 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 ? 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? > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > > > > >columns="1"/> > > > > > > > > > > > > > > > > > > > > > > > > OR > > > > > > > captionText="This shouldn't appear"> > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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: > > > > > > > > > > > > > > > > > > ... > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Danny > > > > > > > > > > > > -- > > > > > > Chordiant Software Inc. > > > > > > www.chordiant.com > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Chordiant Software Inc. > > > > www.chordiant.com > > > > > > > > > > > > > > > > -- > > Chordiant Software Inc. > www.chordiant.com
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:
> > > > >
> > > > >
> > > > >
> > > > > where you could write format1, format2, etc. EL functions to do the
> > > work.
> > > > >
> > > > > You could also do:
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > 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:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > 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 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"%>
>
>
>
>
>
>
>
>label="Selected Values"
> leadingHeader="Available values:"
> leadingDescShown="true"
> trailingHeader="Selected values:"
> trailingDescShown="true"
> binding="#{editor.component}"
> valueChangeListener="#{list.valueChanged}"
> value="#{list.stringArray}">
> longDesc="Long Desc 1" label="First" value="foo"/>
> longDesc="Long Desc 2" label="Second" value="bar"/>
> longDesc="Long Desc 3" label="Third" value="baz"/>
>
>
>
>
>
>
> 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:
>
> ...
>
> 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"> id="content:j_id_jsp_709084578_3pc4">
>
> var _shuttle_no_items='There are no items to move.';var
> _shuttle_no_items_selected='Please select the items to move
> first.'; cellpadding="0" cellspacing="0" border="0" width="10%" summary=""
> id="content:shuttle1" class="af_selectManyShuttle">
> Available values:
>
>
>
>
> Selected values:
>
> class="af_selectOrderShuttle_box" style="width:100%"
> cellpadding="0" cellspacing="0" border="0" summary="">
>
>
>
>
>
>
>
>
>
> summary="">
> class="x1i">
> name="content:shuttle1:leading" title="Available values:"
> ondblclick="TrShuttleProxy._moveItems('content:shuttle1:leading','content:shuttle1:trailing','content:j_id_jsp_709084578_0pc4');"
> onchange="TrShuttleProxy._displayDesc('content:shuttle1:leading','content:j_id_jsp_709084578_0pc4');"
> class="x1y" size="10">
> First
>
> Second
>
> Third
>
>
> ___
>
> for="content:shuttle1:leading" class="x8v">Available
> values:
>
>
>
> height="8">
>
> class="x0">Description
>
> name="content:shuttle1:leading:desc" readonly cols="18"
> wrap="soft">
> for="content:shuttle1:leading:desc"
> class="x8v">Description
>
> height="68">
>
>
>
>
>
>
>
>
>
>
>
>
> href="javascript:TrShuttleProxy._moveItems('content:shuttle1:leading','content:shuttle1:trailing');"> src="/tutoring/images/starsSkin/move.png" width="16"
> height="16" border="0" style="display:block" title="Move selected items to
> other list" alt="Move selected items to other list"> href="javascript:TrShuttleProxy._moveItems
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] 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 > > > > the ending index > > end > > java.lang.Integer > > > > ... 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$V
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:
> > >
> > >
> > >
> > > where you could write format1, format2, etc. EL functions to do the
> work.
> > >
> > > You could also do:
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > 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:
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > 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
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? 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. > > > > > > > > > > > > > > > > > > > > > > OR > > > captionText="This shouldn't appear"> > > > > > > > > > > > > > > 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: > > > > > > > > > > > > ... > > > > > > > > > > > > Thanks, > > > > > > > > Danny > > > > > > > > -- > > > > Chordiant Software Inc. > > > > www.chordiant.com > > > > > > > > > > > > > > -- > > Chordiant Software Inc. > > www.chordiant.com > > > >
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:
>
>
>
> where you could write format1, format2, etc. EL functions to do the work.
>
> You could also do:
>
>
>
>
>
>
>
>
>
> 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:
> > >
> > >
> > >
> > >
> > >
> > > 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] 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 the ending index end java.lang.Integer ... 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] 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] 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] - Javascript errors Integrating with JSF 1.2 RI / Facelets
resources *.jsf ... is wrong. It needs to be: resources /adf/* ... 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 > > > > > > 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";> > > Facelets StarterKit > > myapp > > > > javax.faces.DEFAULT_SUFFIX > > .jspx > > > > > > facelets.REFRESH_PERIOD > > 2 > > > > > > facelets.DEVELOPMENT > > true > > > > > > javax.faces.STATE_SAVING_METHOD > > server > > > > > > com.sun.faces.validateXml > > true > > > > > > com.sun.faces.verifyObjects > > true > > > > > > org.ajax4jsf.SKIN > > classic > > > > > > com.exadel.vcp.trialKey > > trial_key_goes_here > > > > > > > > > > > org.apache.myfaces.trinidad.ALTERNATE_VIEW_HANDLER > > > com.sun.facelets.FaceletViewHandler > > > > > > > > facelets.VIEW_MAPPINGS > > *.jspx > > > > > > > > trinidad > > > org.apache.myfaces.trinidad.webapp.TrinidadFilter > > > > > > > > trinidad > > Faces Servlet > > REQUEST > > FORWARD > > INCLUDE > > > > > > > > resources > > > org.apache.myfaces.trinidad.webapp.ResourceServlet > > > > > > > > resources > > *.jsf > > > > > > > > > > > > Ajax4jsf Filter > > ajax4jsf > > org.ajax4jsf.Filter > > > > > > ajax4jsf > > Faces Servlet > > REQUEST > > FORWARD > > INCLUDE > > > > > > Faces Servlet > > javax.faces.webapp.FacesServlet > > 1 > > > > > > > > Faces Servlet > > *.jsf > > > > > > > > > > > > > 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: > > > > http://java.sun.com/JSP/Page"; version="2.0" > > xmlns:f="http://java.sun.com/jsf/core"; > > xmlns:h="http://java.sun.com/jsf/html"; > > > xmlns:trh="http://myfaces.apache.org/trinidad/html"; > > xmlns:tr="http://myfaces.apache.org/trinidad"; > > >contentType="text/html;charset=utf-8"/> > > > > > > > > > > > > > > > > > > > shortDesc="Select color from pallette" > > label="Enter or select color from palette below"/> > > > > > > > > > > > > > > > > Again, I get the same issues. The javascript is broken and the transparent > image is broken. I doubt if it is a collision with RichFaces as no > components from that library are used on this page, and it seems to render > all of my other facelets pages (with Trinidad comps) in a useable way, so I > am guessing that is configured properly (as per the installation doc). > > > > Any ideas? > > > > Thanks, > > > > Rich > > > > > > > > _ > Scanned by IBM Email Security Management Services powered by MessageLabs. > For more information please visit http://www.ers.ibm.com > _
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: > > > > http://java.sun.com/JSP/Page"; version="2.0" > > xmlns:f="http://java.sun.com/jsf/core"; > > xmlns:h="http://java.sun.com/jsf/html"; > > xmlns:trh="http://myfaces.apache.org/trinidad/html"; > > xmlns:tr="http://myfaces.apache.org/trinidad"; > > > > > > > > > > > > > > > > > > > > > > shortDesc="Select color from pallette" > > label="Enter or select color from palette below"/> > > > > > > > > > > > > > > > > Again, I get the same issues. The javascript is broken and the > transparent image is broken. I doubt if it is a collision with RichFaces as > no components from that library are used on this page, and it seems to > render all of my other facelets pages (with Trinidad comps) in a useable > way, so I am guessing that is configured properly (as per the installation > doc). > > > > Any ideas? > > > > Thanks, > > > > *Rich* > > >
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 lo
Re: [Trinidad] ppr: partialTriggers doesn't work if there are validation messages?
ed, 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 state has changed such that you need updated
> > > > content?
> > > >
> > > >
> > > > -- Adam
> > > >
> > > >
> > > > On 8/28/07, Andrew Robinson wrote:
> > > > > But the action should not be immediate, only the effect of the
> re-rendering
> > > > >
> > > > > On 8/28/07, Adam Winer wrote:
> > > > > > On 8/28/07, Andrew Robinson 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
> me thod < BR>> > > > > 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 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
> > &g t; > ; > > > > 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 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:
> > > > > > > > >
> > > > > > > > > > > > > > > > id="login"
> > > > > > > > > partialSubmit="true"
> > > > > > > > > action="#{identity.login}"
> > > > > > > & gt; &g t; 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 diffe rent 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: > > > > > > > > > > layout.jspx: > > 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";> > contentType="text/html;charset=UTF-8" /> > > > > > > > > > > html > > > > > > > > > > > > body.jspf: > > 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";> > > Alpha > > > > > > > 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.ApplicationFilterChai
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:
> > > > >
> > > > > ...
> > > > >
> > > > >
> > > > >> > > > 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: > > > > > > > > > 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?
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:
> > >
> > > ...
> > >
> > >
> > >> > 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.
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.jav
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:
> text="#{Output.USER}" />
> to a single
>
> using a menu model containing definitions like this:
> 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: [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] 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("");
> > }
> > 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:
> > >
> > >
> > > Some necessary banner text
> > >
> > >
> > > Whatever the particular page requires
> > >
> > >
> > > Again, some necessary banner text
> > >
> > >
> > > 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;
> > >
> > > positi
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:
> > >
> > >
> > > > > 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";>
> > >
> > >
> > > > > 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" />
> > >
> > > 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);
> > >
> > > > > contentType="text/html;charset=UTF-8" />
> > >
> > > > > http-equiv="Content-Type"
> > > content="text/html; charset=UTF-8" />
> > > > > path="#{NMSPanelPageUtil.cssLocation}" />
> > >
> > >
> > >
> > >
> > >
> > >
> > >
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;j >
> >
> >
> > 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:
> > >
> > > > > action="#{WorkingTaskAdmin.addNewWorkingTask}"
> > > focusViewId="/service/workingTaskWizard.xhtml" />
> > >
> > >
> > > but if i press this button then everything works as expected.
> > > > > action="#{WorkingTaskAdmin.addNewWorkingTask}" />
> > >
> > >
> > > I'm using trinidad 1.0.3-core trunk.
> > >
> >
> >
>
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;j
>
>
> 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:
> >
> > > action="#{WorkingTaskAdmin.addNewWorkingTask}"
> > focusViewId="/service/workingTaskWizard.xhtml" />
> >
> >
> > but if i press this button then everything works as expected.
> > > action="#{WorkingTaskAdmin.addNewWorkingTask}" />
> >
> >
> > I'm using trinidad 1.0.3-core trunk.
> >
>
>
Re: [Trinidad] tabIndex support?
It's http://issues.apache.org/jira/browse/TRINIDAD-100. I guess it's mostly not there because of some of the huuuge shortcomings of this HTML API, especially when it comes to big composite components like table; if you set a tabindex on the table, it has to affect the tab order of the whole component, not just one select HTML element. So it's not just as simple as slapping a tabindex attribute on some element, which is why it's never been tackled. That said, tabindex="0" and tabindex="-1" are really handy. -- Adam On 8/23/07, Andrew Robinson <[EMAIL PROTECTED]> wrote: > I don't see any support for tabIndex on trinidad components like > tr:inputText. Is there another way of handling tab order in trinidad > components or is it a shortcoming? > > -Andrew >
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.DocumentRenderer
> {
>
> /**
>*
>*/
> public DocumentRenderer()
> {}
>
> /**
>* @param type
>*/
> public DocumentRenderer(Type type)
> {
> super(type);
> }
>
> /**
>* @see
> org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.DocumentRenderer#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("");
> }
> 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:
> >
> >
> > Some necessary banner text
> >
> >
> > Whatever the particular page requires
> >
> >
> > Again, some necessary banner text
> >
> >
> > 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 th
