The development team I work with has tried many frameworks and has landed on
using GWT in combination with Spring. They love using GWT as they say it saves
them a tremendous amount of time.
Ralph
On Nov 11, 2010, at 7:45 AM, phil swenson wrote:
> This is similar to what you guys are talking ab
I think the question is whether you can implement ALL the view code in
a server-side framework. If you cannot because there are some dynamic
things you want to do client-side to provide a better user experience,
then why not implement ALL the view code so it runs client-side? It
seems that the most
Separation of view code from controller/model is what the view layer
is for (jsp/.erb./.haml/.gsp/etc)
All this does is move more of your logic into javascript in the
browser instead of in your rendering template. You can do this with
any web framework anyway if you like... but I will note it's h
On Thu, Nov 11, 2010 at 9:45 AM, phil swenson wrote:
> This is similar to what you guys are talking about from 37 signals:
>
> http://thinkvitamin.com/mobile/new-rails-like-framework-from-37signals-for-html5-mobile-apps/
>
> I personally don't get the advantage of doing everything in javascript
>
This is similar to what you guys are talking about from 37 signals:
http://thinkvitamin.com/mobile/new-rails-like-framework-from-37signals-for-html5-mobile-apps/
I personally don't get the advantage of doing everything in javascript
on the client (less data to transport)?
On Thu, Oct 28, 2010 a
The main problem I battle with with that you can get around this by having
more, finer grained resources which only expose the information they need,
and can be secured at that finer grained level, but then you increase the
roundtripyness of your system.
This has occasionally led us to keeping mor
On Sun, Oct 31, 2010 at 1:22 AM, Mark Derricutt wrote:
> After a year or so of doing a RESTful application, with ext.js all on the
> front end I'm thinking one of the problems/issues I have with this model is
> that you tend to bleed A LOT of internal implementation details out to the
> client in
One of the other interesting problems we've come up against is that we use
flot.js for client side charting, it's a pure javascript charting framework.
At some point awhile ago we were asked if we could also include our charts
on the PDFs we generate on the back end - in order to do that we'd prob
After a year or so of doing a RESTful application, with ext.js all on the
front end I'm thinking one of the problems/issues I have with this model is
that you tend to bleed A LOT of internal implementation details out to the
client in order for it to do its work.
--
"Great artists are extremely s
Another +1 forI server-side frameworks not generating client-side views, but
just feeding data. However, the other things frameworks do remain valuable
(routing, marshalling, etc.).
Mwanji
--
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To po
On Thu, Oct 28, 2010 at 6:02 PM, Mark Volkmann wrote:
> I agree! I prefer implementing services that return JSON and creating
> HTML views of that data using jQuery in the browser. I recommend
> running JSLint on all your JavaScript code. It has saved me a lot of
> debugging time.
>
Thank you for
On Thu, Oct 28, 2010 at 12:17 PM, Fabrizio Giudici
wrote:
> But I don't like JavaScript (*) at
> all and I wouldn't like to use it in any way.
I used to feel the same way. Reading "JavaScript: The Good Parts"
changed my mind.
--
R. Mark Volkmann
Object Computing, Inc.
--
You received this me
I have been developing web apps this way for a while and enjoy it very much.
No more JSF, thank you (although, as with everything, there is a place for
that, too)
On Thu, Oct 28, 2010 at 1:17 PM, Fabrizio Giudici <
fabrizio.giud...@tidalwave.it> wrote:
> On 10/28/2010 07:02 PM, Mark Volkmann wr
On 10/28/2010 07:02 PM, Mark Volkmann wrote:
I agree! I prefer implementing services that return JSON and creating
HTML views of that data using jQuery in the browser. I recommend
running JSLint on all your JavaScript code. It has saved me a lot of
debugging time.
Architectural speaking, only
On Thu, Oct 28, 2010 at 11:39 AM, clay wrote:
> Five years ago, there were intense debates of web frameworks. There
> were Java framework wars among Struts vs JSF vs Tapestry vs Wicket vs
> Spring vs etc along with the the prominent non-Java frameworks such as
> PHP, ASP.NET, Rails, etc.
>
> Recen
Five years ago, there were intense debates of web frameworks. There
were Java framework wars among Struts vs JSF vs Tapestry vs Wicket vs
Spring vs etc along with the the prominent non-Java frameworks such as
PHP, ASP.NET, Rails, etc.
Recently, I've been working on rich web applications that use:
16 matches
Mail list logo
