Liferay 7 Milestone 3 - Happy Year-End Hacking

Technical Blogs 2014年12月23日 按 Jorge Ferrer Staff

It’s the end of the year season and most programmers take a few days of to spend time with family and/or friends and of course check out some new technologies. While we know there are many exciting new techs to choose from, we wanted you to have at least one more option to choose from by making available a new and shiny milestone of Liferay 7. This is a great opportunity to see the latest developments that are getting so many people excited after our symposiums and DevCon.

 

This milestone includes 160+ stories finished since M2 was released, but the one that probably shines the brighter is the out of the box Geolocation support. As Juan Fernández mentioned in his blog, this milestone already contains the capability to geolocate web content, documents & media and dynamic data lists. The location can be setup to be entered manually by the user (entering an address) or automatically using the HTML5 geolocation feature.

 

Introducing the location in a web content

This becomes a really cool feature as soon as you start displaying a list of assets in a map, something that you can also do out of the box by picking the mapping template of Asset Publisher:

Displaying geolocated assets in a Map with Asset Publisher

And in case you were wondering, you are not tied to Google Maps. You can also use OpenStreetMaps or add any other maps provider. If you haven’t done so yet, go ahead and read Juan Fernandez’s blog about the new geolocation support. This capability will be added to other content types later including your custom ones, through Custom Fields, so take a look at it now and provide your feedback, since you will get a lot of benefit from it :)

 

The second highlight of the release is how the process to modularize more and more parts of the core using our OSGi-based infrastructure is gaining a lot of speed. As proof of that here is an screenshot of the directories that hold the extracted out modules so far (the collapsed dirs just contain one module inside with the same name and -web as a suffix):

 

Finally here are some other smaller improvements that I considered worth of mentioning:

  • Web Content types have been converted to a categories vocabulary (with an automatic upgrade process for those previously using Web Content types).

  • Added back the ability to download Structured Web Content as an XML from the Web Content administration UI.

  • Improvements in the default configuration: Message Boards notifications will include the name of the poster, blog lists will use abstracts instead of full content.

  • Added support for “Likes” for any asset type in addition to the two existing rating systems: stars and thumbs up/down

  • Alloy Editor which debuted in Milestone 2 has also received improvements, specially based on the feedback in the blog entry and during Liferay DevCon 2014. In particular two new buttons were added to the editor: for writing code and for quotes. Additionally some issues were fixed, such as: AE-75. Work has also started to implement larger improvements such as a code editor.

  • Many improvements to the APIs of DynamicDataMapping (DDM) are also included in this release, specially increasing the features exposed through remote APIs.

 

That’s it, if you are eager to check it out, just go to the downloads page for Milestone 3 at sourceforge. I hope you enjoy it and please send us all of your feedback :)

 

Happy Season to everybody!

Liferay 7 Milestone 2 - The adventure continues

Company Blogs 2014年10月29日 按 Jorge Ferrer Staff

It's been around 2 months since Milestone 1 and we are now ready for the second public deliverable of the ongoing Liferay Development: Liferay 7 Milestone 2. As usual it can be downloaded in Sourceforge’s downloads pageIf you prefer to get them from a Maven repo you can get it from Liferay’s maven repo. If you prefer to get it from GitHub you can use the 7.0.0-m2 tag.

If you didn't download Milestone 1, no regrets, just read again its highlights and download with Milestone 2. Compared to the previous milestone, this one includes mainly refinement and bug fixing of the new features, as well as quite a lot of work doing refactorings and starting new cool functionalities that will surface in the milestones to come.

One significant new improvement that you can already see in this Milestone is Alloy Editor. Alloy Editor is a new project lead by Iliyan Peychev which aims at greatly improving the user experience when creating WYSIWYG content. It started drawing inspiration from Medium.com and has outgrown it quite a bit. It uses CKEditor under the hood but provides a new UI on top of it. We have started by applying it to blogs (since it's a simple case). Here are some screenshots of how editing a blog entry feels like in Liferay 7 Milestone 2.

1) This is how the editor looks when it's first open:

2) This is how it looks once I've entered a title, subtitle and some content. Look at the plus within a circle. That's what allows you to insert stuff, such as images (which you can also just drag and drop inside the text):

3) If you want to add format to some text, just select it and a nice simplified toolbar will offer the format options.

4) All non-content related fields are organized in a secondary tab called "Settings":

We are very interested in getting feedback on the authoship experience in blogs, since our goal is to later apply Alloy Editor to other applications.

For a complete list of all improvements done in this milestone visit the board: Liferay 7.0 M2 New features grouped by Area.

Send us your feedback about Alloy Editor or any other feature in any Liferay 7 milestone through the Beta Testing forum category

Liferay 7 Milestone 1 - Only for the really adventurous

Company Blogs 2014年8月29日 按 Jorge Ferrer Staff

The word is out in Twitter, we have released the first development milestone release of Liferay 7. This is a call for really adventurous developers to try it out and give us your feedback. Here are the answers to the questions you may have about the release.

 

So… is Liferay 7 close to being released?

Nope. Our current thinking is that Liferay 7 will be released in the second half of 2015. But we will be releasing several milestone releases before that.

 

What’s the goal of milestone releases?

We want to give adventurous developers an opportunity to take a sneak peak of the new features and frameworks as they are being developed. This will give *you* an opportunity (directly or by finding a friendly adventurous developer) to provide early feedback and help steer the release.

 

A second goal, which will be especially important for the first milestones is to fine tune our internal release process now that the product and team has grown to quite a large size.

 

What’s the quality of Milestone 1 like?

Don’t expect it to be stable other than for testing out some of the new features. Of course never run it in production.

 

The milestones are always built from our master branch and while we work towards making it stable, it’s definitely not for running in production (and at times even for testing). We will make efforts to make it stable to allow for testing but since there is no testing phase there might be last minute changes that break things. If you find them, congrats! You are a real adventurous developer exploring unexplored territory ;)

 

Ok, cool, but what’s new in this release?

Here are some highlights that we would like you to look at:

  • WCM:

  • Collaboration & Social:

    • Ability to @mention users from any portlet that uses a WYSIWYG editor

    • Applied portal notifications to the subscriptions of Blogs, Wiki, Message Boards, …

    • Ability to Geolocate Web Content and documents. Also a new template for Asset Publisher to show them in a map.

  • UI Infrastructure

    • Update to Bootstrap 3. Frontend devs rejoice!!

    • SPA Enabler: You really need to try this out. Thanks to this new cool technology (based on our own SennaJS and AlloyUI Surface) all portlets automatically become Single Page Applications and users can navigate through them without reloading the whole page. Expect huge gains in both speed and data transmitted (which is great for mobile access)

  • Platform Infrastructure

    • Replacement of Lucene with ElasticSearch as the default search engine

    • Support for testing plugins and OSGi modules using Arquillian

    • Exposing many of the extension points in portal.properties and all extensions of liferay-portlet.xml as OSGi components.

    • Exposing many new extension points like Portlet Filters

    • Ability to develop complete portlet as OSGi modules

    • Ability to create standard OSGi modules that invoke Liferay’s core services API easily (it’s no longer needed to create a web app to do this, simplifying the task significantly and reaching a wider Java dev audience).

    • Ability to use Service Builder in OSGi modules

    • Ability to expose any Java Service in an OSGi module as a JSON Web Service (even without using Service Builder!)

    • The prototype release of the new Eclipse Equinox Http Service implementing OSGi RCF 189 - Http Whiteboard

    • Support for JSPs in OSGi modules

    • Several smaller portlets extracted from the core

    • The work to extract Liferay’s large core apps as OSGi modules has started although none of them have not landed in master yet much of the infrastructure is already in place (Expect more news in M2)

 

There are also many more small improvements and technical changes, since we organize our work in the form of Stories we’ve prepared a page with a list of all stories organized by area in the following URL: https://issues.liferay.com/secure/StructureBoard.jspa?s=235 (Thanks Esther for setting this up!)

 

Where can I download it?

At the usual page in Sourceforge’s downloads page. If you prefer to get them from a Maven repo you can get it from Liferay’s maven repo. If you prefer to get it from GitHub you can use the 7.0.0-m1 tag.

 

That’s it, we look forward to hearing your FEEDBACK!

 

PS1: Big thanks to James Falkner, Julio Camarero, Nate Cavanaugh for proof reading and help make the entry more complete

PS2: The source for the cover image is https://www.flickr.com/photos/defenceimages/8329373315/in/photostream/

 
Update (Sept 1st), added link to the GitHub tag to the "Where can I download it" section and credits for Esther on the structure will all new tickets in the milestone.

New in 6.2: Bootstrap.... even in Web Content

General Blogs 2013年11月18日 按 Jorge Ferrer Staff

Continuing with my series of "New in 6.2" entries, today I want to put the focus on a more technical aspect of the new version: the fact that it provides support for Twitter Bootstrap out of the box. Some of the benefits of this are:

The first two points are more technical and for an audience of developers, so they'll be covered in more detail elsewhere, so I want to focus on the last point. The ability to use bootstrap for webcontent is actually a side effect of its use everywhere else, but it's definitely a very useful side effect :)

Since Bootstrap already has good documentation that you can access following the links above I won't try to do an in-depth explanation. Instead I've chosen 3 examples of content where I think applying bootstrap can be useful. 

#1 Nicely formatted tables

When you create a table in a new web content it looks more or less like this:

Which looks ok, but not so good. In order to apply some of the bootstrap you will need to have a little bit of HTML knowledge. While editing the web content click on the "Source" button. Locate the <table> tag which will look something like this:

<table border="1" cellpadding="1" cellspacing="1" style="width: 500px;">

And change it so that it looks like this:

<table class="table table-striped table-bordered">

Each of these values of the class attributes provides one feature:

  • table sets the base styles
  • table-striped colors alternative rows differently
  • table-bordered draws the borders around the table. 

It's worth mentioning that the WYSIWYG editor is not aware of bootstrap, so just getting out of the "Source" mode won't be enough to preview your changes. What you can do is click the "Basic Preview" button at the top of the web content form. 

Just by making this small change your table will look like this:

If you are a bit averse to HTML (or your content is so large that editing the HTML is a pain) you can also achieve the same effect by double clicking in the table to open the properties dialog. Click on the advanced tab and in the "Stylesheet Classes" field enter "table table-striped table-bordered " as shown in the next image:

Clear any styling (specially widths) in other fields and click ok. Preview the content or publish it to check the same result was obtained.

If you are interested in more options that bootstrap tables provides you can check it's official documentation.

#2 Image effects

Bootstrap provides 3 nice effects for images: rounding the borders, making them a circle and adding a polaroid-like fame around it. In order to benefit from this you don't even need to edit the HTML. Go ahead and insert an image with the image dialog as you normally would. For example, let's pick an image of Brian from our about us page. Click the image button in the WYSIWYG editor toolbar. After uploading the image or introducing the URL click the advanced table and enter one of the following values in the "Stylesheet Classes" field:

  • img-rounded for rounded corners
  • img-circle to get an image with the shape of a circle
  • img-polaroid to get a nice frame around the image

If there is any value in the Style field, clear it to avoid conflicts with the bootstrap styles. Here are the results I got for each of the styles:

Cool, right?

#3 Responsive layouts and menus

This is the last and most advanced example. Here you will definitely need to have some HTML knowledge. 

The first thing you need to know is that Bootstrap uses a 12 column grid to lay things out in a page. So when using bootstrap you should think of your page as something like this:

You then specify for each item how many columns it spans. Something like this:

  1. <div class="row-fluid">
  2. <div class="span4">...</div>
  3. <div class="span8">...</div>
  4. </div>

You can then add anything in each of those DIV's.  What is nice, is that on smaller screens, like those of phones, the columns will become fluid and display below each other. Instead of doing a simple example like I've done in the previous two cases, what I'm going to try this time is take one of the more advanced examples that are provided in the twitter page. Here are the steps I have followed:

  1. From a Liferay page, click add > content and then create new (Basic) Web Content. 
  2. Give it a title and click the "Source" button in the editor.
  3. Pick one example (I picked the one titled "Fluid Layout"). View the HTML and copy the source code inside the <body> tag (without the <script> tags at the bottom)
  4. Paste the HTML inside the editor.
  5. Publish. 

This is the result:

Three things to note from this screenshot are:

  • Even the most complex bootstrap samples can work inside a Liferay web content. There are tons of possibilities. 
  • But you must use them with care. If you look at the top of the screenshot you will see that the sample I picked added a black bar positioned at the top of the page. This bar hides the Liferay dockbar, which is definitely not desired. I did this to prove how the fact that you can do something, it doesn't mean it's desired :)  In this specific case you can avoid that effect by looking at the HTML code you copied and remove the class navbar-fixed-top. In general try to avoid using the classes that contain the word "fixed" inside a web content unless you really mean it.
  • You may need to do some CSS tweaking so that it looks pixel perfect in your scenario. In this case the menu would look better without the padding, which in the original Bootstrap example remove with a CSS definition in the page.

If you liked this and want to learn more, my recommendation is to read the nice documentation for Bootstrap 2.3.2.

 

New in 6.2: The new "Side Page Panels"

General Blogs 2013年10月31日 按 Jorge Ferrer Staff

In my last blog entry I explained the thought process we followed to improve the Dockbar. What some of you may have noticed is that I skipped talking about three elements that used to be in the left side of the dockbar in 6.1:

So, what happened to them? These options where part of the overall work that we have done to provide a proper Information Architecture for all administration functions a Liferay administrator may need to use. In particular, several of the options that were accessible through the "Manage" menu are now part of the new Site Administration UI.

What has been left are the operations that are related to what the admin is seeing right now, that is, the current page. That includes adding stuff to the current page, adding a new page, previewing the page in different devices (new in 6.2) or controlling whether to show or not display controls.

One other goal we had was to find a way to show these management controls in a way that didn't require a full bar at the top, since that created a significantly different visual effect for admins than for regular users. While that may be fine in some sites, it's very undesired in others. After evaluating several options we decided to use a technique to add the management options for the  "Current Context" to the left side as shown in the image below:

Now, you may be thinking "Wow, that's cool and beautiful, but it may not fit well in my theme". No worries, we thought of you too. The side icons are fully themable. In fact, this representatoin is only part of Liferay's classic theme. If you use "_styled" as the base for your theme you will default to the traditional top bar from side to side. And when you are ready you can switch to the new side icons with a few lines of CSS/HTML as the Classic theme does. Kudos to Nate for making it so easy to choose what better fits your needs.

Now let's take a look at what's inside each of those icons. They all work the same way, upon clicking them a side bar will appear from the left side. This is a new UI pattern that has been introduced in 6.2 that provides a lot of benefits, including the ability to perform operations while in the context of a page, without loosing it from your view at any point in time. Let's look at each of these side panels:

The goal of the "Add Page" panel is to allow creating pages quickly (Just enter the title and click <Enter>) while still providing access to the most commonly used options. Some aspects to highlight here are:

  • We decided to merge Page Templates and Page Type into one set of options, since the difference is mostly technical and the end user doesn't care.
  • Once you select a page type, it's also possible to select some related options. For example, if you select an Empty Page (the default) you can directly choose the layout of columns. If you select a page template you can choose whether to enable propagation of changes or not.
  • As you type, you can see the title of the page appear in the navigation as you type.
  • We used the new "localizer" component which allows specifying the name of the page in all enabled languages of the site.

 

 

The "Add Application" panel is similar to the existing one, although with a much more modern look & feel. We have mainly focused on fixing some usability pitfalls such as the problem caused by having the "highlighted" portlets separate from the complete list.

 

 

 

The "Add Content" panel is a very cool new feature. It allows users to search for existing content (or create a new one on the fly) and just drag & drop it to the page. Liferay will take care of choosing the most appropriate portlet under the hood and configure it to display the chosen content. This is a good example of the efforts we are making to speak the language of the user, helping him get his task acomplished and taking care of the technical details transparently.

The Preview pane is another of the new features of 6.2 and allows previewing the site with the most popular device sizes and with any other custom size. While there are plenty of simulators out there, just having the ability to preview any Liferay page one click away is a game changer. You'll see :)

And finally the "Edit Page" pane. One of my favorites, because it packs a lot of page configuration options into an small area. And having the page always visible as you edit its properties makes a huge difference.

That's it for now, I hope you liked these improvements. Looking forward to hearing your thoughts and opinion.

 

New in 6.2: The new 'Dockbar'

General Blogs 2013年10月29日 按 Jorge Ferrer Staff

Hey guys,

The 6.2 release is almost out and I want to use this opportunity to talk about some of the improvements we have done to the dockbar. For those newer to Liferay, the Dockbar is the nick name for the bar that appears at the top of the screen and provides personal and administration options to users. In 6.1, this bar looked like this:

Although, of course it is possible to customize it. For example, here at liferay.com it currently looks like this within my blog:

In some other portals I've seen people just remove the dockbar except for for administrators. While this is something easy to do from the theme, I always advice people to use it as a last resort. The reason is that Liferay has a very flexible permission system and when a user has some management permissions for the current site or page the dockbar is where those editing options will appear. Liferay has some advanced logic to determine what options to show to each user, but you probably won't want to replicate that logic in your theme to determine when to show the dockbar and when not to.

For 6.2 we wanted to improve the Look & Feel of the dockbar as well as its usability. But we also wanted to make it less intrusive, easier to customize. Among other reasons we wanted to reduce the situations in which there was a need to remove the dockbar altogether.

After doing the proper analysis and quite a few discussions between Nate, Juan Hidalgo, Ed Chung and myself made the most visible decission: In 6.1 the dockbar is a full horizontal bar, that goes from left to right. While this is not so bad for intranet-like environments, it is often not desired in public sites. Furthermore, for regular users who only saw his name in the par it was a significant waste of space. We decided that the bar would float from the right top edge (with some padding) and grow towards the left as needed. Thanks to this, we save tons of screen real state, specially for regular users who just see this:

Let's see this in the context of the whole page. As you can see below, by placing the dockbar to the right the site logo and name become more relevant, which is what is desired in most situations:

 

If the user belongs to at least one site and has some administration priviledges then two additional menus appear:

  1. My Sites: Shows the sites that the user belongs to, with direct links to the public and private pages (if they exist).

     
  2. Admin: Contains a link to the Control Panel if the user has access to it and direct links to the site administration sections (Pages, Content, Users and Configuration) that the user has access to. The direct links to each section was one of the last additions based on early user feedback and it has two benefits: It requires fewer clicks to perform any administration operation and it shows the type of things the user will be able to manage for this site even before clicking them.

 

That's it for now. I'd love to hear your feedback on these changes.

Also, feel free to let me know what other features or improvements of the dockbar or Liferay 6.2 in general that you would like us to cover in upcoming blog entries.

Liferay Architecture: What would you like to know?

General Blogs 2013年10月3日 按 Jorge Ferrer Staff

Liferay's architecture is pretty lean, but there are lots of things to learn about it. What would you be interested in learning?

I'm doing a talk next week in Liferay's DevCon in Berlin about Advanced Liferay Architecture. I will also deliver it at the Spain Symposium and the North America Symposium. This presentation will be a follow up of last year's presentation about Liferay's Architecture and the blog series that I have been doing here. Here are the topics that I have in the presentation so far:

  • Caching
  • Request Handling
  • Plugin Architecture
  • Message Bus
  • Asynchronous invocation

Which of these topics is more interesting for you? What other topics would you like me to speak about?

Also, if you can't attend any of the events (and if I were you I would miss them :) send me your feedback as well since I will still write blog entries about these topics.

Please add comments or answer in twitter with your proposals.

Understanding Liferay 6.2 Release Candidates

General Blogs 2013年9月25日 按 Jorge Ferrer Staff

The 6.2 release is very very close. Those who have talked with the core team about it know that we have been working hard since the 6.1 release to increase the predictability of the releases and at the same time keep increasing the product quality. You have probably already seen that we have released 6 milestones during this time and 2 betas recently. My goal with this blog entry is to explain the last phase of the release cyle: The Release Candidates.

Quoting from WikiPedia:  "A release candidate (RC) is a beta version with potential to be a final product, which is ready to release unless significant bugs emerge". We released the first release candidate (RC1) last Friday and our QA department has been evaluating it in coordination with other stakeholders. The conclusion is that it is still not ready to be called final. So we will build a new releae candidate (RC2) this Friday and repeat the process. We will keep doing this, building one RC every Friday until one is approved as final.

How many Release Candidates will we have? The answer is "it depends" :) What I can say is that everybody involved in the release is working very hard to make the next RC the final one. So RC2 could be the final or we might need a few more (specially since it's the first time we follow this process and there is fine tunning to be done along the way). 

Note that you can help too. Download RC1 now and/or RC2 when it comes out and help test it, upgrade your portlets, etc. Check out the beta 6.2 documentation as well as you do so. There is a new Wiki Page called Known Upgrade Issues to 6.2 Release Candidates where you can add the issues you find or suggestions you have for other people or read what others have written. We really appreciate your help! 

See you soon at the Symposiums and events world wide to celebrate the release!

Update (Oct 30th, 2013): RC6 has resulted to be a very good release and we wanted to make it GA, however there were a very small number of issues we found that we wanted to fix. So we've decided to change slightly the original plan and are just going to fix those issues and release GA directly (skipping a public RC7, although we are really doing an RC every day since Monday). We will most probably start building GA this Friday. Yeah!! :)

New in 6.2: Streamlined administration through Site Administration and the new Control Panel (2/2)

General Blogs 2013年8月11日 按 Jorge Ferrer Staff

In my previous post I convered the reasons why we decided to streamline the administration UIs of Liferay and in the process review the usability and design of the Control Panel. In that post I already covered two of the key decisions we made as part of this redesign: (1) Extract the "My Account" administration out of the Control Panel and (2) Extract "Site Administration" outside of the Control Panel.

Let's follow up from there with other key decisions.

3. Reorganize the portlets in the Control Panel

Once we've extracted out the portlets within "My Account" and "Site Administration", what do we have left? The remaining tools are those that in 6.1 and previous used to be classified in two sections: "Portal" and "Server". The reasoning for having those two sections was that the portlets that belong to the first manage stuff that belongs to the current portal instance, while the portlets under "server" manage elements that have an effect across all portal instances.

However, the feedback we've gotten over the past couple of years is that this differentiation wasn't very clear, or even highly informative for administrators. Also, some portlets were quite related to each other but were also mixed with other unrelated portlets. For this reason several months ago, Juan Hidalgo our UX Designer based on Madrid, proposed to start brainstorming for alternative classifications. Juan, wrote a card for each tool and pasted them in a big whiteboard (I wish I had a pic but I don't. Juan if you do go ahead and paste it as a comment). After several weeks trying alternatives we were ready to make a proposal, which got interesting feedback from a bunch of people, specially Nate Cavanaugh and Ed Chung. The result was the creation of 4 categories within the Control Panel: Users, Sites, Apps and Configuration. One key thing to highlight is that each of these categories has one portlet that is specially relevant and we expect it to be used much more than the rest in the category (which provide complementary features). Leveraging this, we decided to get rid of the vertical menu and go with a horizontal menu which makes the navigation easier to use. Here is a description of each of the sections along with an screenshot:

  • Users: Contains all portlets related to administering users and user related stuff, such as permissions.
  • Sites: Contains all portlets related to managing sites as well as tools used to build the sites themselves such as site templates and page templates. It is worth noting that within the sites portlet it is possible to fully manage any site (as long as the user has permission) just by clicking on its name. In other words, the site administration UIs of all sites are easily accessible from the Control Panel.
  • Apps: we decided to go along with the overwhelming trend of calling Apps to all extensions to a product. This term had already been adopted by the marketplace so it was good to be consistent. For those used to other terminologies within Liferay, an App can be installed from the marketplace (in which case it can contain one or more plugins) or be deployed locally (in which case it will be composed of one plugin of any type, portlet, hook, web or ext).
  • Configuration: contains all portlets that provide ways to configure the platform. All the configuration performed from here will either affect elements that live outside of a site or will have effect over all sites.

We also decided to provide a frontpage which provides an overview of all portlets available in each of the sections. This provides a quick way to go to any of them in one click. It also provides access to a description of each portlet by hovering the question mark next to its link:

One final thing you can notice in this screenshot of the Control Panel Home is that under each section there is a question and a button that provides access to the most common action that the current user might want to perform. Note that the location of these "Quick Actions" is not final yet.

4. Reduce the number of pop-ups

In 6.1 we introduced quite a few pop-ups to access management UIs as a way to allow the administrator to keep the context. However, after the feedback received and our own UX evaluation we came to the conclusion that we were using pop-ups in situations were they weren't the optimal solution. For this reason, in 6.2 we've replaced many pop-ups with full page reloads, although making sure that the headers and navigation provided proper context as well as a quick way to go back to the previous screen. The general rule we are following is that pop-ups are good for short iterations, but not when the user is going to be working within the pop-up for some time or do quite a bit of clicking around.

The overall experience is definitely much better now and the UI feels much faster.

Note: There are still a few pop-ups that we haven't been able to replace for technical reasons. In particular, the "Manage > Templates/Structures" in Web Content and "Manage > Document Types" in Documents & Media come to mind. We'll replace those later on.

5. Keep backwards compatibility for developers

As you've seen, we've performed tons of changes to improve the usability. However we didn't want these changes to have a big impact on developers. So if you are a developer you will be happy to know that if you developed a portlet for the control panel for 6.1 it will work in 6.2 without any changes. 
This is possible, because under the hood both "Site Administration" and "My Account" are considered to be part of the Control Panel. So in order to create a portlet for any of them a developer just has to add a control-panel-category element within its definition in the liferay-portlet.xml configuration file. We've also made it so that the old category names are automatically converted to the new category names as follows:
  • my -> my
  • content -> site_administration.content
  • portal -> users
  • server ->apps
Here is a full list of the new available categories:
  • Control Panel:
    • users
    • sites
    • apps
    • configuration
  • Site Administration:
    • site_administration.pages
    • site_administration.content
    • site_administration.users
    • site_administration.configuration
  • My Account:
    • my

How can I test it out and provide my feedback?

If you've got this far you are probably interested in finding out how to test this out. It's easy, just download Liferay Portal 6.2 Beta 1 and install it locally. We'd love to hear your feedback either as comments to this blog post or as part of the beta program.

Remaining tasks and aspects under consideration

We are already in the beta cycle of 6.2 so what has been discussed in this blog is quite final. However, there are still some minor UX improvements that are still under consideration and might suffer slight changes. Here is a non-exhaustive list, feel free to give us your opinion:

  • Headers of both Site Administration and Control Panel: we are still not 100% sure of how they look so they may still change.
  • How to let portal administrators know which actions will affect all portal instances: With the new organization it's not clear in environments with multiple instances that some will affect all instances while most won't. We need to find a way to let the user know.
  • Descriptions for each Control Panel section and place the quick actions in a different position that flows better in smaller screen sizes.
  • Navigation witihn the "Sites" and "Users & Organizations" portlets.
 
That's it, I hope you enjoyed these two blog posts. Next I'm planning a post on the changes we've done to the dockbar, anyone interested?

New in 6.2: Streamlined administration through Site Administration and the new Control Panel (1/2)

General Blogs 2013年8月1日 按 Jorge Ferrer Staff

Hey guys,

The 6.2 release is getting closer and closer, so after quite a few months without writing a blog entry I'd like to get back starting a new series I'm calling "New in 6.2". In this blog series I plan to blog about new features in the upcoming release and will try to explain our motivations, the challenges we faced and the reasons for the decisions we made. All in the Open Sourse spirit of being as open and transparent as possible. I'm  also encouraging other developers on the team to do the same.

This first blog post will be about a set of improvements with which I've been personally very involved: the redesign of the Control Panel to make it more usable and versatile and to allow it to keep growing without increasing the complexity. This post will go through our thinking process and show the end result. Since it's a pretty large post I've divided it in two parts. Here goes the first one.

Why we started this effort

The Control Panel was introduced in Liferay 5.2 as a way to provide a central location to manage the whole portal, including all of its sites. Previously administrators had to build their own administration UI by manually adding portlets to pages. I think the goal was achieved with great success and almost all of the feedback has been very positive.

However as the Control Panel has kept growing with more and more portlets new challenges have arised. Additionally some companies were approaching us saying that in their particular scenarios the Control Panel was not the best fit. Here are some of these challenges:

  • Losing context: In some portals the fact that the user (for example a site administrator) looses the context of the site when going to the control panel was a big issue (or even not allowed by the company UX policy). A big factor in this context loss is that the Control Panel offered many more options than just administering that one site, another was the quite different look & feel.
  • Too complex: Let's admit it, the Control Panel was becoming quite complicated as it has gained more and more functionality. While this could be alleviated by giving users the right permissions, the fact is that people kept finding it too confusing.
  • Mix of portal-wide administration, site administraiton and even personal account administration: This is an explicit decision we made, so that there was one and only one administration UI for everything. But not everybody feels comfortable with this, specially because personal account administration is available for all users while portal-wide administration is for a very small number of portal admins, so having one single UI didn't allow optimizing for each separately. Site administration was somewhat in the middle of both extremes.
  • Old look and feel: The look and feel had some changes in 6.1 but it was still not so pretty and that fact made it even more intimidating for some users.
  • Empty first page: When going to the control panel the first page is empty and only shows a message. That's not the best from a user experience perspective. 
  • Non-intuitive navigation through administrable sites: the dropdown embedded within the left menu is quite handy for administrators that manage more than one site, but let's admit it, it's weird to have a dropdown within a menu. Specially since what its selection only affects some one of the menu sections.

For these reasons and a few others many Liferay installations were restricting access to the Control Panel (which in 6.1 can be done with a permission) to very high level administrators. In other cases I found people were relying back to the manual addition of administration portlets to regular pages, which I consider more like a workaround than a final solution.

Before digging into the solution let's see the before pic:

The prototype and early decisions

We had been thinking about how to address these challenges for a while but we couldn't find answers for all the questions. Finally this past May during an engineering retreat we decided to give a try and started a prototype. In this prototype we combined several ideas that had been proposed by different people (Nate, Juan Hidalgo, Ed, myself, ...) over the past few months and voilá... we really liked the result. So much that we decided to fully implement it even if it wasn't originally planned for 6.2.

Here are some of the key decisions we made:

1. Extract the "My Account" administration out of the Control Panel.

We call "My Account" to the set of tools that allow a user to manage his personal stuff. By default that includes "Account Settings" (also known as "My Account" in 6.1 and before) and "My Pages". If a workflow engine is deployed, two more tools become available: "My Submissions" and "My Workflow Tasks". And since Liferay is a platform it's possible to add more tools easily by developing a portlet. In the image above you can see the portlet "My Subscriptions" that we use at liferay.com.

Almost all portals provide a way for users to edit his account settings. This means that "My Account" should be available for all users, which contrasts to the Control Panel which is targetted at Portal Administrators. So in 6.2 we've decided to extract it out of there and make it easily accessible through the user menu in the upper right area:

By default it opens a pop-up giving access to Account Settings as well as any other personal portlet. It is possible to make it load as a regular portlet in the current page with a setting in portal. properties:

 

2. Extract "Site Administration" outside of the Control Panel

The second key decission we made is to extract all site administration tools outside of the Control Panel. In order to do that we have created a new UI, appropriately called Site Administration, that can be accessed from any site. Within this UI all administration tools are organized in 4 sections:

  • Pages: The site pages (public and private).
  • Content: Has an entry for each site application that has content. It also includes other content-related tools such as Categories, Tags and the new Recycle Bin.
  • Users: Tools related to managing users in the context of the site. By default there are two tools, Site Memberships and Site Teams.
  • Configuration: All tools related to configuring the site. The first and probably the most used of these tools is "Site Settings", other useful tools are the new Application Display Templates, Mobile Device Families (previously known as Mobile Device Rules) and more.

Each of these sections has a direct link from the Dockbar, from within a new menu called "Admin":

This is the result of clicking "Content":

Here are some important things to notice from this screenshot:

  1. This UI is actually pretty similar to the old Control Panel, with a left menu and a main area. Although it only has administration tools associated with the current site.
  2. The name of the site along is shown in the dockbar and to its left there is a link to go back to the site.
  3. The down arrow next to the name provides access to a menu with a list of other sites that the current user can administer. This will be specially useful when the current site displays shared content (a new feature in 6.2) from parent sites or other sites managed by the administrator, as well as global.
  4. The list of site administration tools in the left menu is searchable with instant search (aka search as you type)
  5. When going to a section the user is shown the first portlet within that section. In this case it's Web Content, which will be in many sites one of the most commonly accessed portlets.
  6. The left menu acts as an accordion, That means that only one section can be open at a time. This has been done to reduce the size of the menu, which could otherwise create circumstances such as display the current tool below the visible screen area.

 

I'm going to finish here the first part of the post. I would love to hear your feedback about anything I've shared and I'll be happen to answer any questions.

In the second part I'll go through other key decisions, such as the reorganization of the portlets left in the control panel, the efforts to reduce the number of pop-ups or how we have kept backwards compatibility for developers. I will also descrived other changes that are still under consideration and waiting for user feedback as well as the results from UX testing.

Update (Aug 14th): I've just published the second part of this blog post.

Liferay's Architecture: Caching (Part 1)

Company Blogs 2013年1月21日 按 Jorge Ferrer Staff

Here I am again with another in the series about Liferay's architecture. If you haven't read them yet, the four previous entries covered: Overview, Services Layer, Web Services and Service Builder.

This time I'm going to cover a very important concept: caching. In today's web, it's impossible for a web application to provide even good enough performance in the web unless it has a well designed caching system. So what I'm going to cover here is not only useful to understand Liferay's architecture better but might also be beneficial for anyone writting Java web applications, specially if they are large.

Liferay is known to provide very good performance (check the Performance Whitepaper in the whitepapers section of this website for details) and its caching system is a key factor in achieving that performance. This caching system spans through all three layers. The following diagram shows the main caching components in each layer:

Let's cover each of them one by one, starting with the lower layer.

At the persistance layer Liferay relies on Hibernate to do most of its database access. Hibernate has two cache layers called Level 1 (L1) and Level 2 (L2). Level 1 is used to cache objects retrieved from the database within the current datababase session. In the case of Liferay a session is tied to an invocation to a service layer. So when the frontend layer (or a web service) invokes a service a db session is opened and reused until the service method returns. All operations performed until that point will share the L1 cache so the same object won't be retrieved twice from the database.

Hibernate's cache Level 2 is able to span across database sessions and stores database objects (Entity Cache) and results of queries (Query Cache). For example if any logic retrieves from the database all users that belong to a certain organization, the result will be stored in the cache. Note that what is really stored is the list of "references" to the actual objects which are stored in the Entity Cache. This is done to ensure that there aren't several copies of the same object in the cache.

Besides using Hibernate, Liferay's code also performs some complex database queries directly (although reusing the database conneciton). For these queries Liferay has its own Entity and Query cache. In fact thanks to the work of Shuyang these two caches are extremely efficient and as a result, for Liferay 6.2, we have decided to disable Hibernate's level 2 cache by default leaving Liferay's Query cache as responsible for that task to improve performance.

One final important aspect is that all of these caches use an underlying cache provider to manage the objects in memory. By default Liferay uses ehcache to do that, but it is also possible to change the caching provider through portal.properties.  The configuration is done within hibernate-clustered.xml which defines  and configures several cache areas.

Finetunning these configuration files is a very important task for any high-profile site. But don't try to do it based on guesses. You should always do it while running a performance test suite that can help you find bottlenecks and verify changes in the configuration.

Since I want to try and keep these blog entries shorter and more frequent, I'm dividing it in two parts. In the next one I'll cover the caching mechanisms of the services and the frontend layer.

Liferay's Architecture: Service Builder

Company Blogs 2013年1月3日 按 Jorge Ferrer Staff

One of Liferay's "secret" ingredients, specially with regards to its architecture, is Service Builder. This is the tool that glues together all of Liferay's layers and that hides the complexities of using Spring or Hibernate under the hood.

Service Builder was originally built when Liferay used EJBs for everything (in fact it's name back then was EJBBuilder). EJBs were actually built around several very sound architectural patterns, but unfortunately the implementation was not as good. One significant pain for developers using EJBs was that it was necessary to write many XML files and Java classes to do even the simplest thing. So Brian Chan, Liferay's founder, who is known for being super efficient, decided to build a tool to do it for him. When Hibernate came around Brian was able to use Service Builder to switch from Entity EJB's to Hibernate literally over a weekend (I was blown away back then). Later on Service Builder also allowed switching from Service EJBs to Spring, gaining a lot of flexibility.

Service Builder has grown a lot since then. I used to be very skeptic with source code generation until I got to know Service Biulder better. It doesn't pretend to be a generic code generation tool, but rather to meet the needs of Liferay's developers (including plugin developers). It is also very opinionated, in the sense that it doesn't offer many options, just the ones we think fit better in Liferay's context. Because of that it might not be a tool for everybody but in exchange it provides a great degree of consistency to anything develped with it and is easier to learn. The general idea is simple, it just takes an XML file as an input (usually called service.xml) and generates the necessary persistance, service layer, web services, ... infrastructure around it. Check Liferay's Developer's Guide for info on how to use it.

One key breakthrough in the evolution of Service Builder actually happened with a contribution (can't remember the name of the contributor, does anyone know?). Previously, all of the code that was going to be generated was included as Strings within Java code and a community member took the time to move all of it to Freemarker templates. That has made the evolution and maintainence of Service Builder so much better that I don't have words to thank him :)

Right now, for every file that Service Builder will generate there is a Freemarker (.ftl) file associated with it. For example, do you want to find out how a *ServiceImpl.java file is generated, you just have to look at service_impl.ftl within com/liferay/portal/tools/servicebuilder/dependencies 

That's it for now, hope you liked the entry and see you soon for the next one.

Liferay's Architecture: Web services

Company Blogs 2012年12月26日 按 Jorge Ferrer Staff

It's taken a little longer than planned due to Liferay's annual company retreat and the engineering retreat we did along with it, but here I am with the third entry in the Liferay's Architecture blog series. I also plan to write a fourth one and schedule it for publication next week while I'm on vacation. 

My last entry explored how Liferay's code is organized around the concept of services which are used from the frontend (portlets, servlets, ...) but that can also be used by third party or custom plugins using the available Java API. The goal of this entry is to show how the remote services layer is also exposed through several web services protocol for remote consumption.

This layer is built automatically by that wonderful tool called Service Builder based on the remote service interface and annotations left in the implementation by its developers. One of the benefits of automatic generation is that it is easy to support many protocols with little extra effort. However I'm only going to mention the two most significant and used protocols:

  • JSON Web Services: This is a new way of accessing Liferay's web services that was added in 6.1 thanks to the lead of Igor Spasic. It provides a lightweight RPC-based protocol that uses JSON as the data exchange format. This protocol is specially useful when invoking the services from JavaScript (including from the browser) or other non-Java languages. It can also be useful for mobile apps. In fact Liferay Sync Mobile App (guide) for iOS and Android uses this protocol to communicate with Liferay. One very nice and not so widely known feature of JSON Web Services is that it comes with an API browser included. You can access it by going to the URL http://your-host-name/api/jsonws (don't forget to secure it for production). For more information check the JSON Web Services chapter in the Developer's Guide.
  • SOAP: The good old XML-based protocol that has declined in popularity lately but is here to stay. One of the main benefits of SOAP is the amount of tooling available as well as the out of the box integration offered by some software packages. If you need to use SOAP to communicate with Liferay (and it still happens often), it is supported for you. For those curious about the implementation we use Apache Axis 1.4 to handle the protocol aspects. We don't use Apache Axis 2 for a variety of reasons including the fact that it is distributed as many JARs, some of which are already provided by some app servers out of the box which makes support across all app servers quite harder.  For more information check the SOAP Web Services chapter in the Developer's Guide.

One last important aspect you should know is that all web services in Liferay will be invoked using Liferay's permission system. The client applications need to provide the credentials of the user they want to execute the methods as. The simplest option to do it is using HTTP Basic Authentication. That means that if you are accessing web service through an unsafe network (which will be most probably the case) you should use HTTPS to avoid sending the passwords on clear. An alternative coming in 6.2 (which is much nicer in many ways) is to use the OAuth protocol.

That's it for now. I'll use this opportunity to wish you all a Merry Christmas (or for those who don't celebrate Christmas, Happy Holidays! :)) 

Liferay's Architecture: The services layer

Company Blogs 2012年11月22日 按 Jorge Ferrer Staff

Here I am again for a second entry on the series of Liferay Architecture. This time I'm going to talk a bit more about the services layer of Liferay. As can be seen in the architecture diagram with which I started this series, the services layer is at the core of Liferay Portal:

The Services layer contains the great majority of the business logic for the portal platform and all of the portlets included out of the box. The services are organized in two sets:

  • Portal services (com.liferay.portal.service): contains the services for the portal level entities. A simple trick to identify them is to look at the "Portal" section of the Control Panel menu.
  • Portlet services (com.liferay.portlet.*.service): contains the services used by the different portlets in Liferay. There are also some packages that are not really associated to one portlet (or to more that one), so the word portlet here is being abused a little bit. What matters is that all the services that are no part of the core portal platform are properly organized and componentized.

One very specific aspect of the services layer is that it is divided in two sub-layers:

  1. Local Services (<Entity>LocalService.java): this are the ones that that contain the business logic and communicate with the persistance layer.
  2. Remote Services (<Entity>Service.java): the main goal is to perform security checks before invoking the equivalent method in the local service. In some cases the remote services are also responsible for converting the Java objects returned by the local services layer to other formats. For example, the RSS generation for portlets that support it is done in remote services.

I'm going to finish the entry with some further facts and patterns of Liferay's services layer. The first are more well known but some aren't:

  1. Each persisted entity has an associated service. For example, the User entity has UserService, DLFileEntry (the entity used to store documents of Documents & Media) has the DLFileEntryService.
  2. The services methods are executed in a transaction. That means that if your database supports it (and most do) if there is an error in the middle of the execution of a service method (or in any other method invoked by it), all the previous operations will be undone (rolled back) automatically for you. Liferay implements this under the hood using Spring's transations mechanisms.
  3. The persistance layer is always accessed from local services. You should never access it directly unless you really know what you are doing and you are able to handle transactions manually from the invoking code.
  4. The local services are very strict with the return types of its methods. The return type should be one of the following:
    1. void
    2. <Entity>
    3. List<Entity>
    4. primitive type (this is not used often)

That's it for this second entry. I'm looking forward for your feedback. I'd love to know what topics are more interesting to you so that I can keep them into account for next entries.

Update Nov 29th: Added primitive type as a 4th return type. Thanks David for the note about it.

Liferay's Architecture: The beginning of a blog series

Company Blogs 2012年11月12日 按 Jorge Ferrer Staff

Hey guys,

As you have already heard we have done quite a few symposiums during October, starting with the one in San Francisco, followed by Germany and finishing with Spain. And by the way, if you live in Italy and haven't had a chance to go to any of them, don't miss out the opportunity to attend the Liferay Italy Symposium this Friday. You will have an opportunity to meet many people and attend some of the most acclaimed talks done at the other symposiums.

Speaking of which, I have received lots of positive feedback about my presentation about Liferay's Architecture (Thanks so much!) so that has encouraged me to try to reach the wider audience of all of you reading Liferay's blog. This will also give me an opportunity to get to the last set of slides that I didn't have time to cover during the symposiums.

Because there is a lot of content, I'm not going to do one blog entry, but rather a series of them. Most probably one per slide in my presentation, so I can explain each slide properly. In this blog entry I'm just going to show the first slide which actually shows a diagram of Liferay's architecture which I use also as an index of my whole presentation. Here it is:

I will cover each of the elements that can be seen in this diagram in more detail in future blog posts, but here are a few important things to note:

  • For a product as large as Liferay there are many ways to represent its architecture. The perspective that I've chosen for this diagram is one that highlights its layered architecture since I think it is one of the greatest aspect of Liferay.
  • It also highlights how flexible Liferay is in terms of accessing external systems as well as being accessed by all sorts of external "clients" from regular desktops to third party apps going through mobile apps and browsers.
  • How Liferay is buzzword compliant with terms such as SOA, WOA, ... even since before the terms existed ;)
  • How Liferay includes many transversal frameworks that are used inside Liferay but also made available for applications built on top of it.

That's it for now, since I want to try and keep each entry short. I'd love to hear your feedback regarding what you are most interested on regarding Liferay's architecture. Next time I'll dig in more detail into the services layer.

Liferay's source is now at GitHub! Go fork it.

Company Blogs 2012年8月31日 按 Jorge Ferrer Staff

While many people have already find out by themselves I think it's about time to make it official: Liferay's source code is now at GitHub. That includes all of the projects:

  • Liferay Portal
  • Liferay Plugins
  • Alloy UI
  • Liferay Faces
  • Liferay Docs

Why the change? We had been talking for a long time about using a distributed version control system such as Git or Mercurial but it seemed like a huge change. However the number of developers and casual contributors kept increasing and at one point while working on 6.1 we realized the centralized subversion repository was becoming a significant bottleneck. So overnight we decided to give Github a try. We weren't 100% it would work so we didn't make any announcement and made sure to keep SVN repositories in sync. In fact the first few months were quite hard for many developers because Git really requires some mindset changes.

But after around 1 year using it, we can officially say that we love Git and we love GitHub!

It's been a great improvement to our processes and it has allowed us to streamline the code review process (which is pretty strict at Liferay).

I would like to highlight that we are still syncing our old Subversion repositories so you can still use them. But I strongly recommend that you give Github a try. We don't have a date for it yet since some of our internal systems still use the Subversion repositories but eventually we'll stop using them.

Contributing

One of the great innovations of Github is how easy it is to fork a project and make modifications to it. And it is just as easy to send the changes back to the original project using what is known as a pull request. In fact, for small changes to a single file you can even do all of that through a web user interface. Once you have done the changes we hope you decide to contribute it back so that we all keep working on making Liferay such a great product.

For those of you who want to contribute here are some steps/recommendations:

  1. Find what you can contribute to: http://www.liferay.com/community/welcome/contribute
  2. Learn the details of how to do it: http://www.liferay.com/community/wiki/-/wiki/Main/How%20to%20contribute%20to%20Liferay
  3. Find an "sponsor" for your contribution. This step probably needs an larger explanation.

Like many successful Open Source projects Liferay has a very large community. And this large community also generates lots of contributions. Many of those contributions are awesome and are what has made Liferay such a good product, but sometimes they are lost among an avalanche of not so good contributions. GitHub is allowing us to improve this by easily implementing a trust network so that casual contributors can rely on more active contributors who can rely on full time developers. That's exactly how Linux handles its contributions so it cannot be such a bad method ;)

So, if you believe your contribution is awesome or you want to receive feedback about it, once you have created the JIRA ticket and set it to "Contributed" state as explained in the links above I recommend that you go to the Contributions category in the forums and you explain what you've done. Common contributors and full time developers are usually subscribed to this category so it should be easy to find someone who wants to review your code.

Additionally, Drew Blessing, from the Community Verifiers team, has started a new initiative to proactively review the contributions as they come to evaluate their value and make sure that the most valuable contributions are applied as soon as possible. Thanks a lot Drew!

Happy forking! Happy contributing!

Symposium de Liferay en España: 26 y 27 de Octubre de 2011

Company Blogs 2011年9月19日 按 Jorge Ferrer Staff

Hola a todos,

Ya estoy por aquí de nuevo y como no podía ser de otra manera con buenos propósitos de escribir entradas mucho más a menudo. Temas de los que hablar no me van a faltar en los próximos meses con el lanzamiento de la versión 6.1, el marketplace, el roadmap de las siguientes versiones, ...

Estos serán precisamente los temas en torno a los cuales girarán las ponencias del Symposium de Liferay en España que se celebrará los días 26 y 27 de Octubre en Madrid. Después del éxito del año pasado, el evento ha crecido significativamente y durará dos días con dos tracks, uno de negocio y otro técnico.

¿Qué puedo esperar del Symposium? ¿A quien va dirigido?

El evento va dirigido a todas las personas a las que les interese conocer más sobre Liferay y el mundo del software Open Source en el mundo de la empresa. Si has oído hablar de Liferay y te gustaría conocer más sobre él, si lo estás usando y quieres conocer las novedades o simplemente si quieres conocer a las personas que hay detrás del producto, no puedes perderte el Symposium.

También es una oportunidad de conocer a muchas otras personas que usan o están pensando en usar Liferay, a los líderes del proyecto como Bryan Cheung (CEO), Paul Hinz (CMO) o Michael Han (VP Operations), así como a todos los partners de Liferay en España y muchos de los miembros del #LSUG.

Durante el evento se presentará la nueva versión Liferay 6.1 así como el lanzamiento del Liferay Marketplace, un nuevo ecosistema de productos construidos sobre la plataforma.

Y mucho más. Ya puedes consultar la agenda del evento para conocer todos los detalles.

Call for papers: tu oportunidad de participar

Por primera vez, este año ofrecemos también la posibilidad de enviar ponencias para contar experiencias concretas con Liferay. Las ponencias pueden durar 20 minutos o 7 minutos y encuadrarse en uno de los tracks del evento. Algunos ejemplos serían:

  • Track Negocio: ejemplos de uso de Liferay en sectores o con objetivos concretos, integración con otros productos para incrementar el valor de la solución completa, productos construidos sobre Liferay, etc.
  • Track Técnico: uso de librerías, frameworks o cualquier otro tipo de tecnología para extender Liferay o construir aplicaciones sobre él, experiencias de actualizaciones de versión, implementación de estándares, descripción técnica de integraciones con otros productos, ...

Si te interesa, no dejes pasar esta oportunidad ¡sólo quedan 5 días para enviar solicitudes! el plazo termina el viernes 23 de Septiembre. Si tienes una idea interesante tienes tiempo de sobra, dado que basta con que envíes un resumen antes de que termine el plazo. El día 30 se hará el anuncio de las ponencias elegidas y se solicitará la presentación final. Los elegidos no sólo tendrán una entrada gratuita al evento sino que tendrán la oportunidad de compartir escenario con los mayores expertos de Liferay en el mundo.

Puedes ver los detalles en la página del Call for Papers.

Eso es todo por hoy, pero volveré pronto con más. Y por supuesto, confío en verte en el Symposium.

Liferay Dream Day Barcelona: Una gran experiencia

Company Blogs 2011年6月29日 按 Jorge Ferrer Staff

 

Ayer se celebró en Barcelona el primer "Liferay Dream Day". Este evento fue posible gracias a nuestro partner iSoco, que cuenta con gran experiencia en actividades de innovación, y fue una gran experiencia para todos los que estuvimos allí. El evento contó con la participación de varios clientes seleccionados de toda España junto con nuestros partners iSocoB2B2000 y GMV con el objetivo de llevar a cabo una tormenta de ideas (de soñar al fin y al cabo) sobre cómo debería evolucionar Liferay en el futuro. Entre los asistentes se dió una combinación muy interesante de jefes de proyectos, gerentes, directores de tecnología, técnicos, comerciales, etc.
 
Conducido por Philippe Delespesse de Inteligencia Creativa, un experto en este tipo de sesiones de trabajo de innovación, el evento comenzó con la selección de dos temas, gestión de contenidos e integración de aplicaciones. Los participantes fueron organizados en cuatro grupos y Philippe les mostró cómo emplear una tecnología conocida como SCAMPER para generar ideas que pudieran ser una evolución de las funcionalidades existentes o bien ser completamente disruptivas.
 
Algo en lo que Philippe insistió mucho y que me pareció especialmente interesante es que cuando se está en un proceso de innovación está completamente prohibido decir que una idea es mala (al menos por el momento). La razón es que la naturaleza humana lleva a rechazar de inicio ideas que son muy diferentes, por lo que si no se evita conscientemente algunas excelentes ideas podrían ser abandonadas antes de darse cuenta cómo de buenas pueden ser.
 
Fue increible comprobar cuantas ideas de las que surgieron son aspectos en los que ya hemos trabajado o estamos trabajando para la versión 6.1 (algo que yo no estaba autorizado a mencionar hasta el final del día), pero lo más interesatne es que para algunas de esas ideas se ofrecieron aspectos y perspectivas nuevas en las que no habíamos pensado. Los participantes también generaron mumerosas ideas completamente nuevas y a cada grupo se le pidió que eligieron las mejores 5. Esas ideas se pusieron en un tablón y a partir de él seguiremos trabajando durante las siguientes semanas para definirlas en detalle y que sean incorporadas en el roadmap del producto.
 
 
Sesión de tormenta de ideas - Selección de las mejores ideas
 
Una segunda fase del día se dedicó a la creación de sitios web para dispositivos móviles. esta sesión usó una metodología diferentes y ello resultó en una conversación que no estaba directamente relacionada con Liferay (o cualquier otra plataforma). En su lugar derivó en una tormenta de ideas sobre lo que cada uno de los asistentes desearía poder hacer cuando están en la calle, viajando, ... si estuviéramos en un mundo ideal. Al principio fue dificil entender cual era la utilidad de esto, pero según Philippe iba capturando las ideas en sábanas de papel que iba colgando de la pared, me di cuenta de la enorme valía que estas tenían para identificar las necesidades reales de los usuarios finales. Si hubiéramos preguntado directamente a los asistentes como propietarios o desarrolladores de un portal, hubieran tenido que imaginar lo que sus usuarios desearían, pero es muy difícil acertar por lo novedoso de el acceso móvil a Internet. 
 
Algunas de las ideas que surgieron en la segunda sesión
 
 
En conjunto, creo que fue una gran experiencia. Todos los asistentes con los que hablé estaban entusiasmado de haber participado en el evento y deseosos de continuar participando, dado que no es tan habitual ser capaz de influenciar cómo evoluciona un producto a este nivel. Aquellos de vosotros leyendo esto que seáis miembros activos de la comunidad de Liferay probablemente ya estáis acostumbrados a poder dar ideas y contribuir al roadmap de un proyecto de software libre como Liferay. Lo realmente positivo de este tipo de eventos es que ayudan a involucrarse a much gente que quizá no lo hubiera hecho de otra manera, pero que tienen una gran experiencia y por tanto su presencia e ideas ayuda a la comunidad a crecer y construir un producto cada vez mejor.
 
Teniendo en cuenta este éxito es muy probable que el evento se repita en otras zonas de España y el resto del mundo, por lo que si estás interesado en participar comentalo con tu contacto en Liferay o en alguno de nuestros partners. Y por supuesto, si tienes ideas que quieres compartir ahora mismo, no es necesario esperar, puedes sugerirlas en los foros y así conocer la opinión sobre ellas del resto de la comunidad.

 

Liferay Dream Day Barcelona: What a great experience

Company Blogs 2011年6月29日 按 Jorge Ferrer Staff

 

Yesterday we held the first ever "Liferay Dream Day" event in Barcelona. This event was possible thanks to our partner iSoco who is highly specialized in innovation activities and it was an amazing experience for all of us. The event counted with the participation of selected key customers from around Spain along with our partners iSoco, B2B2000 and GMV with the goal of brainstorming (dreaming) how Liferay could evolve in the future. Among the attendants there was a very interesting combination of project managers, CIOs, technical people, sales people, etc.
 
Conducted by Philippe Delespesse from Inteligencia Creativa, an expert in this type of innovation workshops, the event started by selecting two topics, content management systems and integration of applications. The attendants were organizaed in four groups and Philippe showed how to use a methodology called SCAMPER, to come up with new ideas that could be either an evolution or completely disruptive.
 
Something that Philippe insisted on and I found particularly interesting is that during an innovation workshop it is completely forbidden to say that an idea is a bad idea (at least for now). The reason is that it is in human nature to reject ideas that are too different, so if we let that happen very good ideas could be rejected before we realize how good they can really be.
 
It was great to find out that many of the ideas that came up were things that we were already working on for the upcoming 6.1 (which I wasn't allowed to say), but what I found awesome is that even for those ideas some interesting and new perspectives also came up. The participants also came up with lots of new ideas as well and each group were asked to pick the best 5. Those ideas were put on a board and we will keep working on defining them in detail so that they are added to the product roadmap (I'll blog more about the specific ideas later on).
 
Brainstorming session - Selection of the best ideas
 
A second phase of the day was dedicated to the creation of websites for mobile devices. This session used a different methodoloy that resulted in a conversation not related directly with Liferay or any platform, but rather about what people would like to be able to do ideally when they are on the move. At first it was hard to understand were this was getting to, but as the ideas were being captured in a board by Philippe I realized that the great thing about it was that the needs identified were real needs by end users. If we would have asked portal developers or administrators they would have answered what they thought their users wanted, which could or could not be what they really want.
 
Some of the ideas that came out of the second brainstorming session
 
All in all, I think this was a great experience. All of the participants that I talked to were very excited of having been part of the event and wanted to keep participating, because it is not that usual to be able to influence at this level how a product you use should evolve. For those of you reading this that are active community members, you are already used to how it is possible to participate in the evolution of an Open Source product like Liferay. What is great about this type of events is that it helps getting involved to many people who may have not beeen involved otherwise, but have a great deal of experience that helps the whole community grow and help build a better product for everyone.
 
Considering this success I'm pretty sure we will repeat the event in other parts of the world, so if you are interested in participating let your account manager know. And of course, if you have ideas that you want to share right away, there is not need to wait, share them in the forums to find out what the rest of the community thinks about them.

Organizations or Communities, which one should I use? The final answer

Company Blogs 2011年3月11日 按 Jorge Ferrer Staff

One of the questions that comes up more often when I talk to community members, partners and customers is, should I use communities or organizations in my project?

If you haven't asked yourself this question before, let me add some background. Liferay portal is known to have great multi-tenancy support. That means that you can have many independent sites within a single installation of Liferay. There are two ways to build sites in Liferay, organizations and communities, and each one has its own characteristics.

When I am asked this question, I always like to go back to the origin of each of them, because I think it helps understand the differences:

  • Communities: they were created as a way to have groups of pages that could display content and applications. The reason why they were called communities is because the goal of all the initial implementations was to build online communities, but since then people have really been using communities for things for which the term may not apply so well such as corporate sites, product sites, event sites, etc. That's perfectly fine.
  • Organizations: they were created as a way to organize users in a hierarchy. The great thing of this hierarchy is that it allows delegation of user administration, which is a key feature needed by some of the largest installations of Liferay where there are hundreds of thousands or even millions of users. Later, we realized that many people were creating a community associated to each (or several) of their organizations. But keeping this association manually was a bit of a pain, so we improved organizations so that they could have their own site. (For the curious, we did it by creating a community underneath but  hiding that fact from the end user).

Keeping this explanation in mind it should be easier to decide which one to use. If your main purpose is to organize your users and delegate their administration, you should use organizations (It is important to always remember that an Organization Administrator will be allowed to edit the profile of all the users of the organization). If you also need the organization to have pages, then you can use that feature to save time.

If all you want to do is create a website with pages, content and applications that can either be accessed by anyone or just by a group of members of the site, then communities is the best choice.

And of course, remember that you can safely use both communities and organizations within the same portal.

I hope that this explanation makes it easier for you the next time you ask yourself this question, but whenever a question comes up so often I think we should ask ourselves why. We have done it and have been discussing internally how we could improve the product to avoid the question altogether. We have been thinking about several solutions and we are very happy with the one we have found. In fact is super simple, and that's always a good thing.

Improvements in Liferay 6.1 to simplify the creation of sites

 

Let's start with the great news, in Liferay 6.1 you will not have to decide whether to use communities or organizations upfront. Sounds good, right?

Let me explain what will change and how that will be achieved. The first change that we will be making is to rename what we currently know as Communities and call it Sites. The reason for this should be obvious if you have read the rest of this entry, people have been using Liferay's communities to build sites for a long time so it's always a good way to make things easier to understand to give them a name that means exactly what people use them for.

Of course we will still allow creating sites whose purpose is to serve for building online communities. In fact we plan to make it easier and faster to do that by using predefined site templates for community building.

How about organizations? They will still be the main way to organize users in a hierarchy and they will also have the ability to have an associated Site. The main change that we will be making is that if it has one, the Site of an organization will not be invisible. In other words, when the administrator goes to the Control Panel to the Sites Administration application (which is currently known as Communities Administration) he/she will be able to see all the sites, including those that are associated to an organization.

Additionally, it will be possible for an administrator to associate an existing site to an organization at any time. Of course it will also be possible to undo this association whenever wanted. When a site is associated to an organization the following things will happen (this doesn't change from 6.0, but I prefer to still explain it):

  • All users of the organization will become members of the site automatically. That means that they will have access to the private pages of the site and will be able to do any action that has been configured to be doable only by members.
  • The name and description of the Site will be automatically synced with those of the organization (to save the administrator time).

As you can see, the changes that will be introduced won't be large, but it will make the life of developers building portals using Liferay easier. If someone asks you, how do I build a site to do XYZ? There will be one and only one option that you can choose, while still keeping the benefits that we had before.

Furthermore, as we have started working on theses changes and we keep having many benefits that we hadn't thought of to this simple changes. For example, it will be very easy to have a user who is an administrator of the site of an organization but not of the users of the organization without creating custom roles. Also, it will simplify the management of roles and avoid some duplication that is necessary now some times. Not only that but it will also help make Site Templates more powerful, so expect improvements in this area too :)

We hope you like this idea and of course we would really welcome beta testers (maybe I should say alpha testers) that would like to try these changes as we build them in Subversion to give us feedback.

Finally, you might be wondering if this will require any complex upgrade. The answer is no, because there are no significant changes in the APIs or database model, so all your sites will be kept and those that were associated to an organization will stay that way. The only things that will need to be upgraded (and this will be done automatically for you) is related to organization roles. For example, Organization Administrators, will be automatically made Site Administrators, so that they can keep managing the site as they used to. But now you will have the flexibility to assign both roles or only one to your users.

 

显示 59 结果中的 1 - 20。
Items 20
的 3