View Full Version : Best Practise for Writing an Application

12-16-2005, 05:01 AM

what would you recommend as best practise for writing an application based on pentaho?

From what I see there are three choices for the database layer:
- EJB 2.1
- EJB 3.0
- Hibernate
of which I guess EJB 3.0 or Hibernate would be the choice, right?

For the front-end I see these options:
-XSLT (I see Pentaho is using this)

And for the business logic?

What would be the best choice for writing database-driven Portlets for Pentaho and which front-end technology do you recommend?


12-20-2005, 10:29 AM
I also found a project called seam at jboss that uses java server faces. Any experience with that in pentaho?

12-21-2005, 11:01 AM
1. Database
We use Hibernate for storing Java objects into our repositories. This should be transparent to you. If you have your own objects to store then you will gain some configuration and deployment time if you use Hibernate because we have done that part already. For data that you wish to use in reports and dashboards etc you can use any database that has a JDBC driver.

2. User Interface
Pentaho supports JSPs, Servlets and Portlets for displaying user interfaces to users. All of our UI components generate XML and we provide XSLs that create HTML from the XML. You can use the XML to generate a user interface if you want or you can modify the XSLs if the default ones do not suit your needs.

3. Business Logic
You can use Javascript rules, SQL rules, XQuery rules, custom Java rules and workflow (XPDL). We recommend:
* Using the SQL rule for getting selection lists and user-specific selection/filter lists from databases
* Using the Javascript rule for small, global selection lists and user-interface logic
* Using the XQuery rules for getting information back from web services
* Using XPDL to define workflow that includes parallel flows, conditional branches, time-based escalations etc.
* Using custom Java rules (create your own org.pentaho.component.ComponentBase subclass if the above do not solve your needs.

4. Database driven Portlets
SQL rules and the Pentaho Portlets (create new subclasses of org.pentaho.ui.portlet.ViewPortlet if you need). You can use org.pentaho.ui.portlet.ActionPortlet to place a report parameter page in a portlet.


12-22-2005, 09:18 AM
James: thank you for your reply.

I just wonder if XSL doesn't become a performance issues for large sites though I feel very comfortable with XSL even though it is very verbose.

Coming from a scripting language background I find Java-based web development cumbersome. The development cycle is much longer but I have not looked close enough on the difference MVC projects.

On the database level am I correct to say that Hibernate is more favourable compared to EJB3?

Do you use any tag library for standard elements like buttons, lists, tables, forums...

I have found some work on that in gridsphere and Salmon Open Framework for Internet Applications (SOFIA).

Also..can I integrate existing servlets or JSPs into a portlet?

01-04-2006, 10:33 AM
We support web-based, standalone, and embedded deployments. It is difficult to select a single UI framework that can easily be embedded into all other frameworks, as they tend to be incompatible with each other. In order to support embedding and non-Java usage we generate user interfaces as XML and let the caller decide whether to use the XML or to take the HTML that our XSLs generate. The caller is free to use another technology or framework to generate a UI from the XML. XSL is also a non-Java-specific W3C standard.

The scripting languages are good for quick web site development, but no so good for desktop and mobile deployments.

I can't answer your Hibernate vs EJB3 question as there are many factors that depend on your requirements. If you are talking about data storage and not java object persistance I would recommend neither of these and use a relational data-warehouse/data-mart instead.

We do not use tag libraries as they are technology-specific. We use xform internally for UI controls.

I don't think you can integrate a servlet into a portlet (a portlet is the Portal equivalent of a servlet) but you can usually easily convert a servlet or JSP to a portlet. There is a mechanims for calling JSPs from portlets but we don't use it as it behaves differently in different portals and so is not very portable.