Discussions

News: Article: The eXo Platform Reloaded

  1. Article: The eXo Platform Reloaded (22 messages)

    The eXo Platform continues to stride on with 1.0 RC1. This article shows how to integrate with enterprise intranet components, such as portal and content management systems, and how to refactor and test the platform to suit a community's requirements.

    Read The eXo Platform Reloaded

    Threaded Messages (22)

  2. Hi Nithin, Dion, and all TSS fans,

    We have have just released RC2 that includes bug fixes but also a support for multi company portal instances per application server (required for hosting solutions).

    Thx,

    Benjamin
    http://www.exoplatform.com
  3. We have have just released RC2 that includes bug fixes but also a support for multi company portal instances per application server (required for hosting solutions).
    Does this mean that I could run eXo express in a webapp without having access to the servlet container configuration? If so could you point me to some docs on how to achieve this?
  4. We have have just released RC2 that includes bug fixes but also a support for multi company portal instances per application server (required for hosting solutions).
    This means that you can define several portal war like company1.war and company2.war in the same application server (works for express and enterprise).

    Then the first one is reached with http://host/company1/... and the second one is http://host/company1/...

    Each company has its own datasources (ie database) but can still share services that have no state (aka portlet container...).

    In other words you can host many independant company portal on the same box to optimize hosting costs.
    Does this mean that I could run eXo express in a webapp without having access to the servlet container configuration? If so could you point me to some docs on how to achieve this?
    The portlet still need to be deployed as their own WAR. The company portals are deployed as WARs but they still share the portlets (it is up to the admin of each portal to choose which portlet instance to add in the portlet registery to be seen by companies' portal users).
  5. The company portals are deployed as WARs but they still share the portlets (it is up to the admin of each portal to choose which portlet instance to add in the portlet registery to be seen by companies' portal users).
    Our host solution works like this:
    We have the posibility to deploy one war. We have full control over that war. Other than that we have no priviledges, so we can't change the servlet container configuration in any way. I would imagine this is a quite normal situation for people buying services from java enabled web-hotels.

    So my question is: Is it possible for me to configure and run the eXo platform embedden in my webapp?
  6. No it is no possible and no portal will work that way as each portlet must have its own WAR.

    Our solution is to ease an hosting service in his choice to provide portal hosting service. So indeed, the hosting vendor has to install the portal in tomcat (for example). But once done, then only a WAR per hosted customer (the portal.war one) can be added.

    Benjamin
  7. aprove function[ Go to top ]

    Hi,
    Is there any aprovement functions in exo? For example, if a page is edit, then need another one to approve it, otherwise it can't be available to visitors of this portal.

    any advice is welcome.
    If not, can any other cms has such a question?
    thx a lot.

    brian
  8. There is some portal basic configuration in our wiki page
  9. Article: The eXo Platform Reloaded[ Go to top ]

    We had a different approach in our portal/CMS. Instead of having to write XML for the templates we did a WYSIWYG GUI with drag&drop and Swing dialogs to customize it. That way anyone (e.g. non-technical administrators) can do templates, and building a website, templatewise, can usually be done in a day or two, and all work is done through the browser.

    Using a technical approach to configuring a portal may be nice for OpenSource variants where consultant hours are the main source of income, but one of the main reasons our customers like our stuff is because they can administer and use it without having to call us for every small change. Better for us and better for them.
  10. Article: The eXo Platform Reloaded[ Go to top ]

    A couple of years ago you held a session at the Norwegian Userforum Javabin, and I agree - SiteVision really got strong WYSIWYG features. I guess that product is even stronger today ;)

    We beleive our page customerizer is flexible too. You can compose each page in a simple manner. The ability to build your site structures toolwise will come in future versions. However the content portlet now offers WYSIWYG HTML editing of content, with Java Content Repository (JSR-170) as backend.
  11. Rickard, have you tried our platform layout WYSIWYG tool?

    We do have a WYSIWYG editor to create the site layout, the XML is just there to persist the structure (we showed the XML in tha article as the readers wants to know how it is working and not how it can use it in detail :) ).

    As we are NOT using any kind of prefixed templates like in any other portals but that we use JSF trees, our layout mechanism is probably one of the most powerfull of the market, indeed any type of HTML layout can be build with our WYSIWYG tool.

    Finally, you can build an entire web site build on eXo Platform with page tree hierarchy and several layouts for portal pages without a single line of Java nor as single line of HTML. Only css manipulation and use of our WYSIWYG tool. And yes that can be done in one day or too.

    So I don't see why you claim you have a different approach?
  12. Rickard, have you tried our platform layout WYSIWYG tool?
    Nope, and I can't seem to find it. Got link?
  13. Sure,

    once you are login in the platform (you can register on http://www.exoplatform.com site) you will see our 3 admin modes as explained in the article : Portal Edit Mode, Navigation Edit mode and Page edit mode in the left navigation menu.

    Each mode is a WYSIWYG editor (no applet) to manage the layout of the portal pages or the global Portal page (banner, footer, menus and other portlets you wish to see on all pages).

    Note that you have screenshots of those modes in the article.
  14. Sure, once you are login in the platform (you can register on http://www.exoplatform.com site) you will see our 3 admin modes as explained in the article : Portal Edit Mode, Navigation Edit mode and Page edit mode in the left navigation menu. Each mode is a WYSIWYG editor (no applet) to manage the layout of the portal pages or the global Portal page (banner, footer, menus and other portlets you wish to see on all pages).Note that you have screenshots of those modes in the article.
    Duh, I should've read the article a little better 8-) So, the page edit mode is definitely better than having to code XML, although it seems a little simplistic (depending on what you compare with though). But it's still lots better than what most other portals can do I suppose.
  15. Rickard,

    I appreciate your honnesty :) most competitor would have hidden that fact.

    What do you mean by simplistic?

    So far we compared our portal layout mechanism with many other one from IBM Websphere portal, Liferay, Jetspeed... and, as they all are based on static template mechanism, none of them are as much flexible as our mechanism. In fact the closest solution would be Microsoft Sharepoint portal but it's not Java :)

    Note that I have not tested your product myself so I can not compare it with our. I just heard you are using velocity for templating which makes me wonder how you can provide Swing likes tree of UI components (like JSF) that would allow the creation of any type of HTML layout...or maybe you geberate the velocity templates from your WYSIWYG tool :)

    Regards,

    Benjamin
  16. Rickard,I appreciate your honnesty :) most competitor would have hidden that fact.
    Credit where credit is due :-) The fact that you use Pico all over the place is worth loads of credit as well :-)
    What do you mean by simplistic?So far we compared our portal layout mechanism with many other one from IBM Websphere portal, Liferay, Jetspeed... and, as they all are based on static template mechanism, none of them are as much flexible as our mechanism. In fact the closest solution would be Microsoft Sharepoint portal but it's not Java :)Note that I have not tested your product myself so I can not compare it with our. I just heard you are using velocity for templating which makes me wonder how you can provide Swing likes tree of UI components (like JSF) that would allow the creation of any type of HTML layout...or maybe you geberate the velocity templates from your WYSIWYG tool :)Regards,Benjamin
    Well, you are right that all of the portals you mention are *even more* simplistic. Absolutely terrible, even, in terms of template management. Our UI is based on applets+HTML/DOM+Javascript, which gives us the power of Java for UI (and once you learn the ins 'n outs of Swing it really works well) combined with the WYSIWYG of straight HTML/DOM manipulation.

    One of the differences between your and our approach, is that in our model the page *might* be a tree. I.e. all portlets/layouts uses relative positioning and CSS to make sure everything looks good. However, relative positioning is rather difficult to get right for most users, so we also support absolute positioning. In this mode you just drag a portlet onto the page and move it to where you want it to be. And there it stays. This way you can easily build a page just by "putting stuff on the page", without having to bother with "trees" or "structures" or whatnot. The majority of our customers would not understand what a "tree" is, the way we talk about it. They just want "a menu to the left, a logo at the top, and content in the middle". So we support that as well. Plus, we support the combination (which I think is often the best solution), which is to use absolute positioning of layouts which use relative positioning internally. That way you get the best of both worlds.

    I've uploaded a screenshot of our edit mode here:
    http://www.senselogic.se/webdav/files/rickard/sitevision.png
    This website (apart from being in Swedish) uses only relative positioning.

    That, together with lots of CSS for decorations and borders, makes it easy to not only create but also maintain pages, and without having to know anything about CSS or HTML or XML or DOM (etc.). We also support styles and colors as first class concepts, which means that anywhere you can select a color you can do so from a list, and if you then change that color "object" in the site administration it will change everywhere you used that color. This also makes it easy to create and maintain a graphical profile. But then you get more into CMS type features, and this is where it gets interesting. IMHO a portal should be a CMS, and a CMS should be a portal. exo does that to some degree, but it is still more of a "CMS integrated into portal" instead of being a first class function of the software.

    I could go on and on about this, but I'll stop here.
  17. The fact that you use Pico all over the place is worth loads of credit as well :-)
    I saw on pico mailing list that you were also using pico....good choice ;)
    One of the differences between your and our approach, is that in our model the page *might* be a tree. I.e. all portlets/layouts uses relative positioning and CSS to make sure everything looks good. However, relative positioning is rather difficult to get right for most users, so we also support absolute positioning. In this mode you just drag a portlet onto the page and move it to where you want it to be. And there it stays. This way you can easily build a page just by "putting stuff on the page", without having to bother with "trees" or "structures" or whatnot. The majority of our customers would not understand what a "tree" is, the way we talk about it. They just want "a menu to the left, a logo at the top, and content in the middle". So we support that as well. Plus, we support the combination (which I think is often the best solution), which is to use absolute positioning of layouts which use relative positioning internally. That way you get the best of both worlds.


    Well you are right, in fact supporting absolute position of containers (concept described in the article) in the owner-config.xml would be quite simple. Nevertheless, it would be of no interest if not used with a drag and drop tool that would be able to get the coordonate of the portlet or relative blocks you add. You solve this problem by using an applet; this is a decision we avoided from the very begining as our previous experienced with applets were not that good (maybe yours were better :) ). So we were thinking more of a rich client (to be bundled with our eclipse plugin) to build those portal pages including absolute position of blocks. That would be used as a remote tool to provide more feature than our web only WYSIWYG editor.
    That, together with lots of CSS for decorations and borders, makes it easy to not only create but also maintain pages, and without having to know anything about CSS or HTML or XML or DOM (etc.).
    Same stuff here, I guess our approach with as much as CSS as possible is quite similar. From the WYSIWYG editor it is possible to pick the associated style and the entire look of your container will change.
    We also support styles and colors as first class concepts, which means that anywhere you can select a color you can do so from a list, and if you then change that color "object" in the site administration it will change everywhere you used that color.
    In fact what you call first class concepts is what we call "style" and styles are object that are tied to containers in the XML (and can be changed using the WYSIWYG editor). Then those styles can be either referenced or inherited by sub containers and portlets of the page. If the value of the style change then all the object that references it will change too.
    IMHO a portal should be a CMS, and a CMS should be a portal.
    We totally agree and JSR 168 / 170 are at the center of our development strategy. As soon as we get the JSR 170 certification we will unify the core parts of the platform...that will come with many new ideas :)

    Benjamin
  18. Great jobs,exo teams[ Go to top ]

    I'm a Chinese graduate student and build our university's students portal for our school's netcenter,there are more than 2000 user will use it.Formly we bases our portal on jetspeed 1.4,but when it came to jsr168,we try to use some other portal,after review liferay,uPortal and some other portal promised to support jsr168,we finally turn to exo for its brand new structure and technologies,we use it integrated with the CAS for SSO,and integrated many other webapps like webmail etc. It's more stable now,and we'll still build a OA portal based on it.
    Thanks for your great works!
  19. Article: The eXo Platform Reloaded[ Go to top ]

    I'm student and have a training period in a telecom company.
    Our goal is to make a mobile portal prototype (to use on WAP2 devices).
    So we made a criteria list :
    - feasibility of having any XML based language for rendering format (XHTMLMP in my case)
    - features of administration tools (easy to use ?)
    - possibility to let the user have its own personalizable zone (to let him add its own portlets)
    - localization (multilanguage)
    - state of product (in developement, stable release, ...)
    - jsr-168 support
    and studied various OS java portals :
    - Jetspeed 1 & 2
    - Gridsphere
    - Cocoon Portal
    - Liferay
    - eXo
    We finally chose eXo. It's "all portlets made" architecture, extended use
    of jsf, wsrp support, easy layout management, ..., hold our attention.
    We actually trying to refactor portal code to have xhtmlmp renderers for portal base components, and i have to say that it is a real pleasure to collaborate with eXo developpers team which help us as much as they can.
  20. Article: The eXo Platform Reloaded[ Go to top ]

    hi,
    it near four month ago, I have to found a portal solution for our compagny and our customers. Our compagny developed web application in human ressouces, financial workflow, ... and have a portal product with some lacks for our customers demand.
    So I have to choose a Java solution and I select :
      - jetspeed (1 & 2)
      - Jahia
      - Liferay
      - Exo
    The exo team quikly integrate new technologies as JSF, new normalizes like JSR 168. In spite of other team, exo team show us a good activity of there project.
    We are first afraid by the lack of documentation but we appreciate a lot the reactivity of this team on the forum or email.
    Actualy I made a bridge beetween exo and our existing portal build on "Lutece" a project developed by the town of Paris. The source code organisation of this project permit me to do it in four day. Now all the portlet developed on "Osismi" work on exo without any change of code. Thanks to the multiproject organisation of exo, I do in one week what I plan to do in one month.
    There is a lot of really good thing in this project like the layout (a lack of Liferay for example), the content management which is based on JCR - JSR 170(a lack of our portwal), the framework exo base on JSF technology, the eclipse plugin to developped portlet (I really love this plugin), and the other good things ...
    I just add that I follow Francois when he say : " it is a real pleasure to collaborate with eXo developpers team ". Thanks to this team witch help me to make my firts steps on exo and continue to guide me when I have a problem.
    Wanig
  21. Documentation is in the place !![ Go to top ]

    Hi all,
    I wan't to notifie that the documentation in Exo is now excelent. The team integrate xWiki as a portlet in the portal. Thez done a real good documentation. There is all everyone need to use exo. There is user, admin and developper guide.
    This doc is not yet complete but there is allready all point to start with exo, and more. The team choose to let everybody edit this documentation, so if everyone give there experience this will be complete faster and better. So I withdraw what I say on the documentation.
    Thanks to the team for this doc.
    Wanig
  22. eXo - A good choice[ Go to top ]

    What a great article! eXo has progressed a long way from when we first made our decision to use eXo. We're pretty happy with our decsion.

    Our architects at ComFrame (www.comframe.com) spent a lot of time evaluating platforms for building Java web applications. We selected eXo based because of its architecture, commitment to standards and the project team.

    Having the architecture based upon services connected via an IoC framework was important. This would allow the product to develop cleanly. It would also enable us to customize the platform to suit our needs. Since it is impossible to know future requirements a solution that is composed of replaceable services was probably the biggest reason to select eXo.

    Another big reason for selecting eXo was their commitment to supporting standards. They were the leader with JSR-168. They were the leader with JSF. They are the leader with JSR-170. This level of commitment makes developing our better solutions faster.

    Finally, I must compliment the eXo project team, especially Benjamin and Tuan. The team has been very accessible and helpful. They have incorporated features into the framework that we felt were critical to our success. The velocity at which the platform has progressed has been impressive.

    eXo has been a good choice!
  23. I'm a Software Engineer for large government contractor. We have a collaborative solution which is comprised of the tight coupling between a Portal, Document Management Solution, Synchronous Collaboration tools (chat, group chat, whiteboarding, etc..), and Asynchronous Collaboration tools (like email). These tools combined form a powerful environment for our customer to collaborate internally and externally. To better enable the external collaboration to take place it was decided early on that all parts of the solution needed to be based on open standards (preferably with opensource implementations). This way we could deploy with a very low upfront implementation cost and folks could select from an array of interoperable products depending on their own requirements.

    When it came time to select a portal we evaluated Jetspeed 1.4, Liferay, GridSphere, and eXo. At the time only eXo was certified JSR-168 compliant, so our choice was easy. eXo's standards compliance, service oriented architecture, security infrastructure, and powerful layout engine have been critical for us and our solution. Another strong point behind eXo is the people behind the product; they are very responsive to all questions, comments, criticisms, ideas, etc...