Now, we're deciding whether to use GWT or JSF for our framework.
Basically, we're a bunch of inexperienced people in terms of software
development. In addition, we're running out of time... I am not even
sure if we could make it to the deadline. But since we'll have to try
our best to make it in time, we need advice on the technologies we'll
use for the implementation particularly the framework. If you could
add something regarding access to database. We're using Postgres.
Thanks.
To some degree you are comparing apples to oranges. GWT isn't a
server-side framework, and I would normally match it up with Spring
and Struts on the back end, perhaps with a pinch of Hibernate.
JSF on the other hand is a server-side framework that can't do what
GWT does on the client side.
Have you thought about using them together? See G4jsf:
https://ajax4jsf.dev.java.net/nonav/ajax/gwt/gwt-cdk.html
> Basically, we're a bunch of inexperienced people
> in terms of software development. In addition, we're
> running out of time...
That is typically a bad time to learn something new.
Rob
On Feb 10, 10:20 pm, "Robert Hanson" <iamroberthan...@gmail.com>
wrote:
> To some degree you are comparing apples to oranges. GWT isn't a
> server-side framework, and I would normally match it up with Spring
> and Struts on the back end, perhaps with a pinch of Hibernate.
>
> JSF on the other hand is a server-side framework that can't do what
> GWT does on the client side.
I got the idea that GWT and JSF have this common ground (and are
comparable) since articles about JSF that I've read are always saying
JSF solves UI problems with web application development. Maybe the
difference--I could only guess--between them is that JSF covers the
server-side as well. So using JSF and GWT together is like dressing up
JSF pages. Using GWT alone, we'll have to program our server side
separately... Is that right?
> That is typically a bad time to learn something new.
Yeah... I've been regretting that... but we'll have to do this...
> I've read are always saying JSF solves UI
> problems with web application development.
I think the idea of JSF if that you make a component, like a login
form, and you just plop it in the page. JSF then simplifies the
handling of form data so that you just write the business logic (i.e.
testing the login) and JSF worries about mapping form data a Java
object.
The idea being with a cart load of pre-built components you can use a
visual editor to just drop them onto the page. Some of the components
could use JavaScript, like a sortable table component. So the
components can be interactive.
> So using JSF and GWT together is like dressing up
> JSF pages.
GWT is really good for UI coding. So in the JSF sortable table you
could use GWT to replace the need to write the code in JavaScript.
> Using GWT alone, we'll have to program our server side
> separately... Is that right?
Well, GWT does have a nice RPC feature that allows you to send Java
objects between the client and server, so like JSF it hides the
details of normal web coding.
There are just some little differences between the two. With GWT you
get less server-side support, but more UI support, and in my opinion
JSF is the reverse.
I think the choice in your case of using GWT is going to depend on how
dynamic the UI is. If you are just serving plain old HTML, then GWT
probably isn't a good fit. On the other hand if you need a high level
of UI interactivity, I think that JSF would just get in the way.
Rob
Yep. That's definitely the right way to look at it. Even if you have
some relatively minimal interactivity, JSF is probably still a better
way to go. But if you have lots of interactivity, it's GWT all the
way, and forget about JSF.
I'm working on enhancing the g4jsf-cdk that Robert already linked to
above, partly because I have a project that wants to have some pages
that are flat HTML (for which I want to use JSF since it's dead easy
to do flat HTML pages in JSF), and some pages that include complex
interaction (for which I want to use GWT, embedded as a JSF component
so I can reuse all my other server-side logic).
My ideal stack is Seam for the server-side logic (session management,
component structure, transaction handling, EJB3 persistence), JSF as
the overall webapp framework (supports straightforward web sites very
easily, Facelets + JSF is vastly superior to JSP or Struts, glues
together perfectly with Seam), and GWT embedded in JSF components for
high interactivity (can fit into a JSF page seamlessly, can call
through to the same server components as the JSF pages).
After my patch to issue 389 lands (hopefully soon, in GWT 1.4), the
ajax4jsf guys have already expressed interest in a patch to g4jsf-cdk
that will let managed JSF beans expose interfaces directly to GWT
components, so the normal GWT RPC style will just work.
But it's been a long road learning all this, and it's totally on my
own time, so I've been able to go slowly. In another six months this
whole GWT + JSF + Seam stack will be much more widely used (JBoss has
expressed some interest already) and MUCH more well-documented. But
if you don't know GWT *OR* JSF, don't even *think* about combining
them yet.
> > > > We're in a hurry.
> > >
> > > That is typically a bad time to learn something new.
>
> > Yeah... I've been regretting that... but we'll have to do this...
Um, why, exactly? Time pressure is anathema to a learning curve --
it'll make it much harder to go slowly, it'll make you commit much
sooner to hasty decisions made mostly in ignorance, and it'll suck all
the fun out of the project. Why can't you use some technology that
you already understand?
Cheers,
Rob
With this situation, do you think it's possible for our team to go
Struts for the server side. Or we stick to Servlets and JDBC--I'm not
sure if using Struts also solves the database access.