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
On Jan 22, 4:13 pm, aayush <abhatnagar192...@gmail.com> wrote:
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.
On Thu, Jan 22, 2009 at 5:26 PM, Kamal <kamal...@gmail.com> wrote:
> 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
> On Jan 22, 4:13 pm, aayush <abhatnagar192...@gmail.com> wrote:
> > 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.
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.
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.
---------- 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: bojug@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.
On Thu, Jan 22, 2009 at 5:26 PM, Kamal <kamal...@gmail.com> wrote:
> 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
> On Jan 22, 4:13 pm, aayush <abhatnagar192...@gmail.com> wrote:
> > 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.
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.
> 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.
> ---------- 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: bojug@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.
> On Thu, Jan 22, 2009 at 5:26 PM, Kamal <kamal...@gmail.com> wrote:
> > 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
> > On Jan 22, 4:13 pm, aayush <abhatnagar192...@gmail.com> wrote:
> > > 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.
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).
On Fri, Jan 23, 2009 at 6:56 PM, Kamal <kamal...@gmail.com> wrote:
> 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).
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.
Kamal wrote:
> 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).
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)
> 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.
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...@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. :( -- Chandra Sekar.S
On Fri, Jan 23, 2009 at 7:54 PM, aayush <abhatnagar192...@gmail.com> wrote:
> 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 wrote:
> > 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).
> On Fri, Jan 23, 2009 at 7:54 PM, aayush <abhatnagar192...@gmail.com> wrote:
> > 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 wrote:
> > > 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).
> 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).
On Sat, Jan 24, 2009 at 11:24 AM, Kamal <kamal...@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):
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 ;)
On Sat, Jan 24, 2009 at 11:24 AM, Kamal <kamal...@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).
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 :)).
On Sat, Jan 24, 2009 at 8:34 AM, aayush <abhatnagar192...@gmail.com> wrote:
> @Kamal @Peter @Chandru @Abhilshit @Ranganath
> Would any/all of you be interested in part time contributions to the
> GUI component of my OSS project?
> > On Fri, Jan 23, 2009 at 7:54 PM, aayush <abhatnagar192...@gmail.com>
> wrote:
> > > 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 wrote:
> > > > 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).
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.
> 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 :)).
> On Sat, Jan 24, 2009 at 8:34 AM, aayush <abhatnagar192...@gmail.com> wrote:
> > @Kamal @Peter @Chandru @Abhilshit @Ranganath
> > Would any/all of you be interested in part time contributions to the
> > GUI component of my OSS project?
> > > On Fri, Jan 23, 2009 at 7:54 PM, aayush <abhatnagar192...@gmail.com>
> > wrote:
> > > > 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 wrote:
> > > > > 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).
> > 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.
> 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.
> 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.
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.
On Sat, Jan 24, 2009 at 7:11 PM, Kamal <kamal...@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.
> > 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.
On Sat, Jan 24, 2009 at 7:11 PM, Kamal <kamal...@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.
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.
On Sat, Jan 24, 2009 at 7:11 PM, Kamal <kamal...@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.
On Wed, Jan 28, 2009 at 1:00 AM, Chandru <chandru...@gmail.com> wrote:
> 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...@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.
> 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).
|
