Discussion and advice on GUI technology..

[aayush]

Hi guys,
i would like to invite a discussion and expert advice on what is the
best technology for developing server side GUI components.

The oprions are..
1. JSP..Servlets.
2. JSF with richfaces
3. Google Web Toolkit.

Trackback to related discussion here........
http://groups.google.com/group/whitelassi/browse_thread/thread/ad013ec39a12f726

aayush.

[Kamal]

Hi Aayush,

I would strongly advise not to go with Jsp..Servlet or JSF. If you
are thinking of a rich UI GWT is a good option, though it might pose
some challenges in the interaction between UI design & development.
If it is a normal web application I would suggest going with Strust
2.0 or Spring MVC (I personally prefer Struts 2.0).

If you really want to use JSF - then better go with Jboss Seam.

Grails is another option I would seriously consider if it is not a
very large project. It is based on all on very mature core
(Hibernate, Spring) and also makes it easy to get started & develop
applications more productively. The maintainability aspect is still
to be proven - with larger applications / larger teams the dynamic
nature might cause problems. Another thing in favor of grails is the
availability of plugins - a lot of common features (authentication /
authorization, exposing rss feeds etc) can be easily added to your
application with very less effort.


Regards,
Kamal

> Trackback to related discussion here........http://groups.google.com/group/whitelassi/browse_thread/thread/ad013e...
>
> aayush.

[Chandru]

Compared to GWT, I generally prefer JSF + Richfaces.  Mainly due ease of development and better integration with other Java technologies.  Richfaces especially has some really awesome components (for example, Paint2D which comes very handy in our own project) and can add AJAX support to other JSF components.

--
Chandra Sekar.S

Blog: http://tuxychandru.blogspot.com/

[Abhilshit Soni]

I agree with Chandru on that part , JSF + Richfaces is the best choice for server side GUI. Richfaces really has some awesome components  and optimized AJAX request handling, also in their latest version they have come up with two awesome components

1.  <a4j:queue>   which optimizes ajax request handling . It helps  eliminating the possibility of collisions when several JSF requests pass the JSF lifecycle at the same time. The queue prevents sending such requests. Only one request is processed. The rest ones are waiting which helps reducing the traffic between browser and the server. It can also identify "similar" requests coming in within 'requestDelay' and absorb the same which in turn reduces the server load.
Inshort the queue will help you optimize your Ajax requests traffic and reduce server load.

2. <rich:editor>  which is an adaptation of TinyMCE WYSIWYG editor for JSF applications.

as a second choice I would prefer  JSP and Servlet combo over GWT  although GWT offers you more or less Swing like development and event handling
but it actually converts all your JAVA code to JavaScript but one strong reason why I wont go for GWT is

1. Not all the standard Java libraries are supported by GWT. For example, only java.lang and a part of java.util are supported by the GWT tools, which means the code written using Java libraries not supported by GWT cannot be translated by the GWT tools. The developer needs to make a call whether to achieve the desired functionality by writing custom Java code or by writing the code in Javascript.

Regards

Abhilshit Soni
MYBlog

[aayush]

Thanks for all the valuable inputs to the discussion.
JSF seems to be the way...especially after the Excadel demo. The
presentation tier has been decoupled from the implementation, that
makes JSF extremely tolerant to change and customization...

Thanks
aayush

On Jan 23, 11:24 am, Abhilshit Soni <abhi....@gmail.com> wrote:
> I agree with Chandru on that part , JSF + Richfaces is the best choice for
> server side GUI. Richfaces really has some awesome components and optimized
> AJAX request handling, also in their latest version they have come up with
> two awesome components
>
> 1. <a4j:queue>

> <http://livedemo.exadel.com/richfaces-demo/richfaces/queue.jsf> which

> optimizes ajax request handling . It helps eliminating the possibility of
> collisions when several JSF requests pass the JSF lifecycle at the same
> time. The queue prevents sending such requests. Only one request is
> processed. The rest ones are waiting which helps reducing the traffic
> between browser and the server. It can also identify "similar" requests
> coming in within 'requestDelay' and absorb the same which in turn reduces
> the server load.
> Inshort the queue will help you optimize your Ajax requests traffic and
> reduce server load.
>

> 2. <rich:editor><http://livedemo.exadel.com/richfaces-demo/richfaces/editor.jsf>

> which is an adaptation of TinyMCE WYSIWYG editor for JSF applications.
>
> as a second choice I would prefer JSP and Servlet combo over GWT although
> GWT offers you more or less Swing like development and event handling
> but it actually converts all your JAVA code to JavaScript but one strong
> reason why I wont go for GWT is
>
> 1. Not all the standard Java libraries are supported by GWT. For example,
> only java.lang and a part of java.util are supported by the GWT tools, which
> means the code written using Java libraries not supported by GWT cannot be
> translated by the GWT tools. The developer needs to make a call whether to
> achieve the desired functionality by writing custom Java code or by writing
> the code in Javascript.
>
> Regards
>
> Abhilshit Soni

> MYBlog <http://www.thegreatriaratrace.blogspot.com>

>
> ---------- Forwarded message ----------
> From: Chandru <chandru...@gmail.com>
> Date: Thu, Jan 22, 2009 at 10:24 PM
> Subject: [BOJUG] Re: Discussion and advice on GUI technology..
> To: bo...@googlegroups.com
>
> Compared to GWT, I generally prefer JSF + Richfaces. Mainly due ease of
> development and better integration with other Java technologies. Richfaces
> especially has some really awesome components (for example, Paint2D which
> comes very handy in our own project) and can add AJAX support to other JSF
> components.
>

[Kamal]

This is a link to an article by Bob lee comparing GWT with JSF - one
of the main contributors to Webworks / Sturts2 and the author of
Guice. This is a bit dated but the argument still holds. Be sure to
read the disclaimer at the end of the article :-)
http://crazybob.org/2006/05/javaone-google-web-toolkit-vs-jsf.html
"For the majority of intents and purposes, GWT invalidates JSF. Both
frameworks seek to isolate web developers from HTTP, but due to the
fact that Google built GWT from the ground up with AJAX in mind, GWT
offers a cleaner abstraction, better type safety, and a lower learning
curve. When it comes to AJAX and JSF, you're at the mercy of which
functionality your JSF components offer. You must write anything
beyond that (including your business logic) in Javascript. With GWT,
you can stick to 100% Java."

You might also find this article interesting
http://wisdomofganesh.blogspot.com/2007/10/life-above-service-tier.html
It talks about the challenges in building rich applications with the
traditional serverside MVC frameworks like Struts / JSF etc and why
things like GWT / Flex is probably a much better option.

I agree that the base GWT package lacks support for certain features
like Validation etc. But the model makes it easy to expose a
javascript library as a GWT component.
Take a look at
http://code.google.com/p/gwt-ext/
http://code.google.com/p/smartgwt/
for an example.

I have not worked on Richfaces, but I have used JSF (myfaces) in a
couple of applications.
I have also built a fairly complex UI application (a subset of Google
Calendar) using GWT. Based on those two experiences I would vouch for
using GWT for building rich applications.

The argument that GWT doesn't support all Java classes is not a strong
one. This limitation is for only the client side development - the
classes they already support is good enough for most cases. There is
also a mechanism for people to add support for more java classes if
needed.

Building serious web applications with just JSP & Servlets today is
really like going back to the stone ages. They form a good (maybe
not so good - but that is what we have) infrastructure on which
frameworks can be built. You are better off with using a ny framework
(just automatic data binding is a good enough reason for learning a
framework).

Regards,
Kamal

[Ranganath s]

I think the JSF , ICEFACES, Richfaces are any day better than GWT.

-Ranganath.S

--
I blog at http://ranganaths.wordpress.com

[aayush]

Interesting links Kamal...especially the first one. I also liked the
comments of that blog post.

Let me outline my requirements for the GUI specific to my
application....

1. I own an open source project that builds telecom server side
applications built in SIP/DIAMETER and meant to work in a VoIP and IMS
environment.

2. I wish to create a self help provisioning and configuration GUI
where the end user can log in and configure his services.

3. As a result of such configurations, the user's configurations will
be stored in xml form in a xml file management server (one of my open
source components) which connects to a database of its own.

4. The user may modify/update his preferences on the GUI, which will
again be reflected in the server as an updated xml document.

5. Moreover, the provisioning GUI will also
connect to a dedicated database of its own, for storing user specific
data.

Thus, as you can see, the GUI will act as a front end to the user for
providing configuration options. All the call control business logic
will be implemented on the server based on these configurations.
Server side work is ongoing as of today.

I am at a requirements gathering stage as of now for the GUI, so your
inputs/possible contributions are welcome and valuable.

aayush.

[Kamal]

From the description it doesn't look like you need a rich interface,
unless the configurations are complex and very involved and have to be
modified on a regular basis. I would advise going with struts 2 or
spring mvc. May be can have a detailed discussion off line. You will
also consider the expertise you already posses. Unless there is a
real need it is always better to go with something you already know
rather than trying to learn a new way of doing things.

I realized that I haven't give reasons for my advise against using JSF
- just stating an opinion or preference without providing the reasons
for it doesn't really help. So here they are -
- too much of XML configuration
- very steep learning curve (if you really want to understand how
things work - rather than just putting together an application using
wizards and once you start with JSF you will sooner or later be
required to understand to debug issues :-))
- I had a hard time trying to make a simple thing like a data table
work without having to resort to defining a bean as session scope -
debugging it was more painful. Going with session scope resulted in
so many other issues.
- If you use jsp's and not facelets as the view then you can't use
regular html tags - they need to be wrapped in f:verbatim tag which
screws up the whole HTML structure. Maybe there are some more nuances
- you can do it a view but not in a sub view or something like that.

There were a lot more issues because I was trying to make this work in
a portlet environment (that to on websphere portal server)

[Chandru]

One of the prime things to consider while deciding to choose JSF is that, it is more of a component framework than just an MVC web framework.

On Fri, Jan 23, 2009 at 11:32 PM, Kamal <kamal.gs@gmail.com> wrote:

 - too much of XML configuration

 

Agreed.  Hope annotations come to the rescue as in the case of EJBs.  But surprisingly most of the other frameworks you had suggested (except GWT but GWT is just a client side presentation tool like Flex) need lot of XML.

 - very steep learning curve (if you really want to understand how
things work - rather than just putting together an application using
wizards and once you start with JSF you will sooner or later be
required to understand to debug issues :-))

 

As I said the way a web developer looks at it needs a complete change.  Look at it as components (like in a desktop GUI application) and it becomes easy.

- I had a hard time trying to make a simple thing like a data table
work without having to resort to defining a bean as session scope -
debugging it was more painful.  Going with session scope resulted in
so many other issues.

When using input or action components in datatable (combo boxes and list boxes outside tables too), JSF validates the input to ensure that it forms part of the actual list of values provided to user.  This is a validation, which apps have to do anyway as a safe programming practice.  Choosing between session scoped values vs DB access on submit is a decision to be taken based on the application.  But datatable offers few nice stuff like, providing a request scoped parameter giving the actual object for the row where action was performed (where applicable).

 

- If you use jsp's and not facelets as the view then you can't use
regular html tags - they need to be wrapped in f:verbatim tag which
screws up the whole HTML structure.

Again look at it as component framework.  HTML tags don't really form components.  But by combining standard JSF and Richfaces, extremely complex yet maintainable designs can be created.  The project I currently work on is a great example of it but can't reveal too many details about it.  For an idea think of a UI rich with DnD, absolute positioning of several DIVs and a graph (not a simple statistical chart) which gets redrawn on each user action.  The last part is where the paint2D component was extremely handy!

Why I like JSF?

1. Validation and Conversion facilities are excellent.  It comes very handy in many circumstances.  Especially when UI needs currency, time or unit conversions which really has no meaning to underlying business logic.
2. Integration with other parts of Java EE.  Things like resource injection, can make development a lot easier.  As I had said in other post, though I have been working with Spring and Hibernate for quite a few months, I found developing similar apps using EJB 3.0 and JSF much easier.
3. Rich third party components like Richfaces, Icefaces, ADF Faces, etc.

But there is one thing I find really weird in JSF.  While datatable can take objects and return the object corresponding to the row of action, combo boxes and list boxes need a converter to do this.  :(

[Peter Thomas]

Hi,

I feel that you should evaluate Apache Wicket also, here are some links comparing it with Spring MVC, JSF, GWT and Seam / RichFaces:

http://ptrthomas.wordpress.com/2007/03/02/wicket-impressions-moving-from-spring-mvc-webflow/

http://www.dzone.com/links/a_wicket_user_tries_jsf.html

http://ptrthomas.wordpress.com/2008/09/04/wicket-and-gwt-compared-with-code/

http://www.dzone.com/links/seamjsf_vs_wicket_performance_comparison.html

Happy framework hunting!

- Peter.

[aayush]

Thats a bunch of nice links Peter..looks like you have researched
deeply into it.
Apache Wicket..will need to read about it.

As i am not a GUI guy...more of a telco server software guy,
everyone's inputs on this thread have helped me alot.

One of my OSS contributors is keen on JSF, but i am now tempted
towards considering other frameworks as well, especially after this
discussion.

@Kamal @Peter @Chandru @Abhilshit @Ranganath
Would any/all of you be interested in part time contributions to the
GUI component of my OSS project?

The project is here: http://groups.google.com/group/whitelassi


Thanks..
Aayush.

On Jan 23, 3:25 pm, Peter Thomas <ptrtho...@gmail.com> wrote:
> Hi,
>
> I feel that you should evaluate Apache Wicket also, here are some links
> comparing it with Spring MVC, JSF, GWT and Seam / RichFaces:
>

> http://ptrthomas.wordpress.com/2007/03/02/wicket-impressions-moving-f...
>
> http://www.dzone.com/links/a_wicket_user_tries_jsf.html
>
> http://ptrthomas.wordpress.com/2008/09/04/wicket-and-gwt-compared-wit...

[Kamal]

> One of the prime things to consider while deciding to choose JSF is that, it
> is more of a component framework than just an MVC web framework.

I am not convinced that a component based approach can work well with
a round trip to the server required for each action. Take a look at
how icefaces / richfaces deal with this - I tried to port the filter
implementation to a PortletFilter as I wanted to use these components
in a portlet environment - it is very complex.

I have come across a few comments saying that "GWT is JSF done right"
- the ideas (or at least the intentions) behind JSF might be sound
but the current implementation is probably not.

> On Fri, Jan 23, 2009 at 11:32 PM, Kamal <kamal...@gmail.com> wrote:
>
> >  - too much of XML configuration
>
> Agreed.  Hope annotations come to the rescue as in the case of EJBs.  But
> surprisingly most of the other frameworks you had suggested (except GWT but
> GWT is just a client side presentation tool like Flex) need lot of XML.

The other frameworks (struts2 and spring mvc) started with XML, but
now they have a simpler annotation based approach. In case of struts2
with a little effort during initial project setup it is easy to make
it use a convention over configuration approach. This support has
been there for quite a while now in both the frameworks and it is the
recommend approach today.

As I commented in the other thread on EJBs - this is a big
disadvantage with frameworks driven by standards. They are always
behind the curve.

>  - very steep learning curve (if you really want to understand how
>
> > things work - rather than just putting together an application using
> > wizards and once you start with JSF you will sooner or later be
> > required to understand to debug issues :-))
>
> As I said the way a web developer looks at it needs a complete change.  Look
> at it as components (like in a desktop GUI application) and it becomes easy.

If the application really needs that kind of a model it is probably
better to go with something like GWT/Flex which is a lot closer to the
model of developing a desktop application.

> - I had a hard time trying to make a simple thing like a data table
>
> > work without having to resort to defining a bean as session scope -
> > debugging it was more painful.  Going with session scope resulted in
> > so many other issues.
>
> When using input or action components in datatable (combo boxes and list
> boxes outside tables too), JSF validates the input to ensure that it forms
> part of the actual list of values provided to user.  This is a validation,
> which apps have to do anyway as a safe programming practice.  Choosing
> between session scoped values vs DB access on submit is a decision to be
> taken based on the application.  But datatable offers few nice stuff like,
> providing a request scoped parameter giving the actual object for the row
> where action was performed (where applicable).

I had a very simple requirement a view only table with pagination /
sorting support (since the data set can be huge the pagination /
sorting had to be delegated to the database) - I think this is
probably what 80% usage of the data table would be for. And I am wary
of putting anything into the session (except for some minimal
information).

[Peter Thomas]

On Sat, Jan 24, 2009 at 11:24 AM, Kamal <kamal.gs@gmail.com> wrote:

> One of the prime things to consider while deciding to choose JSF is that, it
> is more of a component framework than just an MVC web framework.

I am not convinced that a component based approach can work well with
a round trip to the server required for each action. Take a look at
how icefaces / richfaces deal with this - I tried to port the filter
implementation to a PortletFilter as I wanted to use these components
in a portlet environment - it is very complex.

I feel you need to draw a distinction between JSF and other component based approaches which are far better engineered.  I agree with Kamal that one is better off not using JSF and by the way - things don't look promising *even* in the upcoming JSF 2.0, for example see the comments on this blog entry (by the JSF spec lead):

http://weblogs.java.net/blog/edburns/archive/2009/01/jsf_20_public_r.html

That's right, JSF does not support "bookmarkable urls" - and this sad state of affairs looks set to continue well into the future.  This is just one example, there are many more I can point you to if you are interested.

I have come across a few comments saying that "GWT is JSF done right"
- the ideas (or at least the intentions)  behind JSF might be sound
but the current implementation is probably not.

I have my reservations on GWT - for details see the blog post link I posted in my previous message.  I would recommend GWT only if:

a) you really want to reduce server round trips *drastically*

b) you are prepared to invest time in designing your back-end services to be re-usable, serializable, with the right level of granularity etc.  GWT and REST advocates may give you the impression that all this is easy but it isn't :)
 

> On Fri, Jan 23, 2009 at 11:32 PM, Kamal <kamal...@gmail.com> wrote:
>
> >  - too much of XML configuration
>
> Agreed.  Hope annotations come to the rescue as in the case of EJBs.  But
> surprisingly most of the other frameworks you had suggested (except GWT but
> GWT is just a client side presentation tool like Flex) need lot of XML.

The other frameworks (struts2 and spring mvc) started with XML, but
now they have a simpler annotation based approach.  In case of struts2
with a little effort during initial project setup it is easy to make
it use a convention over configuration approach.  This support has
been there for quite a while now in both the frameworks and it is the
recommend approach today.

As I commented in the other thread on EJBs - this is a big
disadvantage with frameworks driven by standards.  They are always
behind the curve.

Completely agree :)  About the previous point on annotations - well I'm concerned that people may be over-using annotations nowadays - but I'll not say any more on this.  The Spring MVC support for annotation driven controllers is indeed impressive.

>  - very steep learning curve (if you really want to understand how
>
> > things work - rather than just putting together an application using
> > wizards and once you start with JSF you will sooner or later be
> > required to understand to debug issues :-))
>
> As I said the way a web developer looks at it needs a complete change.  Look
> at it as components (like in a desktop GUI application) and it becomes easy.

If the application really needs that kind of a model it is probably
better to go with something like GWT/Flex which is a lot closer to the
model of developing a desktop application.

You missed mentioning Wicket here along with GWT and Flex ;)

 

[Chandru]

On Sat, Jan 24, 2009 at 11:24 AM, Kamal <kamal.gs@gmail.com> wrote:

As I commented in the other thread on EJBs - this is a big
disadvantage with frameworks driven by standards.  They are always
behind the curve.

I'm not gonna pick on this with respect to JSF because though I have a bit of familiarity with other framework's design, I'm not skilled in them.  But EJB 3.0 is not behind any specific framework.  Especially it is much easier to develop and maintain than direct Hibernate + Spring.  But as discussed in other thread, its runtime performance depends on the how the container provides EJB support.

I had a very simple requirement a view only table with pagination /
sorting support (since the data set can be huge the pagination /
sorting had to be delegated to the database) - I think this is
probably what 80% usage of the data table would be for. And I am wary
of putting anything into the session (except for some minimal
information).

For this, what was it that you had to keep in session?  Especially, when the tasks are being handled at database, there really is no need to put anything in session (at least for this requirement).

[Chandru]

I don't have the faintest idea about the domain of the project.  But I can definitely help with UI in my free time (esp because it is an open-source project :)).

[aayush]

Hi Chandru,

Dont worry about the server side complexity or telecom components/
software. The GUI will be the same irrespective of what the server's
business logic is. It is a plain old provisioning console which will
interact with a DB :). Same old login pages/ Service catalog pages
etc.

Glad to see interest in open source. Feel free to join the group and
we can talk more there: http://groups.google.com/group/whitelassi

aayush

[Kamal]

> > As I commented in the other thread on EJBs - this is a big
> > disadvantage with frameworks driven by standards.  They are always
> > behind the curve.
>

> of familiarity with other framework's design, I'm not skilled in them.  But
> EJB 3.0 is not behind any specific framework.  

As I mentioned in the other thread - the Criteria API is a glaring
omission. Try building a query for a search screen where you only
need to include those fields in the query for which the user has
specified some value. Constructing the EJB-QL using string
concatenation becomes very messy. The criteria API is very useful in
this situation. I also concerned that they ignored to include it in
3.0 even though the leading ORMs (hibernate / toplink) had these for
many years and there were people who were finding it very useful.

I have not worked extensively with EJB 3.0 - never felt the need to
and I am also yet to get over the pain of having had to work with EJB
2.

> I had a very simple requirement a view only table with pagination /
>
> > sorting support (since the data set can be huge the pagination /
> > sorting had to be delegated to the database) - I think this is
> > probably what 80% usage of the data table would be for. And I am wary
> > of putting anything into the session (except for some minimal
> > information).
>
> For this, what was it that you had to keep in session?  Especially, when the
> tasks are being handled at database, there really is no need to put anything
> in session (at least for this requirement).

The managed bean that exposed the DataModel bound to the DataTable had
to be defined as session scope. If the bean is request scope it would
result in an unnecessary query - during the restore view phase it
tries to retreive the data of the page previously rendered. The bigger
problem was that pagination (using the dataScroller component) didn't
work. It might be a bug in the specific implementation I was using
(myFaces) but when I started looking around for a solution I saw so
many people struggling with similar / related issues. The specifics
are not really important - but the trouble I encountered in trying to
get simple things like this done put me off in a big way.

[Kamal]

> I feel you need to draw a distinction between JSF and other component based
> approaches which are far better engineered.  

Yes, I have heard good things about Wicket and Tapestry, but haven't
looked at them closely. I did consider including Wicket in my initial
response but held back since I didn't know enough about it.

> > I have come across a few comments saying that "GWT is JSF done right"
> > - the ideas (or at least the intentions)  behind JSF might be sound
> > but the current implementation is probably not.
>
> I have my reservations on GWT - for details see the blog post link I posted
> in my previous message.  I would recommend GWT only if:
>
> a) you really want to reduce server round trips *drastically*

The fact that only the data is exchanged (more compact) and it is
asynchronous allows one some degree of freedom - you can afford to
make a few more calls. Also the networks have become more reliable and
faster.

> b) you are prepared to invest time in designing your back-end services to be
> re-usable, serializable, with the right level of granularity etc.  GWT and
> REST advocates may give you the impression that all this is easy but it
> isn't :)

Yes I am aware of these challenge. For comparable applications
similar challenges would exist using the other approaches as well.

[Abhilshit Soni]

@kamal

> The managed bean that exposed the DataModel bound to the DataTable had

> to be defined as session scope. If the bean is request scope it would
> result in an unnecessary query - during the restore view phase it
> tries to retreive the data of the page previously rendered.
 

Instead ,I think you could have tried  something like this
=> Have a centralized session scope managed bean to handle all your session data.Number of  these can be decided upon the size of the application.

=>Try to make all your  action handlers to be request scoped managed beans.
     Reason: Having more session scoped managed beans means you are utilizing more memory.

=>Whenever an action occurs fetch the data using your DAO's and copy  it to session scope managed bean for later access.   

The bigger
> problem was that pagination (using the dataScroller component) didn't
> work. It might be a bug in the specific implementation I was using
> (myFaces) but when I started looking around for a solution I saw so
> many people struggling with similar / related issues.  The specifics
> are not really important - but the trouble I encountered in trying to
> get simple things like this done put me off in a big way.

MyFaces is just a component library for JSF and there are other similar or may be better component libraries available for JSF (Icefaces/Richfaces  to name a few) and which one is better out of them is entirely a different debate. It may be possible that a component in a particular  library may have bugs. You could have tried another libraries also.

I am working in a project were we are currently using Richfaces but there are projects in possession by our organization were we are  using  components from  Icefaces and  tomahawk both .I have never found it so difficult to tackle with any issues.

As far as Flex vs JSF is concerned its again like comparing apples with oranges. You should compare it with Silverlight, openlaszlo and JavaFX as they  follow a different development lifecycle.

@Ayush
I just had a look upon your project homepage  was not much able to understand the requirements will let you know about  UI part later.

Regards
Abhilshit Soni
MyBlog

[Chandru]

On Sat, Jan 24, 2009 at 7:11 PM, Kamal <kamal.gs@gmail.com> wrote:

As I mentioned in the other thread - the Criteria API is a glaring
omission.  Try building a query for a search screen where you only
need to include those fields in the query for which the user has
specified some value.  Constructing the EJB-QL using string
concatenation becomes very messy.

How is using String concatenation messier than using Criteria in this case.  Anyway let's discuss this in the other thread rather than taking this thread off-topic.

[Chandru]

It might very well be a bug/limitation in MyFaces.  JSF cannot be blamed for defects of third party components.

I thought it would be a better idea to show how to do it with code rather just saying that you probably selected the wrong component.  I got a few minutes to do it today.  :)  I have attached a pure JSF 1.2 code demonstrating simple next/previous pagination and ascending ordering based on one of two columns.  It has neither session scoped beans, nor does it fire redundant queries (query logging is enabled for Toplink).

I have written it without using any third party component.  Of course, this can always be made into a first-class JSF component if needed.  Combining a custom DataModel with Richfaces' DataScroller may work too.  But I wanted to demonstrate with vanilla JSF.

I have used EJBs (they are just too easy :)).  All of them are NetBeans 6.5 projects.  It also includes a MySQL dump to generate the data set of 1000 records.  Create a JNDI data source with name "jdbc/test".  I had developed on Glassfish.  But it should work on any Java EE 5 app server.

Hope that dispels a misconception about JSF.  :D

On Sat, Jan 24, 2009 at 7:11 PM, Kamal <kamal.gs@gmail.com> wrote:

The managed bean that exposed the DataModel bound to the DataTable had
to be defined as session scope. If the bean is request scope it would
result in an unnecessary query - during the restore view phase it
tries to retreive the data of the page previously rendered. The bigger
problem was that pagination (using the dataScroller component) didn't
work. It might be a bug in the specific implementation I was using
(myFaces) but when I started looking around for a solution I saw so
many people struggling with similar / related issues.  The specifics
are not really important - but the trouble I encountered in trying to
get simple things like this done put me off in a big way.

[Chandru]

Ooops!  Boundary checking has a bug in that code.  :D

[Kamal]

> I thought it would be a better idea to show how to do it with code rather
> just saying that you probably selected the wrong component.  I got a few
> minutes to do it today.  :)  I have attached a pure JSF 1.2 code
> demonstrating simple next/previous pagination and ascending ordering based
> on one of two columns.  It has neither session scoped beans, nor does it
> fire redundant queries (query logging is enabled for Toplink).

Thanks, I will take a look.

[Kamal]

A blog post that I came across today, posting a link here as it has
some discussion that is relevant to this topic.
JAX-RS as the one Java web framework to rule them all?
http://macstrac.blogspot.com/2009/01/jax-rs-as-one-web-framework-to-rule.html

[aayush]

Come to think of it, what is your opinion on JBOSS SEAM. It does
provide a lot of goodies...from the perspective of JSF and EJB3
convergence.
let me know your views on it...

aayush

On Jan 28, 10:13 am, Kamal <kamal...@gmail.com> wrote:
> A blog post that I came across today, posting a link here as it has
> some discussion that is relevant to this topic.

> JAX-RS as the one Java web framework to rule them all?http://macstrac.blogspot.com/2009/01/jax-rs-as-one-web-framework-to-r...

[Peter Thomas]

On Thu, Feb 5, 2009 at 9:40 PM, aayush <abhatnag...@gmail.com> wrote:

Come to think of it, what is your opinion on JBOSS SEAM. It does
provide a lot of goodies...from the perspective of JSF and EJB3
convergence.
let me know your views on it...

First, can you elaborate why exactly it appeals to you?  What are the goodies that you can see?  Just curious.

[aayush]

I need not write 'glue code' to integrate the JSF view layer with
EJBs. Moreover, it is seamlessly integrable with telco apps. Eg: I can
create a web phone application that leverages SEAM for views and
database connectivity, while still using telco protocols such as SIP
as part of the same application.

With seam, i can leverage other frameworks on the fly (JPA for
persistance, BPM for lifecycle management, while using JSF for views).
I have also noticed that the tooling support is also extensive. State
management is also unique.

I am not a GUI specialist, and these are only my first impressions. I
work more on telco protocols and develop SIP app servers.

Feel free to correct me or add on information, if you have experience
with seam.

On Feb 5, 9:20 pm, Peter Thomas <ptrtho...@gmail.com> wrote:

[Peter Thomas]

Just a few observations inline:

On Thu, Feb 5, 2009 at 11:51 PM, aayush <abhatnag...@gmail.com> wrote:

I need not write 'glue code' to integrate the JSF view layer with
EJBs.

Yes, this is a limitation of JSF which indeed Seam fixes.  For the complete list (as well as to understand the reality of JSF 1.0) refer this:

http://www.seamframework.org/Documentation/JSF2
 

Moreover, it is seamlessly integrable with telco apps. Eg: I can
create a web phone application that leverages SEAM for views and
database connectivity, while still using telco protocols such as SIP
as part of the same application.

You can say the same about other web-frameworks, why does Seam give telco apps an advantage?

With seam, i can leverage other frameworks on the fly (JPA for
persistance, BPM for lifecycle management, while using JSF for views).

Again, you can do all this with other frameworks as well.  Trying to be as unbiased as possible, I will agree that Seam has good support for an "extended JPA persistence context" and tighter integration with jBPM (because that also is a JBoss product).  But do you really need BPM for your requirement ?  By the way, I have ported the Seam reference / example app (hotel booking) to Apache Wicket (using JPA) in case you are interested:

http://ptrthomas.wordpress.com/2009/01/14/seam-jsf-vs-wicket-performance-comparison/
 

I have also noticed that the tooling support is also extensive.

I think others on this list may disagree, but in my experience, the claim that IDE support, drag and drop etc. is an advantage for JSF - is not really valid for real life applications.  But the best thing is for you to try it out for yourself, you may be comfortable with it, or not.
 

State
management is also unique.

I am not a GUI specialist, and these are only my first impressions. I
work more on telco protocols and develop SIP app servers.

Feel free to correct me or add on information, if you have experience
with seam.

Thanks for sharing your views.  I generally am interested in the characteristics that make a Java developer prefer one particular framework over another, hence the question :)
 

[aayush]

Thanks so much Peter. I will need to read more on Apache Wicket. I
have been to your blog. It was very informative for me :)

On Feb 5, 8:25 pm, Peter Thomas <ptrtho...@gmail.com> wrote:
> Just a few observations inline:
>

> On Thu, Feb 5, 2009 at 11:51 PM, aayush <abhatnagar192...@gmail.com> wrote:
>
> > I need not write 'glue code' to integrate the JSF view layer with
> > EJBs.
>
> Yes, this is a limitation of JSF which indeed Seam fixes.  For the complete
> list (as well as to understand the reality of JSF 1.0) refer this:
>
> http://www.seamframework.org/Documentation/JSF2
>
> > Moreover, it is seamlessly integrable with telco apps. Eg: I can
> > create a web phone application that leverages SEAM for views and
> > database connectivity, while still using telco protocols such as SIP
> > as part of the same application.
>
> You can say the same about other web-frameworks, why does Seam give telco
> apps an advantage?
>
> With seam, i can leverage other frameworks on the fly (JPA for
>
> > persistance, BPM for lifecycle management, while using JSF for views).
>
> Again, you can do all this with other frameworks as well.  Trying to be as
> unbiased as possible, I will agree that Seam has good support for an
> "extended JPA persistence context" and tighter integration with jBPM
> (because that also is a JBoss product).  But do you really need BPM for your
> requirement ?  By the way, I have ported the Seam reference / example app
> (hotel booking) to Apache Wicket (using JPA) in case you are interested:
>

> http://ptrthomas.wordpress.com/2009/01/14/seam-jsf-vs-wicket-performa...

[Chandru]

What is this glue code for JSF - EJB integration that is being talked about?  (Assuming it is EJB 3.0)

[Chandru]

Unless you are talking about using EJBs directly as Managed beans, I
don't see any need for glue code to access EJBs from JSF Beans.

[aayush]

What i meant was....

that using the SEAM framework, i can use the session beans as JSF
action listeners. I can inject/outject the pojo (used as an entity
bean and specifying the getters/setters for the view) into the session
bean. I can reuse the hibernate validator framework (through
annotations) in my entity beans (even if i am otherwise not using
hibernate) and leverage upon JPA...all in a single SEAM application.

With seam, JSF form validation also becomes less verbose, as i can use
the <s:validateAll> tag in my JSP code (constraints being defined
using annotations in the bean)

Thus, seam is providing me with utilities (through standard EJB /seam
annotations) to integrate EJBs with my presentation tier (JSF). Seam
provides me with interceptors to perform bijection, context
demarcation, validation and catch seam component invocations through
those interceptors (just by adding a simple annotation)

Seam provides support for Hibernate3, and the Java Persistence API .
Seam also provides 4 built-in components: EntityHome and
HibernateEntityHome for CRUD, along with EntityQuery and
HibernateEntityQuery for queries.

By glue code, i meant, that without a framework (like seam), the
complexity of making all these components work together would have
been the problem of the developer. Seam provides an easy to use API to
the developer for such purposes.

aayush

On Feb 6, 11:12 am, Chandru <chandru...@gmail.com> wrote:

> Bog:http://tuxychandru.blogspot.com/

[aayush]

>Unless you are talking about using EJBs directly as Managed beans, I
>don't see any need for glue code to access EJBs from JSF Beans.

Talking from a framework perspective, JSF and EJBs are not aware of
each other.

If my application uses JSF for the presentation tier and EJBs for the
business logic tier, then i need to make them work together. As these
are 2 independent frameworks, i have to write my own code to make
calls across these framework boundaries (JSF-EJB3). With SEAM, i can
follow a more convenient, annotation based approach to integrate JSF
and EJBs and even make the EJBs listen to JSF GUI events (but not
exactly as JSF backing beans..rather through entity bean injection
into session beans). Session beans can act as JSF action listeners,
but they cant provide the information for component rendering on
display.

Using annotations, the code needed for integration is very less (as
opposed to writing our own middleware code in the absence of Seam).
Moreover, i can extend POJO-based stateful components from the web
tier to the business logic tier (EJBs). By using a POJO based
approach, debugging and unit testing of such a web application also
becomes convenient.

aayush

[Chandru]

If my application uses JSF for the presentation tier and EJBs for the
business logic tier, then i need to make them work together. As these
are 2 independent frameworks, i have to write my own code to make
calls across these framework boundaries (JSF-EJB3). With SEAM, i can
follow a more convenient, annotation based approach to integrate JSF
and EJBs and even make the EJBs listen to JSF GUI events (but not
exactly as JSF backing beans..rather through entity bean injection
into session beans). Session beans can act as JSF action listeners,
but they cant provide the information for component rendering on
display.

For this you can write a helper managed bean into which you can inject your EJBs with @EJB and then write getters to use them in your pages.  I understand that this is the glue code you're talking of.

But with the current EJB spec, I find that it does have a small overhead for invocation compared to pure web tier objects like managed beans.  Thus your pages calling getters and setters on EJBs' properties for each request may cause quite a bit of overhead.  I'm not sure how Seam can avoid this.  Java EE 6 has proposals (inspired by Seam) to change this though.  :)