WHY LIFERAY IS PURE CRAP -read here if you want resolve problems in liferay

[Paolo Pilitti, geändert vor 12 Jahren.]

'cause there's no documentation at all in the code


Im trying to modify asset categories selector and there is no a comment line
The api docs are pratically empty
every thing is done with some vodoo code ( uncommennted)

the categories are hierarchical, but asset publisher dont support hiearchy

alloy ui : no documentation


THE SOLUTION : abandon liferay

[Joseph John, geändert vor 12 Jahren.]

My experience is different
I am not from development background, my knowledge of J2EE and web technology is minimum
But going through the books and wiki, I was able to set up a mock web site
Now I am trying myself to use /demo Liferay as portal solution
Thanks
Joseph John

[Paolo Pilitti, geändert vor 12 Jahren.]

Yeah, for an editor user, liferay portal can go ( but there are alternatives) but the problem is that liferay PROMISES easy customization and expansion but when you go in deep in some aspects you will smash your head against a wall of insormontable, undocumented, problems.

[James Falkner, geändert vor 12 Jahren.]

Paolo Pilitti:

Yeah, for an editor user, liferay portal can go ( but there are alternatives) but the problem is that liferay PROMISES easy customization and expansion but when you go in deep in some aspects you will smash your head against a wall of insormontable, undocumented, problems.

Hey Paolo,

Thanks for the feedback, we're working on improving the our developer experience, including documentation (have you seen the 6.1 javadocs yet)? With your new knowledge, would you be willing to help us prioritize our efforts? You undoubtedly know of those dark corners of the project that could use extra documentation, and also if you'd care to add more detail around your experience, we could probably target those areas sooner rather than later. No one likes to smash their head against anything, so please help rather than vent, and you can make a difference.

[jelmer kuperus, geändert vor 12 Jahren.]

I'll be blunt and state outright that documenting won't solve anything significant. If Liferay is to move forward it should shed itself of servicebuilder and hire people well versed in api design. The current api's make martin fowler weep.

[Jim Hinkey, geändert vor 12 Jahren.]

As James Falkner mentioned Liferay does in fact have new Javadocs located at http://docs.liferay.com/portal/6.1/javadocs/. Click on the the link at See description to read about the classes documented. Services for some of the most important portal and portlet services have been documented. Granted, there is plenty more to document - But at least this is a start.

The currently documented classes are a result of an the Liferay Javadoc initiative that I've spear-headed with other Liferay engineers and the engineering leads to implement a Javadoc process that will produce high quality documentation on existing classes. Next, we'll be continuing that process and iron out a process to handle submission of code along with its Javadoc in an efficient manner, so as to minimize any slow-down code commits. The Javadoc comments will go through review and editing before committing to the repository to assure high quality Javadocs.

As David N. hinted, it may not be feasible for us here at Liferay to handle community Javadoc pull requests until 6.1 GA. At that time, we'll have the process ironed out and have resources to review and edit your Javadocs.

I thank you all for your patience and look forward to documenting the code with you.

Jim

[jelmer kuperus, geändert vor 12 Jahren.]

I think more review is in order

http://docs.liferay.com/portal/6.1/javadocs/com/liferay/portal/service/GroupLocalService.html#addGroup%28long,%20java.lang.String,%20long,%20long,%20java.lang.String,%20java.lang.String,%20int,%20java.lang.String,%20boolean,%20boolean,%20com.liferay.portal.service.ServiceContext%29

className - the entity's class name
classPK - the primary key of the entity's instance

errr say what?

I am appreciative of what you are trying to do but with the api's as they are this is an uphill battle.

[Jim Hinkey, geändert vor 12 Jahren.]

Hi Jelmer,

For these two parameters, I think adding to the method description something like the following might be helpful. Let me know what you think. Thanks!

[indent]Adds a group.

This method is typically called by an entity service's "add" method (e.g. organizationService.addOrganization(...) ). The className is the complete name of the entity class (e.g. "com.liferay.portal.model.Organization") which can be retrieved by calling getName() on the entity class (e.g. Organization.class.getName()). The entity service method is also responsible for generating a primary key of the entity instance and passing that key in as the value for classPK.

Example,

public Organization addOrganization(...) {
...

long organizationId = counterLocalService.increment();

Group group = groupLocalService.addGroup(
userId, Organization.class.getName(), organizationId, name, null,
GroupConstants.TYPE_SITE_PRIVATE, null, site, true, null);
...
}[/indent]

[jelmer kuperus, geändert vor 12 Jahren.]

Ah but that is only part of the story Because behold! depending on what class you select this method does different things

See if you pass in Organization.class.getName() as the className then the name you specified in the arguments is ignored and instead the classPK is used as the name also the organisation's name is used in the friendly url.

Not what you'd expect from looking at the api right? So this needs to be documented.

But really this only the tip of the iceberg and documenting this method properly will likely take at least 50 lines.

Maybe after you've finished documenting all of this you'll finally be ready to slap brian chan around with a hardcover copy of "implementation patterns", "refactoring" or "clean code". Because dear lord somebody should. There's a lot more truth to the title of the original post than most people dare to admit

[James Falkner, geändert vor 12 Jahren.]

jelmer kuperus:

I'll be blunt and state outright that documenting won't solve anything significant. If Liferay is to move forward it should shed itself of servicebuilder and hire people well versed in api design. The current api's make martin fowler weep.

Liferay is hiring!

This discussion reminds me of this story of the Hammer Factory.

I personally feel that Liferay has a good balance between overbearing API patterns, performance, simplicity, and flexibility (and many other -ilities). It's not even close to perfect, but it gets the job done, and does it with good performance, and with low cost. For each story of "well, our execs were talked into buying Liferay, but when we started to dig into it, it's crap and confusing and I hate my life" there are 10 other success stories that you don't hear about (people tend to complain when things go wrong, and remain silent when it goes right). So what to make of that? Liferay is like many other large, enterprise-oriented, open source and proprietary software systems out there - it has bugs, bad documentation in places, and confusing quirks. But its benefits outweigh its drawbacks (in my opinion). Also, we aren't blind to the issues you are all bringing up here, we don't live in a fantasy land of "everything is A-OK", and we take seriously this kind of feedback. But as a small company we can't move as fast as some would hope, but we're moving in the right direction (again, IMO).

[David H Nebinger, geändert vor 12 Jahren.]

The issue is really yours...

Liferay is an open source project. Feel free to add comments and submit them for inclusion, and they will be welcomed by the community.

The forum is very active. Post a meaningful message w/ a targeted subject line and most of the time you'll get a response.

Assets and categories are apples and oranges; categories can be applied to assets, but assets are not stored as categories.

Liferay (the company) has focused on releasing code and fixing bugs. As a Liferay user, I can appreciate their putting most of their energy and resources in that direction.

Personally I'd advocate for a community-based documentation effort to begin after 6.1 is finalized. The community has a bunch of experts, and by pooling all of their expertise we should be able to cover 80% of the code base and in a relatively short span of time.

Being a hater won't fix anything...

[Francois Fournel, geändert vor 12 Jahren.]

You know, liferay exists because :

- An JEE application not concurrenced in accordance with its cost (free)
....so easy to sell for commercials, and often, customers don't know what they buy, they are confident in their resellers (lol)
Technical team start its first project and it is a real challenge (not formation most of the time of course).
Hoping the customer is patient until the debugging works.....(after XXXX euros in the developpement, he should be patient unfortunately).