In Liferay, when you add a web content to a page, a Portlet is created and you can choose the web content that will be displayed (when logged as admin), and you can choose some parameters (rights to view the content, share...).
I would like to create a Portlet that overloads this Portlet, to allow the admin to choose his / her web content with custom parameters.
Does anyone know how this could be done ? Thanks !
First idea which came to my mind is to hook default Web Content
Display Portlet This would allow you to add some custom business
logic to this portlet and not need to implement all you already get
from original one. Still this will much depends on how much your new
features you want to add, are complex.
As you have said, you are beginner, so here are some hints, how to start up with hook creation:
Visit https://www.liferay.com/documentation/liferay-portal/6.1/development/-/ai/liferay-plugin-types-to-develop-with-maven section Developing Liferay Hook Plugins with Maven This archetype will create for you default structure of hook plugin.
Next step, is to download your liferay sources (if you haven't already) Visit official site https://www.liferay.com/downloads/liferay-portal/available-releases
Now when you have your sources, get these .jsp files which you want to modify, and copy to your hook. Make sure to keep folder structure as in default one.
Add your custom logic, in specified place and after deploying, test it.
Good luck
Another idea is to use maven war overlay which you can read
about more under http://java.dzone.com/articles/mavens-war-overlay-what-are
As you say you're a beginner, I'd suggest to create your own portlet that is independent of Liferay's portlets. You can use Liferay's API to get the article you'd like and its content, while implementing your own functionality to filter out the content you like.
The reason I'm suggesting a custom portlet is: Liferay's portlets must be as generic as possible, to match as many usecases as possible. Thus there are lots of conditionals that you won't need (and won't need to understand) in the implementation. If you have some narrow non-generic requirements to have an alternative behavior, you're easier off implementing exactly those requirements rather than adding to the generic, highly conditional UI. Plus, you might want to keep the original UI for other purposes. If you make a mistake in your own implementation, the original Web Content Display Portlet would still continue to work.
That being said, you might also look at the AssetPublisher portlet. It's the swiss army knife of content management and might already do what you want (and a lot more). This takes criteria and will evaluate them at runtime, displaying matching articles (or other content types).
Related
Asked on Liferay Forums - post
I'm creating a Hook on top of Liferay's Doucment and Media Portlet to extend the original JSP. Extending the JSPs are straightforward, but I have no idea what they might be called. Sure I can guess but who wants to do that? In particular, I want to add an additional menu item on Document and Media's > Document > Edit Dropdown Menu
Does Liferay provide a glossary or index on where I could find this and any other JSPs I might extend?
Simple answer: No.
While JSPs are easy to overload, there's no API involved and technically you're in the implementation and not the API. Thus there's no assumption about good maintainability, no promise for stability and no API-style documentation at all.
I'm aware that JSPs are popular to overload, but they're actually dangerous and must be used with care.
You will have to view source for this kind of modification. But as soon as you realize that you're hitting the implementation, it all makes sense (and you don't really want to overload them any more)
Here's an answer I got from another member on the forums:
Hey Clay,
There is no "glossary" per say (at least not one that I am aware of)
but once you understand the pattern that LR uses it can be pretty
straight forward. First things first, if you don't already have it in
place, make sure you download the source for the version of the portal
that you are using.
under the portal-web module you will find /html/portlet. This is where
all the views for the Liferay portlets are stored. Most of them are
pretty straight forward. For example, doucment_library in your case.
The other thing you want to look at is the struts-config.xml file
(portal-web/WEB-INF). In that file you can search for "documents" and
you will find all sorts of documents and media references. What you
are interested in, for example, is something like this I think --
1 <forward name="portlet.users_admin.edit_organizationpath="portlet.directory.view_organization" />
The "path" attributes are references to the jsp files. So in this
case, /html/portlet/directory/view_organization.jsp -- /html being
implicit for these paths. I often reference this file to understand
where the struts actions for things in the control panel go.
So, no "one pager" with all the details, but once you understand the
pattern (which is super basic) it's easy peasy to get around.
Hope this helps!
The ROOT application contains all of the items described (classic theme, approx 10 layouts and numerous portlets).
Is it possible or good practice to create own packages like this? How to?
Please, give a hint.
Theoretically it is possible to have a single project with a Portlet, Theme, Layout and a Hook all packed in one.
But it is not at all a good-practice to have all the four types togather, from both maintenance and development perspective.
Though sometimes you may have a portlet and hook in one project if they are somehow related for example like you want to have some Listeners to add data to your custom table and then your portlet would provide an interface to update or view that data, so in this case they are interdependent and if the portlet goes the hook is of no use. So go ahead and combine them.
So if the 4 types are related somehow or interdependent than I see a usecase to have them togather (it would be rare) but still from maintenance point of view I would rather keep the 4 separate. Atleast I would keep portlets and themes separate and may have a Portlet-hook combination and a theme-layout combination since they go well with each other even from the maintenance & development point-of-view.
Here is how you can do it
Let the name of the project be say MyCompletePackage-portlet
The project can live in the portlets folder of the plugins-sdk if you are using the plugins-sdk.
Now add the plugin-type specific stuff as you normally do, like:
liferay-hook.xml for hooks
liferay-portlet.xml for portlets
liferay-look-and-feel.xml for themes
liferay-layout-templates.xml for layouts
For hook and portlet combination you won't need to modify the build.xml file and just build as you normally do.
Even for theme and layout combination you won't need to modify the build.xml.
But for theme and portlet combination you would need to include theme specific stuff in your build.xml.
Since the deployer looks for the specific files in the project it would know what all things you are deploying and would register them accordingly.
Let me know if this works for you or if you face any issues.
Disclaimer: I have not tried the 6th point but it should work
Generally one would add all portlets in one war so that they can access the service without any problems and to save context reloading time.
However Themes with portlets might not be a good idea always since we change theme.. and thus while updating portlets reloading in unnecessary. Well that's once in months but still a statement to keep portlets away from themes war.
I've searched on internet and here on SO, but couldn't wrap my mind around the various options.
What I need is a way to be able to introduce customer specific customization in any point of my app, in an "external" way, external as in "add drop-in jar and get the customized behavior".
I know that I should implement some sort of plugin system, but I really don't know where to start.
I've read some comment about spring, osgi, etc, can't figure out what is the best approach.
Currently, I have a really simple structure like this:
com.mycompany.module.client.jar // client side applet
com.mycompany.module.server.jar // server side services
I need a way of doing something like:
1) extend com.mycompany.module.client.MyClass as com.mycompany.module.client.MyCustomerClass
2) jar it separately from the "standard" jars: com.mycompany.customer.client.jar
3) drop in the jar
4) start the application, and have MyCustomerClass used everywhere the original MyClass was used.
Also, since the existing application is pretty big and based on a custom third-party framework, I can't introduce devastating changes.
Which is the best way of doing this?
Also, I need the solution to be doable with java 1.5, since the above mentioned third-party framework requires it.
Spring 3.1 is probably the easiest way to go about implementing this, as their dependency injection framework provides exactly what you need. With Spring 3.1's introduction of Bean Profiles, separating concerns can be even easier.
But integrating Spring into an existing project can be challenging, as there is some core architecture that must be created. If you are looking for a quick and non-invasive solution, using Spring containers programmatically may be an ideal approach.
Once you've initialized your Spring container in your startup code, you can explicitly access beans of a given interface by simply querying the container. Placing a single jar file with the necessary configuration classes on the classpath will essentially automatically include them.
Personalization depends on the application design strongly. You can search for a pluggable application on the Internet and read a good article (for an example: http://solitarygeek.com/java/a-simple-pluggable-java-application). In the pluggable application, you can add or remove a feature that a user decides. A way for the pluggable application is using the Interface for de-coupling of API layer and its implementation.
There is a good article in here
User personalisation is something which needs to be in the design. What you can change as an after thought if the main body of code cannot be changed, is likely to be very limited.
You need to start be identifying what can be changed on a per user basis. As it appears this cannot be changed, this is your main limiting factor. From this list determine what would be useful to change and implement this.
I have a custom portlet that I added to Liferay. I am looking for a way to duplicate the portlet, make some very little changes on it and use it on another community i.e. I want to be able to see the two portlets when I login as super admin and click on the add application link. Does anyone know an easy way of doing this?
You can define any number of portlets in portlet.xml - so if there's currently only one, you can add another one, implement (through copy/paste, inheritance or delegation, just as you like) the functionality needed. If you take a look at the liferay-specific deployment descriptors also in WEB-INF/, you can provide more information about your modified portlet there as well.
If a portlet needs to be duplicated with only small changes, maybe you can look at portlet preferences as well. This way, you can add multiple instances of the same portlet on one or more pages, and configuring their behavior at runtime. No need to duplicate the portlet project or to define multiple portlets in your portlet.xml.
For more information about portlet preferences, check the Portlet API JavaDocs.
I don't thing this is possible, in that case you need to create a new portlet copying all content from the old one and modify it.
I'm playing with a GWT/GAE project which will have three different "pages", although it is not really pages in a GWT sense. The top views (one for each page) will have completely different layouts, but some of the widgets will be shared.
One of the pages is the main page which is loaded by the default url (http://www.site.com), but the other two needs additional URL information to differentiate the page type. They also need a name parameter, (like http://www.site.com/project/project-name. There are at least two solutions to this that I'm aware of.
Use GWT history mechanism and let page type and parameters (such as project name) be part of the history token.
Use servlets with url-mapping patterns (like /project/*)
The first choice might seem obvious at first, but it has several drawbacks. First, a user should be able to easily remember and type URL directly to a project. It is hard to produce a human friendly URL with history tokens. Second, I'm using gwt-presenter and this approach would mean that we need to support subplaces in one token, which I'd rather avoid. Third, a user will typically stay at one page, so it makes more sense that the page information is part of the "static" URL.
Using servlets solves all these problems, but also creates other ones.
So my first questions is, what is the best solution here?
If I would go for the servlet solution, new questions pop up.
It might make sense to split the GWT app into three separate modules, each with an entry point. Each servlet that is mapped to a certain page would then simply forward the request to the GWT module that handles that page. Since a user typically stays at one page, the browser only needs to load the js for that page. Based on what I've read, this solution is not really recommended.
I could also stick with one module, but then GWT needs to find out which page it should display. It could either query the server or parse the URL itself.
If I stick with one GWT module, I need to keep the page information stored on server side. Naturally I thought about sessions, but I'm not sure if its a good idea to mix page information with user data. A session usually lives between user login and logout, but in this case it would need different behavior. Would it be bad practise to handle this via sessions?
The one GWT module + servlet solution also leads to another problem. If a user goes from a project page to the main page, how will GWT know that this has happened? The app will not be reloaded, so it will be treated as a simple state change. It seems rather ineffecient to have to check page info for every state change.
Anyone care to guide me out of the foggy darkness that surrounds me? :-)
I'd go with History tokens. It's the standard way of handling such situations. I don't understand though, what you mean by "It is hard to produce a human friendly URL with history tokens" - they seem pretty human friendly to me :) And if you use servlets for handling urls, I think that would cause the whole page to be reloaded - something which I think you'd rather want to avoid.
Second, I'm using gwt-presenter and
this approach would mean that we need
to support subplaces in one token,
which I'd rather avoid.
If you are not satisfied with gwt-presenter (like I was :)), roll out your own classes to help with MVP - it's really easy (you can start from scratch or modify the gwt-presenter classes) and you'll get a solution suited to your needs. I did precisely that, because gwt-presenter seemed to "complicated"/complex to me - to generic, when all I needed was a subset of what it offered (or try to offer).
As for the multiple modules idea - it's a good one, but I'd recommend using Code Splitting - this type of situation (pages/apps that can be divided into "standalone" modules/blocks) is just what it's meant to be used for, plus you bootstrap your application only once, so no extra code downloaded when switching between pages. Plus, it should be easier to share state that way (via event bus, for example).
Based on what you have posted I presume you come from building websites using a server side framework: JSP, JSF, Wicket, PHP or similar. GWT is not the solution for building page-based navigational websites, like you would with the aforementioned frameworks. With GWT, you load a webapp in the browser and stay there. Handle user events, talk with the server and update widgets; using gwt-presenter is a good thing here as you are forced to think about separation of controller logic and view state.
You can really exploit all features of GWT to build a high-performance app-in-the-browser, but it is definately not meant for building websites (using hyperlinked pages that transfer request parameters via the server session).
This is by far the most widely asked question about GWT here # StackOverflow :)
"How do I define pages and navigation between them in GWT?" Short answer: "You don't."
Use Wicket instead, it runs on the App Engine just fine and enables you to define page bookmarks and all stuff you mentioned above. Look here: http://stronglytypedblog.blogspot.com/2009/04/wicket-on-google-app-engine.html