Re: why are we coding Web apps?
Easy Answer: MS Word! Quid licet iovi non licet bovi as the romans said.In english: if it's ok for Microsoft it's still not ok for you! Thomas snip Then the question is, why do they need those 7000 Windows 2000 Desktops? Wouldn't they be better served by 7000 X server workstations and several Unix machines with centralized user accounts? /snip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: why are we coding Web apps?
It might be easier for you, but not for the corporate IT shop you're trying to sell your stuff to. They probably have some wacked out compliance test to go through for everything they want to install on their 7000 Windows 2000 Desktops (XP being too newfangled and unproven to be used). In contrast, web apps are usually not problematic (except that you can't use Javascript). Thomas Your reason is a special instance of a much more general reason. Web applications are much easier to deal with from a deployment perspective than desktop applications. I don't know, it's not difficult to set up an RMI server, or to deploy a Swing client with Web Start (gives the user a single-click launch from the browser). I've done it, and frankly it's easier than messing with Tomcat and Web frameworks (no offense to Wicket). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: why are we coding Web apps?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Then the question is, why do they need those 7000 Windows 2000 Desktops? Wouldn't they be better served by 7000 X server workstations and several Unix machines with centralized user accounts? I know, that's old-school. The whole concept is out dated and out moded. (And I'm terribly off topic) However, the way I see it, we've come full circle AGAIN. The only difference is that this time, the front-end piece was never ment to be used the way it is. X was designed from the ground up to have all processing on one machine and display on another. Shoehorning desktop-level applications into the web space just because nobody wants to roll them out to 7000 windows machines should *really* be thinking hard about why they have those 7000 windows machines. If everything is being pushed over as a web app, then you have 7000 very expensive web browser hosts using technology that really wasn't ment to be used as a GUI client for desktop level apps. It's grown up that way due to people pushing the envelope with javascript, but it sure wasn't designed for that type of work. Thomas Mäder wrote: It might be easier for you, but not for the corporate IT shop you're trying to sell your stuff to. They probably have some wacked out compliance test to go through for everything they want to install on their 7000 Windows 2000 Desktops (XP being too newfangled and unproven to be used). In contrast, web apps are usually not problematic (except that you can't use Javascript). Thomas Your reason is a special instance of a much more general reason. Web applications are much easier to deal with from a deployment perspective than desktop applications. I don't know, it's not difficult to set up an RMI server, or to deploy a Swing client with Web Start (gives the user a single-click launch from the browser). I've done it, and frankly it's easier than messing with Tomcat and Web frameworks (no offense to Wicket). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - -- Philip A. Chapman Desktop and Web Application Development: Java, .NET, PostgreSQL, MySQL, MSSQL Linux, Windows 2000, Windows XP -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIhLrwAdpynRSGw3URAh5pAJ0d82grx13YFlKZHTbiEi6sdZkJhACfR1Vc 9blmmiwqZWEbYJ9XOp8TyWg= =1u03 -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: why are we coding Web apps?
Yes, you can have EJBs calls over HTTP. Google for HTTPInvoker. It's a component from JBoss. That's what makes the Genesis framework so interesting: http://genesis.dev.java.net See ya
Re: why are we coding Web apps?
[EMAIL PROTECTED] wrote: Yes, you can have EJBs calls over HTTP. Google for HTTPInvoker. It's a component from JBoss. Ah, you lucky EJB guys - you're on top of it already. That's what makes the Genesis framework so interesting: http://genesis.dev.java.net ...to allow people with little knowledge of the Java platform to develop robust applications fast, without requiring them to learn several new technologies and complex concepts. In just six days. And on the seventh, they rest. -- Michael Allan Toronto, 647-436-4521 http://zelea.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: why are we coding Web apps?
Zappaterrini, Larry wrote: Your reason is a special instance of a much more general reason. Web applications are much easier to deal with from a deployment perspective than desktop applications. I don't know, it's not difficult to set up an RMI server, or to deploy a Swing client with Web Start (gives the user a single-click launch from the browser). I've done it, and frankly it's easier than messing with Tomcat and Web frameworks (no offense to Wicket). And any developer who's coded a GUI using a proper toolkit, such as Swing, will never willingly trade it for a Web framework. (A big part of the attraction of Wicket is its Swing-like, component design. But it can't approach the real thing.) Also, there are firewall and security issues surrounding access to central data repositories that web applications handle nicely. That security coddling is a mixed blessing. The browser's sandbox, for instance, makes it a complicated business to provide the user with normal access to resources on the desktop. With Swing, your app is a full peer on the desktop. True, there are firewall and NAT hurdles for RMI clients. I googled for RMI over HTTP and HTTP tunneling, and I didn't get a comfortable, reassuring response. Why is that? It's a mystery... It should be a well beaten path. -- Michael Allan Toronto, 647-436-4521 http://zelea.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: why are we coding Web apps?
This only holds true if you have the full deployment environment under control: Java for OS X is much different than Java for Windows, as Johan can attest for. Just as with browsers you have to consider folks that don't update their JDK's, and many corporate IT guys don't want to update anything (including browsers!). So probably the easiest deployment platform still remains the browser, since most shops do have at least IE6 (while a shitty product in itself, it is manageable to get it to work). Deployment of anything, even web apps is an exciting thing in Corporations. Martijn On Thu, Jul 17, 2008 at 10:18 AM, Michael Allan [EMAIL PROTECTED] wrote: Zappaterrini, Larry wrote: Your reason is a special instance of a much more general reason. Web applications are much easier to deal with from a deployment perspective than desktop applications. I don't know, it's not difficult to set up an RMI server, or to deploy a Swing client with Web Start (gives the user a single-click launch from the browser). I've done it, and frankly it's easier than messing with Tomcat and Web frameworks (no offense to Wicket). And any developer who's coded a GUI using a proper toolkit, such as Swing, will never willingly trade it for a Web framework. (A big part of the attraction of Wicket is its Swing-like, component design. But it can't approach the real thing.) Also, there are firewall and security issues surrounding access to central data repositories that web applications handle nicely. That security coddling is a mixed blessing. The browser's sandbox, for instance, makes it a complicated business to provide the user with normal access to resources on the desktop. With Swing, your app is a full peer on the desktop. True, there are firewall and NAT hurdles for RMI clients. I googled for RMI over HTTP and HTTP tunneling, and I didn't get a comfortable, reassuring response. Why is that? It's a mystery... It should be a well beaten path. -- Michael Allan Toronto, 647-436-4521 http://zelea.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.3.4 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: why are we coding Web apps?
You guys want a Tunnel library that can tunnel RMI over http? http://sebster.com/tunnel/ works fine. We use it in our product So if you want to code a Swing client that sort of is a browser but then a bit fatter and uses http (rmi over htttp or something else) you can do that just fine johan On Thu, Jul 17, 2008 at 10:18 AM, Michael Allan [EMAIL PROTECTED] wrote: Zappaterrini, Larry wrote: Your reason is a special instance of a much more general reason. Web applications are much easier to deal with from a deployment perspective than desktop applications. I don't know, it's not difficult to set up an RMI server, or to deploy a Swing client with Web Start (gives the user a single-click launch from the browser). I've done it, and frankly it's easier than messing with Tomcat and Web frameworks (no offense to Wicket). And any developer who's coded a GUI using a proper toolkit, such as Swing, will never willingly trade it for a Web framework. (A big part of the attraction of Wicket is its Swing-like, component design. But it can't approach the real thing.) Also, there are firewall and security issues surrounding access to central data repositories that web applications handle nicely. That security coddling is a mixed blessing. The browser's sandbox, for instance, makes it a complicated business to provide the user with normal access to resources on the desktop. With Swing, your app is a full peer on the desktop. True, there are firewall and NAT hurdles for RMI clients. I googled for RMI over HTTP and HTTP tunneling, and I didn't get a comfortable, reassuring response. Why is that? It's a mystery... It should be a well beaten path. -- Michael Allan Toronto, 647-436-4521 http://zelea.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: why are we coding Web apps?
if you target Java 5 by using webstart then there isnt to much of a problem just with that But yes you do have especially with the mac the different jvm problems as you have with browsers :( But happily not that many problems (there are way more different browsers and platforms) and if i have to say only one really bugs me (mac) johan On Thu, Jul 17, 2008 at 10:50 AM, Martijn Dashorst [EMAIL PROTECTED] wrote: This only holds true if you have the full deployment environment under control: Java for OS X is much different than Java for Windows, as Johan can attest for. Just as with browsers you have to consider folks that don't update their JDK's, and many corporate IT guys don't want to update anything (including browsers!). So probably the easiest deployment platform still remains the browser, since most shops do have at least IE6 (while a shitty product in itself, it is manageable to get it to work). Deployment of anything, even web apps is an exciting thing in Corporations. Martijn On Thu, Jul 17, 2008 at 10:18 AM, Michael Allan [EMAIL PROTECTED] wrote: Zappaterrini, Larry wrote: Your reason is a special instance of a much more general reason. Web applications are much easier to deal with from a deployment perspective than desktop applications. I don't know, it's not difficult to set up an RMI server, or to deploy a Swing client with Web Start (gives the user a single-click launch from the browser). I've done it, and frankly it's easier than messing with Tomcat and Web frameworks (no offense to Wicket). And any developer who's coded a GUI using a proper toolkit, such as Swing, will never willingly trade it for a Web framework. (A big part of the attraction of Wicket is its Swing-like, component design. But it can't approach the real thing.) Also, there are firewall and security issues surrounding access to central data repositories that web applications handle nicely. That security coddling is a mixed blessing. The browser's sandbox, for instance, makes it a complicated business to provide the user with normal access to resources on the desktop. With Swing, your app is a full peer on the desktop. True, there are firewall and NAT hurdles for RMI clients. I googled for RMI over HTTP and HTTP tunneling, and I didn't get a comfortable, reassuring response. Why is that? It's a mystery... It should be a well beaten path. -- Michael Allan Toronto, 647-436-4521 http://zelea.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.3.4 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: why are we coding Web apps?
Actually, I use a Mac now (vista prompted the purchase) and the Mac JVM is actually not much different... in fact I don't notice anything at all when working with java unless I'm doing something low lever like trying to load a YourKit agent... but even then its not so different. If your using swing and want to use the Mac LAF then you have to consider the way the UI works, but even then its pretty portable. I don't know if anyone is truly concerned about how well it works, but there is the result of my recent experience. - Brill On 17-Jul-08, at 5:34 AM, Johan Compagner wrote: if you target Java 5 by using webstart then there isnt to much of a problem just with that But yes you do have especially with the mac the different jvm problems as you have with browsers :( But happily not that many problems (there are way more different browsers and platforms) and if i have to say only one really bugs me (mac) johan On Thu, Jul 17, 2008 at 10:50 AM, Martijn Dashorst [EMAIL PROTECTED] wrote: This only holds true if you have the full deployment environment under control: Java for OS X is much different than Java for Windows, as Johan can attest for. Just as with browsers you have to consider folks that don't update their JDK's, and many corporate IT guys don't want to update anything (including browsers!). So probably the easiest deployment platform still remains the browser, since most shops do have at least IE6 (while a shitty product in itself, it is manageable to get it to work). Deployment of anything, even web apps is an exciting thing in Corporations. Martijn On Thu, Jul 17, 2008 at 10:18 AM, Michael Allan [EMAIL PROTECTED] wrote: Zappaterrini, Larry wrote: Your reason is a special instance of a much more general reason. Web applications are much easier to deal with from a deployment perspective than desktop applications. I don't know, it's not difficult to set up an RMI server, or to deploy a Swing client with Web Start (gives the user a single-click launch from the browser). I've done it, and frankly it's easier than messing with Tomcat and Web frameworks (no offense to Wicket). And any developer who's coded a GUI using a proper toolkit, such as Swing, will never willingly trade it for a Web framework. (A big part of the attraction of Wicket is its Swing-like, component design. But it can't approach the real thing.) Also, there are firewall and security issues surrounding access to central data repositories that web applications handle nicely. That security coddling is a mixed blessing. The browser's sandbox, for instance, makes it a complicated business to provide the user with normal access to resources on the desktop. With Swing, your app is a full peer on the desktop. True, there are firewall and NAT hurdles for RMI clients. I googled for RMI over HTTP and HTTP tunneling, and I didn't get a comfortable, reassuring response. Why is that? It's a mystery... It should be a well beaten path. -- Michael Allan Toronto, 647-436-4521 http://zelea.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Become a Wicket expert, learn from the best: http:// wicketinaction.com Apache Wicket 1.3.4 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: why are we coding Web apps?
the mac jvm is really horrible
We really develop eclipse/swing applications for 8 years now and throughout
all those years if there is a jvm specific problem
Its the mac, its always the mac, For me it is already so far that i really
hate everything that is a mac.
When they released leopard i think we have to do stuff like this in our
swing code base:
// MAC FIX
@Override
public Insets getMargin()
{
Insets insets = super.getMargin();
if (insets == null)
{
insets = new Insets(0, 0, 0, 0);
}
return insets;
}
Else we would get null pointers deep in there look and feel.
And that is just a small example. we have in our code base all over the
place things like // mac fix
There is only one other company that also kind of does that but on a smaller
level because it just touches a smaller part of java (jdbc) and thats
oracle.
if (oracle) do this
else do that..
But oracle just do that because the can and they are big and they just want
everybody tied to there implementation of jdbc and there way of doing
With the mac it is just apple cant do the job
I look forward to the day that apple just drops the jvm development and let
sun do it.. Then we finally are liberated of that apple crap
johan
On Thu, Jul 17, 2008 at 3:50 PM, Brill Pappin [EMAIL PROTECTED] wrote:
Actually, I use a Mac now (vista prompted the purchase) and the Mac JVM is
actually not much different... in fact I don't notice anything at all when
working with java unless I'm doing something low lever like trying to load a
YourKit agent... but even then its not so different.
If your using swing and want to use the Mac LAF then you have to consider
the way the UI works, but even then its pretty portable.
I don't know if anyone is truly concerned about how well it works, but
there is the result of my recent experience.
- Brill
On 17-Jul-08, at 5:34 AM, Johan Compagner wrote:
if you target Java 5 by using webstart
then there isnt to much of a problem just with that
But yes you do have especially with the mac the different jvm problems as
you have with browsers :(
But happily not that many problems (there are way more different browsers
and platforms) and if i have to say only one really bugs me (mac)
johan
On Thu, Jul 17, 2008 at 10:50 AM, Martijn Dashorst
[EMAIL PROTECTED] wrote:
This only holds true if you have the full deployment environment under
control: Java for OS X is much different than Java for Windows, as
Johan can attest for. Just as with browsers you have to consider folks
that don't update their JDK's, and many corporate IT guys don't want
to update anything (including browsers!). So probably the easiest
deployment platform still remains the browser, since most shops do
have at least IE6 (while a shitty product in itself, it is manageable
to get it to work).
Deployment of anything, even web apps is an exciting thing in
Corporations.
Martijn
On Thu, Jul 17, 2008 at 10:18 AM, Michael Allan [EMAIL PROTECTED] wrote:
Zappaterrini, Larry wrote:
Your reason is a special instance of a much more general reason. Web
applications are much easier to deal with from a deployment
perspective than desktop applications.
I don't know, it's not difficult to set up an RMI server, or to deploy
a Swing client with Web Start (gives the user a single-click launch
from the browser). I've done it, and frankly it's easier than messing
with Tomcat and Web frameworks (no offense to Wicket).
And any developer who's coded a GUI using a proper toolkit, such as
Swing, will never willingly trade it for a Web framework. (A big part
of the attraction of Wicket is its Swing-like, component design. But
it can't approach the real thing.)
Also, there are firewall and security issues surrounding access to
central data repositories that web applications handle nicely.
That security coddling is a mixed blessing. The browser's sandbox,
for instance, makes it a complicated business to provide the user with
normal access to resources on the desktop. With Swing, your app is a
full peer on the desktop.
True, there are firewall and NAT hurdles for RMI clients. I googled
for RMI over HTTP and HTTP tunneling, and I didn't get a
comfortable, reassuring response. Why is that? It's a mystery... It
should be a well beaten path.
--
Michael Allan
Toronto, 647-436-4521
http://zelea.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.4 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: why are we coding Web apps?
Even Mac guys agree that development by Sun would be much better :-)
They still lag behind with java 1.6 (no current 1.6.0_07), do not
support powerpc for 1.6 anymore, can't run 32bit on 1.6 and can't run
64bit on 1.5 etc.
Yeah, java by apple suckzz !
Am 17.07.2008 um 16:08 schrieb Johan Compagner:
the mac jvm is really horrible
We really develop eclipse/swing applications for 8 years now and
throughout
all those years if there is a jvm specific problem
Its the mac, its always the mac, For me it is already so far that i
really
hate everything that is a mac.
When they released leopard i think we have to do stuff like this in
our
swing code base:
// MAC FIX
@Override
public Insets getMargin()
{
Insets insets = super.getMargin();
if (insets == null)
{
insets = new Insets(0, 0, 0, 0);
}
return insets;
}
Else we would get null pointers deep in there look and feel.
And that is just a small example. we have in our code base all over
the
place things like // mac fix
There is only one other company that also kind of does that but on a
smaller
level because it just touches a smaller part of java (jdbc) and thats
oracle.
if (oracle) do this
else do that..
But oracle just do that because the can and they are big and they
just want
everybody tied to there implementation of jdbc and there way of doing
With the mac it is just apple cant do the job
I look forward to the day that apple just drops the jvm development
and let
sun do it.. Then we finally are liberated of that apple crap
johan
On Thu, Jul 17, 2008 at 3:50 PM, Brill Pappin [EMAIL PROTECTED] wrote:
Actually, I use a Mac now (vista prompted the purchase) and the Mac
JVM is
actually not much different... in fact I don't notice anything at
all when
working with java unless I'm doing something low lever like trying
to load a
YourKit agent... but even then its not so different.
If your using swing and want to use the Mac LAF then you have to
consider
the way the UI works, but even then its pretty portable.
I don't know if anyone is truly concerned about how well it works,
but
there is the result of my recent experience.
- Brill
On 17-Jul-08, at 5:34 AM, Johan Compagner wrote:
if you target Java 5 by using webstart
then there isnt to much of a problem just with that
But yes you do have especially with the mac the different jvm
problems as
you have with browsers :(
But happily not that many problems (there are way more different
browsers
and platforms) and if i have to say only one really bugs me (mac)
johan
On Thu, Jul 17, 2008 at 10:50 AM, Martijn Dashorst
[EMAIL PROTECTED] wrote:
This only holds true if you have the full deployment environment
under
control: Java for OS X is much different than Java for Windows, as
Johan can attest for. Just as with browsers you have to consider
folks
that don't update their JDK's, and many corporate IT guys don't
want
to update anything (including browsers!). So probably the easiest
deployment platform still remains the browser, since most shops do
have at least IE6 (while a shitty product in itself, it is
manageable
to get it to work).
Deployment of anything, even web apps is an exciting thing in
Corporations.
Martijn
On Thu, Jul 17, 2008 at 10:18 AM, Michael Allan [EMAIL PROTECTED]
wrote:
Zappaterrini, Larry wrote:
Your reason is a special instance of a much more general
reason. Web
applications are much easier to deal with from a deployment
perspective than desktop applications.
I don't know, it's not difficult to set up an RMI server, or to
deploy
a Swing client with Web Start (gives the user a single-click
launch
from the browser). I've done it, and frankly it's easier than
messing
with Tomcat and Web frameworks (no offense to Wicket).
And any developer who's coded a GUI using a proper toolkit, such
as
Swing, will never willingly trade it for a Web framework. (A
big part
of the attraction of Wicket is its Swing-like, component
design. But
it can't approach the real thing.)
Also, there are firewall and security issues surrounding access to
central data repositories that web applications handle nicely.
That security coddling is a mixed blessing. The browser's
sandbox,
for instance, makes it a complicated business to provide the
user with
normal access to resources on the desktop. With Swing, your app
is a
full peer on the desktop.
True, there are firewall and NAT hurdles for RMI clients. I
googled
for RMI over HTTP and HTTP tunneling, and I didn't get a
comfortable, reassuring response. Why is that? It's a
mystery... It
should be a well beaten path.
--
Michael Allan
Toronto, 647-436-4521
http://zelea.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Become a Wicket expert, learn from the best:
Re: why are we coding Web apps?
Johan Compagner wrote: You guys want a Tunnel library that can tunnel RMI over http? http://sebster.com/tunnel/ works fine. We use it in our product Excellent, that's exactly what's needed. ... multiplexed RMI Socket Factories ... together with the HTTP tunnel this allows you to use bidirectional RMI over the internet, without having to worry about firewalls, HTTP proxies, or NAT routers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: why are we coding Web apps?
On Wed, Jul 16, 2008 at 8:00 PM, Michael Allan [EMAIL PROTECTED] wrote: 1. The user can seamlessly click into the application from external sites, and click back out again. 1 a. A Web client is good for demonstrating a new application, because it's convenient for casual users, who wish to try out the app. Most users have Web browsers pre-installed. They may not have Java, etc. Good enough for me :-) Gabor Szokoli - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: why are we coding Web apps?
Your reason is a special instance of a much more general reason. Web applications are much easier to deal with from a deployment perspective than desktop applications. Also, there are firewall and security issues surrounding access to central data repositories that web applications handle nicely. From: Michael Allan [mailto:[EMAIL PROTECTED] Sent: Wed 7/16/2008 2:00 PM To: users@wicket.apache.org Subject: why are we coding Web apps? Daan van Etten wrote: Yeah I know, problem are that our application are ajax heavy, and stateless and ajax does not cope well I've heard.. Maybe not within Wicket, I know too little of Wicket to draw a valid conclusion on that. But it is definitely possible. Look for example at the SproutCore development model. They create their application in Javascript and do requests to the backend to get records, save records, etc. Their application runs in the browser, making the server more like a stateless backend (from what I understood of SproutCore). I know it's possible (and done before) to build a Javascript application (or even desktop) that way. I'd rephrase that to: ... build a desktop application, or even a Javascript application (if you are into pain) You are generalizing beyond a traditional Web architecture (as Wicket supports), and that opens the field to other client/server architectures, in addition to the Web. And I can't think of a reason for coding a Web client, except this one: 1. The user can seamlessly click into the application from external sites, and click back out again. Can anyone think of another reason? Because otherwise, if I have an app that doesn't need cross-hyperlinks with the larger Web, then why should I code it as a Web app in the first place? Shouldn't I code the front end as a proper GUI, using a framework like Swing? I'm asking myself this question. And in my case I come up with one additional reason, which is just a special case of (1): 1 a. A Web client is good for demonstrating a new application, because it's convenient for casual users, who wish to try out the app. Most users have Web browsers pre-installed. They may not have Java, etc. -- Michael Allan Toronto, 647-436-4521 http://zelea.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. _
