We have downloaded the Notifications portlet from liferay which modifies the JSP:
html/portlet/dockbar/view_user_account.jspf
And we are also modifying this particular jspf in our hook.
Currently what we are doing is we are copying the code from notifications portlet in our custom hook and are deploying our custom hook at the end so that our changes are applied.
Or else we would need to remove the JSP hook from notifications portlet by modifying the notification portlet's source.
Are there any better ways to achieve this?
Thanks
Unfortunately you're stuck between a rock and a hard place. You'll need to modify one of the plugins to not contain the JSP. Liferay can handle each JSP to be overridden max once.
An alternative might be to "hack" your changes through JS DOM manipulation after the page is displayed. This makes maintenance harder, but eases daily business and updates.
The big problem with any workarounds that involve two plugins changing the same JSP is that order is not defined. Also, it can be destructive: After deploying and undeploying two plugins that modify the same JSP, the original JSP is gone :(
Deploying plugin A, then B, followed by undeployment of A will leave you with only plugin B deployed, but use A's version of the overridden JSP.
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'm trying to use ace:fileEntry to upload a picture, as I read this component requires a submit from h:commandButton in order to start downloading. My problem is that when I switched my ice:commandButton with h:, my managed bean (which is in Conversation Scope) gets created again (#PostConstruct called) and the method in h:commandButton and also the fileEntryListener aren't called anymore.
And as another problem that might be causing this is that when I first enter my page the managed bean gets created and I call conversation begin, but when I do a second request (from a commandLink) the managed bean is created again, and a new conversation is started, after that you can play how long do you want the managed bean doesn't get created again.
Back to my initial question, if I have ice:commandButton the managed bean ins't created again, if it's with h: it gets created again.
And to add a little bit more fun in it, if I remove the rendered attribute (which resolves to true) from ace:fileEntry the fileEntryListener is called, but the action from h:commandButton isn't called no matter what.
I tried to add explicit ids to the components, tried to change ice:form with h:form .. nothing. Please Help.
Ps: why ICEfaces 2 can't work with all ice components, why does it requires h:commandButton, instead of ice:commandButton, why the new JSF 2.0 stuff with f:selectItems backed by a regular list isn't working with ice:selectOneMenu, works just with h:selectOneMenu ? What's up with ICEfaces ? And why CDI doesn't work as expected, with Seam 2 also I had problems with conversations called twice .. ps2: if I don't navigate to another view ?cid=1 isn't present in the URL.
Now, with ace:fileEntry and h:commandButton, the reason why the ice:commandButton can not be used is because that is an AJAX component, and browsers will not upload files in an AJAX submit. Even with HTML5 it is not automatic, and new File and XmlHttpRequest APIs must be used. In an HTML4 browser, only a full page, full form, submit will upload the file contents, and only h:commandButton operates that way. For more details, you can see this explained near the top of the page at:
http://wiki.icefaces.org/display/ICE/FileEntry
With our ice: components, which are extended variants of the h: components, such as ice:selectOneMenu, they are lacking some new JSF 2 features because we have been focusing on our newer Advanced Component Environment, due to customer demand for rich client-side components. As well, the focus was on maintaining backwards compatibility with the ice: components, to ease customer migration from ICEfaces 1.8.x to ICEfaces 2.x, and less so to be altering those components' behaviours. But we are still actively maintaining and improving the ice: components, and will be adding the new features soon. Feel free to create any enhancement requests in our Jira system, and to vote on any existing entries, as this does guide our development priorities.
http://jira.icefaces.org/
Mark Collette
I'm Mark Collette from the ICEfaces component team, and hopefully I can answer some of your questions.
Most of your issues seem more related to CDI integration than problems with the components themselves. I know that the symptoms change depending on which component you use, but I think that's because the ice: components use AJAX and the h: components do not. Many times integration issues with other frameworks are more observable in AJAX interactions than in full page GET/POST interactions. So your issues may be due to either our CDI integration, or your application's configuration. So please review our documentation on using ICEfaces with CDI, and if you you still experience any issues, I recommend posting the details to our forums.
http://wiki.icefaces.org/display/ICE/Using+ICEfaces+with+CDI
http://www.icefaces.org/JForum/forums/list.page
[Sorry, but this forum is not letting me post more than 2 links, so I'll split the rest of my message into another post, and hopefully that will work]
Mark Collette
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
I am trying to develop a portlet that has a domain class and database mapping for it done with ServiceBuider. Classes and numerous config files get generated fine, but deploying fails to exception (don't have them available right now).
Is ServiceBuilder supposed to work in liferay sdk 6.0.5 for ordinary Liferay portlets, or is it usable only for ext-plugins/hook-plugins/ liferay Internals? Am I missing some other undocumented restrictions/dependencies.
yup, ServiceBuilder is supposed to work from portlet plugins (and it definitely does). It's deprecated (but works) in ext plugin. See the KnowledgeBase Portlet from the plugins (svn-username: "guest", password is empty)
To find a solution for your problems it would really help to get the exact steps you do as well as the exact exception.