Does af:decorativeBox exist in Trinidad
Does the adf control af:decorativeBox exist in Trinidad. I can't see it documented anywhere. Thanks Martin -- View this message in context: http://www.nabble.com/Does-af%3AdecorativeBox-exist-in-Trinidad-tp22107671p22107671.html Sent from the MyFaces - Users mailing list archive at Nabble.com.
t:selectItems still seems to need a converter
I was wondering if t:selectItems could be enhanced to work without a
converter because it has the list of all the domain objects.
My code is similar to this:
h:selectOneMenu value=#{order.carPart}
t:selectItems value=#{carParts} var=part itemValue=#{part}
itemLabel=#{part.name} /
/h:selectOneMenu
public class Order {
private CarPart carPart;
...
}
t:selectItems automatically generates SelectItem objects for us but it would
be nice if it also allowed objects to be assigned to the actual
selectOneMenu e.g. order.carPart value without requiring a Converter. Is it
possible?
I tried and get a null Converter error.
Thanks
Martin
--
View this message in context:
http://www.nabble.com/t%3AselectItems-still-seems-to-need-a-converter-tp19411254p19411254.html
Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: t:selectItems still seems to need a converter
I see what you are saying. However there do seem to be some components/tags
which handle object mapping automagically e.g.
f:setPropertyActionListener value=#{part} target=#{order.carPart} /
I realise that tags like setPropertyActionListener are not used with
selectOneMenu/selectItems but it is used with other lists e.g. tables, and I
wonder that if setPropertyActionListener can keep a map between html values
and backing objects then maybe it could be done elsewhere.
Kind regards
Martin
Simon Kitching wrote:
Hi,
JSF must send down to the browser a list of (label,value) pairs for the
user to select from, and then on postback the browser sends back the
value part of the selected item. The label and value must both be
strings; this is required by html. Therefore a converter of some sort is
definitely needed in order to generate appropriate value strings for
the items when rendering the page, and on postback the renderer must be
able to map back from the selected value to the appropriate item object.
Doing this conversion automatically is clearly not possible, so an
appropriate converter must be provided. For the case where the items to
be selected from are persistent entities, the converter should generally
write out the key of the object, and on postback retrieve the object
using the key.
Maybe one option is for the select* components on render to use the
index into the list of items as the value. Then on postback, as long as
the same list of objects is available then it could map back from index
to object. This would need some more thought though; for example this is
valid:
h:selectOneMenu
f:selectItem ..
f:selectItems ..
f:selectItem ..
/h:selectOneMenu
which would complicate computing an index. And I think this
functionality would need to be in the t:selectOneMenu etc, as the
t:selectItems component is only used at render time, and is not used to
process the postback data AFAIK. Or this idea may be complete rubbish; I
haven't thought about it for long..
As Cagatay says, you can register a global converter for each of your
persistent classes within a faces-config.xml file. Then it will be used
automatically rather than you having to define the converter within each
t:selectItems or f:selectItems tag.
Regards,
Simon
Cagatay Civici schrieb:
Conversions are the nature of jsf so it really makes sense to use a
converter for t:selectItems.
Generally the common solution is two write a generic jpa entity
converter if you are using jpa with jsf.
Using the converter-for-class kinda config once, you dont need to
define the converter each time you use it.
On Wed, Sep 10, 2008 at 7:22 AM, mjdenham [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
I was wondering if t:selectItems could be enhanced to work without a
converter because it has the list of all the domain objects.
My code is similar to this:
h:selectOneMenu value=#{order.carPart}
t:selectItems value=#{carParts} var=part itemValue=#{part}
itemLabel=#{part.name http://part.name} /
/h:selectOneMenu
public class Order {
private CarPart carPart;
...
}
t:selectItems automatically generates SelectItem objects for us
but it would
be nice if it also allowed objects to be assigned to the actual
selectOneMenu e.g. order.carPart value without requiring a
Converter. Is it
possible?
I tried and get a null Converter error.
Thanks
Martin
--
View this message in context:
http://www.nabble.com/t%3AselectItems-still-seems-to-need-a-converter-tp19411254p19411254.html
Sent from the MyFaces - Users mailing list archive at Nabble.com.
--
View this message in context:
http://www.nabble.com/t%3AselectItems-still-seems-to-need-a-converter-tp19411254p19412905.html
Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: t:selectItems still seems to need a converter
Sorry, my example was quite poor. I was thinking of instances when
setPropertyActionListener is used with lists of items and one specific
object from the list has to be selected before assignment e.g.
rich:dataTable value=#{allPartsList} var=part
rich:column
h:outputText value=#{part.name}/
/rich:column
rich:column
h:commandButton value=Select action=#{order.send}
f:setPropertyActionListener value=#{part}
target=#{order.carPart} /
/h:commandButton
/rich:column
/rich:dataTable
So the above starts with a list i.e. allPartsList and ends up with one list
item from the original list being selected and assigned which seems to be
similar to what a SelectOneMenu should do but it is a DataTable.
I don't understand how clicking a button in a DataTable finds the correct
object but selecting an item in a selectOneMenu can only find the id of the
selected object and not the object itself.
Regards
Martin
Cagatay Civici wrote:
SetPropertyActionListener is a different case, it just resolves the part
and
assigns it to order.carPart when a command is executed.
If not immediate, actionlisteners are fired at invoke application phase
and
at this point any type of conversion is already completed.
So actually setPropertyActionListener does not know about html.
On Wed, Sep 10, 2008 at 8:51 AM, mjdenham [EMAIL PROTECTED] wrote:
I see what you are saying. However there do seem to be some
components/tags
which handle object mapping automagically e.g.
f:setPropertyActionListener value=#{part} target=#{order.carPart} /
I realise that tags like setPropertyActionListener are not used with
selectOneMenu/selectItems but it is used with other lists e.g. tables,
and
I
wonder that if setPropertyActionListener can keep a map between html
values
and backing objects then maybe it could be done elsewhere.
Kind regards
Martin
Simon Kitching wrote:
Hi,
JSF must send down to the browser a list of (label,value) pairs for the
user to select from, and then on postback the browser sends back the
value part of the selected item. The label and value must both be
strings; this is required by html. Therefore a converter of some sort
is
definitely needed in order to generate appropriate value strings for
the items when rendering the page, and on postback the renderer must be
able to map back from the selected value to the appropriate item
object.
Doing this conversion automatically is clearly not possible, so an
appropriate converter must be provided. For the case where the items to
be selected from are persistent entities, the converter should
generally
write out the key of the object, and on postback retrieve the object
using the key.
Maybe one option is for the select* components on render to use the
index into the list of items as the value. Then on postback, as long as
the same list of objects is available then it could map back from index
to object. This would need some more thought though; for example this
is
valid:
h:selectOneMenu
f:selectItem ..
f:selectItems ..
f:selectItem ..
/h:selectOneMenu
which would complicate computing an index. And I think this
functionality would need to be in the t:selectOneMenu etc, as the
t:selectItems component is only used at render time, and is not used to
process the postback data AFAIK. Or this idea may be complete rubbish;
I
haven't thought about it for long..
As Cagatay says, you can register a global converter for each of your
persistent classes within a faces-config.xml file. Then it will be used
automatically rather than you having to define the converter within
each
t:selectItems or f:selectItems tag.
Regards,
Simon
Cagatay Civici schrieb:
Conversions are the nature of jsf so it really makes sense to use a
converter for t:selectItems.
Generally the common solution is two write a generic jpa entity
converter if you are using jpa with jsf.
Using the converter-for-class kinda config once, you dont need to
define the converter each time you use it.
On Wed, Sep 10, 2008 at 7:22 AM, mjdenham [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
I was wondering if t:selectItems could be enhanced to work without
a
converter because it has the list of all the domain objects.
My code is similar to this:
h:selectOneMenu value=#{order.carPart}
t:selectItems value=#{carParts} var=part
itemValue=#{part}
itemLabel=#{part.name http://part.name} /
/h:selectOneMenu
public class Order {
private CarPart carPart;
...
}
t:selectItems automatically generates SelectItem objects for us
but it would
be nice if it also allowed objects to be assigned to the actual
selectOneMenu e.g. order.carPart value without requiring a
Converter. Is it
possible?
I tried
Re: t:selectItems still seems to need a converter
Apologies, I posted my previous e-mail before reading this. Yes I agree it
would be a nice enhancement if select components were to support
select-values being indexes into a data model.
Thanks
Martin
Simon Kitching wrote:
Hi Martin,
Unfortunately this is not the same situation.
A setPropertyActionListener is simply attached to a command component.
And a command-component is simply either triggered or not triggered.
When the command-component is triggered, the listeners run. The
setPropertyActionListener reads its value attribute and writes to its
target attribute; neither the command component nor the listener keep
maps of backing objects or anything similar. Even within a table, this
is what happens. However in that case, the value attribute will point at
the var variable of the table, and it is the table that magically sets
that up appropriately to point to the right row-object.
Actually, the implementation of table is somewhat like my suggestion
below for rendering a list index as the select value. The table does
indeed simply assume that row1 of the data posted back matches row1 of
the object-list held by the backing bean. So it could be argued that
having Select components support select-values being indexes into a
data model is reasonable and consistent with table behaviour. But
certainly nothing like that is implemented at the moment.
Regards,
Simon
mjdenham schrieb:
I see what you are saying. However there do seem to be some
components/tags
which handle object mapping automagically e.g.
f:setPropertyActionListener value=#{part} target=#{order.carPart} /
I realise that tags like setPropertyActionListener are not used with
selectOneMenu/selectItems but it is used with other lists e.g. tables,
and I
wonder that if setPropertyActionListener can keep a map between html
values
and backing objects then maybe it could be done elsewhere.
Kind regards
Martin
Simon Kitching wrote:
Hi,
JSF must send down to the browser a list of (label,value) pairs for the
user to select from, and then on postback the browser sends back the
value part of the selected item. The label and value must both be
strings; this is required by html. Therefore a converter of some sort is
definitely needed in order to generate appropriate value strings for
the items when rendering the page, and on postback the renderer must be
able to map back from the selected value to the appropriate item
object.
Doing this conversion automatically is clearly not possible, so an
appropriate converter must be provided. For the case where the items to
be selected from are persistent entities, the converter should generally
write out the key of the object, and on postback retrieve the object
using the key.
Maybe one option is for the select* components on render to use the
index into the list of items as the value. Then on postback, as long as
the same list of objects is available then it could map back from index
to object. This would need some more thought though; for example this is
valid:
h:selectOneMenu
f:selectItem ..
f:selectItems ..
f:selectItem ..
/h:selectOneMenu
which would complicate computing an index. And I think this
functionality would need to be in the t:selectOneMenu etc, as the
t:selectItems component is only used at render time, and is not used to
process the postback data AFAIK. Or this idea may be complete rubbish; I
haven't thought about it for long..
As Cagatay says, you can register a global converter for each of your
persistent classes within a faces-config.xml file. Then it will be used
automatically rather than you having to define the converter within each
t:selectItems or f:selectItems tag.
Regards,
Simon
Cagatay Civici schrieb:
Conversions are the nature of jsf so it really makes sense to use a
converter for t:selectItems.
Generally the common solution is two write a generic jpa entity
converter if you are using jpa with jsf.
Using the converter-for-class kinda config once, you dont need to
define the converter each time you use it.
On Wed, Sep 10, 2008 at 7:22 AM, mjdenham [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
I was wondering if t:selectItems could be enhanced to work without
a
converter because it has the list of all the domain objects.
My code is similar to this:
h:selectOneMenu value=#{order.carPart}
t:selectItems value=#{carParts} var=part itemValue=#{part}
itemLabel=#{part.name http://part.name} /
/h:selectOneMenu
public class Order {
private CarPart carPart;
...
}
t:selectItems automatically generates SelectItem objects for us
but it would
be nice if it also allowed objects to be assigned to the actual
selectOneMenu e.g. order.carPart value without requiring a
Converter. Is it
possible?
I tried and get a null Converter error
Re: Rendered attribute on SelectItem
Hi Gerhard, Yes, that is more or less what I ended up with, but for efficiency I only update the lists in the backing bean when one of the triggers which the list content depends on changes. I use a4j:support to fire the trigger to update the list and the a4j:support rendered attribute to cause the associated lists to be re-fetched if they are on the same page. However, having an attribute similar to rendered on SelectItem would have simplified things and been quite elegant. Regards Martin -- View this message in context: http://www.nabble.com/Rendered-attribute-on-SelectItem-tf4770641.html#a13730484 Sent from the MyFaces - Users mailing list archive at Nabble.com.
Rendered attribute on SelectItem
Hi, I was looking for SelectItem.rendered so that some items can be optionally hidden. Unfortunately SelectItem.rendered is not supported. Has anybody considered this functionality before? I have a form with about 80 SelectOneMenu components on it and lots of relationships between the components and the list items. Thanks Martin -- View this message in context: http://www.nabble.com/Rendered-attribute-on-SelectItem-tf4770641.html#a13646127 Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: Partial submit is not working on Weblogic 10
Weblogic 10 does not come with jstl enabled by default. Here is a link which describes the process: http://edocs.bea.com/wls/docs100/webapp/configurejsfandjtsl.html Unfortunately I had other problems after this one and reverted to Jsf RI 1.2 and RichFaces. Kind regards Martin slb wrote: I am experiencing a similiar issue. What did you mean by enabling jstl 1.2? I worked out that you need to enable the jstl 1.2 shared library in Weblogic 10 as it is not enabled by default. -- View this message in context: http://www.nabble.com/Partial-submit-is-not-working-on-Weblogic-10-tf4465921.html#a13512330 Sent from the MyFaces - Users mailing list archive at Nabble.com.
Partial submit is not working on Weblogic 10
I downloaded trinidad-demo-1.2.2 and tried to run it on Weblogic 10. First of all I received java.lang.NoClassDefFoundError: javax/servlet/jsp/jstl/core/Config so I added jstl.jar from jakarta-taglibs-standard-1.1.2.zip Then the demo appeared to run without problems but nothing happens when I click on any of the tabs on panelTabbed.jspx, navigationPane.jspx, or panelAccordion.jspx. It seems none of the partial submits work. The last tab on navigationPane.jspx with the title 'Component Guide' does not do a partial submit and it works fine. Also, interestingly, if I click on a tab and then hit Page-refresh the tab changes. Please help. Thanks. Martin -- View this message in context: http://www.nabble.com/Partial-submit-is-not-working-on-Weblogic-10-tf4465921.html#a12733657 Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: Partial submit is not working on Weblogic 10
No, myfaces 1.2 is packed in the demo war. Weblogic 10 comes with the 1.2 ri but it is not the latest and is not installed by default. Matthias Wessendorf-4 wrote: looks like a myfaces 1.2 issue, java.lang.IllegalStateException: strict servlet API: cannot call getWriter() after getOutputStream(). just interested, is weblogic 10 shipping myfaces 1.2 as their JSF impl ? -M On 9/17/07, mjdenham [EMAIL PROTECTED] wrote: I worked out that you need to enable the jstl 1.2 shared library in Weblogic 10 as it is not enabled by default. Now I get the following exception when redeploying the demo app: java.lang.IllegalStateException: strict servlet API: cannot call getWriter() after getOutputStream() at weblogic.servlet.internal.ServletResponseImpl.getWriter(ServletResponseImpl.java:297) at javax.servlet.ServletResponseWrapper.getWriter(ServletResponseWrapper.java:122) at org.apache.myfaces.application.jsp.JspViewHandlerImpl.renderView(JspViewHandlerImpl.java:317) at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:45) at org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:175) Truncated. see log file for complete stacktrace Any ideas? Thanks Martin Matthias Wessendorf-4 wrote: Hi, On 9/17/07, mjdenham [EMAIL PROTECTED] wrote: I downloaded trinidad-demo-1.2.2 and tried to run it on Weblogic 10. First of all I received java.lang.NoClassDefFoundError: javax/servlet/jsp/jstl/core/Config so I added jstl.jar from jakarta-taglibs-standard-1.1.2.zip Trinidad 1.2.x is designed to work with JSF 1.2 / JavaEE 5. So, the JSTL version 1.2 is provided by the container. Doesn't Weblogic 10 do so ? Then the demo appeared to run without problems but nothing happens when I click on any of the tabs on panelTabbed.jspx, navigationPane.jspx, or panelAccordion.jspx. It seems none of the partial submits work. just tested this: http://example.irian.at/trinidad-demo-20070917/faces/components/panelTabbed.jspx works for me. do you get any infos in the log? I recommend to use firebug, to see if there is a partial submit, via XHR (XmlHttpRequest object) -Matthias The last tab on navigationPane.jspx with the title 'Component Guide' does not do a partial submit and it works fine. Also, interestingly, if I click on a tab and then hit Page-refresh the tab changes. Please help. Thanks. Martin -- View this message in context: http://www.nabble.com/Partial-submit-is-not-working-on-Weblogic-10-tf4465921.html#a12733657 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 -- View this message in context: http://www.nabble.com/Partial-submit-is-not-working-on-Weblogic-10-tf4465921.html#a12734893 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 -- View this message in context: http://www.nabble.com/Partial-submit-is-not-working-on-Weblogic-10-tf4465921.html#a12735601 Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: Partial submit is not working on Weblogic 10
I worked out that you need to enable the jstl 1.2 shared library in Weblogic 10 as it is not enabled by default. Now I get the following exception when redeploying the demo app: java.lang.IllegalStateException: strict servlet API: cannot call getWriter() after getOutputStream() at weblogic.servlet.internal.ServletResponseImpl.getWriter(ServletResponseImpl.java:297) at javax.servlet.ServletResponseWrapper.getWriter(ServletResponseWrapper.java:122) at org.apache.myfaces.application.jsp.JspViewHandlerImpl.renderView(JspViewHandlerImpl.java:317) at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:45) at org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:175) Truncated. see log file for complete stacktrace Any ideas? Thanks Martin Matthias Wessendorf-4 wrote: Hi, On 9/17/07, mjdenham [EMAIL PROTECTED] wrote: I downloaded trinidad-demo-1.2.2 and tried to run it on Weblogic 10. First of all I received java.lang.NoClassDefFoundError: javax/servlet/jsp/jstl/core/Config so I added jstl.jar from jakarta-taglibs-standard-1.1.2.zip Trinidad 1.2.x is designed to work with JSF 1.2 / JavaEE 5. So, the JSTL version 1.2 is provided by the container. Doesn't Weblogic 10 do so ? Then the demo appeared to run without problems but nothing happens when I click on any of the tabs on panelTabbed.jspx, navigationPane.jspx, or panelAccordion.jspx. It seems none of the partial submits work. just tested this: http://example.irian.at/trinidad-demo-20070917/faces/components/panelTabbed.jspx works for me. do you get any infos in the log? I recommend to use firebug, to see if there is a partial submit, via XHR (XmlHttpRequest object) -Matthias The last tab on navigationPane.jspx with the title 'Component Guide' does not do a partial submit and it works fine. Also, interestingly, if I click on a tab and then hit Page-refresh the tab changes. Please help. Thanks. Martin -- View this message in context: http://www.nabble.com/Partial-submit-is-not-working-on-Weblogic-10-tf4465921.html#a12733657 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 -- View this message in context: http://www.nabble.com/Partial-submit-is-not-working-on-Weblogic-10-tf4465921.html#a12734893 Sent from the MyFaces - Users mailing list archive at Nabble.com.
