I am stuck and need outside help from JSF experts with the following problem:
I defined some converters in the faces-config.xml for specific classes so I don't have to use the converter-attribute or tag all the time. For example:
<converter>
<converter-for-class>org.joda.time.DateTime</converter-for-class>
<converter-class>com.example.converter.JodaDateTimeConverter</converter-class>
</converter>
Now there is the need for a crawler for a JSF-Component (mostly rich:extendedDataTable) which builds the whole component tree and converts level after level into CSV, HTML or whatever might be needed later on. Namely a generic way to export to CSV, HTML, ... without the need to implement it every single time anew. It is almost done (thanks to the great idea of an old colleague of mine) and it does work great except for one part:
Object expressionResult = expression.getValue(FacesContext.getCurrentInstance().getELContext());
expressionResultString = expressionResult.toString();
That command retrieves the value of an h:outputText and converts it to String. That last line is what I want to replace with the converter-for-class if there is a custom converter for a specific expressionResult. I can't find out how to find that exact converter for my classes (as specified by faces-config). The FacesContext doesn't seem to hold any useful method/object for my use case. Accessing the faces-config.xml directly seems kind of wrong. A correct approach might look something like:
Converter converter = magically_fetch_the_correct_converter_for_expressionResult_type;
converter.getAsString(FacesContext.getCurrentInstance(), component,
expressionResult);
It would be fairly easy if I used converter-id and the appropriate attribute/tag for the components themselves but I really want to avoid that kind of useless additional code.
Can someone out there please help me?
You're looking for Application#createConverter().
Object object = expression.getValue(context.getELContext());
Class<?> type = expression.getType(context.getELContext());
Converter converter = context.getApplication().createConverter(type);
String string = converter.getAsString(context, component, object);
Related
Liferay has feature to modify Struts Action using hook which is straight-forward. However I am trying to override getJSON method of RateEntryAction.
The use case is I need total positive score and total negative score instead of average score that Liferay's OOTB rating component provides.
I already have necessary methods readily available in Liferay API to get the total positive and negative scores. I created a custom type just like "stars" and "votes" to write my necessary logic in hook. I was then planning to override struts action represented by /portal/rate_enty to override the method and add negative and positive votes in the json that is already being returned.
But RateEntryAction (which is the original class) is extending JSONAction and overriding getJSON method. Is it possible to override just getJSON method using struts action hook?
I can see this action class in struts-config.xml, so it's a Struts Action.
This is the path you could try to override.
<action path="/portal/rate_entry" type="com.liferay.portal.action.RateEntryAction" />
I would try to override this path, and see if can put your logic there.
RateEntryAction extends from JSONAction , and this one from org.apache.struts.action.Action , which is the same class that PortletAction extends.
Hope this help
As per my research we can only hook com.liferay.portal.struts.PortletAction sub classes, Yeah JSONAction also extend org.apache.struts.action.Action class same as PortletAction, but liferay allow only those classes hookable which comes under PortletAction class not except that.
As RateEntryAction is not a Struts Action, you can't overload it with a Struts Action Hook. I'm not aware of any hookable way to override it, thus my best guess is that you'll have to either go for ext or introduce a whole new JSON API function and hook all places in Liferay that refer to the original implementation to now go to your implementation.
I suspect that in this case an ext plugin will be easier to maintain. Someone correct me if I'm wrong.
I have a method in my JSF controller that is invoked by an ajax tag nested inside a visual component (really irrelevant which one). The method takes a single argument of type AjaxBehaviorEvent, from which I can obtain a Java representation of the invoking HTML visual component as a UIComponent and also downcast it to its specific corresponding type (e.g. h:inputText corresponding to HtmlInputText).
I understand that, in most cases, the value of the HTML visual component would be retrieved easily by referencing either the controller or entity [g|s]etters to which the form fields are mapped in the view. However, in my particular case, I would like to fetch the value of the visual component (in my case a form field) through its Java object rendering. While studying the faces API, I found ways to read various properties of the object, such as the ID or context but not the value that the component currently holds in the view.
Can anybody explain whether I am just not finding the right way to read it or it is so by design? If the latter, can you explain why it is designed like that? Is it to disable "backdoor" access to form fields as opposed to going through the view mapping?
There are a multitude of ways to pull values off a component. Going by what you already have UIInputt#getValue() and UIInput#getSubmittedValue() will provide the value.
The UIInput#getSubmittedValue() is fit for the purpose only between the APPLY_REQUEST_VALUES and VALIDATE phases of the JSF request. All other phases after, use the UIInputt#getValue(). You'll be using UIInput instead of the raw UIComponent you pulled from the event (UIInput extends UIComponent and it's the parent class for all input components that accept user-edited values). What you'll have will eventually look like:
UIInput theInput = (UIInput)event.getSource();
Object theValue = theInput.getValue();
There are other ways (not as clean) to get values within the request lifecycle also
In the past I used a lot of getter and setter methods to move as much boolean logic as possible from facelet files to JSF backing beans.
This way, the interface of a view was given by the getter and setter methods of its backing bean as well as by the action methods of the backing bean.
An advantage of this approach is that the facelet files are rather logic-free and ,therefore, all logic is within the backing beans and can be unit tested.
But with EL 2.2 another programming style became possible. In EL 2.2 you can invoke methods with expressions like
#{bean.collection.size()},
#{bean.collection.add(elem)},
#{bean.property.substring(0, bean.property.indexOf(something))}.
Is the usage of rather complex expressions like parameterized method invocations good style now or do you rather advise against using such expressions?
Is there a rule of thumb when to use the new method invocation expressions and when not?
The major guideline is the following: reduce as much 'model' logic from the view as possible and leave only the 'view' logic. EL 2.2 made possible some model simplification and reduced the need for creation of artificial properies of JSF beans. Invocation of methods with parameters also enables to pass the necessary information from the view to the controller which would be tedious without that opportunity.
You can call arbitrary methods to access the model from the view that the view part relies on, but you should never call methods that modifies the model from the view.
Let me elaborate on that.
Some legal examples:
evaluate non-accessor methods when building view:
render UI components based on some conditions like rendered="#{request.isUserInRole('administrator')}";
make collection modifications where necessary like <ui:repeat value="#{bean.set.toArray()}" ... >
conditionally evaluate UI component / HTML element attributes like class="#{bean.name.contains('special') ? 'special' : ''}";
output non-accessor data like there are #{bean.list.size()} elements.
pass information to the controller in action methods or listeners:
execute action methods with currently iterated variables like var="data" and action="#{bean.action(data)}" with public String action(Data data);
pass additional data, like current iteration index, in listeners like varStatus="status" and actionListener="#{bean.action(status.index)}" with public String action(int index).
Some to-be-avoided examples:
use EL operators when possible:
use #{not empty bean.list} instead of #{bean.list.size() gt 0}.
use method call with parameters instead of extending the model:
use #{bean.name.contains('special')} instead of #{bean.special} with public boolean isSpecial() {return name.contains("special");}.
prefer leaving view logic in view for plain rendering of the right things and create model logic in case it applies purely to the model:
in case you need to perform some calculations to change the appearance of an object, do that in view directly without changing the model, in case some property is inherent to the model itself, introduce it directly in the model and refer to it from the view.
Some illegal examples:
modify the model from the view:
do not use EL 2.2 possibility of calling methods with parameters to break the MVC paradigm, i.e. do not call #{bean.list.add(element)} from the view side.
Of course, all things said apply to the cases that your goals don't contain targeting at the older servers without EL 2.2 support.
As a bigger picture, I'd recommend to also see BalusC's explanation of what MVC architecture represents within the context of JSF.
Personally, i prefer using "complex" EL expressions when really needed, and take any bit logic/traitement to the correspondant managed-beans.
For example: the first example you put is the only one that i may sometimes use directly, the two others however should be for me put in action methods with void/String returning type according to the need.
Use El 2.2 to reduce our JSF code, e.g. setPropertyActionListener is made redundant, see
JSF Core Tag :setPropertyActionListener vs attribute vs param
I am dynamically generating some Primefaces input and output components, and I need to be able to disable validation on these components in certain use cases, while still updating the model. (Like a save button). It looks like the proper way to do that in xhtml would be to use <f:validateBean disabled="#{myBean.someCondition}/>
However, I cannot figure out how to create this component dynamically. I searched through the javax.faces package and could not find any validateBean component. I thought maybe it would be a property that I need to set on the UIInput component, but none of the methods outlined in that API seem to what I need.
Is this possible?
Edit:
As a reference, here is the component I am creating:
UIInput input = new InputText();
input.setId(field.getFieldKey());
input.setValueExpression("value", expressionFactory.createValueExpression(elContext, field.getFieldValue(), String.class));
input.addClientBehavior("blur", ajaxBehavior);
input.addValidator(new BeanValidator());
You might want to explore these paths :
Set immediate to true on your input.
input.setImmediate(true);
Extend BeanValidator with an empty validate method and pass an instance to your input.
input.addValidator(new DummyBeanValidator());
Hope this helps.
We are about to write a full set of tests for one of our JSF applications using Selenium.
So far, it seems that there are two preferred approaches to uniquely identify each element: by ID or using a unique class name. The later is really a hack and doesn't make sense semantically. The former is the right approach, but the element IDs are generated by JSF.
All the different JSF implementations I've seen seem to be using the same approach: use the parent element as the namespace and then concatenate the element ID using a colon. Fair enough.
The question is: do you know if this is guaranteed in some part of the JSF specification? It'd be a real problem to find out later that we need to rewrite all the component selectors in the tests just because JSF x.y changed the way it generates the ID names.
Thanks!
JSF usually generated the ID of components, if ID attribute is not explicitly mentioned.
It will be generated in the format j_idXXX (XXX will be number incremented)
<h:form id="LoginForm">
<h:inputText id="userName" .../>
</h:form>
for this inputText the id will be formed as LoginForm:userName and if id is not mentioned explicitly,then it will be formed something like LoginForm:j_id15
This is mentioned in JSF specification in section 3.1.6, But the exact format is not specified though.
The clientId is generated using this method UIComponent.getClientId(); Follow this link UIComponent
Is the ID generated by JSF guaranteed to be the same across different versions and implementations?
No. You've to explicitly specify the component ID on the UIInput component of interest and all of its parent UINamingContainer components such as <h:form>, <ui:repeat>, <h:dataTable>, etc yourself. Those IDs will by default be woodstocked using separator character :.
However, the separator character is in turn configureable since JSF 2.0. So, if you change the separator character for your webapp from : to - or something, then you'd have to rewrite the selenium tests which are relying on the HTML element IDs.
From the JSF (2.1) spec:
The client identifier is derived from the component identifier
(or the result of calling UIViewRoot.createUniqueId() if there is
not one), and the client identifier of the closest parent component
that is a NamingContainer according to the algorithm specified
in the javadoc for UIComponent.getClientId(). The Renderer
associated with this component, if any, will then be asked to convert
this client identifier to a form appropriate for sending to the
client. The value returned from this method must be the same
throughout the lifetime of the component instance unless setId() is
called, in which case it will be recalculated by the next call to
getClientId().
Aside from the spec, 3rd party plugins can affect the client identifier (e.g. protlet bridge APIs)