Home » Eclipse Projects » Remote Application Platform (RAP) » Unsupported event handler
| Unsupported event handler [message #23124] |
Tue, 08 May 2007 09:00  |
Eclipse User |
|
|
|
Originally posted by: gschmoe.salomon.at
Hello!
I have a question about the unsupported event types, such as key events,
mouse events, selection events, etc.
On the RAP website I saw that support for these event types is out of
scope for the first release. However, since I'm considering to build a
large application on top of RAP and I definitely cannot ignore this
problem, I would be interesting to know how and when these features are
supported by RAP and what the plan is...
Although I know that this is a performance critical issue, I think a
solution must be provided. The question is whether this is server or
rather client (JS) based. So what is the long-term strategic goal??
The current situation is that we have an SWT application, which makes use
of these listeners/events. What is the suggested short-term solution to
get the application running in RAP??
Regards,
Gernot
|
|
|
| Re: Unsupported event handler [message #23649 is a reply to message #23124] |
Wed, 09 May 2007 10:15  |
| Eclipse User |
|
|
|
Originally posted by: fappel.innoopract.com
Hello,
this is a difficult topic that can't be answered with one simple statement.
The different events that you are mentionend must be looked at separately.
SelectionEvents exits already - even widgedDefaultSelected is already
available e.g in the Tree widget.
MouseEvents will be available partially. I think it is not a technical
problem to provide mouse up and down - but then the application programmer
is in charge to use them in a sensible way. We cannot provide mouse move
since this would cause to much traffic.As an example how workarounds for
this deficit may look like you can use the sash. The selection that is
triggered if the user moves the sash waits till the mouse up occurs, but a
clientside marker line that follows the mouse moves gives a hint how the
resize will take place.
Very difficult are key events since submitting every key-stroke to the
server is not realy an option. In fact we do have several ideas like some
kind of key-stroke-chaining for example but there has been made no decision
yet.
From my point of view it is very difficult to give any advices for short
term solutions, since this depends a lot on the use cases. That much I can
say that there is no out of the box solution available. As the original
workbench implementation uses the events that you mentioned too, we
encounter quite the same problems every day. The original part selection
service for example uses MouseEvents which would have been to expensive to
use. So we changed the implementation and use an ActivateEvent that reduces
serverside turnarounds to the minimum.
Ciao
Frank
"Gernot Sch." <gschmoe@salomon.at> schrieb im Newsbeitrag
news:3566f7cb99b9e0348c2183c71038f02e$1@www.eclipse.org...
> Hello!
>
> I have a question about the unsupported event types, such as key events,
> mouse events, selection events, etc.
> On the RAP website I saw that support for these event types is out of
> scope for the first release. However, since I'm considering to build a
> large application on top of RAP and I definitely cannot ignore this
> problem, I would be interesting to know how and when these features are
> supported by RAP and what the plan is...
>
> Although I know that this is a performance critical issue, I think a
> solution must be provided. The question is whether this is server or
> rather client (JS) based. So what is the long-term strategic goal??
>
> The current situation is that we have an SWT application, which makes use
> of these listeners/events. What is the suggested short-term solution to
> get the application running in RAP??
>
>
> Regards,
> Gernot
>
|
|
|
| Re: Unsupported event handler [message #23819 is a reply to message #23649] |
Thu, 10 May 2007 11:16 |
| Eclipse User |
|
|
|
Originally posted by: gschmoe.salomon.at
Hi!
Thank you for your detailed reply! I'm aware about the technical and
performance problems with these events, and that each type of these events
needs to be treated/optimized separately.
I was asking myself how you handle these events in your workbench
implementation, and in your case you change the implementation.
However, if I have understood correctly, the goal of RAP is to support an
AJAX and rich-client for a single application. Thus, the level of an
application (based on RCP and RAP), there should exist only one
implementation, which means the API is equivalent (although handling evens
may be different).
To be more precise, I have a framework based on SWT and RCP, on which an
application is built. Now, I want to use this application in the browser.
I just exchange RCP with RAP plug-ins (due to the latest namespace
conversion :). The problem is, that for some events the API is not
supported... I think, most users will have the same problem!
Of course I also understand, that all these event implementations cannot
be provided immediately.
Nevertheless, the question arises whether it is useful to provide some
kind of "SWT compatibility" plug-in, which provides at least a dummy
classes (empty event handling) of the missing API functions so that the
project compiles. Then, I can at least run and test (although some
features wont work). Step-by-step, individual strategies handling these
events may be tested and if OK, transferred into the RAP/RWT plug-ins.
Also, since this could be included in a separate "compatibility" plug-in,
it is optional!
For us, this would be very useful to test our product with RAP, and to see
whether RAP is the AJAX framework in which we should build and what are
potential problems and open issues...
Regards,
Gernot
Frank Appel wrote:
> Hello,
> this is a difficult topic that can't be answered with one simple statement.
> The different events that you are mentionend must be looked at separately.
> SelectionEvents exits already - even widgedDefaultSelected is already
> available e.g in the Tree widget.
> MouseEvents will be available partially. I think it is not a technical
> problem to provide mouse up and down - but then the application programmer
> is in charge to use them in a sensible way. We cannot provide mouse move
> since this would cause to much traffic.As an example how workarounds for
> this deficit may look like you can use the sash. The selection that is
> triggered if the user moves the sash waits till the mouse up occurs, but a
> clientside marker line that follows the mouse moves gives a hint how the
> resize will take place.
> Very difficult are key events since submitting every key-stroke to the
> server is not realy an option. In fact we do have several ideas like some
> kind of key-stroke-chaining for example but there has been made no decision
> yet.
> From my point of view it is very difficult to give any advices for short
> term solutions, since this depends a lot on the use cases. That much I can
> say that there is no out of the box solution available. As the original
> workbench implementation uses the events that you mentioned too, we
> encounter quite the same problems every day. The original part selection
> service for example uses MouseEvents which would have been to expensive to
> use. So we changed the implementation and use an ActivateEvent that reduces
> serverside turnarounds to the minimum.
> Ciao
> Frank
> "Gernot Sch." <gschmoe@salomon.at> schrieb im Newsbeitrag
> news:3566f7cb99b9e0348c2183c71038f02e$1@www.eclipse.org...
>> Hello!
>>
>> I have a question about the unsupported event types, such as key events,
>> mouse events, selection events, etc.
>> On the RAP website I saw that support for these event types is out of
>> scope for the first release. However, since I'm considering to build a
>> large application on top of RAP and I definitely cannot ignore this
>> problem, I would be interesting to know how and when these features are
>> supported by RAP and what the plan is...
>>
>> Although I know that this is a performance critical issue, I think a
>> solution must be provided. The question is whether this is server or
>> rather client (JS) based. So what is the long-term strategic goal??
>>
>> The current situation is that we have an SWT application, which makes use
>> of these listeners/events. What is the suggested short-term solution to
>> get the application running in RAP??
>>
>>
>> Regards,
>> Gernot
>>
|
|
|
| Re: Unsupported event handler [message #24321 is a reply to message #23819] |
Mon, 14 May 2007 08:02 |
| Eclipse User |
|
|
|
Originally posted by: fappel.innoopract.com
Hi,
> However, if I have understood correctly, the goal of RAP is to support an
> AJAX and rich-client for a single application. Thus, the level of an
> application (based on RCP and RAP), there should exist only one
> implementation, which means the API is equivalent (although handling evens
> may be different).
I think there may be a little misunderstanding of the goals of RAP, so let
me reach out a little bit by quoting a sentence of the 'Technical Overview'
section of the RWT wiki pages
(http://wiki.eclipse.org/index.php/WidgetToolkit): "RAP strives to enable
the development of Rich Internet Applications using the same programming
paradigm that developers know from RCP." This does not mean that RAP tries
to provide the web-part of a kind of multi-chanel UI that you write once and
run it as both RCP- and web-application, since web-applications rather most
of the time provide different aspects of an application than rich clients
do.
RAP tries to get as close as possible to RCP so that as much as possible
RCP-know-how can be reused. It should be easy for RCP-Developers to write
RAP-applications because of the same programming model. As a current outcome
of these efforts the classes and extension-point IDs of the RAP projects has
been moved to the known namespaces of RCP (as you mentioned), where RAP
provides a subset of the RCP-APIs. This was done in conformance with the SWT
and Platform teams but with the demand that for example the RWT-API does not
only provide all API that is feasible to implement but instead also provides
the consistency and mindfulness of the current SWT-API. Indeed it would be
nice to base both development lines (RAP and RCP) on the same code where
possible, but this is s.th. that is out of the current project scope.
> Nevertheless, the question arises whether it is useful to provide some
> kind of "SWT compatibility" plug-in, which provides at least a dummy
> classes (empty event handling) of the missing API functions so that the
> project compiles.
Actually one of the reasons the subset-API-approach was chosen was to help
programmers that want to reuse RCP code to identify non-working
program-parts at compile time, since it was felt that it would be very
troublesome and time consuming to identify at runtime which of the provided
API-functionalty really works. Unfortunately providing the missing API in a
'SWT-compatibility-plug-in' does not work since the subset is realized ot
method and field level and not at classes level.
Do your compile problems mainly apply to the SWT-API, meaning the provided
JFace and Workbench implementations are sufficient for your RCP framework?
Ciao
Frank
"Gernot Sch." <gschmoe@salomon.at> schrieb im Newsbeitrag
news:2f87296d64abd44097b7736ec42989b5$1@www.eclipse.org...
> Hi!
>
> Thank you for your detailed reply! I'm aware about the technical and
> performance problems with these events, and that each type of these events
> needs to be treated/optimized separately.
>
> I was asking myself how you handle these events in your workbench
> implementation, and in your case you change the implementation.
> However, if I have understood correctly, the goal of RAP is to support an
> AJAX and rich-client for a single application. Thus, the level of an
> application (based on RCP and RAP), there should exist only one
> implementation, which means the API is equivalent (although handling evens
> may be different).
>
> To be more precise, I have a framework based on SWT and RCP, on which an
> application is built. Now, I want to use this application in the browser.
> I just exchange RCP with RAP plug-ins (due to the latest namespace
> conversion :). The problem is, that for some events the API is not
> supported... I think, most users will have the same problem!
>
> Of course I also understand, that all these event implementations cannot
> be provided immediately.
> Nevertheless, the question arises whether it is useful to provide some
> kind of "SWT compatibility" plug-in, which provides at least a dummy
> classes (empty event handling) of the missing API functions so that the
> project compiles. Then, I can at least run and test (although some
> features wont work). Step-by-step, individual strategies handling these
> events may be tested and if OK, transferred into the RAP/RWT plug-ins.
> Also, since this could be included in a separate "compatibility" plug-in,
> it is optional!
>
> For us, this would be very useful to test our product with RAP, and to see
> whether RAP is the AJAX framework in which we should build and what are
> potential problems and open issues...
>
>
> Regards,
> Gernot
>
> Frank Appel wrote:
>
>> Hello,
>
>> this is a difficult topic that can't be answered with one simple
>> statement. The different events that you are mentionend must be looked at
>> separately.
>
>> SelectionEvents exits already - even widgedDefaultSelected is already
>> available e.g in the Tree widget.
>
>> MouseEvents will be available partially. I think it is not a technical
>> problem to provide mouse up and down - but then the application
>> programmer is in charge to use them in a sensible way. We cannot provide
>> mouse move since this would cause to much traffic.As an example how
>> workarounds for this deficit may look like you can use the sash. The
>> selection that is triggered if the user moves the sash waits till the
>> mouse up occurs, but a clientside marker line that follows the mouse
>> moves gives a hint how the resize will take place.
>
>> Very difficult are key events since submitting every key-stroke to the
>> server is not realy an option. In fact we do have several ideas like some
>> kind of key-stroke-chaining for example but there has been made no
>> decision yet.
>
>> From my point of view it is very difficult to give any advices for short
>> term solutions, since this depends a lot on the use cases. That much I
>> can say that there is no out of the box solution available. As the
>> original workbench implementation uses the events that you mentioned too,
>> we encounter quite the same problems every day. The original part
>> selection service for example uses MouseEvents which would have been to
>> expensive to use. So we changed the implementation and use an
>> ActivateEvent that reduces serverside turnarounds to the minimum.
>
>> Ciao
>> Frank
>
>> "Gernot Sch." <gschmoe@salomon.at> schrieb im Newsbeitrag
>> news:3566f7cb99b9e0348c2183c71038f02e$1@www.eclipse.org...
>>> Hello!
>>>
>>> I have a question about the unsupported event types, such as key events,
>>> mouse events, selection events, etc.
>>> On the RAP website I saw that support for these event types is out of
>>> scope for the first release. However, since I'm considering to build a
>>> large application on top of RAP and I definitely cannot ignore this
>>> problem, I would be interesting to know how and when these features are
>>> supported by RAP and what the plan is...
>>>
>>> Although I know that this is a performance critical issue, I think a
>>> solution must be provided. The question is whether this is server or
>>> rather client (JS) based. So what is the long-term strategic goal??
>>>
>>> The current situation is that we have an SWT application, which makes
>>> use of these listeners/events. What is the suggested short-term solution
>>> to get the application running in RAP??
>>>
>>>
>>> Regards,
>>> Gernot
>>>
>
>
|
|
|
| Re: Unsupported event handler [message #24769 is a reply to message #24321] |
Wed, 16 May 2007 07:51 |
| Eclipse User |
|
|
|
Originally posted by: kendotlarson.mindspring.com
I also have to deal with the same problem of getting a very large
SWT/JFace application to work with RAP - that is, getting the same
codebase to work with both.
I would definitely see value in having a way of having stubbed out
classes and methods. Perhaps they could be configured to throw
exceptions, print to System.err, or do nothing.
It is also useful to see the compile errors for unimplemented classes
and methods, sometimes.
If there were some way to have both, that would be ideal, but I can't
think of an easy way to accomplish that. If there were ever an argument
for #ifdefs in java, this might be it :)
I do think there are some cases where RWT could be made more like SWT
without compromising its goals - see my point on constructors and
dispose in #1 below.
I'll give the details of how I've dealt with the issues so far:
1. I found that I actually had to compile some of my classes against RWT
instead of SWT, because otherwise I would get VerifyError exceptions at
runtime. This in particular would happen with methods that use the
Image class, presumably because its class signature is significantly
different. It would be nice to not have to do this recompile (for
example, this is not needed between different SWT implementations for
different platforms (mac, linux, etc).
This problem would be somewhat eased if RWT had at least the same
hierarchy as SWT in some cases. For example, Display could extend
Device, Color could extend Resource.
Also, it seems like there is no reason that Image and Color could not
have constructors - the constructed objects could just have references
to the equivalent of the current Image and Color. I also see no harm in
them having dispose methods that do nothing. dispose is not an
"unimplemented" RWT method/feature, it is simply not necessary to do
anything in that method. So leaving it out of the API has few benefits,
and just makes cross-development harder.
2. Because I had to recompile, there is the problem of missing classes,
methods, and SWT constants. Well, what I mean is this problem is made
worse when you have to recompile. SWT constants get inlined when
compiled against SWT, so they create no runtime problem when running
against RWT, but if you recompile, you have to define the constants
yourself somewhere else. What I did was make an SWTUtils class that
defined all of the missing constants, and used that for any constants
not supported by RWT. This way the code will compile either way.
Missing classes - I've been working on filling some of these in. I have
a few things like MessageBox, GC, ImageData (to be able to dynamically
generate and draw on images) and TitleAreaDialog partially working,
which I'd be glad to share with anyone when they get a little farther along.
Missing methods - my workaround is to add a bunch of methods to my
SWTUtils helper class, like SWTUtils.getSystemTray(Display display).
Many of these methods turn out to not be super-critical anyway, like
mouse hover listeners and things that the app can function without.
SWTUtils is obviously implemented differently for my SWT and RWT versions.
3. Control flow: probably the biggest difficulty in getting code to work
with both SWT and RWT is to deal with the fact that you can't have any
blocking calls to open shells or dialogs - that is, no dispatch loops.
This is not something that RWT can or should do anything about. My
solution was to make some helper classes that can open a dialog and call
a listener when the dialog is closed. This translates directly into the
callback mechanism in RWT (see Window.open). For SWT, I just add a
dispose listener to call the callback, and run the dialog normally.
This means that throughout my app, I end up using the RWT callback-style
to open dialogs.
Ken
Frank Appel wrote:
> Hi,
>
>> However, if I have understood correctly, the goal of RAP is to support an
>> AJAX and rich-client for a single application. Thus, the level of an
>> application (based on RCP and RAP), there should exist only one
>> implementation, which means the API is equivalent (although handling evens
>> may be different).
>
> I think there may be a little misunderstanding of the goals of RAP, so let
> me reach out a little bit by quoting a sentence of the 'Technical Overview'
> section of the RWT wiki pages
> (http://wiki.eclipse.org/index.php/WidgetToolkit): "RAP strives to enable
> the development of Rich Internet Applications using the same programming
> paradigm that developers know from RCP." This does not mean that RAP tries
> to provide the web-part of a kind of multi-chanel UI that you write once and
> run it as both RCP- and web-application, since web-applications rather most
> of the time provide different aspects of an application than rich clients
> do.
>
> RAP tries to get as close as possible to RCP so that as much as possible
> RCP-know-how can be reused. It should be easy for RCP-Developers to write
> RAP-applications because of the same programming model. As a current outcome
> of these efforts the classes and extension-point IDs of the RAP projects has
> been moved to the known namespaces of RCP (as you mentioned), where RAP
> provides a subset of the RCP-APIs. This was done in conformance with the SWT
> and Platform teams but with the demand that for example the RWT-API does not
> only provide all API that is feasible to implement but instead also provides
> the consistency and mindfulness of the current SWT-API. Indeed it would be
> nice to base both development lines (RAP and RCP) on the same code where
> possible, but this is s.th. that is out of the current project scope.
>
>> Nevertheless, the question arises whether it is useful to provide some
>> kind of "SWT compatibility" plug-in, which provides at least a dummy
>> classes (empty event handling) of the missing API functions so that the
>> project compiles.
>
> Actually one of the reasons the subset-API-approach was chosen was to help
> programmers that want to reuse RCP code to identify non-working
> program-parts at compile time, since it was felt that it would be very
> troublesome and time consuming to identify at runtime which of the provided
> API-functionalty really works. Unfortunately providing the missing API in a
> 'SWT-compatibility-plug-in' does not work since the subset is realized ot
> method and field level and not at classes level.
>
> Do your compile problems mainly apply to the SWT-API, meaning the provided
> JFace and Workbench implementations are sufficient for your RCP framework?
>
> Ciao
> Frank
>
>
> "Gernot Sch." <gschmoe@salomon.at> schrieb im Newsbeitrag
> news:2f87296d64abd44097b7736ec42989b5$1@www.eclipse.org...
>> Hi!
>>
>> Thank you for your detailed reply! I'm aware about the technical and
>> performance problems with these events, and that each type of these events
>> needs to be treated/optimized separately.
>>
>> I was asking myself how you handle these events in your workbench
>> implementation, and in your case you change the implementation.
>> However, if I have understood correctly, the goal of RAP is to support an
>> AJAX and rich-client for a single application. Thus, the level of an
>> application (based on RCP and RAP), there should exist only one
>> implementation, which means the API is equivalent (although handling evens
>> may be different).
>>
>> To be more precise, I have a framework based on SWT and RCP, on which an
>> application is built. Now, I want to use this application in the browser.
>> I just exchange RCP with RAP plug-ins (due to the latest namespace
>> conversion :). The problem is, that for some events the API is not
>> supported... I think, most users will have the same problem!
>>
>> Of course I also understand, that all these event implementations cannot
>> be provided immediately.
>> Nevertheless, the question arises whether it is useful to provide some
>> kind of "SWT compatibility" plug-in, which provides at least a dummy
>> classes (empty event handling) of the missing API functions so that the
>> project compiles. Then, I can at least run and test (although some
>> features wont work). Step-by-step, individual strategies handling these
>> events may be tested and if OK, transferred into the RAP/RWT plug-ins.
>> Also, since this could be included in a separate "compatibility" plug-in,
>> it is optional!
>>
>> For us, this would be very useful to test our product with RAP, and to see
>> whether RAP is the AJAX framework in which we should build and what are
>> potential problems and open issues...
>>
>>
>> Regards,
>> Gernot
>>
>> Frank Appel wrote:
>>
>>> Hello,
>>> this is a difficult topic that can't be answered with one simple
>>> statement. The different events that you are mentionend must be looked at
>>> separately.
>>> SelectionEvents exits already - even widgedDefaultSelected is already
>>> available e.g in the Tree widget.
>>> MouseEvents will be available partially. I think it is not a technical
>>> problem to provide mouse up and down - but then the application
>>> programmer is in charge to use them in a sensible way. We cannot provide
>>> mouse move since this would cause to much traffic.As an example how
>>> workarounds for this deficit may look like you can use the sash. The
>>> selection that is triggered if the user moves the sash waits till the
>>> mouse up occurs, but a clientside marker line that follows the mouse
>>> moves gives a hint how the resize will take place.
>>> Very difficult are key events since submitting every key-stroke to the
>>> server is not realy an option. In fact we do have several ideas like some
>>> kind of key-stroke-chaining for example but there has been made no
>>> decision yet.
>>> From my point of view it is very difficult to give any advices for short
>>> term solutions, since this depends a lot on the use cases. That much I
>>> can say that there is no out of the box solution available. As the
>>> original workbench implementation uses the events that you mentioned too,
>>> we encounter quite the same problems every day. The original part
>>> selection service for example uses MouseEvents which would have been to
>>> expensive to use. So we changed the implementation and use an
>>> ActivateEvent that reduces serverside turnarounds to the minimum.
>>> Ciao
>>> Frank
>>> "Gernot Sch." <gschmoe@salomon.at> schrieb im Newsbeitrag
>>> news:3566f7cb99b9e0348c2183c71038f02e$1@www.eclipse.org...
>>>> Hello!
>>>>
>>>> I have a question about the unsupported event types, such as key events,
>>>> mouse events, selection events, etc.
>>>> On the RAP website I saw that support for these event types is out of
>>>> scope for the first release. However, since I'm considering to build a
>>>> large application on top of RAP and I definitely cannot ignore this
>>>> problem, I would be interesting to know how and when these features are
>>>> supported by RAP and what the plan is...
>>>>
>>>> Although I know that this is a performance critical issue, I think a
>>>> solution must be provided. The question is whether this is server or
>>>> rather client (JS) based. So what is the long-term strategic goal??
>>>>
>>>> The current situation is that we have an SWT application, which makes
>>>> use of these listeners/events. What is the suggested short-term solution
>>>> to get the application running in RAP??
>>>>
>>>>
>>>> Regards,
>>>> Gernot
>>>>
>>
>
>
|
|
|
| Re: Unsupported event handler [message #25103 is a reply to message #24769] |
Wed, 16 May 2007 13:19 |
| Eclipse User |
|
|
|
Originally posted by: jkrause.innoopract.com
Hi Ken,
Thank you for you input, which is very valuable to us. One major theme
for the current milestone is finalizing our move to a subset of SWT /
JFace / Workbench. You may have noticed that we have moved the complete
JFace 3.3 code to RAP, commenting out the parts that do not work - yet
(but some never will). Images and Fonts are an area where we still need
to invest some work. The issue with those two classes is that they are
often used very extensively, and creating the objects is expensive with
respect to memory, even if they only hold a reference. But we are just
working on implementing the JFace resource package and adopting the SWT
class hierarchy for Color and Resource, that might ease your pain. And
we will continue to work on providing more SWT API. All input is welcome.
With regard to your SWTUtils implementation: I think this is a great
approach for an individual project, because you are judging what is
important to you and which parts you are willing to "ignore". But from
my point of view it would be problematic to follow such an approach on a
general RAP level, because then you don't know any longer what is really
working and what is ignored. If you are willing to share any of your
code we are more than happy to work with you. We have created a
"sandbox" component for RAP, which should make contributions easier and
share code within the community. We will nominate the first committer
for this component today, and everybody is welcome to join.
The difference in control flow is something that we have been discussing
just recently, and it is interesting reading your comment that we should
NOT provide some magic to make that work (which might not be feasible
anyway).
Cheers,
Jochen
Ken Larson wrote:
> I also have to deal with the same problem of getting a very large
> SWT/JFace application to work with RAP - that is, getting the same
> codebase to work with both.
>
> I would definitely see value in having a way of having stubbed out
> classes and methods. Perhaps they could be configured to throw
> exceptions, print to System.err, or do nothing.
>
> It is also useful to see the compile errors for unimplemented classes
> and methods, sometimes.
>
> If there were some way to have both, that would be ideal, but I can't
> think of an easy way to accomplish that. If there were ever an argument
> for #ifdefs in java, this might be it :)
>
> I do think there are some cases where RWT could be made more like SWT
> without compromising its goals - see my point on constructors and
> dispose in #1 below.
>
> I'll give the details of how I've dealt with the issues so far:
>
>
> 1. I found that I actually had to compile some of my classes against RWT
> instead of SWT, because otherwise I would get VerifyError exceptions at
> runtime. This in particular would happen with methods that use the
> Image class, presumably because its class signature is significantly
> different. It would be nice to not have to do this recompile (for
> example, this is not needed between different SWT implementations for
> different platforms (mac, linux, etc).
>
> This problem would be somewhat eased if RWT had at least the same
> hierarchy as SWT in some cases. For example, Display could extend
> Device, Color could extend Resource.
>
> Also, it seems like there is no reason that Image and Color could not
> have constructors - the constructed objects could just have references
> to the equivalent of the current Image and Color. I also see no harm in
> them having dispose methods that do nothing. dispose is not an
> "unimplemented" RWT method/feature, it is simply not necessary to do
> anything in that method. So leaving it out of the API has few benefits,
> and just makes cross-development harder.
>
> 2. Because I had to recompile, there is the problem of missing classes,
> methods, and SWT constants. Well, what I mean is this problem is made
> worse when you have to recompile. SWT constants get inlined when
> compiled against SWT, so they create no runtime problem when running
> against RWT, but if you recompile, you have to define the constants
> yourself somewhere else. What I did was make an SWTUtils class that
> defined all of the missing constants, and used that for any constants
> not supported by RWT. This way the code will compile either way.
>
> Missing classes - I've been working on filling some of these in. I have
> a few things like MessageBox, GC, ImageData (to be able to dynamically
> generate and draw on images) and TitleAreaDialog partially working,
> which I'd be glad to share with anyone when they get a little farther
> along.
>
> Missing methods - my workaround is to add a bunch of methods to my
> SWTUtils helper class, like SWTUtils.getSystemTray(Display display).
> Many of these methods turn out to not be super-critical anyway, like
> mouse hover listeners and things that the app can function without.
> SWTUtils is obviously implemented differently for my SWT and RWT versions.
>
> 3. Control flow: probably the biggest difficulty in getting code to work
> with both SWT and RWT is to deal with the fact that you can't have any
> blocking calls to open shells or dialogs - that is, no dispatch loops.
> This is not something that RWT can or should do anything about. My
> solution was to make some helper classes that can open a dialog and call
> a listener when the dialog is closed. This translates directly into the
> callback mechanism in RWT (see Window.open). For SWT, I just add a
> dispose listener to call the callback, and run the dialog normally. This
> means that throughout my app, I end up using the RWT callback-style to
> open dialogs.
>
>
> Ken
>
>
> Frank Appel wrote:
>> Hi,
>>
>>> However, if I have understood correctly, the goal of RAP is to
>>> support an AJAX and rich-client for a single application. Thus, the
>>> level of an application (based on RCP and RAP), there should exist
>>> only one implementation, which means the API is equivalent (although
>>> handling evens may be different).
>>
>> I think there may be a little misunderstanding of the goals of RAP, so
>> let me reach out a little bit by quoting a sentence of the 'Technical
>> Overview' section of the RWT wiki pages
>> (http://wiki.eclipse.org/index.php/WidgetToolkit): "RAP strives to
>> enable the development of Rich Internet Applications using the same
>> programming paradigm that developers know from RCP." This does not
>> mean that RAP tries to provide the web-part of a kind of multi-chanel
>> UI that you write once and run it as both RCP- and web-application,
>> since web-applications rather most of the time provide different
>> aspects of an application than rich clients do.
>>
>> RAP tries to get as close as possible to RCP so that as much as
>> possible RCP-know-how can be reused. It should be easy for
>> RCP-Developers to write RAP-applications because of the same
>> programming model. As a current outcome of these efforts the classes
>> and extension-point IDs of the RAP projects has been moved to the
>> known namespaces of RCP (as you mentioned), where RAP provides a
>> subset of the RCP-APIs. This was done in conformance with the SWT and
>> Platform teams but with the demand that for example the RWT-API does
>> not only provide all API that is feasible to implement but instead
>> also provides the consistency and mindfulness of the current SWT-API.
>> Indeed it would be nice to base both development lines (RAP and RCP)
>> on the same code where possible, but this is s.th. that is out of the
>> current project scope.
>>
>>> Nevertheless, the question arises whether it is useful to provide
>>> some kind of "SWT compatibility" plug-in, which provides at least a
>>> dummy classes (empty event handling) of the missing API functions so
>>> that the project compiles.
>>
>> Actually one of the reasons the subset-API-approach was chosen was to
>> help programmers that want to reuse RCP code to identify non-working
>> program-parts at compile time, since it was felt that it would be very
>> troublesome and time consuming to identify at runtime which of the
>> provided API-functionalty really works. Unfortunately providing the
>> missing API in a 'SWT-compatibility-plug-in' does not work since the
>> subset is realized ot method and field level and not at classes level.
>>
>> Do your compile problems mainly apply to the SWT-API, meaning the
>> provided JFace and Workbench implementations are sufficient for your
>> RCP framework?
>>
>> Ciao
>> Frank
>>
>>
>> "Gernot Sch." <gschmoe@salomon.at> schrieb im Newsbeitrag
>> news:2f87296d64abd44097b7736ec42989b5$1@www.eclipse.org...
>>> Hi!
>>>
>>> Thank you for your detailed reply! I'm aware about the technical and
>>> performance problems with these events, and that each type of these
>>> events needs to be treated/optimized separately.
>>>
>>> I was asking myself how you handle these events in your workbench
>>> implementation, and in your case you change the implementation.
>>> However, if I have understood correctly, the goal of RAP is to
>>> support an AJAX and rich-client for a single application. Thus, the
>>> level of an application (based on RCP and RAP), there should exist
>>> only one implementation, which means the API is equivalent (although
>>> handling evens may be different).
>>>
>>> To be more precise, I have a framework based on SWT and RCP, on which
>>> an application is built. Now, I want to use this application in the
>>> browser. I just exchange RCP with RAP plug-ins (due to the latest
>>> namespace conversion :). The problem is, that for some events the API
>>> is not supported... I think, most users will have the same problem!
>>>
>>> Of course I also understand, that all these event implementations
>>> cannot be provided immediately.
>>> Nevertheless, the question arises whether it is useful to provide
>>> some kind of "SWT compatibility" plug-in, which provides at least a
>>> dummy classes (empty event handling) of the missing API functions so
>>> that the project compiles. Then, I can at least run and test
>>> (although some features wont work). Step-by-step, individual
>>> strategies handling these events may be tested and if OK, transferred
>>> into the RAP/RWT plug-ins.
>>> Also, since this could be included in a separate "compatibility"
>>> plug-in, it is optional!
>>>
>>> For us, this would be very useful to test our product with RAP, and
>>> to see whether RAP is the AJAX framework in which we should build and
>>> what are potential problems and open issues...
>>>
>>>
>>> Regards,
>>> Gernot
>>>
>>> Frank Appel wrote:
>>>
>>>> Hello,
>>>> this is a difficult topic that can't be answered with one simple
>>>> statement. The different events that you are mentionend must be
>>>> looked at separately.
>>>> SelectionEvents exits already - even widgedDefaultSelected is
>>>> already available e.g in the Tree widget.
>>>> MouseEvents will be available partially. I think it is not a
>>>> technical problem to provide mouse up and down - but then the
>>>> application programmer is in charge to use them in a sensible way.
>>>> We cannot provide mouse move since this would cause to much
>>>> traffic.As an example how workarounds for this deficit may look like
>>>> you can use the sash. The selection that is triggered if the user
>>>> moves the sash waits till the mouse up occurs, but a clientside
>>>> marker line that follows the mouse moves gives a hint how the resize
>>>> will take place.
>>>> Very difficult are key events since submitting every key-stroke to
>>>> the server is not realy an option. In fact we do have several ideas
>>>> like some kind of key-stroke-chaining for example but there has been
>>>> made no decision yet.
>>>> From my point of view it is very difficult to give any advices for
>>>> short term solutions, since this depends a lot on the use cases.
>>>> That much I can say that there is no out of the box solution
>>>> available. As the original workbench implementation uses the events
>>>> that you mentioned too, we encounter quite the same problems every
>>>> day. The original part selection service for example uses
>>>> MouseEvents which would have been to expensive to use. So we changed
>>>> the implementation and use an ActivateEvent that reduces serverside
>>>> turnarounds to the minimum.
>>>> Ciao
>>>> Frank
>>>> "Gernot Sch." <gschmoe@salomon.at> schrieb im Newsbeitrag
>>>> news:3566f7cb99b9e0348c2183c71038f02e$1@www.eclipse.org...
>>>>> Hello!
>>>>>
>>>>> I have a question about the unsupported event types, such as key
>>>>> events, mouse events, selection events, etc.
>>>>> On the RAP website I saw that support for these event types is out
>>>>> of scope for the first release. However, since I'm considering to
>>>>> build a large application on top of RAP and I definitely cannot
>>>>> ignore this problem, I would be interesting to know how and when
>>>>> these features are supported by RAP and what the plan is...
>>>>>
>>>>> Although I know that this is a performance critical issue, I think
>>>>> a solution must be provided. The question is whether this is server
>>>>> or rather client (JS) based. So what is the long-term strategic goal??
>>>>>
>>>>> The current situation is that we have an SWT application, which
>>>>> makes use of these listeners/events. What is the suggested
>>>>> short-term solution to get the application running in RAP??
>>>>>
>>>>>
>>>>> Regards,
>>>>> Gernot
>>>>>
>>>
>>
>>
|
|
|
| Re: Unsupported event handler [message #25186 is a reply to message #25103] |
Wed, 16 May 2007 16:43 |
| Eclipse User |
|
|
|
Originally posted by: kendotlarson.mindspring.com
Thanks Jochen.
I agree, the SWTUtils approach is not general and doesn't make sense as
part of RAP (except for a certain category of code, discussed below).
Since I have already changed my code to work this way, there is not much
remaining pain. However there still is a lot of work for newcomers
involved in getting an arbitrary SWT/JFace app to work with RAP, so
maybe others will do what I did, or someone will come up with something
better. It occurred to me that some tricks could be done with bytecode
generation or something along the lines of what aspectj does to somehow
create more compatible classes and methods for those who want them, but
not muck up the core RAP distribution.
Yes, I'll likely be interested in contributing once I get some of these
things working better. The one that is probably the most useful that I
did was to take GC and related classes from SWTSwing (which implements
all the drawing using Swing/AWT/Java2D) and get them to partly work for
RAP. The trickiest part is to convert between SWTSwing's Image and
RAP's Image. One of the things I found inflexible was the fact that an
Image could only be easily created from a resource using a classloader.
But by using a custom classloader, this can be used to load images
from disk, and by using temp files, load images from arbitrary data by
writing them out. (actually the temp files could be avoided by using a
custom URL handler).
I think I understand now the issue with Image constructors - since the
web app is going to be used by multiple users simultaneously, that would
be a lot of Images, as they would be reconstructed for each user.
However, we use a resource manager to ensure only 1 copy of each image,
and proper disposal, even with SWT. So I'm not sure that combining
Image with a resource manager is necessary for everyone.
I could see the use of some parts of an SWTUtils of general use - not
for the things that are missing in RAP, but the things that are
different. For example, to the extent that it remains so that there are
no Color or Image constructors, I think a common way of constructing
them (SWTUtils.createImage) would be useful for cross-toolkit
programming. (A better name for SWTUtils would be SWTCompatibility). I
do still think that ultimately the better solution is to allow
constructors on the classes and then use resource managers.
With regard to control flow, it did occur to me that you could change it
so that the GUI thread is separate from the servlet thread, allowing
blocking operations like Window.open. You'd then have to detect the
blocking, and flush the changes out using the servlet thread. You would
then potentially have a thread running and blocked for each client,
which may not be so expensive, given the large #s of other objects that
exist for each client (controls, display, etc). The callback style can
get pretty convoluted when you have 3 or 4 consecutive blocks. It makes
things like exception handling and finally blocks tough. So I don't
take an absolute position on this issue. The one thing I like about the
callback style is that it makes "User think time" more clear. We use
hibernate, and you are not supposed to keep a hibernate session open
during "user think time", but it becomes very apparent in the code if
you open a session, prompt the user, then do something with the session
and close it.
Ken
Jochen Krause wrote:
> Hi Ken,
>
> Thank you for you input, which is very valuable to us. One major theme
> for the current milestone is finalizing our move to a subset of SWT /
> JFace / Workbench. You may have noticed that we have moved the complete
> JFace 3.3 code to RAP, commenting out the parts that do not work - yet
> (but some never will). Images and Fonts are an area where we still need
> to invest some work. The issue with those two classes is that they are
> often used very extensively, and creating the objects is expensive with
> respect to memory, even if they only hold a reference. But we are just
> working on implementing the JFace resource package and adopting the SWT
> class hierarchy for Color and Resource, that might ease your pain. And
> we will continue to work on providing more SWT API. All input is welcome.
>
> With regard to your SWTUtils implementation: I think this is a great
> approach for an individual project, because you are judging what is
> important to you and which parts you are willing to "ignore". But from
> my point of view it would be problematic to follow such an approach on a
> general RAP level, because then you don't know any longer what is really
> working and what is ignored. If you are willing to share any of your
> code we are more than happy to work with you. We have created a
> "sandbox" component for RAP, which should make contributions easier and
> share code within the community. We will nominate the first committer
> for this component today, and everybody is welcome to join.
>
> The difference in control flow is something that we have been discussing
> just recently, and it is interesting reading your comment that we should
> NOT provide some magic to make that work (which might not be feasible
> anyway).
>
> Cheers,
>
> Jochen
>
>
> Ken Larson wrote:
>> I also have to deal with the same problem of getting a very large
>> SWT/JFace application to work with RAP - that is, getting the same
>> codebase to work with both.
>>
>> I would definitely see value in having a way of having stubbed out
>> classes and methods. Perhaps they could be configured to throw
>> exceptions, print to System.err, or do nothing.
>>
>> It is also useful to see the compile errors for unimplemented classes
>> and methods, sometimes.
>>
>> If there were some way to have both, that would be ideal, but I can't
>> think of an easy way to accomplish that. If there were ever an
>> argument for #ifdefs in java, this might be it :)
>>
>> I do think there are some cases where RWT could be made more like SWT
>> without compromising its goals - see my point on constructors and
>> dispose in #1 below.
>>
>> I'll give the details of how I've dealt with the issues so far:
>>
>>
>> 1. I found that I actually had to compile some of my classes against
>> RWT instead of SWT, because otherwise I would get VerifyError
>> exceptions at runtime. This in particular would happen with methods
>> that use the Image class, presumably because its class signature is
>> significantly different. It would be nice to not have to do this
>> recompile (for example, this is not needed between different SWT
>> implementations for different platforms (mac, linux, etc).
>>
>> This problem would be somewhat eased if RWT had at least the same
>> hierarchy as SWT in some cases. For example, Display could extend
>> Device, Color could extend Resource.
>>
>> Also, it seems like there is no reason that Image and Color could not
>> have constructors - the constructed objects could just have references
>> to the equivalent of the current Image and Color. I also see no harm
>> in them having dispose methods that do nothing. dispose is not an
>> "unimplemented" RWT method/feature, it is simply not necessary to do
>> anything in that method. So leaving it out of the API has few
>> benefits, and just makes cross-development harder.
>>
>> 2. Because I had to recompile, there is the problem of missing
>> classes, methods, and SWT constants. Well, what I mean is this
>> problem is made worse when you have to recompile. SWT constants get
>> inlined when compiled against SWT, so they create no runtime problem
>> when running against RWT, but if you recompile, you have to define the
>> constants yourself somewhere else. What I did was make an SWTUtils
>> class that defined all of the missing constants, and used that for any
>> constants not supported by RWT. This way the code will compile either
>> way.
>>
>> Missing classes - I've been working on filling some of these in. I
>> have a few things like MessageBox, GC, ImageData (to be able to
>> dynamically generate and draw on images) and TitleAreaDialog partially
>> working, which I'd be glad to share with anyone when they get a little
>> farther along.
>>
>> Missing methods - my workaround is to add a bunch of methods to my
>> SWTUtils helper class, like SWTUtils.getSystemTray(Display display).
>> Many of these methods turn out to not be super-critical anyway, like
>> mouse hover listeners and things that the app can function without.
>> SWTUtils is obviously implemented differently for my SWT and RWT
>> versions.
>>
>> 3. Control flow: probably the biggest difficulty in getting code to
>> work with both SWT and RWT is to deal with the fact that you can't
>> have any blocking calls to open shells or dialogs - that is, no
>> dispatch loops. This is not something that RWT can or should do
>> anything about. My solution was to make some helper classes that can
>> open a dialog and call a listener when the dialog is closed. This
>> translates directly into the callback mechanism in RWT (see
>> Window.open). For SWT, I just add a dispose listener to call the
>> callback, and run the dialog normally. This means that throughout my
>> app, I end up using the RWT callback-style to open dialogs.
>>
>>
>> Ken
>>
>>
>> Frank Appel wrote:
>>> Hi,
>>>
>>>> However, if I have understood correctly, the goal of RAP is to
>>>> support an AJAX and rich-client for a single application. Thus, the
>>>> level of an application (based on RCP and RAP), there should exist
>>>> only one implementation, which means the API is equivalent (although
>>>> handling evens may be different).
>>>
>>> I think there may be a little misunderstanding of the goals of RAP,
>>> so let me reach out a little bit by quoting a sentence of the
>>> 'Technical Overview' section of the RWT wiki pages
>>> (http://wiki.eclipse.org/index.php/WidgetToolkit): "RAP strives to
>>> enable the development of Rich Internet Applications using the same
>>> programming paradigm that developers know from RCP." This does not
>>> mean that RAP tries to provide the web-part of a kind of multi-chanel
>>> UI that you write once and run it as both RCP- and web-application,
>>> since web-applications rather most of the time provide different
>>> aspects of an application than rich clients do.
>>>
>>> RAP tries to get as close as possible to RCP so that as much as
>>> possible RCP-know-how can be reused. It should be easy for
>>> RCP-Developers to write RAP-applications because of the same
>>> programming model. As a current outcome of these efforts the classes
>>> and extension-point IDs of the RAP projects has been moved to the
>>> known namespaces of RCP (as you mentioned), where RAP provides a
>>> subset of the RCP-APIs. This was done in conformance with the SWT and
>>> Platform teams but with the demand that for example the RWT-API does
>>> not only provide all API that is feasible to implement but instead
>>> also provides the consistency and mindfulness of the current SWT-API.
>>> Indeed it would be nice to base both development lines (RAP and RCP)
>>> on the same code where possible, but this is s.th. that is out of the
>>> current project scope.
>>>
>>>> Nevertheless, the question arises whether it is useful to provide
>>>> some kind of "SWT compatibility" plug-in, which provides at least a
>>>> dummy classes (empty event handling) of the missing API functions so
>>>> that the project compiles.
>>>
>>> Actually one of the reasons the subset-API-approach was chosen was to
>>> help programmers that want to reuse RCP code to identify non-working
>>> program-parts at compile time, since it was felt that it would be
>>> very troublesome and time consuming to identify at runtime which of
>>> the provided API-functionalty really works. Unfortunately providing
>>> the missing API in a 'SWT-compatibility-plug-in' does not work since
>>> the subset is realized ot method and field level and not at classes
>>> level.
>>>
>>> Do your compile problems mainly apply to the SWT-API, meaning the
>>> provided JFace and Workbench implementations are sufficient for your
>>> RCP framework?
>>>
>>> Ciao
>>> Frank
>>>
>>>
>>> "Gernot Sch." <gschmoe@salomon.at> schrieb im Newsbeitrag
>>> news:2f87296d64abd44097b7736ec42989b5$1@www.eclipse.org...
>>>> Hi!
>>>>
>>>> Thank you for your detailed reply! I'm aware about the technical and
>>>> performance problems with these events, and that each type of these
>>>> events needs to be treated/optimized separately.
>>>>
>>>> I was asking myself how you handle these events in your workbench
>>>> implementation, and in your case you change the implementation.
>>>> However, if I have understood correctly, the goal of RAP is to
>>>> support an AJAX and rich-client for a single application. Thus, the
>>>> level of an application (based on RCP and RAP), there should exist
>>>> only one implementation, which means the API is equivalent (although
>>>> handling evens may be different).
>>>>
>>>> To be more precise, I have a framework based on SWT and RCP, on
>>>> which an application is built. Now, I want to use this application
>>>> in the browser. I just exchange RCP with RAP plug-ins (due to the
>>>> latest namespace conversion :). The problem is, that for some events
>>>> the API is not supported... I think, most users will have the same
>>>> problem!
>>>>
>>>> Of course I also understand, that all these event implementations
>>>> cannot be provided immediately.
>>>> Nevertheless, the question arises whether it is useful to provide
>>>> some kind of "SWT compatibility" plug-in, which provides at least a
>>>> dummy classes (empty event handling) of the missing API functions so
>>>> that the project compiles. Then, I can at least run and test
>>>> (although some features wont work). Step-by-step, individual
>>>> strategies handling these events may be tested and if OK,
>>>> transferred into the RAP/RWT plug-ins.
>>>> Also, since this could be included in a separate "compatibility"
>>>> plug-in, it is optional!
>>>>
>>>> For us, this would be very useful to test our product with RAP, and
>>>> to see whether RAP is the AJAX framework in which we should build
>>>> and what are potential problems and open issues...
>>>>
>>>>
>>>> Regards,
>>>> Gernot
>>>>
>>>> Frank Appel wrote:
>>>>
>>>>> Hello,
>>>>> this is a difficult topic that can't be answered with one simple
>>>>> statement. The different events that you are mentionend must be
>>>>> looked at separately.
>>>>> SelectionEvents exits already - even widgedDefaultSelected is
>>>>> already available e.g in the Tree widget.
>>>>> MouseEvents will be available partially. I think it is not a
>>>>> technical problem to provide mouse up and down - but then the
>>>>> application programmer is in charge to use them in a sensible way.
>>>>> We cannot provide mouse move since this would cause to much
>>>>> traffic.As an example how workarounds for this deficit may look
>>>>> like you can use the sash. The selection that is triggered if the
>>>>> user moves the sash waits till the mouse up occurs, but a
>>>>> clientside marker line that follows the mouse moves gives a hint
>>>>> how the resize will take place.
>>>>> Very difficult are key events since submitting every key-stroke to
>>>>> the server is not realy an option. In fact we do have several ideas
>>>>> like some kind of key-stroke-chaining for example but there has
>>>>> been made no decision yet.
>>>>> From my point of view it is very difficult to give any advices for
>>>>> short term solutions, since this depends a lot on the use cases.
>>>>> That much I can say that there is no out of the box solution
>>>>> available. As the original workbench implementation uses the events
>>>>> that you mentioned too, we encounter quite the same problems every
>>>>> day. The original part selection service for example uses
>>>>> MouseEvents which would have been to expensive to use. So we
>>>>> changed the implementation and use an ActivateEvent that reduces
>>>>> serverside turnarounds to the minimum.
>>>>> Ciao
>>>>> Frank
>>>>> "Gernot Sch." <gschmoe@salomon.at> schrieb im Newsbeitrag
>>>>> news:3566f7cb99b9e0348c2183c71038f02e$1@www.eclipse.org...
>>>>>> Hello!
>>>>>>
>>>>>> I have a question about the unsupported event types, such as key
>>>>>> events, mouse events, selection events, etc.
>>>>>> On the RAP website I saw that support for these event types is out
>>>>>> of scope for the first release. However, since I'm considering to
>>>>>> build a large application on top of RAP and I definitely cannot
>>>>>> ignore this problem, I would be interesting to know how and when
>>>>>> these features are supported by RAP and what the plan is...
>>>>>>
>>>>>> Although I know that this is a performance critical issue, I think
>>>>>> a solution must be provided. The question is whether this is
>>>>>> server or rather client (JS) based. So what is the long-term
>>>>>> strategic goal??
>>>>>>
>>>>>> The current situation is that we have an SWT application, which
>>>>>> makes use of these listeners/events. What is the suggested
>>>>>> short-term solution to get the application running in RAP??
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Gernot
>>>>>>
>>>>
>>>
>>>
|
|
|
Goto Forum:
Current Time: Mon Jun 30 13:10:12 EDT 2025
Powered by FUDForum. Page generated in 0.03772 seconds |
Home