Newsletter portlet available for testing

Hi all,

As from today you can test newsletter portlet on our sandbox here http://liferay.eo.pl/web/guest/newsletter-portlet . Feel free to add, change, delete. If you find it usefull or you have some ideas how can we improve existing functionalities leave us a comment. Our sandbox is deployed on Liferay 6.0.3 but we can prepare that plugin for newer versions of Liferay. Pricing and licencing is coming soon 🙂

Advertisement

Well brother it doesn’t look good

Taken from Liferay JIRA. Question is those new tickets are related to trunk (which is unstable so they should be closed or tagged “will check that in 6.1 RC) or to stable version (6.0.6) of Liferay.

Liferay hate, love, learn

Today I saw a intereting page. It’s all about why Liferay sucks. I know that LR is no shiny diamond (I hate Liferay blogs portlets) and I know it has many very interesting features (I love Liferay web content structures) but lets see what other people say:

Built on top of obsolete and over-engineered fundamentals (Java Portlet API) that are pain to work with. Community edition lacks proper Javadoc. No real support for easy portlet development, portlets are NOT simple portal extensions as proclaimed by Liferay. Liferay code looks like a bunch of util method calls, some methods have 100+ lines of code. In the end, people end up hacking their way through Liferay / Portlet API to satisfy various business requirements, instead of building something that would suit their needs. Liferay is an illusion of something that can do everything (“Hey, it has CMS, it has forums, it has galleries!”) and this is something sales people like to listen to – User-440ujs

I don’t agree on Javadocs – you can see that they are updated (see here). As for all other things I agree in 50%. Source code is messy and scriptles are overused but beatifull code wont help you sell portal to your customer.

Next one.

The CMS is a joke. Making a Liferay site look like anything other than Liferay is an act of self-torment. Whoever is in charge of Liferay UX needs to be replaced. Avoid this turd like the plague! – User-107fzu

Yep, styling is hard but thats beacuse pages consits of many portlets. It’s like saying that space shuttle is more complicated than a car – yes it is. But as for Liferay UX – I agree in 100%. Liferay UX (even in the newest LR 6.1) is horrible. Tons of Javascript, unconsistent configuration pages (I’m talking about web content structure). As I said beafore many thing in Liferay and in UX also are just proof-of-concept. Sometimes I’m wondering is there anyone responsible for LR UX as whole one product. In terms of UX Liferay is light years behind WordPress and miles behind Alfresco and Joomla.

Developing a new portlet is both, extremely painful (i mean, physically painful) and limited (Liferay is a lot of things, but open to new technologies is not one of them). Hot deploy is a very attractive feature, sadly it basically doesn’t work, you can have a well nice 70% of struggling with the tool, 20% testing, leftovers for coding. If you need something that hasn’t been developed for it before, well prepare to be another lost soul – User-987i9x-250c0e

I don’t agree on the first sentence. Developing portlets is harder if you don’t know how to do it. It’s not simple (and sometimes unsecure) PHP where you can write echo “Hello world”. Hot deploy – I’ve heard that someone is working on fixing that (I think it was Tomas Polesovsky).

Other comments were about lack of LDAP integration (we tested that last month and it worked fine ootb), no way to delete old instance (well in such complex system turning off  is a safer option than delete).

On the opposite we have many Love comments (most came from Jorge Ferrer) but one of them is worth pasteing here:

Liferay rocks! Not simple tool for dummies (hey guys – it’s Java not PHP), but you can extend everything! Try to learn commercial portals – Tomas Polesovsky

The part you should remember is “you can extend everything! Try to learn commercial portals”. If you will work on large projects you will see that difference between PHP and JAVA is not so big – you will ran to same problems in both.

Social little things

Let’s talk about social optioons in Liferay. As you know (or not) Liferay has a lot of social extensions out-of-the-box. Some of them are grouped into Social Networking package (you can get it here). and other are in Liferay core. So we have friendship options like: request friendship, accept / deny friendship, invite friends (IMHO this one is obsolete as I don’t see any real use case for than in any of portals we are developing), friends (nice but there is no configuration like show with / without avatras or show only avatars), wall (most functional portlet of them all), activities, friends activities and my favourite ones  – Meetups and Summary. I said that those are my favourite ones beacuse I see big potential in such option not that they have such functionalities. For example Meetups is duplicating functionality of calendar. Why can’t we have “I attend” option in calendar? With that option we will be able to mimic with Liferay sites such as Last.fm.  Don’t know why this one was made as separate portlet. Similar thing is beign done with Summary portlet. Why there is additional field in it that is not linked in any wahy with user profile? Why there is no configuration page where administrator could select what fields from user profile he want’s this portlet to show? Maybe it’s the case of “no functional specification in Liferay”? Maybe. But that’s for another talk. Let’s get back to our social options.

Portlets are one thing. Another one is contributing to your portal. Here situation is also good looking. We can prepare public pages for users and private pages. On his private and public pages user can add his content (with new layer for entering WC through Asset Publisher this is much easier to customize than ever before). One big problem is that Liferay has no Content Sharing option (disscussed here). Oh, there is Global scope but I haven’t’ found proper compilation of user permissions to allow User access to that scope. Also Global scope doesn’t give you any isolation of users and their content so User A is able to edit and change WC of User B. Hope that this will be solved in near future.

So we have functionalities, content and now we want users to enter this damn data into our portal. There is no other option as to give them a virtual carrot so they will follow it. One carrot is the Social Equity and ranking of most egaged users. Users will earn point for writting and commenting and that’s awesome. Second carrot is the ability to personalize their site. They can do that by manipulating portlets (another minus for LR is lack of good graining of perrmisions so we are not able to dissallow changeing Look & Feel of portlets). or by choosing their theme. One thing to remember – Liferay has no option to define theme for each user. Yep, I know that for many portals this is basic function but for reason unknown this is not made in LR. But if you want something like this take a look at Alimozzaman blog (here). He wrote a step by step instruction how to do it. I think he should fill JIRA ticket for that and contribute solution (as we did with data structure in LPS-743).

I won’t wrote much about OpenSocial – you can read Paul Hintz presentation or view his webinar at Liferay LIVE here.

So as you can see you can almost build entire social network application from scratch using Liferay. Just remember that with every functionality in Liferay comes one bug or lack of something (good spec and thinking in most cases).

But that’s for another talk.

Liferay Life – Developing Social Applications leveraging OpenSocial

Here is recording of last Liferay Life session. This time Paul Hinz reviewed the basics of Open Social and Liferay’s implementation.

Community voice

What is community for should be a easy question. But if you think a little longer, for example in context of Liferay the answer is not so easy to define. There are many thins you can used it for but there are only few options that will get you most benefit. As a proud member of  The Community I can say that in my opinion those options are:

1. Community can be used for getting requirements for next release of your product.

At Liferay: in my opinion last year was a one way road. There were requests from Community, there were Wiki proposals pages and Liferay used those for preparing roadmap but we didn’t get any feedback or questions. It was more dictatorship than democracy. I know that WordPress is like dictatorship too but there is a big difference because WP is more narrowed product and there is so big community that you wont be able to filter those good ideas (one WP Forum thread contains more posts than whole Liferay forum).  It changed since James Falkner took role of Community Leader. He started 100 Paper Cuts program which will help Liferay to define at least part of our needs. He’s also a person responsible for hearing us out. So now this is starting to look as two-way highway. +1pt for James here.

2. Community can be used as part of marketing.

At Liferay: well it was not. If you don’t speak with Community Community won’t speak about you. Maybe it will be but not the way you want. If you want people to talk about you you must give them a good cause. You can give them a super fast, good documented product (works well with WordPress), you can give them superb functionalities (like RIAK) and / or you can give them loads of information to process (I love how Magento is doing that with their daily updated blog).  In my opinion Liferay didn’t used all power of Community in this case. Product is good but information flow is terrible. There are of course Liferay LIVE sessions but  if their are announced a day before it’s not very useful for you (-1 pt for Paul for not telling soon enough about today Liferay Influencer Briefing).  I hope this will change for better with Community Leadership program and revamp of Community landing page

3. Community can do part of your job

You can achieve more if you stimulate Community to do part of your job in role of developers, testers or analytics. It’s a nice example of barter when company gives basic product and support (in meaning of patches) and Community gives code, tests or planning job. Actually this is the part where Liferay is doing a great job.  There are many partner companies that contribute good quality code. There is a clear information about how you can contribute. Two things missing are Liferay employee that will commit all those Community Contributed solutions to trunk and Liferay Marketplace (Paul we want to sell portlets!).

So to summarize you can get many things from Community but first you must put your own work into building a proper relations with it. As you can see on example of Liferay you can do it in a wrong way but changing that always pays up and it’s never to late for doing that. Working with Community is a never ending process like SEO positioning so never leave you Community alone without proper attention or you will get such negative and frustrated opinion like this one. Talk to us, work with us, give us tools that will help us make more money and we will share that revenue with you in form of good feedback, word of mouth, additional code for you and licence (if you sell those 😉 ).

 

And one message to the Community: be active and give Liferay staff a chance to correct their previous misdeeds 🙂

And one more time about documentation

I know that Liferay documentation is already on “Community Complaints” lists (you can check it here) but I couldn’t resist.

from geekandpoke.typepad.com

Why I can’t use portal-impl in my portlet?

When I started my adventure with liferay and I was young I had a big headache with a view: „Why liferay developers didn’t share portal-impl.jar for external portlets. This is so stupid”. When we don’t have access to this module our development is very difficult. I can’t extend my Action class and I must manually attend all incoming requests beacause portal-impl.jar provides most classes used by the portal’s portlets. Why I can’t use this one?

Today, when I spent a long time with liferay my answer is: NO, you should not use a portal-impl.jar in your portlet. Remember: NEVER put portal-impl into anywhere other than where it came from. This will cause untold problems beacause portal-impl is the central core of the portal and it is a main piece of cake. So you can’t put portal-impl in lib directory in your portlets or in other strange places. Why? Liferay uses all kinds of classloader tricks to get access to various classes. So adding portal-impl to library folder in your portlet will realy mess this up. There will be duplicated instances of classes which are load from different class loaders. Additionaly portal-impl.jar contains internal classes of liferay core implementation, so if you use it in this version remember that next one can change all method’s or just remove some classes.

In portal-service.jar liferay provides a set of methods, which you can use in your own implementation. It sits in the global classpath (on tomcat this is <tomcat>/lib/ext/*.jar). All the services and utilities are available from these.

Wait a second… this feature looks nice, but how can I develop my controller (for example struts)? You should use apache struts bridge to handle lifecycle of struts portlet (refer sample-struts-portlet in community svn plugin repository). Also Liferay provides some kinds of bridges (e.g. mvc, php, python and more) and it is the simplest and the best way to create your own action class or your own controller. In my opinion there are some very important reasons to do with this way:

• your code is totally independent
• portlets are more flexible
• there is a big chance that your code will be working with newer version of liferay
• you write code with framework you like

But Liferay’s StrutsPortlet bridge should not be used for any new development. If you really must use Struts 1.x it’s better to use Apache portlet bridge. You can also use Liferay’s MVCPortlet. Or, you can use one of the other frameworks supported by Liferay: Spring MVC, Struts 2, and JSF.

DOC_22

Liferay Live – Liferay Community Roadmap

Here is todays Liferay Live session about Liferay Community Roadmap. Hope you will enjoy it 🙂

Liferay 6.0: Liferay’s lost potential – is it true?

Micheal wrote on eweek.com labs review about Liferay 6. He named it “Liferay’s lost potential”. Is it a proper title for that review – I leave this answer for you to decide. In my opinion true is somewhere in the middle.

There are many negative sides of using this platform because Liferay is buggy. I’m not telling that because I saw so many tickets in JIRA (I know that many of them are out-of-date) but because I use Liferay every day for different things. I know that there are no flawless applications (but WordPress is so close to that) but usability bugs in 2011? My favorite is that one where you must login to webdav using your userID instead of normal login. In that moment of Liferay administration training all my clients have this special look on their faces (it looks similar to WTF).  Also (because I’m from country where English is not primary language) all the localization bugs (but those will be solved in upcoming Liferay 6.1).

It’s nice to have 60+ portlet out-of-the-box but most of them look like simple “proof of concept” (Words and Hello Velocity portlets should be moved from Liferay bundle to Community Plugins repository!!!) , others are old and now almost useless (Translator portlet say hello to Google Translate) and others will never be used on any big portal (yeah, I’m talking about you Password Generator portlet and Loan Calculator portlet).

User documentation is still poor. My favorite part is the explanation of Review date field in Web Content edition page – see for yourself and look for “review date” in official Administrator Guide. Developer documentation is just a little bit better thanks to Liferay developers who started updating JavaDoc. Functionality documentation? I saw many tickets in JIRA but never any doc with good specification how should that part of Liferay work (maybe that is why there are so many usability flaws).

And themes? Yep, WordPress has them. I never show my clients Liferay themes available in Community Repository. Never. NEVER. Why? Take one (at random) and try building nice looking site without any CSS coding. Impossible. But there is a little change coming up in that matter.

So why do we like Liferay? We like it because it’s the only option if you want to build news portal without writing all the code from scratch. If you stabilize your own branch of Liferay CE or buy Liferay EE it will serve you well for many projects. You will have working API, some standardized integration code and very powerful feature of “web content structures and templates”.  You will also be able to configure you portal using one portlet – Asset Publisher – the only portlet that can do everything you will need. And don’t forget building verticals (based on community or instance feature of Liferay) in couple of clicks. You won’t see that in other CMS systems.

And speed? Well, WordPress is faster than Liferay but remember that TIE fighter is always faster than Imperial Star Destroyer. You don’t need that second one to set up one blog but you won’t be able to build heavy-traffic horizontal portal with the first one.