Forums

Home » Liferay Portal » English » 3. Development

Combination View Flat View Tree View
Threads [ Previous | Next ]
toggle
jim beam
Liferay methodology
April 21, 2013 7:59 AM
Answer

jim beam

Rank: New Member

Posts: 3

Join Date: April 21, 2013

Recent Posts

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
April 21, 2013 11:37 AM
Answer

Jack Bakker

Rank: Liferay Master

Posts: 547

Join Date: January 3, 2010

Recent Posts

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
April 22, 2013 5:29 PM
Answer

jim beam

Rank: New Member

Posts: 3

Join Date: April 21, 2013

Recent Posts

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
April 22, 2013 6:33 PM
Answer

Jack Bakker

Rank: Liferay Master

Posts: 547

Join Date: January 3, 2010

Recent Posts

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
April 26, 2013 6:31 AM
Answer

jim beam

Rank: New Member

Posts: 3

Join Date: April 21, 2013

Recent Posts

Thanks, Jack!