Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   Java (http://www.velocityreviews.com/forums/f30-java.html)
-   -   Re: Support for both Web and Desktop front-ends [Architecture] (http://www.velocityreviews.com/forums/t751429-re-support-for-both-web-and-desktop-front-ends-architecture.html)

Warren Tang 07-14-2011 02:05 AM

Re: Support for both Web and Desktop front-ends [Architecture]
 
Thanks Arved for your detailed explanation. It really make things much clearer for me.

As I don't want to learn so much new things at a time, I should keep it as simple as possible. If Java SE can get the job done, I won't go for Java EEor Spring this time.

My current understanding is that I can really do it with Java SE only. Thatis GWT for the web and Swing for the desktop, with no Spring or Java EE involved. If I can properly divide the code into the 4-tiers as you described, I believe I can get pretty good results.

For me it's like the ".NET" way which I am familiar with. As my knowledge on Java grows, I may go for other possibilities.

Arved Sandstrom 07-14-2011 10:02 AM

Re: Support for both Web and Desktop front-ends [Architecture]
 
On 11-07-13 11:05 PM, Warren Tang wrote:
> Thanks Arved for your detailed explanation. It really make things much clearer for me.
>
> As I don't want to learn so much new things at a time, I should keep it as simple as possible. If Java SE can get the job done, I won't go for Java EE or Spring this time.
>
> My current understanding is that I can really do it with Java SE only. That is GWT for the web and Swing for the desktop, with no Spring or Java EE involved. If I can properly divide the code into the 4-tiers as you described, I believe I can get pretty good results.
>
> For me it's like the ".NET" way which I am familiar with. As my knowledge on Java grows, I may go for other possibilities.


Regardless of one's personal feelings about Spring, it's a non-essential
framework. You don't _need_ it, no.

I'm not a GWT expert, but even a GWT app that produces HTML and
Javascript is still a web app that needs a web server, so by definition
it's Java EE territory. For example, even a basic GWT application will
be packaged according to Servlet API guidelines.

"Java EE" is not a label to be fearful of (:-)), and there's a lot of
Java EE APIs that you will not be using for a basic GWT application, so
you can start off relatively easy. Your actual GWT web tier coding will
look like Java SE and in that sense you're correct. I do know that GWT
resources (official docs and 3rd party stuff) are thorough and
plentiful, so I would not anticipate major problems.

With reference to the 4 conceptual tiers I described, you'll have
grasped that these _are_ conceptual, with no reference to project
packaging or physical deployment. It's possible to have all 4 of them
living inside a single web application. Having said that, you'll
probably end up having code on the server (it won't just be GWT
compiler-generated HTML and JS on the browser); I recommend perusing
http://code.google.com/webtoolkit/do...unication.html.
GWT RPC, for example, is based on servlets.

GWT is an interesting choice. It's certainly true that creative and
ubiquitous use of AJAX can actually let you code up a web UI that
behaves similarly to a desktop UI, in terms of workflow. There is
nothing inherently wrong with this, but remember that a GWT app is still
a web app, so now you're dealing with HTTP and sessions and different
kinds of security issues. An AJAX call is still an HTTP request. Again,
GWT has lots of good documentation regarding all this.

To briefly return to Spring, there is no shortage of articles and
semi-official documentation that talks about integrating GWT and Spring.
A word to the wise: Spring boosters would have it that nothing else out
there is comparable in terms of supporting "efficient, lightweight,
POJO-based" server-side development. Of course, nothing is further from
the truth - standard Java EE APIs already do the trick. So my
recommendation stands: possibly learn up on some Spring down the road to
add to your professional toolkit, because lots of shops do use Spring,
but don't consider the framework as being necessary. It may be a
necessary evil depending on who you work with, but it's not necessary.

HTH,
AHS

Arne Vajh°j 07-21-2011 10:43 PM

Re: Support for both Web and Desktop front-ends [Architecture]
 
On 7/14/2011 6:02 AM, Arved Sandstrom wrote:
> On 11-07-13 11:05 PM, Warren Tang wrote:
>> Thanks Arved for your detailed explanation. It really make things much clearer for me.
>>
>> As I don't want to learn so much new things at a time, I should keep it as simple as possible. If Java SE can get the job done, I won't go for Java EE or Spring this time.
>>
>> My current understanding is that I can really do it with Java SE only. That is GWT for the web and Swing for the desktop, with no Spring or Java EE involved. If I can properly divide the code into the 4-tiers as you described, I believe I can get pretty good results.
>>
>> For me it's like the ".NET" way which I am familiar with. As my knowledge on Java grows, I may go for other possibilities.

>
> Regardless of one's personal feelings about Spring, it's a non-essential
> framework. You don't _need_ it, no.
>
> I'm not a GWT expert, but even a GWT app that produces HTML and
> Javascript is still a web app that needs a web server, so by definition
> it's Java EE territory. For example, even a basic GWT application will
> be packaged according to Servlet API guidelines.


GWT is traditionally compared with Java EE we frameworks.

And if it is using the GWT server side stuff then it has to be used
with a servlet container.

But it is actually possible to only use the client side stuff and have
Apache httpd or IIS serve up the generated HTML and JavaScript without
having any Java EE server in the production environment.

Arne



All times are GMT. The time now is 01:56 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.