You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by cowwoc <co...@bbs.darktech.org> on 2008/10/22 15:44:58 UTC
Proposal: the browser as a desktop client
Hi,
I'd like to propose we leverage existing Java to Javascript compilers to
improve Wicket on a couple of fronts. If you think of the web browser as a
desktop client involved in a client-server architecture then it becomes
obvious that Wicket is currently asking the server to handle a lot of logic
on behalf of the client. It does this because it's easier to develop in Java
than in Javascript. In an ideal world, the server should only see HTML forms
in two states:
- their initial state (sent to the client)
- their submitted state (merged into the database)
The client would be able to communicate with web services in between to
update the client-side state but most applications won't even need this. The
vast majority of form manipulation (adding rows, data validation) can be
handled completely on the client-end.
I foresee the following benefits:
- Vastly simplified logic: A lot of resources have been spent building the
HTML parser and classes related to server-side form manipulation. All these
are built in for free in JS. For example, interacting with HTML elements and
IDs is far easier than in Java code.
- Improved responsiveness for end-users
- Improved server scalability
- "Nice" URLs, both for humans and for web crawlers. This would also open up
the door for RESTful implementations.
This would be different from GWT. You would benefit from the modularity of
Wicket, coding HTML and CSS in their native languages. The only difference
is that you'd now be manipulating dynamic forms on the client-end instead of
the server-end.
Let me know what you think.
Gili
--
View this message in context: http://www.nabble.com/Proposal%3A-the-browser-as-a-desktop-client-tp20111040p20111040.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Proposal: the browser as a desktop client
Posted by cowwoc <co...@bbs.darktech.org>.
I just to clarify one point. You would still have three types of components:
HTML
CSS
Java
You would still be binding the Java code against HTML IDs (clean separation
of concerns). The only thing that would change is where the Java code
executes.
--
View this message in context: http://www.nabble.com/Proposal%3A-the-browser-as-a-desktop-client-tp20111040p20111247.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Proposal: the browser as a desktop client
Posted by Igor Vaynberg <ig...@gmail.com>.
so write a prototype and present it to the community. we are all eyes.
-igor
On Thu, Oct 23, 2008 at 2:40 PM, cowwoc <co...@bbs.darktech.org> wrote:
>
> GWT generates business logic, HTML and CSS from Java code; as opposed to
> letting you bind business logic written in Java against normal HTML files.
> It doesn't have a clean separation of concerns like Wicket.
>
> Ask yourself this, why does the client rely on the server to do dynamic form
> manipulation on its behalf? Is it because the server really cares about the
> intermediate form states or is it because we don't want to write this logic
> in Javascript?
>
> Gili
>
>
> Johan Compagner wrote:
>>
>> use GWT because thats the key difference between wicket and gwt
>>
>> I only see some things like validators that could be precompiled not th
>> complete webapp and all your current page/panel/component/html code
>>
>>
>> On Wed, Oct 22, 2008 at 3:44 PM, cowwoc <co...@bbs.darktech.org> wrote:
>>
>>>
>>> Hi,
>>>
>>> I'd like to propose we leverage existing Java to Javascript compilers to
>>> improve Wicket on a couple of fronts. If you think of the web browser as
>>> a
>>> desktop client involved in a client-server architecture then it becomes
>>> obvious that Wicket is currently asking the server to handle a lot of
>>> logic
>>> on behalf of the client. It does this because it's easier to develop in
>>> Java
>>> than in Javascript. In an ideal world, the server should only see HTML
>>> forms
>>> in two states:
>>>
>>> - their initial state (sent to the client)
>>> - their submitted state (merged into the database)
>>>
>>> The client would be able to communicate with web services in between to
>>> update the client-side state but most applications won't even need this.
>>> The
>>> vast majority of form manipulation (adding rows, data validation) can be
>>> handled completely on the client-end.
>>>
>>> I foresee the following benefits:
>>>
>>> - Vastly simplified logic: A lot of resources have been spent building
>>> the
>>> HTML parser and classes related to server-side form manipulation. All
>>> these
>>> are built in for free in JS. For example, interacting with HTML elements
>>> and
>>> IDs is far easier than in Java code.
>>> - Improved responsiveness for end-users
>>> - Improved server scalability
>>> - "Nice" URLs, both for humans and for web crawlers. This would also open
>>> up
>>> the door for RESTful implementations.
>>>
>>> This would be different from GWT. You would benefit from the modularity
>>> of
>>> Wicket, coding HTML and CSS in their native languages. The only
>>> difference
>>> is that you'd now be manipulating dynamic forms on the client-end instead
>>> of
>>> the server-end.
>>>
>>> Let me know what you think.
>>>
>>> Gili
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Proposal%3A-the-browser-as-a-desktop-client-tp20111040p20111040.html
>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Proposal%3A-the-browser-as-a-desktop-client-tp20111040p20140090.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Proposal: the browser as a desktop client
Posted by cowwoc <co...@bbs.darktech.org>.
Johan,
I'm not saying you should move *everything* over to the client. I'm saying
that most form manipulation can take place without querying the database,
especially on a per-request basis. Adding rows and cell validation tend to
rely on at most one database lookup (during the initial request). Even if
you *do* need to query the database before carrying out some operation (I
dare say this is a minority situation) you can issue a web service call to
do just that. Wicket's current implementation assumes that by default form
manipulation should take place on the server. I am saying that by default it
should take place on the client. The same functionality is still possible,
it's just your default that changes. And as I mentioned, this approach has
many benefits besides performance.
Gili
Johan Compagner wrote:
>
> because on the server the business logic runs
> Its a complete different paradigm
>
> if thinks that are now done in onclick() or onsubmit() would run on the
> client
> what would be possible then? Currently many people just call DAO's there
> (spring stuff and so on)
>
> johan
>
>
> On Thu, Oct 23, 2008 at 11:40 PM, cowwoc <co...@bbs.darktech.org> wrote:
>
>>
>> GWT generates business logic, HTML and CSS from Java code; as opposed to
>> letting you bind business logic written in Java against normal HTML
>> files.
>> It doesn't have a clean separation of concerns like Wicket.
>>
>> Ask yourself this, why does the client rely on the server to do dynamic
>> form
>> manipulation on its behalf? Is it because the server really cares about
>> the
>> intermediate form states or is it because we don't want to write this
>> logic
>> in Javascript?
>>
>> Gili
>>
>>
>> Johan Compagner wrote:
>> >
>> > use GWT because thats the key difference between wicket and gwt
>> >
>> > I only see some things like validators that could be precompiled not th
>> > complete webapp and all your current page/panel/component/html code
>> >
>> >
>> > On Wed, Oct 22, 2008 at 3:44 PM, cowwoc <co...@bbs.darktech.org>
>> wrote:
>> >
>> >>
>> >> Hi,
>> >>
>> >> I'd like to propose we leverage existing Java to Javascript compilers
>> to
>> >> improve Wicket on a couple of fronts. If you think of the web browser
>> as
>> >> a
>> >> desktop client involved in a client-server architecture then it
>> becomes
>> >> obvious that Wicket is currently asking the server to handle a lot of
>> >> logic
>> >> on behalf of the client. It does this because it's easier to develop
>> in
>> >> Java
>> >> than in Javascript. In an ideal world, the server should only see HTML
>> >> forms
>> >> in two states:
>> >>
>> >> - their initial state (sent to the client)
>> >> - their submitted state (merged into the database)
>> >>
>> >> The client would be able to communicate with web services in between
>> to
>> >> update the client-side state but most applications won't even need
>> this.
>> >> The
>> >> vast majority of form manipulation (adding rows, data validation) can
>> be
>> >> handled completely on the client-end.
>> >>
>> >> I foresee the following benefits:
>> >>
>> >> - Vastly simplified logic: A lot of resources have been spent building
>> >> the
>> >> HTML parser and classes related to server-side form manipulation. All
>> >> these
>> >> are built in for free in JS. For example, interacting with HTML
>> elements
>> >> and
>> >> IDs is far easier than in Java code.
>> >> - Improved responsiveness for end-users
>> >> - Improved server scalability
>> >> - "Nice" URLs, both for humans and for web crawlers. This would also
>> open
>> >> up
>> >> the door for RESTful implementations.
>> >>
>> >> This would be different from GWT. You would benefit from the
>> modularity
>> >> of
>> >> Wicket, coding HTML and CSS in their native languages. The only
>> >> difference
>> >> is that you'd now be manipulating dynamic forms on the client-end
>> instead
>> >> of
>> >> the server-end.
>> >>
>> >> Let me know what you think.
>> >>
>> >> Gili
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/Proposal%3A-the-browser-as-a-desktop-client-tp20111040p20111040.html
>> >> Sent from the Wicket - User mailing list archive at Nabble.com.
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Proposal%3A-the-browser-as-a-desktop-client-tp20111040p20140090.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Proposal%3A-the-browser-as-a-desktop-client-tp20111040p20140645.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Proposal: the browser as a desktop client
Posted by Johan Compagner <jc...@gmail.com>.
because on the server the business logic runs
Its a complete different paradigm
if thinks that are now done in onclick() or onsubmit() would run on the
client
what would be possible then? Currently many people just call DAO's there
(spring stuff and so on)
johan
On Thu, Oct 23, 2008 at 11:40 PM, cowwoc <co...@bbs.darktech.org> wrote:
>
> GWT generates business logic, HTML and CSS from Java code; as opposed to
> letting you bind business logic written in Java against normal HTML files.
> It doesn't have a clean separation of concerns like Wicket.
>
> Ask yourself this, why does the client rely on the server to do dynamic
> form
> manipulation on its behalf? Is it because the server really cares about the
> intermediate form states or is it because we don't want to write this logic
> in Javascript?
>
> Gili
>
>
> Johan Compagner wrote:
> >
> > use GWT because thats the key difference between wicket and gwt
> >
> > I only see some things like validators that could be precompiled not th
> > complete webapp and all your current page/panel/component/html code
> >
> >
> > On Wed, Oct 22, 2008 at 3:44 PM, cowwoc <co...@bbs.darktech.org> wrote:
> >
> >>
> >> Hi,
> >>
> >> I'd like to propose we leverage existing Java to Javascript compilers to
> >> improve Wicket on a couple of fronts. If you think of the web browser as
> >> a
> >> desktop client involved in a client-server architecture then it becomes
> >> obvious that Wicket is currently asking the server to handle a lot of
> >> logic
> >> on behalf of the client. It does this because it's easier to develop in
> >> Java
> >> than in Javascript. In an ideal world, the server should only see HTML
> >> forms
> >> in two states:
> >>
> >> - their initial state (sent to the client)
> >> - their submitted state (merged into the database)
> >>
> >> The client would be able to communicate with web services in between to
> >> update the client-side state but most applications won't even need this.
> >> The
> >> vast majority of form manipulation (adding rows, data validation) can be
> >> handled completely on the client-end.
> >>
> >> I foresee the following benefits:
> >>
> >> - Vastly simplified logic: A lot of resources have been spent building
> >> the
> >> HTML parser and classes related to server-side form manipulation. All
> >> these
> >> are built in for free in JS. For example, interacting with HTML elements
> >> and
> >> IDs is far easier than in Java code.
> >> - Improved responsiveness for end-users
> >> - Improved server scalability
> >> - "Nice" URLs, both for humans and for web crawlers. This would also
> open
> >> up
> >> the door for RESTful implementations.
> >>
> >> This would be different from GWT. You would benefit from the modularity
> >> of
> >> Wicket, coding HTML and CSS in their native languages. The only
> >> difference
> >> is that you'd now be manipulating dynamic forms on the client-end
> instead
> >> of
> >> the server-end.
> >>
> >> Let me know what you think.
> >>
> >> Gili
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/Proposal%3A-the-browser-as-a-desktop-client-tp20111040p20111040.html
> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Proposal%3A-the-browser-as-a-desktop-client-tp20111040p20140090.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Proposal: the browser as a desktop client
Posted by cowwoc <co...@bbs.darktech.org>.
GWT generates business logic, HTML and CSS from Java code; as opposed to
letting you bind business logic written in Java against normal HTML files.
It doesn't have a clean separation of concerns like Wicket.
Ask yourself this, why does the client rely on the server to do dynamic form
manipulation on its behalf? Is it because the server really cares about the
intermediate form states or is it because we don't want to write this logic
in Javascript?
Gili
Johan Compagner wrote:
>
> use GWT because thats the key difference between wicket and gwt
>
> I only see some things like validators that could be precompiled not th
> complete webapp and all your current page/panel/component/html code
>
>
> On Wed, Oct 22, 2008 at 3:44 PM, cowwoc <co...@bbs.darktech.org> wrote:
>
>>
>> Hi,
>>
>> I'd like to propose we leverage existing Java to Javascript compilers to
>> improve Wicket on a couple of fronts. If you think of the web browser as
>> a
>> desktop client involved in a client-server architecture then it becomes
>> obvious that Wicket is currently asking the server to handle a lot of
>> logic
>> on behalf of the client. It does this because it's easier to develop in
>> Java
>> than in Javascript. In an ideal world, the server should only see HTML
>> forms
>> in two states:
>>
>> - their initial state (sent to the client)
>> - their submitted state (merged into the database)
>>
>> The client would be able to communicate with web services in between to
>> update the client-side state but most applications won't even need this.
>> The
>> vast majority of form manipulation (adding rows, data validation) can be
>> handled completely on the client-end.
>>
>> I foresee the following benefits:
>>
>> - Vastly simplified logic: A lot of resources have been spent building
>> the
>> HTML parser and classes related to server-side form manipulation. All
>> these
>> are built in for free in JS. For example, interacting with HTML elements
>> and
>> IDs is far easier than in Java code.
>> - Improved responsiveness for end-users
>> - Improved server scalability
>> - "Nice" URLs, both for humans and for web crawlers. This would also open
>> up
>> the door for RESTful implementations.
>>
>> This would be different from GWT. You would benefit from the modularity
>> of
>> Wicket, coding HTML and CSS in their native languages. The only
>> difference
>> is that you'd now be manipulating dynamic forms on the client-end instead
>> of
>> the server-end.
>>
>> Let me know what you think.
>>
>> Gili
>> --
>> View this message in context:
>> http://www.nabble.com/Proposal%3A-the-browser-as-a-desktop-client-tp20111040p20111040.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Proposal%3A-the-browser-as-a-desktop-client-tp20111040p20140090.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Proposal: the browser as a desktop client
Posted by Johan Compagner <jc...@gmail.com>.
use GWT because thats the key difference between wicket and gwt
I only see some things like validators that could be precompiled not th
complete webapp and all your current page/panel/component/html code
On Wed, Oct 22, 2008 at 3:44 PM, cowwoc <co...@bbs.darktech.org> wrote:
>
> Hi,
>
> I'd like to propose we leverage existing Java to Javascript compilers to
> improve Wicket on a couple of fronts. If you think of the web browser as a
> desktop client involved in a client-server architecture then it becomes
> obvious that Wicket is currently asking the server to handle a lot of logic
> on behalf of the client. It does this because it's easier to develop in
> Java
> than in Javascript. In an ideal world, the server should only see HTML
> forms
> in two states:
>
> - their initial state (sent to the client)
> - their submitted state (merged into the database)
>
> The client would be able to communicate with web services in between to
> update the client-side state but most applications won't even need this.
> The
> vast majority of form manipulation (adding rows, data validation) can be
> handled completely on the client-end.
>
> I foresee the following benefits:
>
> - Vastly simplified logic: A lot of resources have been spent building the
> HTML parser and classes related to server-side form manipulation. All these
> are built in for free in JS. For example, interacting with HTML elements
> and
> IDs is far easier than in Java code.
> - Improved responsiveness for end-users
> - Improved server scalability
> - "Nice" URLs, both for humans and for web crawlers. This would also open
> up
> the door for RESTful implementations.
>
> This would be different from GWT. You would benefit from the modularity of
> Wicket, coding HTML and CSS in their native languages. The only difference
> is that you'd now be manipulating dynamic forms on the client-end instead
> of
> the server-end.
>
> Let me know what you think.
>
> Gili
> --
> View this message in context:
> http://www.nabble.com/Proposal%3A-the-browser-as-a-desktop-client-tp20111040p20111040.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>