Help

Controls

PermLinkWikiLink

Built with Seam

You can find the full source code for this website in the Seam package in the directory /examples/wiki. It is licensed under the LGPL.

Forum: Seam Users Forum ListTopic List
19. Aug 2008, 12:15 CET | Link

I use Facelets and I have to solve some GUI-related things (such as datatable and the like) via JAVA-Code. So I use the binding-Attribute and I have to declare the Bean in faces-config.xml: 

<managed-bean>
<managed-bean-name>gui</managed-bean-name>
<managed-bean-class>com.GUI</managed-bean-class>
<managed-bean-scope>session</managed-bean-scope>
</managed-bean>

All works, but I have few questions:

- Is the dynamic generation of GUI via JAVA-Code slower than doing the same via Facelets (without binding)

- What is the session-scope, when I use this gui-component in a CONVERSATION-Scope? (session or conversation?)

- Is there a possibility to avoid the declaration in faces-config.xml, as I do want to manage the beans via SEAM and not via SEAM and via JSF.

- Are there general prinicpals bout generation UI via JAVA by using SEAM ( I do not use Wicket or GWT)

6 Replies:
20. Aug 2008, 15:04 CET | Link

In the SEAM-Reference it s said, that developing the GUI via JAVA-Code has one disadvantage:

We generally prefer not to use this feature of JSF unless absolutely necessary, since it creates a hard dependency from application logic to the view

In GWT or Wicket you develop the whole GUI under JAVA-Code..

20. Aug 2008, 16:00 CET | Link
Is the dynamic generation of GUI via JAVA-Code slower than doing the same via Facelets (without binding)

Dynamic generation in Java code will always be faster by some degree though not always as flexible in certain aspects.

What is the session-scope, when I use this gui-component in a CONVERSATION-Scope? (session or conversation?)

Can you rephrase the question, not following

Is there a possibility to avoid the declaration in faces-config.xml, as I do want to manage the beans via SEAM and not via SEAM and via JSF.

Not sure why you are defining them in the faces-config.xml to begin with, just annotate your pojo with @Name and it becomes a Seam component

Are there general prinicpals bout generation UI via JAVA by using SEAM ( I do not use Wicket or GWT)

You might be interested in: http://www.seamframework.org/Documentation/SeamDynamicCRUD

SEAM

Seam

Rating:  * * *
21. Aug 2008, 10:50 CET | Link

Hello Samuel,

thank you! That helps me a lot :-)

The one important thing is:

Dynamic generation in Java code will always be faster by some degree though not always as flexible in certain aspects.

Look at GWT or Wicket, ECHO or the impressive Framework jSEAMLESS (developing the view only in JAVA-Code (like SWING) )

Why they decided to use this way? Performance, better learning Curve for JAVA-Developers? MVC can also be adapted developing the view in JAVA-Code.

Well, the flexibility in order of changing and reusability of the view is higher using Tags instead of JAVA-Code.

21. Aug 2008, 15:51 CET | Link

Right, if JSF components were easier to write/maintain I would be using them most likely. I'm still waiting for JSF 2 and the annotation based approach of creating custom components. In the mean time, Facelets is extremely powerful in what it can accomplish.
21. Aug 2008, 20:27 CET | Link

Can I use the Mojarra preview release based on the JSF 2.0 EDR1 specification in SEAM ?

I want to begin a new EJB-Project and does not want to use the old things when I know, that JSF 2.0 has some pretty stuff like annotation based approach of creating custom components.

What do you think? I do not want to develop the view with JSF 1.2 knowing that soon all becomes easier and better. Are there other ways of building common UI-Components in JSF 2.0 in relation to JSF 1.2 ?

21. Aug 2008, 22:22 CET | Link

JSF 2 is a long ways off from being GA'd, so I wouldn't even bother with it. And, I haven't seen any integration yet with it and Seam though I'm sure some of the devs have done it or know how, if your feeling adventurous, go ahead.

Don't necessarily think of existing technology as already old and deprecated, the grass is always greener on the other side eh? Design code that is easily refactored and updatable, then you won't have to worry when you do want to upgrade.