Design validation (Spring+JSR 168 Portlets+iBATIS)

[uenluena]

Hello everyone,

Im currently working on a Websphere Portal project, where i evaluated the possibility to use spring + ibatis for the current scenario:

- For the time being our main goal is to write a framework that can handle a e-form solution (IBM Lotus Forms) where the product gives the possibility to do XForm Submissions. In general the product is producing a XML-Fragment that needs to be processed.

-The processing is done inside a portlet method where a service object gets the needed data by DAO's and construct the domain objects based on business logic implemented in the service object.

My DAO's are as thin as:

 public ITemplate getTemplate(Template tpl) {
        getSqlMapClientTemplate().queryForObject(GET_TEMPLATE, tpl);
        return tpl;
    }

The unit tests for the DAO layer use a nonJNDI datasource definition and look like

	public void testDataLoad() {
		ITemplate tpl = new Template();
		tpl.setIdentifier("FORM_22");
		ITemplateDAO tplDAO = (TemplateDAO) ContextHelper.getInstance().getBean(
				"templateDAO");
		ITemplate tplReturn = tplDAO.getTemplate(tpl);
		logger.log(Level.INFO,tpl.toString());
		assertEquals(tplReturn.getFilename(), "form22v8.xfdl");
	}

My question is more about the general setup and the service layer in general. Do you think its a good approach to do the following layering:

View: JSF
Controller: Portlet
Service Layer: service objects with logic
DAO: simple CRUD operations
ORM: ibatis
DB: Oracle

I dont intend to use the MVC module of Spring.

What do you think about the setup? Any kind of comments or remarks are welcome.

[sandrews]

JSF in a portlet environment is an interesting use case that unfortunately is not yet fully baked. Have you used JSF + portlets before? I'm interested in your experiences.

The 2.0 release of Spring Web Flow adds significant support for JSF. In the distribution is an experimental sample app, booking-portlet-faces, that uses JSF in a portlet. You will need a JSR-301 portlet bridge in order to get the app running. I'm not aware of a fully working bridge, hence the experimental state.

-Scott

[uenluena]

No, i have actually no experience with JSF + Portlets and thats why we're in the process to do some prototypes to validate our concept. We went into the prototyping as there are some frameworks/technologies that we never used before (JSF+Spring)

[uenluena]

does noone else have any comments? I would really appreciate any kind of comments to avoid any wrong paths that i could take...as im new to spring, some approval from experienced users would help me a lot

[spiff]

We have been using IBM's JSF implementation with Websphere Portal 6.0 for the last 4 months and it's been far from satisfactory.

. It's a JSF 1.0 implementation, so you can forget about the latest improvements (1.2 is the latest version, 2.0 should be out soon) or using libraries such as Tomahawk that require JSF 1.1+.
. IBM's "enhanced" JSF tags (the hx tags) have many issues. Many times we had to resort to using the standard tags because the hx tag would behave incorrectly. We also ran into bugs when using multiple JSF portlets in the same page.
. IBM's portlet bridge doesn't handle portlet mode change very well, so we had to extend the base FacesPortlet and hardcode some of these changes.
. JSF tags have their own HTML renderers so you don't have full control over the generated HTML code. This might not be a problem for you, but it gave headaches to our web designers who had to redo some style sheets and work around more issues.
. I have found JSF beans harder to unit test.

That being said, we solved or worked around these problems and our portlets are running fine now, so this combination works. However if we had to do it all over again, I would go with Spring Portlet MVC.

Cheers,
GB

[uenluena]

Thanks for your valuable feedback :-)

We intended to use standard JSR168 Portlets and not the IBM extension of it as they will soon stop to support it and direct everyone to the standard implementation in their developer works articles.

We also have no plans to use the IBM JSF implementations but much more the standard SUN implementation.

I will check the possibility and the benefits of using Spring Portlet MVC. Any feedback according this would greatly appreciated.

[spiff]

Yes of course stay away from the IBM portlet API. We didn't investigate using another JSF implementation as we just used the one that came bundled with the IDE (IBM Rational Application Developer 7). Big mistake. If you insist on using JSF, investigate whether you could use a later Sun RI or MyFaces with the IBM portlet bridge or another one.

As for Spring Portlet MVC, I did a quick prototype with it and it worked fine. If you ever developed with Spring Web MVC then you should feel quite at ease with it. Contrary to the JSF portlet bridge, Spring Portlet MVC doesn't hide the distinction between the action and render phases. It's up to you to decide if that's a benefit or an inconvenient.

Cheers,
GB