Development best practices

[Hitoshi Ozawa, modificado hace 11 años.]

Recently, I've been seeing some developers use expando api in their programs. I have to admit that I first though expando was a neat idea and suggested using it, but I have to say that it was a complete failure. If you've programmed with liferay, you'll soon find that api do not get deprecated but suddenly change or gone. That is to say, it's not very wise to write complicated large programs that depends too much on liferay api's too much. The another issue is data migration and version up - there's always seems to be trouble - it's better to keep database tables simple and under your control because liferay's tools sometimes does not completely work the first time around.

That said, I was wondering if some other developers have their best practices which they have which may be against what liferay recommends. It would be nice to share and write them up in a wiki for all to read to save new developers their time and headache.

[David H Nebinger, modificado hace 11 años.]

Have you really noticed that the expando bridge/expando API has undergone that much change?

That said, the only reason to use the expando stuff is because you either don't or can't create your own service builder entities. It's weird that my service builder entities also seem to come w/ the expando bridge already attached. Seems strange that I'd ever want to use the expando bridge on entities which I've created, since I could always extend them myself.

The best 'best practice' I'd add is to always download the source for the portal for the version you're developing against. It seems like a lot of questions that come out in the forum are sometimes easily answered by viewing the underlying source...

[Mika Koivisto, modificado hace 11 años.]

I think the problem is that most people use the API incorrectly. They should always use ExpandoBridge as it provides much simpler API.

[Hitoshi Ozawa, modificado hace 11 años.]

I think the problem is that most people use the API incorrectly. They should always use ExpandoBridge as it provides much simpler API.

Then, you'll have to promise to deprecate the API as is the norm in java projects instead of just changing or dropping them. I think this request has been raised several times in the forum before. I'm limiting myself to using simple entity services otherwise to play it safe.

There was a wiki by James about the community activity map in the community top page. He wrote something about using web content instead of creating a portlet because it was easier to update. I have to agree on the choice taken, but I can't convince every programmer to use web content because learning curve is too high to get programmers interested in it.

It may be fun to have a friendly (not heated) debate at Liferay symposium to exchange ideas.

[Hitoshi Ozawa, modificado hace 11 años.]

Mika, how about this scenario. Since this is a slow day and I've drunk too much coffee and too much coke.

Have several portal instances each with several organizations. Suppose I want portalInstance1.org1, portalInstance1.org2, and portalInstance2.org1 all to share common additional field, but don't want portalInstance1.org3 and portalInstance2.org2 not to have the field.
How would I do this with expando?

[Sandeep Nair, modificado hace 11 años.]

Yes i can quote quite many areas that is not just JAVA where stuff were just dropped instead of deprecating that created trouble for me

Like in AUI if you were using AUI dialog before 6.1 the button names in dialog were having attributes text and in 6.1 it suddenly changed to label !!! Imagine you suddenly start seeing dialog box in 6.1 with no text appearing in button all of a sudden.

Similarly I dont remember the version but before there was support for using both these keys portal.dependency.jars and portal-dependency-jars in liferay-plugin-package.properties and suddenly Liferay decided to drop portal.dependency.jars and i was getting all those ClassNotFoundExceptions which startled me for an hour.

As Hitoshi said, deprecation(or still having support) is always better than just dropping.