In IBM Websphere for IPC, we have something called as Wiring which allows us to switch to the receiving portlet page in case you have your event receiving portlet to be on different page than that of source portlet.
I am wondering if there is any way to achieve this in Liferay.
I have also followed the link: Using JSR-268 IPC for portlets on different pages in Liferay but not clear about application-context.xml as I have created a simple Liferay plugin-portlet-project from Eclipse.
Yes it is possible. You just need to pass the Layout id, portlet id along with your parameters.
<liferay-renderURL var="varLink" plId="layout-id" portletName="portletName_WAR_WarName"/>
Wiring is Websphere Portal's concept.
Liferay is not supporting Wiring, but you can do Inter-portlet communication using public render parameters & portlet events ( in case of ACTION->View IPC).
In case when you need (VIEW->VIEW) IPC, you can use liferay's session sharing mechanism.
More details on my blog https://rutvijshah.wordpress.com/2009/12/13/liferay-session-sharing-made-easy/
Related
Fairly new to Liferay. I learned it is possible to create plugins UI with different frameworks including JSF. Also I learned I can extend functionality of an existing plugin with hooks. Now I am curious if it is possible to add new JSF pages to an existing plugin which interface is build with JSP using hooks?
Suppose I want to extend dynamic data list portlet, add some new functionality and for this I need to add new pages.
Is it possible to add new pages in general?
Can I create a new plugin with JSF as a front end framework, implement the logic I want to add within JSF pages, would it be possible to redirect a user from an original JSP to those JSF pages, let user do something there and then return the user back to original dynamic_data_list JPSs?
If it is possible, how can I do this with Liferay 6.2?
Thanks
The mechanics are documented in the developer guide or the Wiki. It's not exactly a hook that you deploy to the running system, rather a development option to inject custom changes into existing plugins, and you deploy the modified version instead of the original one.
With this, you can do everything that you can add as extra feature this way (see the build process). Technically the answer to the first two bulletpoints is "yes". If the linked documentation doesn't help answering your third bulletpoint, please ask more specifically what actually doesn't work. But keep in mind that only core liferay is customizable with hooks, plugins are customizable at compile time - and not with hooks.
Both files seem very similar, subsequently I'm struggling to understand their purposes.
I have seen faces-config referred to as a plain JSF controller, while adfc-config is an extended ADF controller.
Some clarification would be good, as right now I can't see why you would have both in an ADF application if that is the case, so I must be missing something.
adfc-config is different from faces-config
Faces Config is the controller of your application, it's what make JSF based frameworks work effectively, and it's where you will need to define your own customization like view handlers, converters, validators, etc...
adfc-config is just the main application unbounded Task Flow, which make it a little easier for developers to define their pages and main navigation root inside of it instead of doing it the JSF way and define them in faces config, it also provide additional functionality like defining managed beans which will have much more scopes than the original JSF given the ADF Framework additions, but still at the end it's just an Unbounded Task Flow. Here is the documentation reference about adfc-config.xml
adfc-config is used by the ADF Faces framework, when task flows are in the picture.
More information at: http://docs.oracle.com/cd/E23943_01/web.1111/b31974/taskflows.htm
Yes, you are right when you say that the functionality looks similar. Things like pageFlowScope / backingBeanScope / task flows / etc. are extensions to the standard JSF framework and require a custom configuration file.
So, if you create a project based on the Fusion WebApplication template, then you will see a default adfc-config.xml file entry.
Hope that helps.
I see that when we extend this GenericPortlet class, there are methods like doHelp, doEdit, doView and processAction.
When I had gone through the tutorials on internet, I see that people using GenericPortlet don't bother to override the two methods doEdit and doHelp.
Please tell me, when and in which scenarios do we need to override these two methods (doEdit and doHelp), Is there any website that allows users to have these behaviours ??
Thank you for reading.
These 3 methods are part of the Portlet API (JSR168) .
The 'doHelp' method is conceptualized to show the user helpful information about how to use the portlet and it is render method implemented for HELP mode.
The 'doEdit' method is conceptualized for portlet configuration to personalize the portlet i.e. to specify user preferences and it is render method implemented for EDIT mode.
In real production this proposal isn't really optimal, hence portlet container's like Liferay have made their own concept for these things and don't use 'doHelp' and 'doEdit' methods.
For portlet configuration as used in liferay see this wiki.
We are trying to implement a portlet communication that will be able to simulate the classical redirect, but without success for now.
This looks to be a common question in the portlet world, but there is a lack of documentation/howtos/tutorials on specific portal implementations.
Does anyone have a positive experience achieving portlet communication in this environment:
- liferay 6.0.5
- JSF1.2 - richfaces 3.3.x implementation
IPC Public render parameters get passed to other portlets in the RENDER phase, IPC events get sent in the ACTION phase and passed to the other portlets in the EVENT phase. If you use JSF and don't reload the page then neither of these are possible so Portlet communication via IPC is not an option.
It is however possible to have them communicate using Javascript purely on the client side. The responsible way to manage this is to get each JS library to use the portlet namespace to prevent method and variable collision, but in a controlled environment (ie when you write all custom portlets running on the Portal server) you can omit this.
The other way is to have all communicating portlets to use the Portal server as a middleware container, and they all have to write data to the server and get updates by polling the server. This is not as clean or easy as talking JS to each other directly on the client.
I was wondering if it's possible to add JSF components to the tag library programmatically?
I'm implementing a plug-in mechanism in our application. And now, if I create a JSF component in the plug-in, I need to change the components taglib xml file in the main application, which is not the goal.
I'd rather like to put a components taglib xml file inside a plug-in which is then handled by the main application. Is there any way to do that?
The reason why I'm asking this is the following:
In our application, we send secure messages through a web interface. The messages are created by filling out forms, which are, in most cases, generated. But some forms have special behavior and we don't want to release the whole application if a new 'special form' is implemented, so we decided to put these in plug-ins.
Thanks for any help.
Cheers,
Andreas