Does GWT provide support for themes ?
11 views
Skip to first unread message
Shahzeb Khan
Apr 22, 2010, 9:17:52 PM4/22/10
to Google Web Toolkit
Does GWT provide support for themes like whe JSF or rich faces ?
We are evaluating GWT for using it as the presentation layer over
JSF . Other option we have is Richfaces .
So far we love GWT but support for themes will be the deal breaker or
maker . I have noticed some third party gwt support sites provide it
but we would not be using any thing else not officically coming from
google .
Thanks in advance .
--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
We are evaluating GWT for using it as the presentation layer over
JSF . Other option we have is Richfaces .
So far we love GWT but support for themes will be the deal breaker or
maker . I have noticed some third party gwt support sites provide it
but we would not be using any thing else not officically coming from
google .
Thanks in advance .
--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Stefan Bachert
Apr 24, 2010, 11:34:07 AM4/24/10
to Google Web Toolkit
Hi,
It depends what you understand under theming support.
You can select one of three standard themes within the module.xml.
And you can create your own if you like.
When you want to exchange the css (at runtime), you already have the
sample downloaded in GWT 2.0.3.
It is called "Showcase".
To make a decision between JSF/RF and GWT depend on theming support
sounds somewhat irrational.
It is like to choose between car or boat because of the color of the
vehicle.
By the way, JSF/RF is not officially supported by Google, and RF is an
implementation of JSF.
Stefan Bachert
http://gwtworld.de
It depends what you understand under theming support.
You can select one of three standard themes within the module.xml.
And you can create your own if you like.
When you want to exchange the css (at runtime), you already have the
sample downloaded in GWT 2.0.3.
It is called "Showcase".
To make a decision between JSF/RF and GWT depend on theming support
sounds somewhat irrational.
It is like to choose between car or boat because of the color of the
vehicle.
By the way, JSF/RF is not officially supported by Google, and RF is an
implementation of JSF.
Stefan Bachert
http://gwtworld.de
Shahzeb Khan
Apr 25, 2010, 3:36:46 AM4/25/10
to Google Web Toolkit
Thanks Stephen you did answer my question and by Friday we had decided
to go with GWT .
however deciding a front end framework based on the dynamics of it's
offering is very rational .
Both technologies achieve same thing even though by having completely
different architectures and if google is to survive and prosper at
this end ( and we hope\wish that it does since we are going ahead with
it) then it must provide support for other jee frameworks .
For example we could not get rid of JSF . We are using GWT-JSF-Spring-
Seam-Hibernate and the only reason JSF is still in that equation is
that I could not find a way to integrate GWT with a pageflow framework
like Spring Webflow or jbpm . I loved what GWT offered but it needs
more openess .
I would appreciate if you do criticize me here if I am doing any thing
wrong .
On Apr 25, 1:34 am, Stefan Bachert <stefanbach...@yahoo.de> wrote:
> Hi,
>
> It depends what you understand under theming support.
>
> You can select one of three standard themes within the module.xml.
> And you can create your own if you like.
>
> When you want to exchange the css (at runtime), you already have the
> sample downloaded in GWT 2.0.3.
> It is called "Showcase".
>
> To make a decision between JSF/RF and GWT depend on theming support
> sounds somewhat irrational.
> It is like to choose between car or boat because of the color of the
> vehicle.
>
> By the way, JSF/RF is not officially supported by Google, and RF is an
> implementation of JSF.
>
> Stefan Bacherthttp://gwtworld.de
to go with GWT .
however deciding a front end framework based on the dynamics of it's
offering is very rational .
Both technologies achieve same thing even though by having completely
different architectures and if google is to survive and prosper at
this end ( and we hope\wish that it does since we are going ahead with
it) then it must provide support for other jee frameworks .
For example we could not get rid of JSF . We are using GWT-JSF-Spring-
Seam-Hibernate and the only reason JSF is still in that equation is
that I could not find a way to integrate GWT with a pageflow framework
like Spring Webflow or jbpm . I loved what GWT offered but it needs
more openess .
I would appreciate if you do criticize me here if I am doing any thing
wrong .
On Apr 25, 1:34 am, Stefan Bachert <stefanbach...@yahoo.de> wrote:
> Hi,
>
> It depends what you understand under theming support.
>
> You can select one of three standard themes within the module.xml.
> And you can create your own if you like.
>
> When you want to exchange the css (at runtime), you already have the
> sample downloaded in GWT 2.0.3.
> It is called "Showcase".
>
> To make a decision between JSF/RF and GWT depend on theming support
> sounds somewhat irrational.
> It is like to choose between car or boat because of the color of the
> vehicle.
>
> By the way, JSF/RF is not officially supported by Google, and RF is an
> implementation of JSF.
>
Sripathi Krishnan
Apr 25, 2010, 5:01:46 AM4/25/10
to google-we...@googlegroups.com
For example we could not get rid of JSF . We are using GWT-JSF-Spring-
Seam-Hibernate and the only reason JSF is still in that equation is
that I could not find a way to integrate GWT with a pageflow framework
like Spring Webflow or jbpm . I loved what GWT offered but it needs
more openess .
Conventional frameworks like webflow, jbpm, struts, jsp, <put-your-technology-here> all have a server side page lifecycle. To go from one page to another, the browser goes to the server, which generates new html content and the browser renders the page again. This is the traditional style of web pages. You can AJAX'ify them by using js libraries like jquery/yui/<insert-your-js-library>, but the basic page flow lifecycle does not change.
GWT has a different architecture. There is only 1 html page in GWT. Once that page has downloaded, it stays in the browser for the length of that session. Transition from one view to another is done on client side using javascript. You can still use server side technologies like jbpm and struts, but their job will be restricted to serving the first html page; thereafter, GWT will take over. Because you are only going to serve 1 html page, using any webframework with GWT is almost always an overkill.
So, the reason you can't integrate GWT with Spring Webflow is because they really are two radically different things. By introducing JSF in the picture, you will bridge the gap to some extent, but it is only going to complicate things for you.
You have to decide how you want your page transitions to work. If its server side, then just use JSF and forget GWT. If its client side, just use GWT and forget JSF. If its something in between, make sure there are very good reasons for doing so, and then go ahead with a combination of JSF and GWT. The only reason for an in-between approach is a legacy application, everything else can be overcomed.
--Sri
Stefan Bachert
Apr 25, 2010, 11:35:26 AM4/25/10
to Google Web Toolkit
Hi Shahzeb,
I do not criticize you. I criticize arguments when I consider them
wrong, inadequat or misleading.
When you are going to build an application which should behave like an
classical native gui-application, you need some kind of Ajax-
technology. In this area I expect the most activity in new
development.
When you are going to build a classical web site where you jump from
page to page, something like JSP is sufficient. (In the end some kind
of CMS may be sufficient)
This are the both ends I see for web related systems.
JSF is to poor for both. The responsiveness on user events is to poor
because anything goes over the network. So JSF is not the best choise.
(I use sometime an Iceface application, a JSF variant. There is a
judgement widget which allowes to assign 0 to 5 stars, any changes
send about 40KByte over the net and take about 1 second. That is just
a poor user experience, with GWT there would be no need to wait)
The performance to deliver classical HTML-page is poor relative to
JSP.
JSF (even when JSF 2.0 was release recently) is a technological dead
end. It is for nothing the best.
Classical Ajax-Technology has its own deficiencies. It based on
JavaScript. JavaScript is poor for software engineering.
JavaScript behaves different across browsers and JavaScript is not
(blackbox) testable. JavaScript needs much of discipline, so it is not
really usable for large teams.
It is GWTs contribution to overcome the weaknesses of JavaScript while
maintaining the strength
Spring Webflow is a technology which tries to overcome the limitation
of the classical http approach which is to poor for applications.
There is no need for it in an Ajax-World. (And I don't like to
configure lots of xml files)
In GWT the client side (browser) holds the state, you send it to the
server when it is necessary. No need for a concept like Spring
Webflow.
I guess a lot of people doing classical web development were still
infected by this gaga concepts introduced by dealing with the abuse of
http/html which never meant to be used for web applications.
GUI-Development with GWT could be very logical, surprising isn't it.
Not that I think every thing is OK with GWT, I know some of its
weaknesses, however, I am absolutely convinced that the issues could
be solved within this technology.
You are going ahead with GWT, it would wondering me when - let's say
in 6 month - you still think GWT and JSF are two different ways to do
the same.
Stefan Bachert
http://gwtworld.de
All people are the same, all of them do know nothing of an infinite
number of things
I do not criticize you. I criticize arguments when I consider them
wrong, inadequat or misleading.
When you are going to build an application which should behave like an
classical native gui-application, you need some kind of Ajax-
technology. In this area I expect the most activity in new
development.
When you are going to build a classical web site where you jump from
page to page, something like JSP is sufficient. (In the end some kind
of CMS may be sufficient)
This are the both ends I see for web related systems.
JSF is to poor for both. The responsiveness on user events is to poor
because anything goes over the network. So JSF is not the best choise.
(I use sometime an Iceface application, a JSF variant. There is a
judgement widget which allowes to assign 0 to 5 stars, any changes
send about 40KByte over the net and take about 1 second. That is just
a poor user experience, with GWT there would be no need to wait)
The performance to deliver classical HTML-page is poor relative to
JSP.
JSF (even when JSF 2.0 was release recently) is a technological dead
end. It is for nothing the best.
Classical Ajax-Technology has its own deficiencies. It based on
JavaScript. JavaScript is poor for software engineering.
JavaScript behaves different across browsers and JavaScript is not
(blackbox) testable. JavaScript needs much of discipline, so it is not
really usable for large teams.
It is GWTs contribution to overcome the weaknesses of JavaScript while
maintaining the strength
Spring Webflow is a technology which tries to overcome the limitation
of the classical http approach which is to poor for applications.
There is no need for it in an Ajax-World. (And I don't like to
configure lots of xml files)
In GWT the client side (browser) holds the state, you send it to the
server when it is necessary. No need for a concept like Spring
Webflow.
I guess a lot of people doing classical web development were still
infected by this gaga concepts introduced by dealing with the abuse of
http/html which never meant to be used for web applications.
GUI-Development with GWT could be very logical, surprising isn't it.
Not that I think every thing is OK with GWT, I know some of its
weaknesses, however, I am absolutely convinced that the issues could
be solved within this technology.
You are going ahead with GWT, it would wondering me when - let's say
in 6 month - you still think GWT and JSF are two different ways to do
the same.
Stefan Bachert
http://gwtworld.de
All people are the same, all of them do know nothing of an infinite
number of things
Shahzeb Khan
Apr 25, 2010, 9:05:58 PM4/25/10
to Google Web Toolkit
Great explaination Sri . Much appreciated and really helpful. Thanks .
On Apr 25, 7:01 pm, Sripathi Krishnan <sripathikrish...@gmail.com>
wrote:
> > google-web-tool...@googlegroups.com<google-web-toolkit%2Bunsubs cr...@googlegroups.com>
> > .
> > .
> > .
On Apr 25, 7:01 pm, Sripathi Krishnan <sripathikrish...@gmail.com>
wrote:
> > For example we could not get rid of JSF . We are using GWT-JSF-Spring-
> > Seam-Hibernate and the only reason JSF is still in that equation is
> > that I could not find a way to integrate GWT with a pageflow framework
> > like Spring Webflow or jbpm . I loved what GWT offered but it needs
> > more openess .
>
> The reason GWT doesn't integrate well with webflow or JBPM is because they
> have a radically different philosophy of doing things.
>
> **Conventional frameworks like webflow, jbpm, struts, jsp,
> > Seam-Hibernate and the only reason JSF is still in that equation is
> > that I could not find a way to integrate GWT with a pageflow framework
> > like Spring Webflow or jbpm . I loved what GWT offered but it needs
> > more openess .
>
> The reason GWT doesn't integrate well with webflow or JBPM is because they
> have a radically different philosophy of doing things.
>
> <put-your-technology-here> all have a server side page lifecycle. To go from
> one page to another, the browser goes to the server, which generates new
> html content and the browser renders the page again. This is the traditional
> style of web pages. You can AJAX'ify them by using js libraries like
> jquery/yui/<insert-your-js-library>, but the basic page flow lifecycle does
> not change.
>
> **GWT has a different architecture. There is only 1 html page in GWT. Once
> one page to another, the browser goes to the server, which generates new
> html content and the browser renders the page again. This is the traditional
> style of web pages. You can AJAX'ify them by using js libraries like
> jquery/yui/<insert-your-js-library>, but the basic page flow lifecycle does
> not change.
>
> that page has downloaded, it stays in the browser for the length of that
> session. Transition from one view to another is done on client side using
> javascript. You can still use server side technologies like jbpm and struts,
> but their job will be restricted to serving the first html page; thereafter,
> GWT will take over. Because you are only going to serve 1 html page, using
> any webframework with GWT is almost always an overkill.
>
> So, the reason you can't integrate GWT with Spring Webflow is because they
> really are two radically different things. By introducing JSF in the
> picture, you will bridge the gap to some extent, but it is only going to
> complicate things for you.
>
> You have to decide how you want your page transitions to work. If its server
> side, then just use JSF and forget GWT. If its client side, just use GWT and
> forget JSF. If its something in between, make sure there are very good
> reasons for doing so, and then go ahead with a combination of JSF and GWT.
> The only reason for an in-between approach is a legacy application,
> everything else can be overcomed.
>
> --Sri
>
> session. Transition from one view to another is done on client side using
> javascript. You can still use server side technologies like jbpm and struts,
> but their job will be restricted to serving the first html page; thereafter,
> GWT will take over. Because you are only going to serve 1 html page, using
> any webframework with GWT is almost always an overkill.
>
> So, the reason you can't integrate GWT with Spring Webflow is because they
> really are two radically different things. By introducing JSF in the
> picture, you will bridge the gap to some extent, but it is only going to
> complicate things for you.
>
> You have to decide how you want your page transitions to work. If its server
> side, then just use JSF and forget GWT. If its client side, just use GWT and
> forget JSF. If its something in between, make sure there are very good
> reasons for doing so, and then go ahead with a combination of JSF and GWT.
> The only reason for an in-between approach is a legacy application,
> everything else can be overcomed.
>
> --Sri
>
> > .
> > > > For more options, visit this group athttp://
> > groups.google.com/group/google-web-toolkit?hl=en.
>
> > groups.google.com/group/google-web-toolkit?hl=en.
>
> > > --
> > > You received this message because you are subscribed to the Google Groups
> > "Google Web Toolkit" group.
> > > To post to this group, send email to google-we...@googlegroups.com
> > .
> > > To unsubscribe from this group, send email to
> > google-web-tool...@googlegroups.com<google-web-toolkit%2Bunsubs cr...@googlegroups.com>
> > > You received this message because you are subscribed to the Google Groups
> > "Google Web Toolkit" group.
> > > To post to this group, send email to google-we...@googlegroups.com
> > .
> > > To unsubscribe from this group, send email to
> > .
> > > For more options, visit this group athttp://
> > groups.google.com/group/google-web-toolkit?hl=en.
>
> > groups.google.com/group/google-web-toolkit?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Google Web Toolkit" group.
> > To post to this group, send email to google-we...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > google-web-tool...@googlegroups.com<google-web-toolkit%2Bunsubs cr...@googlegroups.com>
> > You received this message because you are subscribed to the Google Groups
> > "Google Web Toolkit" group.
> > To post to this group, send email to google-we...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > .
Shahzeb Khan
Apr 26, 2010, 7:49:43 PM4/26/10
to Google Web Toolkit
Reply all
Reply to author
Forward
0 new messages