JSF & converters

Hello, sorry for my bad english.
I don't understand something.
Use a outputText for example, and bind its value to an Integer for example, already instanciated in the backing bean.
Then, set a DateConverter to this outputText and display the page, you will see that your inputText displays a Date, that have probably been instancied by JSF.
I no really have problem with this, but when I look at the DateConverter code of the sun reference implementation, I don't see any new date instanciation. I even have the feeling that a ConverterException should be thrown.
So, I would know where is this date create, and why.
Do you know more about this?
If no, do you know if there is "log mode" that could help me see which methods are called?
Thanks in advance.

But here, the converter is used to display something from the backing bean, not to convert a string as an object.
So you say that, if the attribute is not of the correct type ( an Integer and not a Date), then the converter will first use getAsObject???
In the getAsObject method, a parser is used to parse "value", and if value is not a date, this should send a ConverterError in my advice. Or parser.parse(value) could eventually send a new Date if value is not an instance of Date...
I don't exactly know.
Thanks for answers.

Similar Messages

Injecting EJB to JSF Converter

Is it possible to inject EJB (or at least EntityManager) to JSF Converter or Validator?
I don't know if i'm missing something or is it just impossible - it works when injecting EJB into Managed Bean.
Thanks.
Sławek S.

Slawek_Sobotka wrote:
Thanks.
So I'll redefine my question to be problem oriented:
I have SelectItem that contains Address object.
I have implemented AddressConverter so that it converts Adress to String simply by using it's id.
How to convert back: from string (address's id) do Address object?Map it. Two general ways are mentioned here: [http://balusc.blogspot.com/2007/09/objects-in-hselectonemenu.html].
I would like to load it form DB...That's a bit too expensive for less or more static data.
Another solutions are:
- SelectItem should contain address.id instead of address. Than no converter is need. My ManagedBean is reposnsible for translating ids do entities. Works but primitive.JSF can't help that HTTP/HTML only understands Strings (by the way, primitives are also already implicitly converted by EL, you only don't know that).
- Converter is created by factory method of Managed Bean. MB sets address list to the converter while creating it. List shouldn't be huge if it is used in GUI.
drawback: loading list in BB twice because converter is used while rendering and while decoding.
- In converter try to possess MB that has EJB and call method that reutrns entities, sth like this: facesContext.getApplication().getELResolver()...Reloading static data on every request makes als no sense.
Retoric question: what for are useful JSF Converters?To convert between Object and String, so that it can be passed through HTTP request/response and displayed/taken in HTML.

How to display and edit the clob datatype column from Data base

Hi ,
I have a requiremsnt as below
1) One Table having some columns with CLOB data type along with varchar columns
2) need to display the data from DB in search screen and need to be edited clob column in edit screen
I created EO and VO with that Table and how to display the clob value into the input box for editing.
using Jdev 11.1.1.5.0 version.
Can you please help on this.
THanks & REgards,
Madhu

Hi,
If you are using an inputText component to display a Character Large Object (CLOB), then you will need to create a custom converter that converts the CLOB to a String.
For custom convertor refer below link,
http://docs.oracle.com/cd/E2438201/web.1112/e16181/af_validate.htm#BABGIEDH
(section7.4 Creating Custom JSF Converters)
Thanks,
Santosh M E

ANNOUNCE: Martin Marinschek on MyFaces 2.0, IRIAN, and Related Topics

Hello,
In this podcast, JSFCentral editor-in-chief Kito D. Mann talks with Martin Marinschek about MyFaces, IRIAN, and related topics. This interview was recorded in December of 2009 at the JSF Summit conference in Orlando, Florida. Here is an excerpt:
Kito: Lets talk a little bit about the project. MyFaces was originally just an implementation but now it has grown into a very large set of projects. Tell us a bit about some of the different projects that are part of the MyFaces umbrella.
Martin: I hope I dont miss anything. Of course there is the core MyFaces implementation and API. For the JSF implementation you have to do the API and the Impl, so it is actually two jars which are developed in the core section. Then there are the three component libraries: Trinidad, Tomahawk, and Tobago. Then there is Orchestra, which is a conversation scope implementation for long running conversations with integration to JPA as well. Then there is the JSF Portlet Bridge, and there is ExtVal validation integration for JSF, where you can put annotations on your managed beans and domain objects. It will directly be converted into JSF converters and validators, pretty nicely done. Now that bean validation has been standardized, it is also an implementation of bean validation, so you can use the bean validation annotations together with ExtVal.
Read the full article here: http://www.jsfcentral.com/articles/marinschek-03-10.html
Kito D. Mann -- Author, JavaServer Faces in Action
http://twitter.com/kito99 http://twitter.com/jsfcentral
http://www.virtua.com - JSF/Java EE consulting, training, and mentoring
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
+1 203-404-4848 x3

We are pleased to announce that Target Management 3.0M5 is available for
download.
News for Users include
* UI for viewing and changing file permissions and owner on UNIX
* SSH Keepalive mechanism
* Link with Editor action fixed
* Ctrl+Space Field Assist for history in the Terminal input field
On the internals, TM 3.0M5 provides faster startup and reduced footprint
thanks to improved lazy loading of filter pools; and the SystemRegistry
implementation has moved to non-UI plugins for improved UI/Non-UI
Separation.
See the build notes for more information:
http://download.eclipse.org/dsdp/tm/downloads/drops/S-3.0M5- 200802181400/
As always, the build is available for download and on the TM milestone
update site, and will be on the Ganymede Update Site soon.
Enjoy!
Martin Oberhuber
Wind River Systems, Inc.
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm

Avoiding f:convertDateTime/af:convertDateTime override

Hi,
According to http://www.oracle.com/webapps/online-help/jdeveloper/10.1.3/state/content/navId.4/navSetId._/vtTopicFile.jsf_apps%7Cadfcreate%7Caf_aconvertdatetimetag~html/
ADF overrides the Date converter ID so calls to f:convertDateTime call af:convertDateTime instead. I want to undo this override because the ADF date/time converter throws up intrusive error popups if the item doesn't parse when all I really want is a tasteful error message displayed by the control. Stock JSF converters and validators do this, but ADF is forcing me to use its.
How can I do this?
Thanks

No. I'm using EJB3.0. I'm not sure what you mean by having a date format set at the entity object. How would I go about that?
I have a date format set in my selectInputDate, which works nicely, so when I select a date from the popup it will correctly enter say "01-JAN-07" into the box. But when I click submit, it gives me a date validation error, because it is validating against my locale (I think). I just need to know how to specify the date pattern to the validation routine. Do I need to write my own converter? This is my selectInputDate:
<af:selectInputDate value="#{bindings.dateRequired.inputValue}"
label="#{field_labels[\'HardwareRequest.dateRequired\']}"
required="#{bindings.dateRequired.mandatory}"
columns="#{bindings.dateRequired.displayWidth}"
binding="#{backing_app_smurf_HardwareRequestNew.inputText4}"
id="inputText4">
<af:validator binding="#{bindings.dateRequired.validator}"/>
<af:convertDateTime pattern="#{format.date}"/>
</af:selectInputDate>
Am I the only one that thinks using JDeveloper is like playing with Russian dolls?
R

InputDate : adding custom convertor

Hi,
inputDate component is returning the date in "MM/dd/yyyy" format, if I don't attach any converter to it.
Ex:
<af:inputDate label="Date of Birth" id="id1"/>           But it is returning the date in long format(ex: Wed Jan 30 00:00:00 UTC+0530 2013) when I add a converter to it. I have created a customDateConverter by extending DateTimeConverter to take care of formatting display and store date formats in getAsObject() and getAsString() methods.
<af:inputDate label="Date of Birth">
                <f:converter converterId="customDateConverter"/>
                </af:inputDate>         Why it is returning date in long format when I add a custom converter? How can I control the calender date format when a custom converter is added?
Thanks in advance for your help
Edited by: user13331987 on Jan 30, 2013 6:31 AM

I will try to explain again. What is misunderstood is that you should have two separate conversions - a conversion between XML file's format "yyyy-MM-dd" and a java.util.Date object and a conversion between a java.util.Date object and a string in format "MM-dd-yyyy". The 1st one must be done when you read/write from/to the XML file and load/store the value into/from a some kind of a Model layer. The 2nd one happens between the server-side <af:inputDate> component's local value and the string displayed/entered in the HTML field on the screen during the JSF's APPLY_REQUEST_VALUES phase. The 2nd conversion is performed by a JSF converter, but the 1st one cannot be done using a JSF converter and it has to be done in other way. Please, look at the details below:
You must have some kind of a Model layer (for example, a backing bean) that supplies the <af:inputDate> component with a value of java.util.Date datatype.
import java.util.Date;
public class MyBean {
private Date myDateValue;
public Date getMyDateValue() {
    return myDateValue;
public void setMyDateValue(Date value) {
    myDateValue = value;
<af:inputDate value="#{MyBean.myDateValue}" ...>The datatype of the value must be java.util.Date, it cannot be java.lang.String because the "value" attribute of <af:inputDate> does not accept String. It is your responsibility to read the necessary date literal (which is in format "yyyy-MM-dd") from the XML file, to convert the string to java.util.Date and to load the value into the corresponding bean property when you navigate to the necessary record. Also it is your responsibility to convert the bean property's java.util.Date value to a string representation in format "yyyy-MM-dd" when storing it back to the XML file. You can do that using a standard Java formatter class (e.g. java.text.SimpleDateFormat) if you read/write the XML file directly in code (e.g. when you do not use any framework for marshaling/unmarshaling XML files). You cannot use a JSF converter here because JSF converters are serve different purpose.
Then you must define a JSF converter on the <af:inputDate> component in order to convert the internal value of the JSF component (which is of type java.util.Date) to a readable string representation displayed/entered in the input field on the screen in format "MM-dd-yyyy":
<af:inputDate value="#{MyBean.myDateValue}" ...>
<af:convertDateTime pattern="MM-dd-yyyy"/>
</af:inputDate>Dimitar
Edited by: Dimitar Dimitrov on Jan 30, 2013 9:06 PM
Edited by: Dimitar Dimitrov on Jan 30, 2013 9:12 PM

JSF 1.2 Converters in Tomcat 6.0.2

When running the jsf-cardemo web app that comes with JSF 1.2 on Tomcat 6.0.2, I get an exception when loading the customerInfo.jsp page (see below). Not sure if this is an issue with Tomcat or not.
org.apache.jasper.JasperException: /customerInfo.jsp(157,0) Cannot coerce value (creditCardConverter) to type (javax.faces.convert.Converter) for attribute converter.
     org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:40)
     org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:406)
     org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:255)
     org.apache.jasper.compiler.Validator$ValidateVisitor.checkXmlAttributes(Validator.java:1080)
     org.apache.jasper.compiler.Validator$ValidateVisitor.visit(Validator.java:818)
     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:837)
     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:837)
     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:837)
     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:837)
     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.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:1679)
     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.java:566)
     org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:314)
     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)
     com.sun.faces.context.ExternalContextImpl.dispatch(ExternalContextImpl.java:413)
     com.sun.faces.application.ViewHandlerImpl.executePageToBuildView(ViewHandlerImpl.java:480)
     com.sun.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:125)
     com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:133)
     com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:244)
     com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:140)
     javax.faces.webapp.FacesServlet.service(FacesServlet.java:245)

I'd log a bug with the Tomcat folks. This is working fine in GlassFish's JSP implementation.

How to custom a conversion error in JSF page in JDeveloper

According to the book "Core JavaServer Faces" p213 (fifth edition), if I add the following line to messages.properties file, and specifiy it in the faces-config.xml and .jsp file, then the displayed conversion error message should be my tailored one instead of the default. However, I still get the default error message. Besides, I didn't find "CONVERSION" variable in UIInput class. Is the book wrong? And what's the correct way?
javax.faces.component.UIInput.CONVERSION=Please correct your input

I didn't choose any special in JDeveloper IDE. I just selected "new" to create a file called "message.properties" and put the line there. I didn't specify converters excepts declaring the type in the Jave Beans. I guess the converting is done by the JSF framework automatically. It must be a JSF converter since I created the page as a JSF page.

A new approach to JSF error handling?

Hi.
I would like to run an idea by the community to check that I am not being crazy in doing this stuff. I would appreciate any comments, criticism or ideas.
I was thinking about JSF's error processing mechanism, specifically about how label text gets associated with an input field. So, I am talking about this kind of stuff:
<h:outputLabel for="firstName" value='#{msgs["applicant.search.firstName"]}: ' />
<h:inputText id="firstName" value='#{applicantDetailsBackingBean.firstName}' required=�true�/>If the value is not entered into the input field, we will get an error message saying:
�First Name�: is required.
So HtmlMessageRenderer has replaced the field id in the FacesMessage with the label text by using the association set up with the 'for' attribute on the label. All of this message "decoration" work happens in the RENDER phase in a centralized location. I see a couple of weaknesses in this approach
1) It is too late for resolving label text data if the label is inside a data table
2) JSF establishes associations between label text and the input fields by using the label components to point to their input fields. Although this seems more natural, it limits label text sources to just the label components present on the current page (or whatever is nested under them), which makes it impossible to associate input field messages with label text that does not exist on the page in its entirety.
Let's look at a couple examples, both of which I ran into in my application:
1) Consider a situation in which we have a dataTable where every row consists of a student name and an input field for entering their assignment mark. The validation on the input field will be restricted to valid letter grades only. If the user enters an invalid grade, we want them to see an error message of the form: +�The mark entered for <student name> is invalid�.+ Since <student name> is dependent on the row in which the error occurred, this error message is not possible to generate with bare JSF functionality.
2) Another situation that gets us in trouble is when the label text we want in our error message is not on the page (or not in it's entirety). For example, your page could be split up into multiple parts with those parts having input fields with the same name. We would want the error message to include the page part as well as the field name. This is not easily achieved with the bare JSF functionality.
So to generalize, any situation where a label component with a static value throughout the lifecycle is not available will cause difficulty.
Please correct me if I am wrong on any of these points.
Since in my app I had a lot of complicated pages to deal with, I solved my difficulties by writing a very simple framework that I called Message Decorator Framework (MDF). It enabled me to easily construct much more detailed error messages than what the standard JSF approach seems to allows for. MDF provides a mechanism to specify the label text to be applied to a validation or a conversion message by either a literal, an el expression or via an id of another ValueHolder and all of these work in data tables.
The idea is a s such, and this is what i would like your opinion on:
MDF provides more flexible message decoration by adapting the opposite approach to the one used by the JSF:
1) Message decoration is decentralized. MDF wraps converters and validators on individual input fields and performs message text replacement right on the spot in the PROCESS_VALIDATIONS phase, when all of the pertinent data for resolving the label text is still available.(i.e the components in data tables would still have the correct values for the current row being validated)
2) The label text to be used is specified by the input field, not the label. This allows the developer to reference any text value, instead of tying them to a specific label component.
Pictures are better than words, so here is an architectural diagram:
http://www.imagehosting.com/out.php/i1259440_ArchitectureDiagram.png
The framework consists of two main classes, ConverterMessageDecorator and ValidatorMessageDecorator. I will just talk about the converter part, b/c the validator part is very similar but wraps a list of validators instead of one converter.
So ConverterMessageDecorator is a JSF converter. Its purpose is to wrap the converter that is going to do the actual conversion work and decorate the FacesMessage inside ConverterException if one was thrown.
The converter to wrap can be either determined automatically based on the type of the value reference of the input field or specified explicitly. This converter decorates the message by replacing all instances of the input field�s id with the resolved label text. The power of this approach is that not only do you get a much more flexible way to specify what the label text is (either fieldLabel or fieldLabelComponent attributes), but now data tables are no longer a problem.
Here are some usage examples:
<h:inputText value='#{section33SetupBackingBean.contribution.sampleGatePct}'>
   <md:decorateConverterMessage fieldLabel= '#{msgs["section.34.setup.contribution.initial.sampling.gate.max.size"]}' />
</h:inputText>
�etc�
<h:inputText value='#{section33SetupBackingBean.payment.sampleGatePct}'>
   <md:decorateConverterMessage fieldLabel= '#{msgs["section.34.setup.payment.initial.sampling.gate.max.size"]}' />
</h:inputText>The two input fields have exactly the same labels on the screen (they are in two different parts of the page), so if we used their respective labels, the error messages would look the same for these two input fields.
More complicated example:
<h:dataTable value="#{paymentCalcBackingBean.currentPaymentPercentages}" var="currentPercentage" >
<h:column>
<ops:refDataDescription id="provinceLabelTextId" refDataType="provinceStateType"
            code="${currentPercentage.programProvince.provinceStateTypeCode}" />
</h:column>
<h:column>
<h:inputText value="${currentPercentage.federalPercentage}">
<md:decorateConverterMessage fieldLabelComponent="provinceLabelTextId" valueRequired="true" >
   <f:converter converterId="ops.PercentageConverter" />
</md:decorateConverterMessage>
<md:decorateValidatorMessage fieldLabelComponent="provinceLabelTextId" >
   <f:validator validatorId="ops.PercentageValidator" />
</md:decorateValidatorMessage>
</h:column>
�etc�
</h:dataTable>This would produce errors shown in this screenshot: http://www.imagehosting.com/out.php/i1259418_Example3.png
Here is another example that shows off what you can do by referencing other ValueHolders on the page.
The code is exactly the same as the snippet shown above, but the inputText component is referencing a text box, so the label text is going to be whatever the user types into the text box:
http://www.imagehosting.com/out.php/i1259467_Example4.png
Does this approach seem reasonable to people, or am I reinventing the wheel? Please let me know.
Val

Try restarting the DTR application and see if the problem persists.

About jsf and tiles

Good days , the following exception is happening:
javax.faces.FacesException
at de.mindmatters.faces.lifecycle.RenderResponsePhase.executePhase(RenderResponsePhase.java:53)
at de.mindmatters.faces.lifecycle.AbstractPhase.execute(AbstractPhase.java:37)
at de.mindmatters.faces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:166)
at de.mindmatters.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:226)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:138)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:363)
at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:406)
at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:211)
at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at org.mortbay.jetty.Server.handle(Server.java:313)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:506)
at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:830)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:514)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:381)
at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:396)
at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
Caused by: java.lang.NullPointerException
at org.apache.myfaces.tomahawk.application.jsp.JspTilesViewHandlerImpl.renderView(JspTilesViewHandlerImpl.java:168)
at org.ajax4jsf.framework.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:101)
at org.ajax4jsf.framework.ajax.AjaxViewHandler.renderView(AjaxViewHandler.java:221)
at de.mindmatters.faces.lifecycle.RenderResponsePhase.executePhase(RenderResponsePhase.java:45)
... 21 more
my web.xml
<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/applicationContext.xml</param-value>
</context-param>
<context-param>
<param-name>com.sun.faces.verifyObjects</param-name>
<param-value>true</param-value>
<description>
Set this flag to true if you want the JSF
Reference Implementation to verify that all of the application
objects you have configured (components, converters,
renderers, and validators) can be successfully created.
Default value is false.
Poner a false cuando se ponga en produccion.
</description>
</context-param>
<context-param>
<param-name>com.sun.faces.validateXml</param-name>
<param-value>true</param-value>
<description>
Set this flag to true if you want the JSF
Reference Implementation to validate the XML in your
faces-config.xml resources against the DTD. Default
value is false.
Poner a false cuando se ponga en produccion.
</description>
</context-param>
<context-param>
<param-name>javax.faces.STATE_SAVING_METHOD</param-name>
<param-value>client</param-value>
<description>
Indica donde queremos guardar el estado de la aplicacion.
Poner a server cuando se ponga en produccion. antes probarlo!
</description>
</context-param>
<context-param>
<param-name>org.apache.myfaces.ALLOW_JAVASCRIPT</param-name>
<param-value>true</param-value>
<description>
Este parametro le dice a MyFaces si se va a permitir renderizar javascript.
Default: "true"
</description>
</context-param>
<context-param>
<param-name>org.apache.myfaces.PRETTY_HTML</param-name>
<param-value>true</param-value>
<description>
si es verdadero, el renderizado html estara formateado, permitiendo que se pueda leer
bien. En la fase de desarrollo, estara a true, cuando este en produccion, estara a false.
</description>
</context-param>
<session-config>
<session-timeout>
30
</session-timeout>
</session-config>
<welcome-file-list>
<welcome-file>
index.jsp
</welcome-file>
</welcome-file-list>

<listener>
<listener-class>org.springframework.web.context.request.RequestContextListener</listener-class>
</listener>
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
<servlet>
<servlet-name>Faces Servlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>

<servlet>
<servlet-name>TilesServet</servlet-name>
<servlet-class>org.apache.struts.tiles.TilesServlet</servlet-class>
<init-param>
<param-name>definitions-config</param-name>
<param-value>/WEB-INF/tiles-defs.xml</param-value>
</init-param>
<load-on-startup>2</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>*.jsf</url-pattern>
</servlet-mapping>
<filter>
<filter-name>MyFacesExtensionsFilter</filter-name>
<filter-class>org.apache.myfaces.webapp.filter.ExtensionsFilter</filter-class>
</filter>
</web-app>
tiles-defs.xml
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE tiles-definitions PUBLIC
"-//Apache Software Foundation//DTD Tiles Configuration 1.1//EN"
"http://jakarta.apache.org/struts/dtds/tiles-config_1_1.dtd">
<tiles-definitions>
<definition name="Base" path="/paginas/plantillaBasica.jsp">
<put name="titulo" value="Base" type="string"/>
<put name="cabecera" value="/cabecera.jsp" type="page"/>
<put name="cuerpo" value="base" type="page"/>
<put name="pie" value="base" type="page"/>
</definition>
<definition name="/busquedaDosCajas.tiles" extends="Base">
<put name="titulo" value="Busqueda con dos cajas" type="string"/>
<put name="cuerpo" value="/paginas/cuerpoDosCajas.jsp" type="page"/>
</definition>
</tiles-definitions>
faces-config.xml
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE faces-config PUBLIC
"-//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.1//EN"
"http://java.sun.com/dtd/web-facesconfig_1_1.dtd">

<faces-config>
<application>
<view-handler>org.apache.myfaces.tomahawk.application.jsp.JspTilesViewHandlerImpl</view-handler>
</application>

<application>
<variable-resolver>
org.springframework.web.jsf.DelegatingVariableResolver
</variable-resolver>
</application>

<application>
<locale-config>
<default-locale>es</default-locale>
</locale-config>
</application>

<navigation-rule>
<from-view-id>*</from-view-id>
<navigation-case>
<from-outcome>succesNoJS</from-outcome>
<to-view-id>/paginas/listado.jsp</to-view-id>
</navigation-case>
<navigation-case>
<from-outcome>error</from-outcome>
<to-view-id>error.jsp</to-view-id>
</navigation-case>
</navigation-rule>
</faces-config>
index.jsp
<%@ page session="false"%>
<%
response.sendRedirect("busquedaDosCajas.jsf");
%>
anybody could help me? i dont know whats happening
regards a lot

first make sure you are using Tiles stand-alone (in Struts Sandbox)
add the follwoing servlet to your web.xml
<servlet>
<servlet-name>Tiles Servlet</servlet-name>
<servlet-class>org.apache.tiles.servlet.TilesServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
add the following context-param to your web.xml
<context-param>
<param-name>tiles-definitions</param-name>
<param-value>/WEB-INF/tiles.xml</param-value>
</context-param>
add the following to your faces-config.xml
<view-handler>org.apache.shale.tiles.TilesViewHandler</view-handler>
add the following dependency to your pom.xml
<dependency>
<groupId>org.apache.shale</groupId>
<artifactId>shale-tiles</artifactId>
<version>1.0.3</version>
</dependency>
that should be it.
Khaled

Mojarra doesn't implement setting properties on declared converters?

Hi,
I tried to register a custom converter in faces-config, by means of the following declaration:
<converter>
          <description>Formats a number with exactly two fractional digits.</description>
          <converter-id>numberformat.two</converter-id>
          <converter-class>javax.faces.convert.NumberConverter</converter-class>
          <property>
               <property-name>maxFractionDigits</property-name>
               <property-class>java.lang.Integer</property-class>
               <default-value>2</default-value>
          </property>
          <property>
               <property-name>minFractionDigits</property-name>
               <property-class>java.lang.Integer</property-class>
               <default-value>2</default-value>
          </property>
     </converter>I've used this kind of code before a long time ago when using MyFaces, and this always Just Worked. However, with Mojarra it just doesn't work.
I used the converter on my view like this:
<h:outputText value="#{bb.someVal}">
     <f:converter converterId="numberformat.two"/>
</h:outputText>By putting a breakpoint in javax.faces.convert.NumberConverter, I can check that the converter is being called, but the properties just aren't set on the instance.
I hunted the Mojarra source code, but I also can't find any code that is supposed to set these properties.
For instance, the ApplicationImp.createConverter method consists of this code:
public Converter createConverter(String converterId) {
        if (converterId == null) {
            String message = MessageUtils.getExceptionMessageString
                (MessageUtils.NULL_PARAMETERS_ERROR_MESSAGE_ID, "convertedId");
            throw new NullPointerException(message);
        Converter returnVal = (Converter) newThing(converterId, converterIdMap);
        if (returnVal == null) {
            Object[] params = {converterId};
            if (logger.isLoggable(Level.SEVERE)) {
                logger.log(Level.SEVERE,
                        "jsf.cannot_instantiate_converter_error", converterId);
            throw new FacesException(MessageUtils.getExceptionMessageString(
                MessageUtils.NAMED_OBJECT_NOT_FOUND_ERROR_MESSAGE_ID, params));
        if (logger.isLoggable(Level.FINE)) {
            logger.fine(MessageFormat.format("created converter of type ''{0}''", converterId));
        return returnVal;
    }So without all the error checking, the method basically boils down to just this:
return (Converter) newThing(converterId, converterIdMap);The heart of newThing consists of this:
try {
            result = clazz.newInstance();
        } catch (Throwable t) {
            throw new FacesException((MessageUtils.getExceptionMessageString(
                  MessageUtils.CANT_INSTANTIATE_CLASS_ERROR_MESSAGE_ID,
                  clazz.getName())), t);
        return result;So there's no code that's supposed to set these properties in sight anywhere.
Also the converter tag (com.sun.faces.taglib.jsf_core.ConverterTag) nor any of its base classes seems to contain such code.
Either I'm doing something very wrong, or Mojarra has silently removed support for setting properties on custom converters, which would seem awkward.
Any help would be greatly appreciated.

rlubke wrote:
Mojarra has never supported such functionality, so it hasn't been silently removed.Thanks for explaining that. Like I said, the silently removed option thus was the less likely of the two ;)
The documentation for this converter sub-element states:
<xsd:element name="property"
type="javaee:faces-config-propertyType"
minOccurs="0"
maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation>
Nested "property" elements identify JavaBeans
properties of the Converter implementation class
that may be configured to affect the operation of
the Converter. This attribute is primarily for
design-time tools and is not specified to have
any meaning at runtime.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
That documentation is quite clear indeed. I now notice that the project I was working on still had a JSF 1.1 faces-config DTD, and that documentation said this:
Element : property
The "property" element represents a JavaBean property of the Java class represented by our parent element.
Property names must be unique within the scope of the Java class that is represented by the parent element,
and must correspond to property names that will be recognized when performing introspection against that
class via java.beans.Introspector.
Content Model : (description*, display-name*, icon*, property-name, property-class, default-value?,
suggested-value?, property-extension*)So there it actually says nothing about the design time aspect.
I do have to mention that I think this entire difference between design time and run time could maybe have been a bit more officially formalized. Don't get me wrong, I think JSF and the whole of Java EE is a really good spec that has helped me tremendously with my software development efforts, but this particular thing might be open for some improvements. A similar thing also happens in the JPA spec, where some attributes on some annotations are strictly for design time tools and/or code generators, but it's never really obvious which ones that are.
More on topic though, wouldn't it actually be a good idea if those properties where taken into account at run-time? That way you could configure a set of general converters and make them available using some ID. In a way this wouldn't be really different in how we're configuring managed beans today.

JSF Shopping List

Hi all....my development team has been working in a web framework for the past 8+ months and we have hit a few serious roadblocks. I'm considering spearheading a switch to JSF, but I need to know if it will meet our requirements. After a perusal of O'Reilly's JSF book, by Hans Bergen, I have a general feel, but I'm interested in your opinions & experiences--e.g., the framework we're using claims to have certain functionality, but it's clearly broken.
Some of the items on this list have obvious answers & some are answerred in the O'Reilly book, but I'm interested in confirmation from you, the folks in the trenches.
Thanks in advance for your help,
- Mike
Shopping List:
General Items:
- what are JSFs biggest drawbacks if I were to use it as an enterprise technology for the next 5 years?
- what are the biggest problems with Facelets?
- if I use Facelets, do I still have to be a JSP guru?
- what are the best books on JSF?
- which is better, MyFaces or RI?
Specific Items:
- does JSF have the ability to create a library of reusable components?
- backwards compatibility of components as new versions are released?
- server-side and client-side validation?
- can I easily create custom validation components?
- does JSF have any glaring concurrency issues?
- can I programmatically add components to a page at run time?
- does JSF require me to use JDK1.5, or can I use 1.4?
- does JSF support a single application properties file for i18n?
- does JSF support per-page properties file for i18n (that override what is in the application file)?
- can I easily display a single page in a different language?
- does JSF allow for page inheritence? (can I create custom sub-pages from a generic parent "SearchPage"?)

I'll answer the things that I can. You cover quite a range with your questions though...
- what are JSFs biggest drawbacks if I were to use
e it as an enterprise technology for the next 5
years?- JSF is still a young technology and will likely undergo a number of changes that will break backwards compatibility.
- Performance could become an issue on very large applications.
- what are the biggest problems with Facelets?- There are a number of little "got'cha's" once you start getting into it. Expect to be writing a number of custom validators and components.
- There is a lack of control over the faces lifecycle, which can frustrate attempts to skip phases.
- if I use Facelets, do I still have to be a JSP
P guru?Not at all. Faces actually takes over for JSP quite nicely, especially once you realize it's full capability. However, it doesn't hurt to have minimal knowledge of JSP. Nothing more than a developer worth his salary couldn't learn in a day or two.
- what are the best books on JSF?I like Core JavaServer Faces by David Geary and Cay Horstmann. Partial book is online:
http://www.horstmann.com/corejsf/
- which is better, MyFaces or RI?Hah! This could start a few wars. Honestly, haven't looked much at MyFaces but I know that it just extends the RI with some extra components. Most people who use MyFaces swear by it. However, I wrote an entire enterprise application with just the RI and my own customs. Works great!
- does JSF have the ability to create a library of
f reusable components?Yes, absolutely. I did this with my app and the new library will be very helpful to future projects.
- backwards compatibility of components as new
w versions are released?Ok... Here you might have a few problems. I've already heard rumours of JSF 1.2 breaking a lot of 1.1. I know that there were major changes between 1.0 and 1.1 too. The JSF developers do not seem to be terribly concerned with backwards compatibility.
- server-side and client-side validation?Server-side only. You'll need to use a client-side technology (such as JavaScript) for client-side validation. However, JSF components offer JavaScript hooks, so you can easily execute functions onchange, onclick, onblur, etc...
- can I easily create custom validation components?Easy is a relative term. =) Not always. Writing customs will require a high learning curve. How easy it is depends on what you're doing and how closely you're tying it into other pre-existing components/validators/converters. After each custom you write, it starts getting a little easier.
- does JSF support a single application properties
s file for i18n?I'll hazard a guess on this one, don't quote me on it. A separate message properties file is required for each locale. The message bundle will choose the appropriate one for each locale.
- does JSF support per-page properties file for i18n
n (that override what is in the application file)?I think not. Again, just guessing here.
- can I easily display a single page in a different
t language?Yes, actually this is quite easy. Assuming you set up the locale properly, you just need to use the h:outputText component with f:loadBundle to retrieve the messages.
Hope this helps,
CowKing

Invoking JSF actions from a hyperlink

I suspect I already know the answer to this question based on my experiments and what I've read on the web and in books, but I thought I'd ask here just in case.
The basic problem is that I would like to invoke JSF from a hyperlink. For example: mystore.com/displayProduct.faces?id=1234
But I can't. JSF just seems to be (intentionally) built not to allow access to the JSF lifecycle via GET requests. Which makes it fine for web sites that are composed simply of loads of forms, but seems quite unsuitable for web sites that need to display products and search results via links that are easy to bookmark and easy for search engines to crawl.
Thanks for any words of wisdom anyone might have...

Thanks for the reply and the link. I had a look at the linked thread and might be able to use that technique for getting parameters out of a GET request into my action, but I still need to get JSF to call my action method somehow and there is no way that I can see to tell it which method to call.
Also, it seems like manually reading values from the request is sidestepping a lot of JSF and losing out on the value that it adds, i.e. validating and converting the parameters for me. I could manually populate components in the bean and then call the validators and converters myself, but still.

Reusable JSF components - bundling a converter with a text field

I am trying to create reusable text fields for different types of data (notes, amounts, percentages) that will use a JSF converter to implement formatting.
Here is what I have done
- created an application in JDeveloper that contains my components as JSF declarative components
- created the Converter classes
- registered the converter classes in faces-config.xml of the reusable components project
- added my Converters to the inputText fields for each of my declarative components using the property palette
- deployed the components as a jar file using the ADF Library Jar File archive type
- created a second application to act as a consumer of the components
- imported the jar file into the component palette using a file system connection
- added the jar file to the active project's component library
- added a converter entry for the converter I am trying to use to this project's faces-config.xml
- created a consumer jspx page and dragged and dropped the control onto the page
I put some system.outs in the getAsString() and getAsObject() methods of the converter I am trying to use and they are not output when I run the page. I've also set breakpoints in those methods to see if they are being called.
I have no indication that my converter is being called.
Can someone please confirm that what I am trying to do is possible using the declarative components?
Any insight appreciated.
Dave

Actually this is working. I made the incorrect assumption that getAsString() in the converter class would be called on the initial request.
Another thing I just noticed is that it is not necessary to reference the converter in the faces-config.xml of the consuming project. Not sure how this works, but its a nice feature :)

JSF Server Error

hi
can any one help me to clear the following server error in JSF
WARNING: Can't parse configuration file:jndi:/localhost/ourdemo/WEB-INF/faces-config.xml
Thanx in advance.
regards,
Bala

This is my web-app
<web-app>
<display-name>JavaServer Faces Sample Application</display-name>
<description>
JavaServer Faces Sample Application
</description>
<context-param>
<param-name>javax.faces.STATE_SAVING_METHOD</param-name>
<param-value>client</param-value>
</context-param>
<context-param>
<param-name>com.sun.faces.validateXml</param-name>
<param-value>true</param-value>
<description>
Set this flag to true if you want the JavaServer Faces
Reference Implementation to validate the XML in your
faces-config.xml resources against the DTD. Default
value is false.
</description>
</context-param>
<context-param>
<param-name>com.sun.faces.verifyObjects</param-name>
<param-value>true</param-value>
<description>
Set this flag to true if you want the JavaServer Faces
Reference Implementation to verify that all of the application
objects you have configured (components, converters,
renderers, and validators) can be successfully created.
Default value is false.
</description>
</context-param>

<servlet>
<servlet-name>Faces Servlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
<load-on-startup> 1 </load-on-startup>
</servlet>

<servlet-mapping>
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>/faces/*</url-pattern>
</servlet-mapping>
<security-constraint>
</security-constraint>
</web-app>
Bala

JSF & converters

Similar Messages

Maybe you are looking for