Tribune

Home » Liferay Portal » English » 3. Development

Vista Combinata Vista Piatta Vista ad Albero
Discussioni [ Precedente | Successivo ]
toggle
jim beam
Liferay methodology
21 aprile 2013 7.59
Risposta

jim beam

Punteggio: New Member

Messaggi: 3

Data di Iscrizione: 21 aprile 2013

Messaggi recenti

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
21 aprile 2013 11.37
Risposta

Jack Bakker

Punteggio: Liferay Master

Messaggi: 547

Data di Iscrizione: 3 gennaio 2010

Messaggi recenti

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
22 aprile 2013 17.29
Risposta

jim beam

Punteggio: New Member

Messaggi: 3

Data di Iscrizione: 21 aprile 2013

Messaggi recenti

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
22 aprile 2013 18.33
Risposta

Jack Bakker

Punteggio: Liferay Master

Messaggi: 547

Data di Iscrizione: 3 gennaio 2010

Messaggi recenti

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
26 aprile 2013 6.31
Risposta

jim beam

Punteggio: New Member

Messaggi: 3

Data di Iscrizione: 21 aprile 2013

Messaggi recenti

Thanks, Jack!