Skip navigation
1 2 3 Previous Next

GateIn

61 posts

We have been busy working on new features since we released GateIn 3.6. Today, I would like to announce two new versions of the Portal: 3.7.0.Final and 3.8.0.Beta01. Both of them are available for download already. They will be followed by the version 3.8.0.Final within a couple of weeks.


New and noteworthy in GateIn 3.7.0.Final

 


New and noteworthy in GateIn 3.8.0.Beta01

  • There is no JBoss AS 7 distribution any more. JBoss AS 7 was replaced with JBoss EAP 6.3.0.Alpha.
  • Page Composition API - An enhancement of the Portal Public API allowing to create and edit page content, i.e. add and remove portlets and layout containers. See the Page Composition API section of GateIn Documentation.
  • Automatic way to update all sites at once (Portal, groups and user sites). See GTNPORTAL-3328 and Working with Templates chapter of GateIn documentation.
  • Impersonation - Portal administrator can now view another user's customized dashboard/pages without logging out. See GTNPORTAL-2662 and the Impersonation chapter of GateIn documentation.
  • Experimental support for large third party JavaScript frameworks, such as Dojo. See Native AMD Modules in GateIn documentation.
  • Public Render Parameters can be now propagated to a different page. See GTNPORTAL-3369.
  • Navigation nodes can be defined with external links. See GTNPORTAL-2428 and the specification if the feature: Custom Navigaton Node Properties
  • Login validation and accounts expiration can be additionally customized. See GTNPORTAL-3402.
  • Pages can be completely hidden using check-box and date-control, see GTNPORTAL-3370.
  • General markup review and cleanup and greater alignment and consistency with W3C validation.
  • All features, bug fixes and minor enhancements are listed in GateIn 3.8.0.Beta01 Release Notes.


Download here to try it out. Your feedback is welcome in GateIn Forums. Please report issues in GateIn Jira.

On the 13-16th November the "Interaction South America" conference occurred in Recife, Brazil. The ISA is the biggest event of Interaction Design with this year's theme being "New models, new industries, new interactions". The conference consisted of four days of papers, cases, workshops and lectures with big names like Bill Buxton, Jared Spool and Lou Rosenfeld.

 

I presented a case describing my experience on working for an open-source project, the proposed redesign for GateIn, and the advances of the Red Hat Common User Experience initiative. There were about 50 people attending. On top of cases, papers and lectures, I attended to the workshop "Lean UX: Agility Through Cross-Functional Collaboration", with Josh Seiden, co-author of the book "Lean UX: Applying Lean Principles to Improve User Experience". Below you can see an overview of interesting points of the event.

 

Lean User Experience (UX)

 

Lean UX was inspired by the theories from Lean Startup and Agile development. Josh Seiden describes Lean UX as "a practice of bringing the true nature of a product to light faster, in a collaborative, cross-functional way with less emphasis on deliverables and greater focus on a shared understanding of the actual experience being designed".

 

As a case study, Josh presented a video where a team built an application to help sell glasses. They camped in a glasses store and developed an iPad application from scratch in less than a week; designing, testing and developing their app on site. Watch the video (click on it):

 

Screen Shot 2013-11-27 at 5.32.15 PM.png

 

There are 9 principles for Lean Teams (source www.luxr.co):

  • Design + biz + development + ... = 1 product team.
  • Externalize!
  • Goal-driven and outcome-focused.
  • Repeatable and routinized.
  • Research with users is the best source of information.
  • Focus on solving the right problem.
  • Generate many options & decide quickly what to pursue.
  • Recognize hypotheses & validate them.
  • Rapid cycles: think/make/check.

 

I'll comment some of them.

 

  • Goal-driven and outcome-focused: Instead of focusing in outputs (features), focus on outcomes (benefits). Do you need "chat" in your product (feature) or a better communication solution that fits your users' needs (outcome)? By jumping directly to features, you might ignore better possibilities to solve a problem.
  • Recognize hypotheses: Before adding any feature to your product, write down a hypotheses. E.g.: "We believe that a chat in our product will facilitate routine users, preventing them out of the product to communicate with a colleague".
  • Test hypotheses: Some of them need design, others don't. In the case above, some interviews could confirm the hypotheses. In case of some redesign, usability testing would fit better.

 

In the workshop, our team had the initiative to test a hypothesis with Josh Seiden. It was a redesign of a voice call app which I tested with him to see if he would complete a specific task easier and faster.

944311_689092461101184_130935258_n.jpg

 

The message of Lean UX is the following: instead of investing lots of money developing your revolutionary app, build something simple that can be tested by users. Launch a page with a concept and put a "Download" button. Thus, you will confirm if your idea is really interesting to the users. That's the spirit!

From 13 to 16 November there will be a big event in Brazil which will discuss interaction design, the "Interaction South America" conference. This is the biggest event of Interaction Design in South America, and will feature big names in the field such as Bill Buxton (Principal Researcher at Microsoft Research) and Louis Rosenfeld (co-author of Information Architecture for the World Wide Web), the bible of Information Architecture.


This year I will talk about interaction design at the conference, presenting the proposal of redesign I did for GateIn.


Screen Shot 2013-11-04 at 4.49.36 PM.png

My idea is not to talk only about the redesign process and its phases, but also about my experience collaborating to an open source project, something I'd never done before.

 

I will also talk about the Red Hat Common User Experience Initiative. For the ones who are not familiar with it, it's a project that aims to provide a common design for the Red Hat products. I'm contributing to it indirectly as I am using the proposed elements in a project, and suggesting new elements that were not designed. A console that uses the elements proposed by RCUE should look like the image below:

 

Screen Shot 2013-11-04 at 5.01.18 PM.png


So that is basically what I intend to cover at the conference. I'll write another post soon talking about how was it. Hopefully we see again soon

stianst

GateIn Portal API

Posted by stianst Jul 22, 2013

Everything comes with a public API nowadays, and now so does GateIn Portal. This post introduces the Java API, there's also a REST API which there will be a separate post about.

 

For this release the main focus was on navigation, specifically manging portal navigations and creating custom navigation portlets.

Managing Portal Navigations

Portal navigations are menus that contain hyperlinks to other parts of a portal. In the past these could only be created through the web interface, but can now also be created through the Java or REST API's. Most operations that are required to manage portal navigations are supported. For example adding nodes to a portal navigation, moving nodes around, controlling permissions and managing internationalized labels for nodes.

 

For the full details on what can be done look at the Developer Guide: https://docs.jboss.org/author/display/GTNPORTAL36/Portal+API.

Custom Navigation Portlets

If the standard navigation portlets doesn't do the job for you, now it's very easy to create your own custom navigation portlet to build a menu exactly the way you want it. You can easily control what nodes are displayed in the menu with the filtering mechanism and how many levels of nodes to display with the node visitors mechanism.

 

There's a number of resources available to get you started:

With the release of GateIn 3.6.0.Final we introduced some new CDI scopes to ease its use within a portlet.  This second blog on CDI scopes for GateIn, will cover @PortletRedisplayScoped. This scope can be used with GenericPortlets, Portlet Filters, or JSF Portlets.

 

This scope is retained beyond a single Portlet Request lifecycle to be retrieved for all subsequent Render Requests that don't involve an Action or Event. The Beans in this scope are destroyed subsequent Action or Event requests, enabling continual refreshing of the portlet by a user to repeatedly display the same exact content as the Bean data will not be re generated for each Render. The following table illustrates when the context for the scope is activated (A), destroyed (X), or when its already present (P):

 

 

Portlet TriggerAction StartAction CompleteEvent StartEvent CompleteRender StartRender CompleteResource StartResource Complete
Portlet ActionX then APPPPP

Portlet Event

X then APPP

Portlet Render



A (if not present)P

Portlet Resource





AX

 

An important distinction is that any Beans created within the scope context as part of a Portlet Action, Portlet Event or Portlet Render are not visible within a Portlet Resource call, and vice versa. Each ResourceRequest will receive a completely empty set of Beans that have been constructed, including calls to any @PostConstruct, but that have had no code executed against them.

 

There is one difference with how Resource Request Beans are handled as compared to @PortletLifecycleScoped, in that any Beans that are used during a Resource Request will be merged into the context of the main portlet lifecycle. What this means is that the values on a @PortletRedisplayScoped bean that was used during a Resource Request will replace the contents of the same Bean type for the next Render Request that is executed. In most cases that wouldn't be a problem, but it's a potential gotcha if you make lots of Ajax calls and suddenly wonder why the values in your Beans are all wrong the next time you Render the portlet.

 

To begin using the new scope, simply add the following dependency into your portlet project pom.xml:

 

        <dependency>
            <groupId>org.gatein.api</groupId>
            <artifactId>gatein-api</artifactId>
            <version>1.0.0.Final</version>
            <scope>provided</scope>
        </dependency>

 

We mark the dependency as provided since GateIn will automatically link our deployment to the latest API dependency at runtime.

 

With the above dependency we can then create a bean such as:

 

@PortletRedisplayScoped
public class LifecycleBean implements java.io.Serializable {
  ...
}

 

Note that we implement Serializable for our Bean, as the context is stored within the User Session, which can potentially be passivated by the container.

 

As far as CDI is concerned, @PortletRedisplayScoped is a bean scope like all those that it provides. This enables us to inject @RequestScoped, @ConversationScoped, @SessionScoped or @ApplicationScoped beans into a @PortletRedisplayScoped bean, or vice versa.

 

Hope this and the scope we covered in the previous blog will make developing CDI portlets with GateIn that much easier!

With the release of GateIn 3.6.0.Final we introduced some new CDI scopes to ease its use within a portlet.  In this first blog on CDI scopes for GateIn, we will cover @PortletLifecycleScoped. This scope can be used with GenericPortlets, Portlet Filters, or JSF Portlets.

 

This scope lives for a single Portlet Request lifecycle and is destroyed on completion, meaning that there is no way to guarantee a subsequent Render will generate the same portlet content. The following table illustrates when the context for the scope is activated (A), destroyed (X), or when its already present (P):

 

 

Portlet TriggerAction StartAction CompleteEvent StartEvent CompleteRender StartRender CompleteResource StartResource Complete
Portlet ActionAPPPPX

Portlet Event

APPX

Portlet Render



AX

Portlet Resource





AX

 

An important distinction is that any Beans created within the scope context as part of a Portlet Action, Portlet Event or Portlet Render are not visible within a Portlet Resource call, and vice versa. Each ResourceRequest will receive a completely empty set of Beans that have been constructed, including calls to any @PostConstruct, but that have had no code executed against them. Any changes to Beans within a ResourceRequest is not retained in any way. This situation is perfect for making Ajax calls from a portlet, so long as the data you're relying on perform the work is accessible from non @PortletLifecycleScoped beans.

 

To begin using the new scope, simply add the following dependency into your portlet project pom.xml:

 

        <dependency>
            <groupId>org.gatein.api</groupId>
            <artifactId>gatein-api</artifactId>
            <version>1.0.0.Final</version>
            <scope>provided</scope>
        </dependency>

 

We mark the dependency as provided since GateIn will automatically link our deployment to the latest API dependency at runtime.

 

With the above dependency we can then create a bean such as:

 

@PortletLifecycleScoped
public class LifecycleBean {
  ...
}

 

As far as CDI is concerned, @PortletLifecycleScoped is a bean scope like all those that it provides. This enables us to inject @RequestScoped, @ConversationScoped, @SessionScoped or @ApplicationScoped beans into a @PortletLifecycleScoped bean, or vice versa.

 

Hope this and the scope we cover in the next blog will make developing CDI portlets with GateIn that much easier!

With the release of GateIn 3.6.0.Final we now have the ability to inject CDI beans directly into our portlet classes, whether they extend GenericPortlet or implement the Portlet interface, and any class that implements a Portlet Filter interface.

 

The injection works just the same as with any other CDI injection, with one small caveat. When deciding which Beans to inject into our portlet or filter, keep in mind that injecting a normal scoped bean, such as @SessionScoped, is fine even though there is no User Session present, because the container will simply inject a client proxy for us, but it's not possible to inject a Bean that is being produced by another Bean that doesn't have a valid context.

 

To explain this with an example, if we take the following portlet class:

 

public class BadPortlet extends GenericPortlet {
  @Inject
  private Greeting myGreeting;
}

 

and create a producer for it such as:

 

@SessionScoped
public class GreetingProducer implements Serializable {
  @Produces
  public Greeting produceGreeting(InjectionPoint point) {
    ...
  }
}

 

We receive a ContextNotActiveException because we're trying to produce one Bean from another Bean that is not yet, as there is no User Session during Portlet Container initialization.

 

When wanting to inject a produced Bean into a portlet class or filter, they need to be produced by @ApplicationScoped or @Dependent scoped Beans.

 

Here's an example portlet showing how we can use CDI injection:

 

public class MyPortlet extends GenericPortlet {
  @Inject
  MyBean bean;

  public void doView(RenderRequest request, RenderResponse response) throws PortletException, IOException {
    PortletRequestDispatcher dispatcher = getPortletContext().getRequestDispatcher("/myPage.jsp");
    request.setAttribute("myBean", bean);
    dispatcher.include(request, response);
  }
}

 

In our JSP we can then access the bean with ${myBean}.

 

I hope that this introduction into creating CDI enabled portlets and portlet filters will make your next portlet a bit easier to use with CDI!

A couple of screencasts have been created which cover the awesome new mobile (and responsive!) site which is included in GateIn 3.6.

 

The first one covers a brief overview of the mobile site that shows some of its cool new features and how it acts on a mobile phone.

 

 

 

 

The second screencast covers some of the configuration details when dealing with a mobile or responsive site. Including how to configure the viewport for the portal, restrict the shared layout to non-administrators and how to setup the responsive header portlet.

 

It also covers how to create a new mobile or responsive portal.

 

 

Check them out!

Gate In Device Detection and Site Redirection for performing redirection based on Use Agent has been available since version 3.5.0.Final but configuration was only possible through manual editing of a XML file, it’s modification would not affect the portal at runtime and even after restarting the server it would only be reloaded after deleting some data generated at startup. But that’s history, Gate In 3.6.0.Final introduces the “Site Redirects and Import/Export Portlet” to solve all these details for Site Redirection while also integrating the previous “Import/Export Site” portlet behavior in a more modern way, thanks to the fabulous work on the UI/UXP by Gabriel Cardoso and making use of the cool Richfaces Bootstrap Components!

 

You can find this portlet when logged as an Administrator under Group > Administration > Site Redirects and Import/Export on the top menu.

 

Configuring Site Redirects

Once on the portlet the list of available Sites is presented on the left side menu. Spaces are also present but they are not available for Redirects, only for Exporting.

Selecting a site will present the available Redirect conditions, which can be ordered by using drag and drop. These should be ordered in a way that most specific Redirects are on top (e.g.: “iOS”, “Touch”, “Mobile”).

 

redirects-list.png

 

A Redirect can be configured by clicking the “Configure” wrench icon, which shall present the following screen for its configuration:

 

redirect-config-main.png

 

In the top section, it is possible to toggle the redirect on or off, change it’s name and select to which site it should redirect to.

 

The “Conditions” section is where it is possible to define the conditions to evaluate in order to know if this redirect should be activated. These conditions are composed by valid Java regular expressions, can be checked for its presence or absence and are evaluated against the User Agent String. It is also possible to evaluate against custom defined properties (such as width, height, number of colors, etc), which should be configured at detection.jsp. See more detailed information on this at GateIn Developer Guide - Site Redirection.

 

redirect-edit-condition.png

 

At the “Node Mappings” section there’s the possibility to define where to redirect when the use is heading for a particular portal node, by either using node name matching where he’s redirected to the node with the same name or to define a custom node mapping, such as “classic/flash” redirecting to “ios/flash-not-available”. In case no mapping is defined and a node with the same name is not available (when node name mapping is enabled), the default action to perform should be defined in the unresolved nodes select.

More detailed information about how to configure redirects can be found at the User Guide.

 

Export a Site or Space

This same portlet allows exporting a site or space to be used in a different portal instalation or for backup purposes.

To do so, click the small arrow that shows on the right side of each site or space and click on the export option from the dropdown menu and a download of a zip containing the relevant files will start.

 

Import a Site

Importing a site is as easy, simply select the option to import from the left side menu and from the popup window, select the files to import (up to 5 at a time), select the desired import mode and voilá.

 

import-sites-spaces.png

In GateIn 3.6.0.Final we have added possibility to integrate the GateIn portal with Social networks Facebook, Google Plus and Twitter. Portal users will be able to register and login into the GateIn Portal using their 3rd party accounts from these social networks. In addition we have provided a set of quickstart portlets, which allow users to use the data from their social networks. For example we have a portlet for displaying all Facebook friends of a particular user.

 

This integration is leveraging the OAuth 2.0 protocol (in case of Facebook and Google+), and the OAuth 1.0A protocol (in case of Twitter). The GateIn Portal serves as an OAuth Client while particular social network serves as an OAuth Authorization and Resource server.

 

More information about the GateIn Portal integration is available in the documentation here and more inforomation about quickstart portlets is here

 

Before you dive into details in the documentation, you can check our video screencasts and see it in action first!

 

The first screencast is showing how to register and login into the GateIn Portal using social network accounts:

 

 

The second screencast is showing how to import Social portlet quickstarts into Eclipse IDE using JBoss Tools plugin, deploy into the GateIn Portal and then use the portlets to show information from Social network:

 

 

Enjoy the screencasts and the music in the background composed by Viliam Rockai.

bdaw

GateIn Portal 3.6.0.Final

Posted by bdaw Jul 1, 2013

I am are proud to announce GateIn Portal 3.6.0.Final release.

 

This is the outcome of several months of hard work of all developers involved in this project. Here I would like to thank everyone who helped make this release a reality.

 

For the past month and after Beta02 we have been mainly focused on fixing bugs. You can see the effect in Release Notes with 79 solved issues.

 

All key features have already been covered when announcing Beta01 and Beta02. Therefore I would like to just mention them briefly:

 

 

It is not possible to share enough details regarding all of new features in just one blog post. Therefore instead we decided to provide you with better coverage of all exciting improvements coming in GateIn Portal 3.6.0.Final. During next few weeks you can expect developers involved in the project to regularly post new articles or screencasts here. Stay tuned!

 

So what is comming next? We are switching focus to work on 3.7 release to follow. Let us know if there are any particular features you are interested in or you would be willing to contribute to. In parallel Julien is working on next gen architecture for GateIn 4.0.

 

Enjoy new GateIn 3.6.0.Final. Download and try it out while it is hot

bdaw

GateIn Portal 3.6.0.Beta02

Posted by bdaw May 29, 2013

We are proud to announce GateIn Portal 3.6.0.Beta02 release. This is our last stop before 3.6.0.Final that we plan to ship around end of June. It contains countless number of bug fixes and smaller improvements since Beta01. You can see the full changelog here

 

We are still polishing things for the final release however several key features can be tried out already. Just to name few of them:

  • EAP 6.1 integration. It is possible to build and deploy GateIn on EAP binaries available on jboss.org.
  • Several UI improvements regarding accessibility (for eg. you can navigate menu with tab).

 

Binaries are available here. Please try it out and give us feedback!

This year was the first time that JUDCon came to Brazil. The event happened on April 19 and 20, and was the first Red Hat Latin American Developer Conference. Mark Little, who leads the JBoss engineering team gave a keynote and announced the rebranding of JBoss As as WildFly.

 

The JUDCon 2013:Brazil presented nearly 70 sessions and had an attendance to 340 developers. Since talks about design are rare in this kind of event, I decided to submit mine, which was approved: Designing a New User Interface for Open Source Projects. In this post you can follow a little of what was covered in the presentation.

 

 

A project without a designer

 

I started saying that the User Interface of an Open Source project can suffer a lot without a designer. And that's not only related to visual design, but also to usability, the quality of usage.

 

Screen Shot 2013-05-02 at 12.55.31 PM.png

 

As an example, I shown the page of PECL, a repository for PHP Extensions. I guess they probably don't have a designer in the team... What do you think?

 

In the case of Gatein, some inconsistencies have been appearing over time. Do you see any reason for the login pop-up (in the left) and the login page (in the right) to be different?

 

Screen Shot 2013-05-02 at 1.01.25 PM.png

In this example, we can see inconsistencies of visual design (header, left image, colors, borders) and navigation design (the option "forgot user/password" and the possibility of getting out of the dialog is only available in the popup).

 

But how to avoid that inconsistencies and usability problems happen?

 

 

A design process for the Web

 

Instead of defining everything when you are ready to code the solution, how about following a design process that divides the problem in steps? That's what Jesse James Garrett presented in his famous diagram "The elements of user experience" in the early 2000's.

 

Screen Shot 2013-05-02 at 1.10.27 PM.png

 

He is basically saying that, after having the scope (requirements), it is needed to think about structure (flows and information architecture maps), skeleton (wireframes) and only after that go to the visual design. The next images show examples of this steps in the redesign of GateIn.

 

Screen Shot 2013-04-16 at 6.44.32 PM.png

Structure: fragment of the new Information Architecture proposed for GateIn

 

admin4.gif

Skeleton: Wireframe for the Portal Configuration page. The new design proposed the usage of more pages instead of pop-up dialogues.

 

Screen Shot 2013-05-03 at 8.35.39 AM.png

Surface: first proposal of visual design for the redesign of Gatein.

 

 

Where to start in case of a redesign?

 

Ok, that's the process of design. But where to start in case of a redesign? Specifically in GateIn, we wanted to improve visual design and usability. So my first task when I joined the development team was to conduct a usability inspection. To do that, I followed the Jakob Nielsen's 10 Heuristics for User Interface Design.

 

The outcome of this work was a spreadsheet listing the problems found. Usability inspection: fragment of the list with the usability problems found.

 

Screen Shot 2013-04-16 at 6.40.34 PM.png

Usability inspection: fragment of the list with the usability problems found.

 

Based on that, we could prioritize which pages to redesign first. The first one was the Portal Configuration page. After proposing a new Information Architecture for the portal and a new wireframe for the page, we went to the implementation of it in HTML and CSS.

 

 

Speeding up with Twitter Bootstrap

 

To accelerate the implementation, we decided to test Twitter Bootstrap, a front-end framework to speed up the development. The first implementation was done based on the wireframe, without having the visual design. We used only the HTML structure suggested by Bootstrap, without adding any line of CSS. The result can be seen in the next image.

 

Screen Shot 2013-04-17 at 11.17.46 AM.png

Our HTML with only CSS from Twitter Bootstrap.

 

Without any customized CSS, Twitter Bootstrap already provides a good header, nice buttons, a solid structure for the sidebar and well-designed forms, including tables. By adding a customized CSS with only 250 lines, we could achieve the result of the next image.

 

Screen Shot 2013-04-17 at 11.13.37 AM.png

 

It is interesting to say that, without Twitter Bootstrap, this design would need much more lines and time to be implemented. It needed only around 15 hours to look like this.

 

Although the interface was OK, we wanted something more special for GateIn. Based on this HTML prototype, we refined the visual design and reached the following result:

 

The redesigned pages were also implemented in HTML + CSS + jQuery, and can be seen at:

 

 

A mobile demo with Responsive Web Design

 

Since we planned on launching site redirects support for GateIn 3.6, we decided to offer a mobile demo with a design that works well in mobile devices.

 

Screen Shot 2013-05-02 at 2.13.32 PM.png

Mobile demo in a smaller screen.

 

Before being integrated to the project, it was implemented in HTML + CSS + jQuery, using Twitter Bootstrap too. The solution can be seen here: http://statichtml-theute.rhcloud.com/cardosogabriel/gatein-client/responsive/index-mobile.html. Try to reduce and increase the size of the window, or access it in different devices.

 

To make the original design responsive, I focused on two details:

 

Fluid widths and distances in percentage (%)


If you want to make the design fit the screen, you need to convert the widths, margins and paddings to "%" instead of "px". Here is an example:

 

Screen Shot 2013-05-02 at 2.20.13 PM.png

 

This makes the container (width of the page) fit 95% of the width of the device, instead of having a fixed width that would not fit all devices.

 

Break points


This is the magic of the Responsive Web Design. With break points you can declare specific CSS for specific dimensions. In the case of the Mobile Demo, I wanted the container to fit 95% of the screen for most of the cases. However, for smaller widths, I wanted it to occupy 100%, and for bigger widths, I wanted it to occupy 1170px as maximum. To do that, you just need to do declarations like these:

 

Screen Shot 2013-05-02 at 2.24.56 PM.png

Screen Shot 2013-05-02 at 2.24.22 PM.png

 

 

Conclusion

 

With this talk I wanted to show the design process that comes from the requirements until the HTML implementation. The full presentation can be seen at: http://www.slideshare.net/gabrielcardoso9/designing-a-new-user-interface-for-open-source-projects

 

GateIn was an excellent showcase, since its redesign followed the steps presented by Garrett in its diagram. Twitter Bootstrap provided nice UI components reduced significantly the time required to implement the solutions. Having applied the Responsive Web Design to the interface was exciting and made it look beautiful in many different devices.

 

I hope you have learnt something from this post. Stay tuned to the next GateIn releases. More design news are coming

bdaw

GateIn Portal 3.6.0.Beta01

Posted by bdaw Apr 8, 2013

We are proud to announce the first beta of GateIn Portal 3.6! Go to our downloads page right away and grab it while it is hot!

 

While GateIn Portal is downloading let me highlight few important improvements delivered in this release:

 

Site Redirects.

 

The core part of this feature has been released in GateIn Portal 3.5 few months ago. Now we ship the brand new Administration UI that let you configure redirection rules and specific conditions in an intuitive way

 


 

Public API

 

After many months of hard work we now provide a public API to deal with sites and navigations for both Java and REST.

 

Just check our Developer Guide:

https://docs.jboss.org/author/display/GTNPORTAL36/Portal+API

 

Mobile site demo

 

GateIn Portal now comes with a dedicated demo mobile site: when you access portal from your ios or android device you should get automatically redirected to the mobile site. This site provides an adaptive layout and adapts the portal screen to the most appropriate size for your device.

 

 

 

 

 

 

Touch enabled devices

 

The main portal page has been reworked to deliver better experience on mobile devices:  many minor improvements to the interface make GateIn Portal work better out of the box on touch enabled devices.

 

Future

 

We plan to release the second beta of GateIn 3.6 in May and it should provide a few other improvements that keep the team busy. You can track some of them with our specifications, just to point to two such features:

 

CDI support in portlets - https://community.jboss.org/wiki/CDISupportInGateInPC

OAuth2 support - https://community.jboss.org/wiki/GateInOAuth-AuthentificationWithSocialNetworkAccounts

 

Exceptionally we decided to stretch a bit our release schedule with those two beta releases, our goal being to deliver well tested and polished final release. You can expect the 3.6 final around July this summer and you will get the best GateIn Portal release ever!

julien_viet

GateIn 4.0

Posted by julien_viet Jan 23, 2013

GateIn 4.0

 

GateIn 3.0 was released almost 3 years ago as the result of the collaboration of the eXo Platform and Red Hat team. The team worked then on a serie of improvements for 3 years until the recent GateIn 3.5: the project improved and gained maturity among releases, specially with the recent 3.5 release. The main goal of GateIn 4.0 is to rework the portal engine: the current engine has aged enough for being replaced by a more modern engine for providing better everything.

 

This project is important to me: I left Red Hat for eXo Platform in 2008 and I was working on the future JBoss Portal 3.0 at this moment and I left some unfinished ideas. During the GateIn collaboration other ideas came, some were implemented in GateIn, some could not due to the architecture. 4.0 is for me the opportunity to work this out.

Juzu

 

The Juzu Web framework will be used for rebuilding the aggregation engine: a portal before all is a web application and the idea is to let Juzu focus on the web part and leave to the GateIn engine focus on being a set of controllers (in the MVC way) for aggregating content or editing it.

 

Juzu was started a year ago, it provides since version 0.6 a servlet mode that makes it able to deliver web applications in addition of portlet applications. Of course it embeds some part of GateIn already in it, for instance the Juzu route controller is an improvement of the route controller of GateIn.

 

Juzu relies on the JSR-330 specification for wiring components and provides therefore a standard programming model. It integrates with Annotation Processing for doing wonderful things with Java (yes we not planning to rewrite GateIn in another language).

 

The project

 

The main focus is to rewrite is the portal engine with the serving of portal pages based on a better model and the native portal applications: the page edition for example. The scope is well defined and is defined in the In Place Editing specification . It describes an evolution of the current GateIn model written by Benjamin Paillereau, his great work is the essence of the feedback provided by many customers, integrators and other users.

 

A key part of the technical aspect is the aggregation engine: it will be based on the big pipe technology for providing increased performances and better latency for page rendering. The portal will also push to the client the stale portlets: for example you define a cache timeout of 1 minute for a portlet will result in GateIn updating the portlet fragment every minute.

 

Beside this we are have other goals (not extensive)

 

  • Better usability and configuration for providing a better experience
  • 4.0 will give you the possiblity to embed GateIn with an in memory implementation that provides a fast and stateless portal for testing purposes
  • Rebase the skinning and layout on Twitter Bootstrap

The road

 

GateIn 4.0 will not be the next GateIn release right away, we have plans to provide additional GateIn 3.x releases that the team is currently working on. Nevertheless GateIn 4.0 development has started recently, you can follow the development on the gatein-dev mailing list "GateIn 4.0.0" thread. I bootstrapped this work a few weeks ago and I welcome anyone wanting to contribute to join us on the list.

 

Open source and open minded.

Filter Blog

By date:
By tag: