论坛

主页 » Liferay Portal » English » 3. Development

组合视图 统一视图 树状图
讨论主题 [ 上一个 | 下一个 ]
toggle
jim beam
Liferay methodology
2013年4月21日 上午7:59
答复

jim beam

等级: New Member

帖子: 3

加入日期: 2013年4月21日

最近的帖子

Hi all,

I am new to Liferay and I am wondering how I should properly utilize the framework in my situation.
My goal is to be able to add and manage new portal users, customers and products.
One or more users belong to a particular customer.
Each customer can have products associated with it.

The portal admin should be able to perform CRUD operations on customers, users and products.

My current legacy database has existing tables for customers, users and products.
As far as I understand I will have to use the liferay users_ table and link my existing content to it.
What is the correct approach... Should I create separate portlets for managing users, customers and products, or one for all of them? Or should I extend an existing Liferay portlet/plugin?

Should I use the Service Builder to generate new customers and products tables and then import the legacy content to them or is it better (and possible) to use the existing legacy tables and map them to objects (and how would that happen).

Please give me some insights so I can use the framework properly...

Thanks in advance!
Jack Bakker
RE: Liferay methodology
2013年4月21日 上午11:37
答复

Jack Bakker

等级: Liferay Master

帖子: 514

加入日期: 2010年1月3日

最近的帖子

Hey Jim

I have web systems where there are minimum two(2) databases: Liferay's ('lportal') and what I've been calling a business database ('biz').

Liferay handles organizations and users quite well on its own tho I often create relationships between 'lportal' entities and 'biz' entities keying on, for org and user entities: organizationid or screenname(a.k.a. username).

For products (and shopping?) there is a Liferay shopping cart portlet tho I haven't used it and instead have put my shoppingcart entities in the 'biz' database.

The service builder can generate services for local and remote (SOAP or REST-style) over your 'biz' db so you end up with a suite of services (with CRUD methods if you want) that allow various soft-clients to interface with your services - where in this example services storeTo/interfaceWith 'lportal' and 'biz' db.

Liferay's Control Panel really is a gateway to multiple portlets and you certainly can add your own admin portlets to the Control Panel for managing 'biz' database entities
where then given the 'suite' of services across 'lportal' and 'biz' you have available, you can deal with much, including upgrades to Liferay (I recommend you don't go too far in your own Control Panel portlets unnecessarily recreating what Liferay already provides).

Enjoy
jim beam
RE: Liferay methodology
2013年4月22日 下午5:29
答复

jim beam

等级: New Member

帖子: 3

加入日期: 2013年4月21日

最近的帖子

Thanks, Jack!

Jack Bakker:

Liferay handles organizations and users quite well on its own tho I often create relationships between 'lportal' entities and 'biz' entities keying on, for org and user entities: organizationid or screenname(a.k.a. username).

If I get it correctly you maintain two different databases ('lportal' and 'biz'). I guess you use a separate data-source for the 'biz' database (configured in the ext-spring.xml file). Isn't it easier to keep the biz-related tables also inside the 'lportal' database (with a biz_ namespace) so that you can link them to the user table with direct foreign keys and enforce "on delete cascade" for example? Otherwise how would you make sure that deleting a lportal user will delete the related entities from the biz database... (or maybe liferay has automatic handling of relations across databases?)

Jack Bakker:

Liferay's Control Panel really is a gateway to multiple portlets and you certainly can add your own admin portlets to the Control Panel for managing 'biz' database entities
where then given the 'suite' of services across 'lportal' and 'biz' you have available, you can deal with much, including upgrades to Liferay (I recommend you don't go too far in your own Control Panel portlets unnecessarily recreating what Liferay already provides).

What do you mean by "don't go too far in your own Control Panel". For example for adding/modifying customers I will have to use the service builder to create a new portlet that has utilities linking to the database table 'customers'. Or is there a more appropriate approach - for example extending an existing liferay portlet?

Cheers!
Jack Bakker
RE: Liferay methodology
2013年4月22日 下午6:33
答复

Jack Bakker

等级: Liferay Master

帖子: 514

加入日期: 2010年1月3日

最近的帖子

Hey Jim

Enterprise systems I deal with generally have ldap, multiple databases (including 'lportal'). For me, there are, for example, usernames(=screennames) that are keys for users across multiple datastores.

However, if putting all your additional entities in the lportal db works for you, then why not. For me, aside from hooks and necessary patches, I try not to modify the Liferay core too much so I can upgrade Liferay more easily - where on upgrade I don't need to change my 'biz' db (n my case a 'biz' db or two that other applications also store to).

Enjoy
jim beam
RE: Liferay methodology
2013年4月26日 上午6:31
答复

jim beam

等级: New Member

帖子: 3

加入日期: 2013年4月21日

最近的帖子

Thanks, Jack!