|
| Re: Architecture overview [message #55659 is a reply to message #55380] |
Fri, 26 October 2007 06:27   |
Eclipse User |
|
|
|
Originally posted by: fappel.innoopract.com
Hi,
unfortunately there is no such overall documentation available at the
moment. The javascript creation differs from GWT since we do not translate
javacode into javascript. But we think about to split the RWT library into
lets say a common part (containing the current API and serverside
implementations) and rendering fragments. Technically such a split wouldn't
be a big deal.
The one and only fragment at the time being would be the fragment using
qooxdoo. But having that split in place it would be easily possible to
evaluate and implement the usage of different client side technologies (e.g.
GWT, Silverlight, Flash, Applets etc) by creating additional rendering
fragments. As RAP separates client-side technology strictly from the
application development those fragments could be used interchangeable
without changing any line of code in existing applications. Even more,
having multiple rendering fragments the RAP runtime could select the best
fitting solution for the browser capabilities used on the client side.
The only downside of this approach I currently see lays by the poor custom
widget developer that may have to support those different technologies...
But anyway that all is still future.
Ciao
Frank
"Xavier "M
|
|
|
|
| Re: Architecture overview [message #56130 is a reply to message #55965] |
Mon, 29 October 2007 10:30 |
 Xavier Méhaut
Messages: 133
Registered: July 2009 |
Senior Member |
|
|
Thanks a lot for all this information, I'm going to read quite soon..
To go further, can you explain quickly the swt to js translating scheme
you use to build the WEB UI? Is it a kind of X-server developped uppon js?
regards
Xavier
ps : it is otherwise a good news to know that ther coulbe be different
rendering possibilities in the future... RAP is really very innovative and
go further than GWT (I used t use with great pleasure daily) because it
offers the eclipse plaform to client6server developments, like J2EE offers
n-tier development to former JSP/Php applications. regards
> Hi,
> in this context it might be interesting for all of you what we are doing
> in the platform-incubator where we try to make
> Eclipse-Core-Technologies with GWT.
> See http://wiki.eclipse.org/Eclipse_Techs_For_GWT
> Tom
> Frank Appel schrieb:
>> Hi,
>>
>> unfortunately there is no such overall documentation available at the
>> moment. The javascript creation differs from GWT since we do not translate
>> javacode into javascript. But we think about to split the RWT library into
>> lets say a common part (containing the current API and serverside
>> implementations) and rendering fragments. Technically such a split wouldn't
>> be a big deal.
>>
>> The one and only fragment at the time being would be the fragment using
>> qooxdoo. But having that split in place it would be easily possible to
>> evaluate and implement the usage of different client side technologies
(e.g.
>> GWT, Silverlight, Flash, Applets etc) by creating additional rendering
>> fragments. As RAP separates client-side technology strictly from the
>> application development those fragments could be used interchangeable
>> without changing any line of code in existing applications. Even more,
>> having multiple rendering fragments the RAP runtime could select the best
>> fitting solution for the browser capabilities used on the client side.
>>
>> The only downside of this approach I currently see lays by the poor custom
>> widget developer that may have to support those different technologies...
>> But anyway that all is still future.
>>
>>
>> Ciao
>> Frank
>>
>>
>> "Xavier "Méhaut"" <xavier.mehaut@free.fr> schrieb im Newsbeitrag
>> news:eea2975c000612e6640afeff968941a6$1@www.eclipse.org...
>>> Hello,
>>> I would like to know if there is a documentation about the overall
>>> architecture of the project. I would also like to know the process of
>>> translating eclipse code to javascript one. Is it the same pattern as for
>>> GWT? Have you thought of using GWT javascript target code instead of
>>> quooxdoo for compliance?
>>> best regards
>>> Xavier
>>>
>>
>>
Thanks a lot for all this information, I'm going to read quite soon..
To go further, can you explain quickly the swt to js translating scheme
you use to build the WEB UI? Is it a kind of X-server developped uppon js?
regards
Xavier
ps : it is otherwise a good news to know that ther coulbe be different
rendering possibilities in the future... RAP is really very innovative and
go further than GWT (I used t use with great pleasure daily) because it
offers the eclipse plaform to client6server developments, like J2EE offers
n-tier development to former JSP/Php applications. regards
|
|
|
| Re: Architecture overview [message #57497 is a reply to message #56130] |
Mon, 05 November 2007 09:12 |
| Eclipse User |
|
|
|
Originally posted by: fappel.innoopract.com
Hi,
it's not that complicated than providing a JS-based X-server implementation.
It is more like a mapping between client-side and server-side widgets. This
means for each and every widget of the widget-tree that exists on the
server-side a client-side representation is created. Both trees are
synchronized using AJAX requests. Status changes of widgets on the
client-side are submitted and applied to the respective widgets on the
server-side. After that eventhandler invokation takes place. For example a
listener that was added to a push button gets executed. The eventhandling
itself may changes the status of the server-side widgets. Those changes are
detected and send back to the client, where they get applied to the
respective client-side widgets - request-LifeCycle complete.
For more information the custom widget tutorial may a good starting point:
http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse. rap.help/help/html/advanced/custom-widget.html
Ciao
Frank
"Xavier "M
|
|
|
| Re: Architecture overview [message #57762 is a reply to message #57497] |
Mon, 05 November 2007 14:21 |
Xavier Méhaut
Messages: 133
Registered: July 2009 |
Senior Member |
|
|
Hi Franck,
Thanks a lot for these information again. It is roughly as I've seen how
it could work. I've another question about the memory print ; is it not
too expensive? Have you also tied to do benchmarks in mandatory bandwith
, or amounbt of requests needed for umdating all the Window? What is a
gain proportion between a traditional web navigation through pages and
with RAP, or even GWT for instance?
I would like to have such comparisons in order to be able to choose this
technology instead of another (up to now I focus more on GWT)...
Could it be envisageable to deport as with GWT all the UI on the client
side without having the UI mirroring on the server side too?
best regards
Xavier
> Hi,
> it's not that complicated than providing a JS-based X-server implementation.
> It is more like a mapping between client-side and server-side widgets. This
> means for each and every widget of the widget-tree that exists on the
> server-side a client-side representation is created. Both trees are
> synchronized using AJAX requests. Status changes of widgets on the
> client-side are submitted and applied to the respective widgets on the
> server-side. After that eventhandler invokation takes place. For example a
> listener that was added to a push button gets executed. The eventhandling
> itself may changes the status of the server-side widgets. Those changes are
> detected and send back to the client, where they get applied to the
> respective client-side widgets - request-LifeCycle complete.
> For more information the custom widget tutorial may a good starting point:
>
http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse. rap.help/help/html/advanced/custom-widget.html
> Ciao
> Frank
> "Xavier "Méhaut"" <xavier.mehaut@free.fr> schrieb im Newsbeitrag
> news:1af5c795b825d7df240da9832a26b85d$1@www.eclipse.org...
>> Thanks a lot for all this information, I'm going to read quite soon..
>> To go further, can you explain quickly the swt to js translating scheme
>> you use to build the WEB UI? Is it a kind of X-server developped uppon js?
>>
>> regards
>> Xavier
>>
>> ps : it is otherwise a good news to know that ther coulbe be different
>> rendering possibilities in the future... RAP is really very innovative and
>> go further than GWT (I used t use with great pleasure daily) because it
>> offers the eclipse plaform to client6server developments, like J2EE offers
>> n-tier development to former JSP/Php applications. regards
>>
>>> Hi,
>>
>>> in this context it might be interesting for all of you what we are doing
>>> in the platform-incubator where we try to make Eclipse-Core-Technologies
>>> with GWT.
>>
>>> See http://wiki.eclipse.org/Eclipse_Techs_For_GWT
>>
>>> Tom
>>
>>> Frank Appel schrieb:
>>>> Hi,
>>>>
>>>> unfortunately there is no such overall documentation available at the
>>>> moment. The javascript creation differs from GWT since we do not
>>>> translate javacode into javascript. But we think about to split the RWT
>>>> library into lets say a common part (containing the current API and
>>>> serverside implementations) and rendering fragments. Technically such a
>>>> split wouldn't be a big deal.
>>>>
>>>> The one and only fragment at the time being would be the fragment using
>>>> qooxdoo. But having that split in place it would be easily possible to
>>>> evaluate and implement the usage of different client side technologies
>> (e.g.
>>>> GWT, Silverlight, Flash, Applets etc) by creating additional rendering
>>>> fragments. As RAP separates client-side technology strictly from the
>>>> application development those fragments could be used interchangeable
>>>> without changing any line of code in existing applications. Even more,
>>>> having multiple rendering fragments the RAP runtime could select the
>>>> best fitting solution for the browser capabilities used on the client
>>>> side.
>>>>
>>>> The only downside of this approach I currently see lays by the poor
>>>> custom widget developer that may have to support those different
>>>> technologies... But anyway that all is still future.
>>>>
>>>>
>>>> Ciao
>>>> Frank
>>>>
>>>>
>>>> "Xavier "Méhaut"" <xavier.mehaut@free.fr> schrieb im Newsbeitrag
>>>> news:eea2975c000612e6640afeff968941a6$1@www.eclipse.org...
>>>>> Hello,
>>>>> I would like to know if there is a documentation about the overall
>>>>> architecture of the project. I would also like to know the process of
>>>>> translating eclipse code to javascript one. Is it the same pattern as
>>>>> for GWT? Have you thought of using GWT javascript target code instead
>>>>> of quooxdoo for compliance?
>>>>> best regards
>>>>> Xavier
>>>>>
>>>>
>>>>
>>
>>
>> Thanks a lot for all this information, I'm going to read quite soon..
>> To go further, can you explain quickly the swt to js translating scheme
>> you use to build the WEB UI? Is it a kind of X-server developped uppon js?
>>
>> regards
>> Xavier
>>
>> ps : it is otherwise a good news to know that ther coulbe be different
>> rendering possibilities in the future... RAP is really very innovative and
>> go further than GWT (I used t use with great pleasure daily) because it
>> offers the eclipse plaform to client6server developments, like J2EE offers
>> n-tier development to former JSP/Php applications. regards
>>
|
|
|
| Re: Architecture overview [message #57857 is a reply to message #57762] |
Tue, 06 November 2007 09:06 |
| Eclipse User |
|
|
|
Originally posted by: fappel.innoopract.com
Hi,
actually the approach is very lean. We just exchange the deltas for
client-server synchronization and trigger submits only if there's a need to
inform the server about the changes. For example collapsing a tree changes
the status of the client side widget. As long as there is no server-side
listener interested in that event the status change is simply recorded at
the client-side. If a user pushes a action-button on the other hand, the
recorded state will be submitted and synchronized on the server-side before
the action-listener is invoked.
If we take a look at the workbench demo application for example: once the
application is started the average response size is somewhat around 300b.
And I believe that there is still ground for improving this. Measurements
done with that demo application have shown that processing such an average
request/response cycle took somewhat between 0-15ms. (The server used for
those measurements was a discarded laptop-machine with not too much
computation power, actually the measurements where just an attachment of
some tests regarding deadlocks...). Given this the average response time
boils down to the network latency, which I expect to get continously less in
the future.
Ciao
Frank
"Xavier "M
|
|
|
Powered by
FUDForum. Page generated in 0.03405 seconds
] 
Search
Help
Register
Login
Home
