extend liferay plugin functionality with hooks - liferay

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.

Related

How to resolve conflict between hooks modifying the same jsp?

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.

Orchard CMS - code or UI when doing custom extensions?

I have a question for professional Orchard developers?
Given that I can create new ContentTypes and ContentParts using the UI, when should you use the UI to create new Content Types/Parts versus creating a custom module and coding everything. What are the tradeoffs? Is there a time to combine the approaches and create some of your content types/parts in the UI and then extend them further using code?
What are the advantages of each method? (For example, it seems to me that deploying changes is easier using code...but still possible using the UI using the Import/Export module?
UI it seems you get things done pretty quickly, but is less flexible and portable than writing code?
What are the things you HAVE to do in code?
I tend to start by using the UI to test ideas and just adding templates to my theme to display these new parts. I also use the UI when I just want to add a new part to an existing type.
Where I find making a very simple module with my types specified in migrations useful is where I have a site in production that I know will need upgrading in the future. I have a dev version of the site that I play about with and then when ready to go live I create a migration that will upgrade the site.
This also means I can test the migration before going live and I don't need to have a list of manual changes required to make to the live site that is prone to mistakes.

How is your approach for creating your own set of controls aka own Extensions Library?

What is your approach for creating your own set of controls aka own Extensions Library? After a few years of Xpages development we have a huge set of controls that are general purpose for building UI, some web services etc. (Probably as most other developers.) When we start a new project now we have to copy the entire stuff from one database to new one which involves controls, jars, css, images, JAVA code ... and then you completely loose control to maintain some central version of this controls & codes, everything is scattered among several projects/databases and things get messy fast.
We have thought about creating our own extension library as described here
http://www-10.lotus.com/ldd/ddwiki.nsf/dx/Master_Table_of_Contents_for_XPages_Extensibility_APIs_Developer_Guide but there is not enough documentation for this topic and the entire development process is quite complicated (at least seems to me. I tried two times based on docs above going through eclipse plugin project -> feature project -> update site and still having some bugs around)
What is your experience and approach for creating and maintaining shared Xpages controls in your Domino environment? Is there some hidden feature we miss here that can help us?
Take a look at the XSP Starter Kit on OpenNTF and the XPages SDK to setup an eclipse environment for plugin development. You'll also want Eclipse IDE for RCP and RAP Developers. Install the starter kit and SDK into eclipse and you should be all set.
The starter kit is a sample plugin with all kinds of examples of phase listeners, components, etc. Once you want to deploy your plugin, create an update site from within eclipse and use the Update Site NSF available on your server install to place your update site. Once that's done, you can replicate that NSF to any other servers that may need the plugin.
For more information about the starter kit, take a look at this slide deck. There is also a github project for the starter kit. Documentation for the XPages SDK can be found here. And a video for setting up the SDK is available on youtube. Lastly, here's the documentation for setting up the update site NSF.
While we haven't gotten to that yet in XPages, our model for regular Notes design elements is to have a central template that contains the elements that are shared, with those specific design elements marked to inherit from that template. Sometimes, a database inherits design elements from two different central templates.
That way, those centrally controlled design elements remain the same in all databases.
I would recommend looking at some example's on github for how they have library/components setup. One of the more simpler examples that has just a single component built into a Library is Steve Pridemore's App Layout Extension...https://github.com/DominoDev, Another good one is Nathan Freeman's Starterkit: https://github.com/the-ntf/xspstarterkit. Hopefully these will help you get the file structure down on which files you need and how they work.

Does Liferay 6.0.5 serviceBuider work?

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.

Are JSF/Seam/Spring suited for non-enterprise work? (website, not "web application")

I'm starting work on a new website (sort of an e-commerce product comparison thing) and I'm trying to choose what technologies to build it on. I've ruled out PHP and I don't think I want to use Python or Ruby. I really like Java and Hibernate so I started looking into Java-based web technologies.
My problem is that all of the documentation and examples I've read can't seem to stop repeating the words "enterprise" and "web applications." I'm afraid of ending up with giant XML configuration files and business-oriented components while losing the ability to actually design the website. From what I've read of JSF, I like the idea of reusable components, but I still want the ability to customize individual pages. So my question is, are JSF/Seam/Spring well-suited for non-enterprise development? If not, what Java technologies are?
I have just started looking into JSF/Seam so please forgive me if this is an uninformed quesiton. Thanks in advance. :)
No problem. The JSF/Seam stack gives you all the customization you want, and it has very few XML files. In fact, it uses a lot of annotations to define entities and components, so you don't have to worry about writing tou much XML (it is one of the reason why Seam was invented).
JSF's standard components are rendered as simple HTML tags, while if you want to go AJAX and use Richfaces it will be a little harder to customize it, but nothing dramatic. I can assure you that for the view part, you can write whatever you want in your webpages.
Here's a nice reference of how the JSF tags are rendered.
For the model and DB part, the JPA framework gives you the ability to work with simple Java Objects, and sometimes using it in an "enterprise" context with legacy schema is even more difficult, so don't worry.
For a simple website you may safely skip the EJB part, this will help you writing a more cleaner project structure. You can package all your website in a simple .WAR file.
As for the "enterprise" word, I think it is more related to the fact that the Java EE framework gives you the feature you may need in an enterprise context, (i.e. EJBs), but you can avoid them.
They don't bite.

Resources