Home » Eclipse Projects » Remote Application Platform (RAP) » New RAP Client - where to start?
| New RAP Client - where to start? [message #92471] |
Tue, 10 June 2008 03:55  |
Eclipse User |
|
|
|
Originally posted by: gmccreath.xbiosystems.com
Hi all,
This is my first posting to this group.
I am interested in looking at how to create a new client type for RAP.
Specifically, I would like to investigate whether an Adobe Flash/Flex
client is possible.
I am coming from and echo2 / karora.org background and am familiar with
the way that toolset does its client/host synchronization and rendering.
Quite clean and easy to understand. Property change events and child
add/remove are accumulated and sent as XML to the client - and vice versa
plus 'actions'. No javascript passes between client and host.
I have been poking around the RAP source but do not see any clear place
where I could start. It seems to be very javascript oriented - even the
newly separated rwt package (with qx7 removed) still looks javascript
oriented.
If I were to create a flex client I would not want to send javascript out
to the client - I would either send XML or use blazeDS to serialize
objects out. Something like that.
My questions are:
* Is it yet possible to create a new client for RAP?
* If so, what is my starting point ...
* (dare I ask) Is there any documentation or articles?
Perhaps one of the RAP crew could spend 20mins and post a
detailed-as-possible-in-20-mins explanation here or on the wiki about how
this works and where it is headed.
Many thanks.
Greg.
|
|
|
| Re: New RAP Client - where to start? [message #92797 is a reply to message #92471] |
Wed, 11 June 2008 13:24  |
| Eclipse User |
|
|
|
Originally posted by: fappel.innoopract.com
Hi,
with the q07 fragment we started the separation-process of client and
serverside technology. But as you've noticed there is still a lot of
javascript stuff around in the host-fragment. So this was just the
beginning and not the end. The main reason we decided to go on with
fragments is that we are able to work on the integration of q08 without
compromising the working system.
But by choosing that approach we are also able to work on a clear
demarcations of server-side stuff, communication and client-side stuff.
_____ _____
| | | |
| | | |
|_____| |_____|
| |
|_______________________|
Ciao
Frank
-----Ursprüngliche Nachricht-----
Von: Greg [mailto:gmccreath@xbiosystems.com]
Bereitgestellt: Dienstag, 10. Juni 2008 05:55
Bereitgestellt in: eclipse.technology.rap
Unterhaltung: New RAP Client - where to start?
Betreff: New RAP Client - where to start?
Hi all,
This is my first posting to this group.
I am interested in looking at how to create a new client type for RAP.
Specifically, I would like to investigate whether an Adobe Flash/Flex
client is possible.
I am coming from and echo2 / karora.org background and am familiar with
the way that toolset does its client/host synchronization and rendering.
Quite clean and easy to understand. Property change events and child
add/remove are accumulated and sent as XML to the client - and vice
versa
plus 'actions'. No javascript passes between client and host.
I have been poking around the RAP source but do not see any clear place
where I could start. It seems to be very javascript oriented - even the
newly separated rwt package (with qx7 removed) still looks javascript
oriented.
If I were to create a flex client I would not want to send javascript
out
to the client - I would either send XML or use blazeDS to serialize
objects out. Something like that.
My questions are:
* Is it yet possible to create a new client for RAP?
* If so, what is my starting point ...
* (dare I ask) Is there any documentation or articles?
Perhaps one of the RAP crew could spend 20mins and post a
detailed-as-possible-in-20-mins explanation here or on the wiki about
how
this works and where it is headed.
Many thanks.
Greg.
|
|
|
| Re: New RAP Client - where to start? [message #92812 is a reply to message #92471] |
Wed, 11 June 2008 13:47 |
| Eclipse User |
|
|
|
Originally posted by: fappel.innoopract.com
Hi,
with the q07 fragment we started the separation-process of client and
serverside technology. But as you've noticed there is still a lot of
javascript stuff around in the host-fragment. So this was just the
beginning and not the end. The main reason we decided to go on with
fragments is that we are able to work on the integration of q08 without
compromising the working system.
But by choosing that approach we are also able to work on a clear
demarcations of server-side stuff, communication and client-side stuff.
Currently we use the widget's lifecycle adapter to serialize its state
to the client. This is done by translating the changes of widget
attributes into javascript statements. This statements get transported
to the client and a little hook application on the clientside executes
them. Of course this couples the serverside implementation tight to the
clientside technology.
To me in the future it should look something like this:
_____ _____
| | | |
| S | | C |
|_____| |_____|
| |
|<- marshal/unmarshaling ->|
|__________________________|
|
Request-/Response Protocol
S stands for the Serverside, C for the clientside. State changes should
no longer be translated into javascript statements understandable only
for a certain client technology, but let's say marshaled
Ciao
Frank
-----Ursprüngliche Nachricht-----
Von: Greg [mailto:gmccreath@xbiosystems.com]
Bereitgestellt: Dienstag, 10. Juni 2008 05:55
Bereitgestellt in: eclipse.technology.rap
Unterhaltung: New RAP Client - where to start?
Betreff: New RAP Client - where to start?
Hi all,
This is my first posting to this group.
I am interested in looking at how to create a new client type for RAP.
Specifically, I would like to investigate whether an Adobe Flash/Flex
client is possible.
I am coming from and echo2 / karora.org background and am familiar with
the way that toolset does its client/host synchronization and rendering.
Quite clean and easy to understand. Property change events and child
add/remove are accumulated and sent as XML to the client - and vice
versa
plus 'actions'. No javascript passes between client and host.
I have been poking around the RAP source but do not see any clear place
where I could start. It seems to be very javascript oriented - even the
newly separated rwt package (with qx7 removed) still looks javascript
oriented.
If I were to create a flex client I would not want to send javascript
out
to the client - I would either send XML or use blazeDS to serialize
objects out. Something like that.
My questions are:
* Is it yet possible to create a new client for RAP?
* If so, what is my starting point ...
* (dare I ask) Is there any documentation or articles?
Perhaps one of the RAP crew could spend 20mins and post a
detailed-as-possible-in-20-mins explanation here or on the wiki about
how
this works and where it is headed.
Many thanks.
Greg.
|
|
|
| Re: New RAP Client - where to start? [message #92827 is a reply to message #92471] |
Wed, 11 June 2008 14:12 |
| Eclipse User |
|
|
|
Originally posted by: fappel.innoopract.com
Hi,
sorry about the accidently posted message which wasn't finished. Here
comes the whole thing :-)
with the q07 fragment we started the separation-process of client- and
serverside technology. But as you've noticed there is still a lot of
javascript stuff around in the host-fragment. So this was just the
beginning and by far not the end. The main reason we decided to go on
with fragments is that we are able to work on the integration of q08
without compromising the working system.
But by choosing that approach we are also able to work on a clear
demarcations of serverside-, communication- and clientside stuff.
Currently we use the widget's lifecycle adapter to serialize its state
to the client. This is done by translating the changes of widget
attributes into javascript statements. This statements get transported
to the client and a little hook application on the clientside executes
them. Of course this couples the serverside implementation tightly to
the clientside technology. This means that if you want to use a
different clientside technology, you must write LCAs for each widget
from scratch by reimplementing the whole wheel :(
To me in the future it should look something like this:
_____ ¬_____
| | | |
| S | | C |
|_____| |_____|
| |
|<- marshal/unmarshaling ->|
|__________________________|
|
Request-/Response Protocol
S stands for the Serverside, C for the clientside. State changes should
no longer be translated into javascript statements understandable only
for a certain clientside technology. Instead the changes should be let's
say marshaled into a clientside independent protocol. So it would make
no difference for the server whatever technology is used on the
clientside. The clientside can be a browser using qooxdoo, flash or it
could even be a special SWT-Client etc.
So at the moment I think it's still too early to write an full blown own
clientside RAP representation, without taking the risk of having a lot
of rework to do in the future.
Ciao
Frank
-----Ursprüngliche Nachricht-----
Von: Greg [mailto:gmccreath@xbiosystems.com]
Bereitgestellt: Dienstag, 10. Juni 2008 05:55
Bereitgestellt in: eclipse.technology.rap
Unterhaltung: New RAP Client - where to start?
Betreff: New RAP Client - where to start?
Hi all,
This is my first posting to this group.
I am interested in looking at how to create a new client type for RAP.
Specifically, I would like to investigate whether an Adobe Flash/Flex
client is possible.
I am coming from and echo2 / karora.org background and am familiar with
the way that toolset does its client/host synchronization and rendering.
Quite clean and easy to understand. Property change events and child
add/remove are accumulated and sent as XML to the client - and vice
versa
plus 'actions'. No javascript passes between client and host.
I have been poking around the RAP source but do not see any clear place
where I could start. It seems to be very javascript oriented - even the
newly separated rwt package (with qx7 removed) still looks javascript
oriented.
If I were to create a flex client I would not want to send javascript
out
to the client - I would either send XML or use blazeDS to serialize
objects out. Something like that.
My questions are:
* Is it yet possible to create a new client for RAP?
* If so, what is my starting point ...
* (dare I ask) Is there any documentation or articles?
Perhaps one of the RAP crew could spend 20mins and post a
detailed-as-possible-in-20-mins explanation here or on the wiki about
how
this works and where it is headed.
Many thanks.
Greg.
|
|
|
| Re: New RAP Client - where to start? [message #93016 is a reply to message #92827] |
Thu, 12 June 2008 07:43 |
| Eclipse User |
|
|
|
Originally posted by: gmccreath.xbiosystems.com
Thanks for the honest answer Frank.
I am glad to see that it will be heading in that direction. I had the
feeling that the Q7 separation was just a starting point.
Yes, I fired up FireBug to inspect the traffic between the client and
server and was a little surprised to see javascript being used there, so I
followed it back down 'into the hole' at the server to RWTLifeCycle to see
how the meta-data / render stuff looked. I don't admit to understanding
it, but can see how the separation has begun.
Just throwing in my $0.10 worth, I kind of like that way that the echo2
framework does it. The server-side model components are 'observed' for
changes in properties and component additions / deletions (using JavaBeans
PropertyChangeEvent stuff) and a global 'delta' is kept (not a map for
each model component). The delta is rendered for transmission to the
client using static methods on component 'peers'. There is a one-to-one
between a component (eg button) and its peer.
The client is the same, it bundles up changes and submits them all to the
server whenever a server-call is required (an 'action' or event handler is
fired).
The client state is first sync'd back with the server, then the pending
action / event is performed, the resulting server model delta is rendered
out to the client. Nice and MVC.
All this using XML to and fro. Admittedly, the echo2 XML is *very*
verbose due to the fact that it sends styling with every response.
I do like the way that it observes the server-side model using javabeans
property change events - unlike RAP, which I believe does a visitation on
all server-side model components for each-and-every response getting
widget lifecycle adapters and interacting with them. (is that right?)
So, any high level ideas as to what your new protocol will look like? The
'A' in 'RAP' = 'Ajax' = XML as the container. ... ?
dare I ask ...
As always, your time is appreciated. Many thanks.
Greg.
|
|
|
| Re: New RAP Client - where to start? [message #93169 is a reply to message #93016] |
Fri, 13 June 2008 03:24 |
| Eclipse User |
|
|
|
Originally posted by: m.n.com
I think Echo3 has worked hard to resolve the verbose/chattiness.
IGreg wrote:
>
> Thanks for the honest answer Frank.
> I am glad to see that it will be heading in that direction. I had the
> feeling that the Q7 separation was just a starting point.
>
> Yes, I fired up FireBug to inspect the traffic between the client and
> server and was a little surprised to see javascript being used there, so
> I followed it back down 'into the hole' at the server to RWTLifeCycle to
> see how the meta-data / render stuff looked. I don't admit to
> understanding it, but can see how the separation has begun.
>
> Just throwing in my $0.10 worth, I kind of like that way that the echo2
> framework does it. The server-side model components are 'observed' for
> changes in properties and component additions / deletions (using
> JavaBeans PropertyChangeEvent stuff) and a global 'delta' is kept (not a
> map for each model component). The delta is rendered for transmission
> to the client using static methods on component 'peers'. There is a
> one-to-one between a component (eg button) and its peer.
> The client is the same, it bundles up changes and submits them all to
> the server whenever a server-call is required (an 'action' or event
> handler is fired).
>
> The client state is first sync'd back with the server, then the pending
> action / event is performed, the resulting server model delta is
> rendered out to the client. Nice and MVC.
>
> All this using XML to and fro. Admittedly, the echo2 XML is *very*
> verbose due to the fact that it sends styling with every response.
> I do like the way that it observes the server-side model using javabeans
> property change events - unlike RAP, which I believe does a visitation
> on all server-side model components for each-and-every response getting
> widget lifecycle adapters and interacting with them. (is that right?)
>
> So, any high level ideas as to what your new protocol will look like?
> The 'A' in 'RAP' = 'Ajax' = XML as the container. ... ?
>
> dare I ask ...
>
> As always, your time is appreciated. Many thanks.
>
> Greg.
>
>
|
|
|
| Re: New RAP Client - where to start? [message #93517 is a reply to message #93016] |
Mon, 16 June 2008 07:29 |
| Eclipse User |
|
|
|
Originally posted by: fappel.innoopract.com
Hi,
it's not clear how the protocol will look like yet. Using XML is a
possibility, but we'll have to check the impact on the possible client
side techologies.
Ciao
Frank
-----Ursprüngliche Nachricht-----
Von: Greg [mailto:gmccreath@xbiosystems.com]
Bereitgestellt: Donnerstag, 12. Juni 2008 09:43
Bereitgestellt in: eclipse.technology.rap
Unterhaltung: New RAP Client - where to start?
Betreff: Re: New RAP Client - where to start?
Thanks for the honest answer Frank.
I am glad to see that it will be heading in that direction. I had the
feeling that the Q7 separation was just a starting point.
Yes, I fired up FireBug to inspect the traffic between the client and
server and was a little surprised to see javascript being used there, so
I
followed it back down 'into the hole' at the server to RWTLifeCycle to
see
how the meta-data / render stuff looked. I don't admit to understanding
it, but can see how the separation has begun.
Just throwing in my $0.10 worth, I kind of like that way that the echo2
framework does it. The server-side model components are 'observed' for
changes in properties and component additions / deletions (using
JavaBeans
PropertyChangeEvent stuff) and a global 'delta' is kept (not a map for
each model component). The delta is rendered for transmission to the
client using static methods on component 'peers'. There is a one-to-one
between a component (eg button) and its peer.
The client is the same, it bundles up changes and submits them all to
the
server whenever a server-call is required (an 'action' or event handler
is
fired).
The client state is first sync'd back with the server, then the pending
action / event is performed, the resulting server model delta is
rendered
out to the client. Nice and MVC.
All this using XML to and fro. Admittedly, the echo2 XML is *very*
verbose due to the fact that it sends styling with every response.
I do like the way that it observes the server-side model using javabeans
property change events - unlike RAP, which I believe does a visitation
on
all server-side model components for each-and-every response getting
widget lifecycle adapters and interacting with them. (is that right?)
So, any high level ideas as to what your new protocol will look like?
The
'A' in 'RAP' = 'Ajax' = XML as the container. ... ?
dare I ask ...
As always, your time is appreciated. Many thanks.
Greg.
|
|
|
Goto Forum:
Current Time: Thu Apr 25 04:44:07 GMT 2024
Powered by FUDForum. Page generated in 0.03023 seconds |
] 
Search
Help
Register
Login
Home
