requestScope is a com.sun.faces.context.RequestMap object, I found its methods reference at http://www.docjar.com/docs/api/com/sun/faces/context/RequestMap.html. I wonder if it belongs to the JSF API.
The packages here http://www.docjar.com/projects/Mojarra-2.0.1-code.html are different from the official reference here: download.oracle.com/docs/cd/E17802_01/j2ee/javaee/javaserverfaces/2.0/docs/api/index.html. It seems the packages have been moved into javax.*. So what version is XPage based on?
Erik Brooks has an article about this. Or take a look at the Wikipedia page.
XPages are based on JSF 1.2
I learned the answer after I knew more about J2EE. JSF API is only the specification. com.sun.faces.* and similar things are concrete implementations.
Related
I have looked everywhere for the following issue, but unfortunately not able to find the solution. I an using JSF 2.2, richfaces, Netbeans 7.3.1 and GlassFish Server. I am trying to build a GUI for selecting multiple items in the rich:picklist, adding them to the right and clicking a submit button which would execute methods (having JDBC calls) associated with each of the selected items on the right and hence populating the tables in Database. Any working example would be greatly appreciated. Thanks!
You can see a live demo of all richfaces components here http://livedemo.exadel.com/richfaces-demo/
Here all the components usage and its tag information every thing is clearly given. Still if you feel any problem with understanding then you can post another question with a specific problem. The question you have asked is a very general one. no offense.
Hope above link helps you.
Can anyone tell me where com.ibm.xsp.component.UIIncludeComposite is documented? I searched in the help file for UIIncludeComposite but found nothing.
There is only one brief mention of it in Mastering xPages.
com.ibm.xsp.component.UIIncludeComposite is the class for the object returned by getComponent when calling getComponent for a custom control.
In fact where is anything documented? I think the single biggest frustration as a newbie xPage programmer is the lack of documentation or where to find it.
The Java class is documented in the Javadoc available at http://www-10.lotus.com/ldd/ddwiki.nsf/dx/Domino_Designer_Extensibility_APIs_Javadoc_8.5.3 which points to this page for the specific class:
http://public.dhe.ibm.com/software/dw/lotus/Domino-Designer/JavaDocs/DesignerAPIs/com/ibm/xsp/component/UIIncludeComposite.html
General documentation for Upgrade Pack 1 and Extension Library is available here:
http://www-10.lotus.com/ldd/ddwiki.nsf/xpViewCategories.xsp?lookupName=Domino%20Designer%20XPages%20Extension%20Library
Especially rich:autocomplete. There are a lot of possible attributes but not all of them are explained, neither in the Developers Guide nor in the Component Reference. For example there is no information about fetchValue, immediate, selecteditemClass,...
You need to check the Tag Library Documentation. Here is the <rich:autocomplete>.
Does anyone have a link to a concise summary of what makes a portlet "JSR-286 compliant" vs being only "JSR-168 compliant". I've got a copy of the spec and that's anything but concise so linking the spec is not a useful answer. I've searched the web for an hour now and I've found nothing that is clear (aside from the spec, which of course requires that you read the previous spec too, and then weed out the "new features" from the "required compliance".
Particularly I've found that there's quite a bit of confusion out there on the necessity of web.xml, which appears to come from people using Liferay and not realizing that Liferay is dropping in a web.xml for them.
Do JSR-286 portlets require a web.xml file in their WAR files?
What I'd really like is something that contains one or more of the following lists:
Things you have to do to a JSR-168 to make it become JSR-286 compliant
Things you must not do, that would cause an otherwise JSR-286 compliant portlet to be considered only JSR-168.
You can leave "use the portlet-app_2_0.xsd" off the list, as I consider that part obvious.
I'm open to the answer that both lists are empty aside from the DTD/xsd for portlet.xml, and the difference is only in what the portal supports, but please back that assertion up with a link or other reference.
The reason I care is I see posts about Vaadin portlets in Liferay that imply that some features are not available for JSR-168 portlets... It may also be that some logic in Liferay switches based on which version of portlet.xml it sees, but I haven't confirmed that either so that would be interesting information too, but not the answer to my question.
According to this doc, but it's also mentioned in jsr286:
The JSR 286 spec(Portlet 2.0) does not break binary compatibility with JSR168(Portlet 1.0). This means that all portlets written against the Portlet 1.0 specification can run unchanged. The only exceptions to this rule are:
renderResponse.setContentType is no longer required before calling getWriter or getOutputstream. In JSR168, calling getWriter or getOutputstream without previously setting the content type resulted in an IllegalStateException.
getProtocol for included servlets / JSPs returns ‘HTTP/1.1’, In JSR168, it returned null.
So as long as your jsr168 portlet doesn't depend on the value returned by getProtocol() you're safe (ie every jsr168 portlet is a jsr286 portlet).
The posts you see seem to be logical as jsr286 is a newer spec and there are some features that make jsr268 portlet not a jsr168 portlet.
Ok, Since I've not found anything new that distinguishes a 2.0 portlet from a 1.0 portlet (aside from using additional services and ) I'll begin the lists for my answer here.
Must Do:
Conform to the 2.0 XSD for portlet.xml (xmlns="http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd")
Must Not Do:
Rely on getWriter throwing an exception if renderResponse.setContentType has not been called yet. (Seems unlikely anyway)
Rely on getProtocol() returning null
The upshot is, if you simply convert your portlet.xml, you are now "286 compliant" unless you relied on the two items in the second list for your program flow. I can't find anything else, but if someone finds another item for these lists, please edit.
I don't often have need for tomahawk components anymore since jsf 2.0 provides great selectOneMenu support and most of other functionality I used to use them for, but when it comes to a selectOneRadio component I don't know of another provider with a layout="spread" option. This is essential from time to time to achieve a certain layout I'm asked for.
I'm using Tomahawk for exactly this purpose but recently discovered some serialization issues caused by this component during failover. I was wondering if anyone has discovered another provider with similar "spread" functionality or if anyone has written/published an alternative based on h:selectOneRadio?
We also wanted to use the "spread" option - in our case for DDA compatibility (no using tables for layout) but for political reasons were unable to use Tomahawk. We ended up writing our own custom renderer for radio buttons and checkboxes.
It wasn't too hard, took me a few hours to get it working the way we wanted. I'm at home for a couple of days without access to the code base so I can't give you the exact code but it's a pretty simple matter of overriding the encodeBegin() and decodeBegin() (or encodeEnd() and decodeEnd() depending on your usecase) methods and writing the html appropriate for your application.