I am very new to liferay 7 ,actually we are migrating liferay 6.2 to liferay-7 ,in the 6.2 we are using ext to override the action class but in the liferay-7 I am getting some cofusion,could you please help me out.
The main theme of my ext is : whenever a new role getting created in an organization from the control panel, we need to store the role information and organization information in our custom table for that we have overriden EditRoleAction.java in LR6.2 so same thing we are trying to achieve in LR7.
Action class in Liferay 6.2 :
Portal path :
D:\Liferay6.2workspace\portal\portal-impl\src\com\liferay\portlet\rolesadmin\action\EditRoleAction.java
Ext Path:
CutomRoles-ext/docroot/WEB-INF/ext-impl/src/com/liferay/portlet/rolesadmin/action/EditRoleAction.java
Action class in Liferay 7.0GA4 :
D:\Liferay7GA4\portal\modules\apps\foundation\roles\roles-admin-web\src\main\java\com\liferay\roles\admin\web\internal\portlet*RolesAdminPortlet.java*
It really sounds like overriding the Action is not the right place to go. Look up ServiceWrappers - these will run on the business layer, and you can add additional code to (from memory) RoleLocalService.addRole(...) and other related methods.
Ext was never necessary for this purpose and shouldn't have been used in the first place. In fact, with the use of ext you deliberately make maintenance and upgrades a lot harder than when you go the regular plugin route. And with Liferay 7 and DXP the use of ext should be the extremely rare absolute exception to the rule. In fact, it's just now being reintroduced after being absent so far (because in a few rare exceptional cases it's still the only way). However, it's safe to assume that you don't need it.
Now that the description in the comments to this answer goes much further than the description in the question: You might need some portlet-level customizations as well. For this: Identify where the portlet is currently implemented (e.g. identify the module) and override its actions (there's a good chance that this article can help) and potentially also the UI.
And yet another alternative: You might be able to achieve the same by using Teams in the organization's site: They behave almost like roles but are only available to a single site (no organization though, but you state that your organizations have sites anyway)
Related
I'm looking for simple way to update custom translations in Liferay without redeploy of language hook. Restart is no option for me too :).
UPDATE:
The customer has quite big portal with about 50 different portlet-applications. Each application has rich user interface in four languages. Together the portal has about 800 keys that must be translated.
For this translation work the customer has specific department that works with appropriate tools. This tools can generate Liferay compliant property files.
Furthermore, by 800 key-words / translations, that is frequently necessary to change the translation.
Hence, I'm looking for method to update UI translations live - on the fly. Without redeploy of language-hook and without restart the Liferay.
If you're thinking of translating the content that you already enter to your portal, that's already changeable through the UI, no hook or anything necessary. However, as you mention hooks I believe that this is not what you're looking for.
Redeploy of a language hook is the simple option to update the application's language (i.e. Liferay's own UI). You can hot-deploy a language hook without restarting the server. All the other solutions I can think of are at least an order of magnitude more complex and would involve program code that overrides the mechanics how Liferay looks up translated UI elements.
IMHO you can choose either one, "simple" or "no redeploy of a hook". You can't eat your cake and have it, too.
Update (after your update): What I described above is Liferay's mechanism, which you're free to use or to ignore. If your plugins have specific needs that their translation must be updated without the plugins being updated at all, you're free to choose any different language lookup mechanism of your choice. The Liferay mechanism - in this case - might not be what you need to use. Or you'll need to talk to your business users and get their information on how often they believe that the translation will be required to update when the plugins stay unchanged. Or how often they are prepared to redeploy the plugins (and if they can wait for this amount of time)
Now our team is facing new project - creation of new company's intranet portal. Because of some reasons we are considering java open source portals and deciding between Liferay and GateIn.
One of very important requirements is following: portal representation for users must depend on country/language settings of customer computer, it means not only portlets localization but users in US subsidiaries of the company should see probably other structure than users in France.
Is it possible to implement the requirement in Liferay and GateIn?.
This can definitely be achieved through Liferay. Please have a look at the concepts of creating organisations.
Am not sure if this can be done in GateIn. However, there are many other things that you may need to keep in mind before choosing these Portals. I have tried to mention few of them here.
1. Check the stability of the Portal server that you will choose to run on a particular Container. GateIn initially was unstable.
2. You may have to override few files (for your customization) if required. GateIn uses GTMPL view technology for the same. Check how good are you in this. In this case, Liferay is easier (Liferay doesn't use any GTMPL UI framework)
3. Apart from developing a location based Portal, if you are also trying to achieve other things like fully Ajax based pages, a good UI framework (like JSF) etc then check if the Portal server you are choosing runs on a particular Container which supports Ajax, JSF (latest versions)
Above were few and list may grow. But, to conclude I would suggest to go for Liferay :)
This can be achieved with Gatein at different level :
Sites : you can declare multiple sites running on the same portal instance(sharing same User Base). In this case you can automatically redirect user to different country sites, based on the country/language of the user.
Sites Navigations : Gatein provides portal, group and user navigations. Navigation is created dynamically when a user connects to the portal. You can have only websites, navigation will created dynamically by user (based on group and user permissions).
Pages (Dynamics layout rendering): GateIn renders each page dynamically. A page is composed of multiple containers that contains portlets or gadgets.
By setting permissions on each container and by using User Group or Membership of the connected user, it's possible to have different page layout.
Of course, you can also mixed these 3 approaches to build your portal.
Liferay is very buggy, and community is very bad. Unless you pay the support.
GateIn promises much, but still lacks functionality.
You may consider JBoss Juzu and Apache Struts to develop generic portlets in order to void any portal vendor lock-in.
Struts provides features of internationalization, localization, timezones achieve my project.
I make use of struts2-portlet plugin to achieve a reporting portlet running on multiple portals. Here is my sample: code.google.com/p/jasperrocks/wiki/Features
First of all, let me tell you what I am or my company is intended to do. We have already developed a project using Java, JSP and Servlet. We want it to integrate with Liferay so that we can change logo, css, images, themes or any other UI related component at run time using Liferay admin panel. But backend should be what we have developed.
In short, the UI of our project is controlled by Liferay, but control of data displayed on UI or submitted from UI should be from our developed backend code.
Now I have a few questions regarding above said approach of fulfilling the requirement:
What we are trying to do is possible?
Is this approach recommendable for what we intended to do?
Or do we need to develop our project from scratch to fit into Liferay? Like developing portlets and deploying in Liferay or other approach that has been given in Liferay documentation.
What about database integration? We have around 15 columns/fields in user table in database of our project which is completely different from that of Liferay's user table.
Liferay is a very new for us. We have checked the documentation section of Liferay but still few things like above said requirements and its implementation is not clear. Also, we would like to know in what scenarios/requirements Liferay is useful.
Ok let me try to answer your question point-wise and I would answer your last question first, which should automatically clear other questions:
Q. Also, we would like to know in what scenarios/requirements Liferay is useful.
This can have a very wide answer, but I have made it shorter for you:
If your site is content heavy and not data heavy then go for Portal
If you plan to use only a single web-application in a portal then I would suggest standalone custom developed web-application is much better.
I agree liferay portal will give you lot of things out-of-box like Single Sign-on, authorization, authentication, friendly-url and page creation and also lot of applications like Blogs, Wikis, Document library, some social networking apps etc. But think about it, do you really need all this? if not, then this is overkill
Here are some really nice links to better understand a portal's usage:
When to use a portal
Why to use portal technology
liferay tag wiki: It has nice description as to what is liferay and it also contains relevant links to Admin guide which will tell you what all functionalities liferay has and how you can manage it.
So still if you find your other questions unanswered, read-on ...
Q1. What we are trying to do is possible?
Nope. Portlet technology is different from Servlet technology. Liferay (or anyother portal) does not provide a way (atleast a simple one) to integrate servlets that would render pages inside a portal. For eg: Since with servlet you define URL mappings for a particular servlets before-hand in a web.xml but in a portal the URLs are generated by the Portlet Container. So portals work with portlets and not Servlets.
Q2. Is this approach recommendable for what we intended to do?
Nope. As I already explained in Q1.
Q3. Or do we need to develop our project from scratch to fit into Liferay? Like developing portlets and deploying in Liferay or other approach that has been given in Liferay documentation.
If you want to go the liferay way then Yes.
If you want to build applications that talk to your custom tables then portlets are the way to go.
Q4. What about database integration? We have around 15 columns/fields in user table in database of our project which is completely different from that of Liferay's user table.
If you go with Liferay. In this scenario you can create a combination of liferay-hook & portlet (may be using service-builder) to customize liferay's User creation mechanism and there by store data in both Liferay's User table and your custom tables.
Liferay's permission system is really fine-grained so you can also benefit from this system and put permission even on the data level.
In conclusion I would say:
Everything boils down to what your requirements are and what resources you have. And sometimes what future requirements you can have.
Note: All the terms used in this answer which are specific to liferay (like service-builder, hook etc) are explained in the liferay tag wiki.
Hope this helps. If you would like to know anything specific I would gladly update my answer.
I'm working on a liferay portlet similar to 'Documents and Media', that connects to an Alfresco repository, and using the apache chemistry open cmis API to interact with repository items.
I'm almost done with applying Permissions through ACEs, but I have a major issue, dealing with alfresco's "Inherit Parent Space Permissions" feature which propagates the parent folder's properties to all the children. Looks like this feature is not supported by cmis, but I have to find a way to edit this property from liferay.
Although there isn't any available high-level API to edit this property, I guess I can make a workaround by using the Alfresco's REST API.
Doing something like this maybe.
But before doing that I'd like to make sure there is no other way to do that. I mean, it's a pretty major feature missing here. If I understand correctly, if you can't have access to that property you can choose between :
Disabling the inheritance for all items, and lose the benefits
from the inheritance and ACL propagation.
Or Enabling the
inheritance for all Spaces, and since ACL works like granting-rules
(and not restricting ones), having the children resources always less
restricted as you navigate deeper in the repository. This way, you
end up having all the restricted resource pretty close to the
'company home' space, and put the higher-availability resources very
deep in the repository space structure.
Or Having the inheritance enabled, and each time you want to remove a single permission from a
child resource, make a call to alfresco from another lower level API,
disable the inheritance (and lose all the propagated ACEs, desired or
not), then add again the necessary aces.
This doesn't sound reasonable to me, so I'm really afraid I'm missing something here, like a major high-level API feature. Could someone please tell me if I'm on the right track, and whether or not is the lower-level API calls the only option available ?
CMIS does not support changing the ACL inheritance setting. You can determine which ACE's are inherited, but you can't turn inheritance on and off. You'll have to write your own web script and call that from your portlet.
I'm developing a wicket application (currently using wicket 1.5) which is about to get a blog-like feature. Users can post stuff or mark certain business objects as public and other users can comment on these. Only the owning user is allowed to edit these business objects or posts.
I know that there are several frameworks providing hide/show or switch-panel functionality based on the current user but is there anything that can be used to do this not only user-based but context-based as well? I know that I'll have to provide my business logic but I'd prefer to skip all the repeating boilerplate-code, so even an AOP-driven-approach might do the trick but since I never worked with that before, I don't know.
Edit: More details on the scenario:
Within the application any (logged in) user can enter let's say recipes which he can flag as public (can be read by anyone) or private (can be read only by himself). Any logged in user can comment on any public recipe (either public or private). Private comments can only be read by the commenter and the recipe owner. Only the owner can edit a recipe. Only the commenter can edit his comments. Only the recipe owner or the commenter can delete comments.
So basically I'm just looking for an idea to expand the classic role-based security model by a context based role ("owner") and by writing this it seems that the only wicket edge to this would be, that I'd prefer a solution based on a framework that integrate well wit wicket (or even one where the integration is already provided by wicketstuff).
If you're looking for a security framework that supports instance-based authorization, you could take a look at Spring Security ACLs.
But unless you want to build something say, as flexible and generic as the Unix file system, I don't think this kind of solution is necessary.
Anyway, to 'integrate' whatever solution you choose into Wicket pages, you could do something as simple as overriding the `onConfigure()ยด method (on pages or components), to verify user permissions and set things visible/invisible, enabled/disabled as needed.
#Override
public void onConfigure() {
boolean isAuthor = getCurrentUser().equals(post.getAuthor());
deleteButton.isVisible(isAuthor);
editLink.isEnabled(isAuthor);
}