JBossDeveloper

Hi,

We are starting a new ERP project based on JBoss 5.0.0 and Seam/JSF. Our main reasons for choosing this technology were:-

1. Open Source (our project also follows the JBoss model of Open Source and supported commercial products).
2. JBoss/JPA/Seam/Drools/jBPM/WebServices support. One of the challenges of an ERP system is how to allow it to be customised. At present we do not have RAD support but with Drools and jBPM allowing customisation of business processes and Seam/JSF allowing customising of backend code we have a reasonably good technology stack.
3. Seam support for conversations was a major reason for us to use Seam.
4. We choose not to use Wicket because although it made page design simpler, the page backend code became quite horrendous. We prefer using facelets and jsfc tags to allow our pages to be still designed by web designers.

Regards.

Robert,
could you tell me more about your experience in developing with Seam?

Because we started with GWT, but the performance was awful,
so we are planning to use Jboss Seam for developing ERP applications. But we don't really know whether is it worth it or not..

Also we will generate GUI code and EJBs using seam-gen. (We use an MDA approach)
Is there any detailed documentation about seam-gen? How could we extend it?

Thanks,
Ildi

Robert Burns wrote:


We choose not to use Wicket because although it made page design simpler, the page backend code became quite horrendous. We prefer using facelets and jsfc tags to allow our pages to be still designed by web designers.

From Wicket documentation: Wicket does not mix markup with Java code and adds no special syntax to your markup files. The worlds of HTML and Java are parallel and associated only by Wicket ids, which are attributes in HTML and Component properties in Java. Since Wicket HTML is just HTML and Wicket Java is just Java, coders and designers can work independently to a large degree and without relying on any special tools.

I haven't really tried wicket but from what I have read and seen their site they seem to be more designer friendly than facelets. Can you explain why do you think it is not true?

I have heavily modified seam-gen, and I think an MDA based approach using seam-gen has a lot of potential, but I have not seen a lot of interest from the community in following that approach.

I believe that seam-gen could become something much better than NakedObjects or JMatter, but sadly right now, there is really no documentation on how to extend seam-gen, support for Freemarker (the templating engine of seam-gen) is not one of the primary concerns of the Jboss Tools project, and the seam-gen generated applications do not really take advantage of what seam or richfaces can do to make good UIs.

And please don't misunderstand me, I think it is great that Seam has an utility like seam-gen, and I love the job that the JBoss Tools project is doing, if neither of them pays more attention to seam-gen or freemarker I think it is because the developer community is not requesting more enhancements related to them.

So, if you want to see a better seam-gen, please use JIRA to ask for more seam-gen related features. (Or code them yourself and donate them to the project... I hope I had time to that)

I am sure that seam-gen could be improved to generate an application like this one.

Facelets is a pain when coming to UI generalization. From the first glance it seems very very attractive - all its templating capabilities are just what you have been looking for.
But soon you will fill the difference between tag and component handlers (you probably got to know when reading the manual, but didn't feel like a pain). And when you realize that they can't be mixed with each other due to different contexts they are evaluated in you will wish to escape Facelets.

The problem is I don't know the alternative. Probably Wicket.

Vladimir Kovalyuk wrote on Jan 30, 2009 10:45:


Facelets is a pain when coming to UI generalization. From the first glance it seems very very attractive - all its templating capabilities are just what you have been looking for.
But soon you will fill the difference between tag and component handlers (you probably got to know when reading the manual, but didn't feel like a pain). And when you realize that they can't be mixed with each other due to different contexts they are evaluated in you will wish to escape Facelets.

The problem is I don't know the alternative. Probably Wicket.

Can you please elaborate and give an example of where this causes problems. To date I have not come across this issue.

Regards.

1. Some page consists of rich:tabPanel with several content within tabs.

2. Some of tabs consist of DataTable, which is built by currently applied configuration of CustomizedView object. The latter describes which column and in which order are displayed to the user, defines filters for underlaying data and defines sorting modes. CustomizedView instances are kept in database with their names and definition, there are several system-wide CustomizedViews and user can define his/her own.

3. The values are displayed indirectly using editors/viewers inclusions.

<rich:tabPanel>
   <c:forEach var="tab" items="#{backingBean.tabs}">
      <rich:dataTable var="item" value="#{backingBean.viewData[tab]}">
          <rich:columns var="column" value="#{backingBean.view[tab].columns}">
              <f:facet name="header">#{model.getLabel(column)}</f:facet>
              <ui:include src="/editors/#{model.getPropertyEditor(column)}.xhtml" />
          </rich:columns>
      </rich:dataTable>
   </c:forEach>
</rich:tabPanel>

rich:tabPanel is just an example and can be replaced with any other compound component.

Robert, I will be happy if you show me where I'm mistaken 'cause I really want to benefit from that sort of markup and find it impossible up to now. In this example at least impossible to evaluate #{model.getPropertyEditor(column)} 'cause column evaluates to null.

I tried to discuss this with JSF commitee, Jacob Hookom and Gavin King but didn't obtain any reply.

The problem Vladimir Kovalyuk is writing about has nothing to do with the EL expresion, the problem, as Vladmir stated is the difference between tag and component handlers.