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!
Related
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).
Can I create my own nested portlet? i need to have a nested portlet, in which to add three custom portlets. Those three portlets should be added from code.
Can you do it? Yes. Should you do it? Well...
Consider using standard Layout templates - these are extremely quick to create.
For populating a page with content/portlets, I'm typically pointing to the sourcecode for sevencogs-hook (which was delivered up to Liferay 6.1.0 CE but is still valuable documentation for placing portlets on a page - among other things). Others might point you to dynamically adding portlets to a page.
If you have a limited amount of variations of portlets that you'd like to add to the page/nested portlet, consider adding all of them but selectively not displaying any content (e.g. use inter-portlet-communication) - this makes it more obvious to the random page administrator (who might be someone else than you) which content will be displayed where. Also, it gives you flexibility if you want to rearrange the output.
Picking up my first paragraph - just look at the source code for the core nested-portlet to figure out the mechanics to dynamically dispatch to embedded portlets if you can't think of solving the problem in any of the alternative ways that I've suggested. If you can't figure it out (or if the "how" was your original question") please edit your question and clarify what the actual question is - I have the feeling that you're not interested in a yes/no answer.
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
I wonder if I should use it, in this example. I'm reading files, and I need to store one parameter with that file.
According to this parameter I'm bundling files together and sending them over the wire.
I came accross jaf activation framework, and I'm not sure if it is appropriate to use it in such simple example.(store 'file' into DataHandler with this parameter or to make me simple holder). Of course I don't know if requirments can change in the future, and I will need more.
What do you think about it?
My impression is that it's too much, it's difficult to get proper sources. But on the other hand it has what I need.
The question could be more general as well, should I use framework which can do a lot more, if I need something really simple and I can code it quickly?
thanks in advance
To answer your more general question, I would most often make use of frameworks wherever possible.
It's always possible that you're going to want more functionality in that area. If you're using the framework then great. Otherwise you have to back out and rewrite. Or maintain two different implementations.
Frameworks have been debugged/tested etc. and will handle the edge cases. Often what you think of as being trivial ends up more complicated than you first thought.
Don't forget that due to how class loading works, the JVM will only load the classes you require. Consequently you're only affecting the size of deployment of your application, not the runtime size (by referencing a sizable jar)
I'm working on a java SE 1.5+ swing application, in conjunction with others. I'm wondering what the best way of managing string resources is. I understand the principles behind resource bundles etc. I'd like to avoid having one property file for every class that needs a string, as this seems a bit of overkill. Especially when you have a lot of classes that may only make a single reference to a string (say in an error handler). On the other hand it makes it easier when collaborating with others as you reduce the risk of merge conflicts.
It seems particularly cumbersome to have to load resource bundles, every time you need to display simple user feedback, likewise in error handlers, when many classes are involved.
What is the most effective way to manage strings in a fairly large application with hundreds of classes, many of which aren't GUI related, but need to pass informative messages back up to the GUI when exceptions occur.
I'm using NetBeans which generally creates a property file for each GUI class, for all text relating to buttons, labels etc.
What makes you think you have to have a separate properties file for every class? Generally you only need a few (or just one!) properties file (per language, of course).
Just call ResourceBundle.getBundle() with appropriate parameters - you can use the same bundle from multiple classes.
EDIT: Having one set of property files per dialog etc makes it easier to see where any particular string is coming from, but it makes it harder to reuse the same messages etc. Quite where the right balance is will depend on the application.
JSR 296 Swing Application Framework has support for resource management (and it looks like will be part of Java 7). SAF aims to pre-build parts of a Swing app that many people frequently need while encapsulating best practices. You probably don't want to tie to it directly but its worth taking a look at what they do to see whether it gives you some ideas. If I recall, they use cascading resource bundles with well-defined naming conventions. The latter means you know where to look and the former means that you can reuse properties across some portion of your package hierarchy.
Many JSR 296 resources collected here.
This may be naive, but what about storing them in a database, either embedded or external? This might simplify management, and changing languages more configurable.
I'm going to implement something similar to Launchpad's translation platform this year:
https://launchpad.net/+tour/translation
In a nutshell:
Concurrent translation
Phrase suggestions based on previously-entered phrases
Policies, e.g. Partly restricted and structured: anyone can suggest translations, while trusted community members review and approve new work
UPDATE
Of course, this builds on top of ResourceBundle etc, but is a nice way to manage all them strings ;-)