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]