[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-core-dev] eclipse as a general application framework
|
A lot of thanks to both of you. I've added more questions below. Please
take a look. I would appreciate your help.
shaohua
Jeff_McAffer@xxxxxxx
Sent by: To: platform-core-dev@xxxxxxxxxxx
platform-core-dev-admin@e cc:
clipse.org Subject: Re: [platform-core-dev] eclipse as a general application
framework
12/05/01 09:56 AM
Please respond to
platform-core-dev
Depending on what you want, another approach to this is to leave the
resources plugin in and just not use it. That is, if the perspectives you
present don't allow for any resource manipulation, the resources plugin
will not do much. There would be a small overhead in memory and on disk
but that's it.
<mas>I am not sure if this is going to work. Are you assuming that that I
don't use org.eclipse.ui.* ? If I want to use the workbench, it will try (I
guess) to contact the resource, which in turn will write to the local disk.
Am I right? This is not good if it's true. more below.</mas>
Jeff
Hi Shaohua,
The extent of the work depends on your goal. If you wish to use the UI as
a general application framework, I expect the following changes are
required:
- pull out the resources plugin, vcm plugins (model and ui), jdt plugin
(model and ui), etc. These are all simply plugins, so it would be very
easy to remove them from the platform. The resulting platform might be
composed of the following plugins:
org.apache.xerces
org.eclipse.core.boot
org.eclipse.core.runtime
org.eclipse.core.target
org.eclipse.help.*
org.eclipse.sdk <mas>do I need this?</mas>
org.eclipse.swt
org.eclipse.ui.
This would take about 10 minutes of deletion.
- The org.eclipse.ui plugin will contain errors wherever a reference to the
org.eclipse.core.resources plugin is made.
<mas>You are right. 1409 to be exact.</mas>
You will have to fix these
errors. As a first crack, I would split the plugin into two parts: the
workbench itself, then standard components + resource layer. Together,
these plugins would provide the behavior of the current resource centric
workbench. The workbench layer itself could be used as the basis for a new
non-resource specific platform.
<mas>First, is there any legal/??? issue here?
Can I use the original package instead of creating my own one?
I would certainly love to use the original package structure. see below.
Second, isn't this essentially the same as writing a new resource package,
with my own persistance stuff? If this is the case, using the original
package structure (org.eclipse.resource.*) would make life much easier.
I can use the orginal interface names and change the method. I don't have
to change the import statement exists in almost every file in the ui
package.
Wonder how difficult will it be to create a new resource package?
Any suggestings on the way to tackle this?</mas>
For a person familiar with the code, this might take 1 to 2 weeks. For the
most part, there are very few references to IResources in the
org.eclipse.ui, but it may be difficult to abstract out those that exist.
However, I think it's possible with some creativity. Our primary goal with
any work is backwards compatability with the existing API's. In other
words, a plugin wrote for version 1.0 of Eclipse should continue to work,
even after the abstraction has been performed.
If you wish to reuse the UI components within org.eclipse.ui in a more
generic way, as a series of parts which can be combined in various ways,
substantial effort is required. The classes for part layout, perspectives,
etc, are not intended for public consumption, so it would require much
thought to clean them up, make the API's consistent, etc.
<mas>I am not clear here. I like the current UI a lot and I'd like to
be able to use it. What's blocking me from using it is the resource,
I guess. I want to be able to get information from a database, turn
them into objects, and be accessible to the ui. And I don't want to
leave any trace (some ui preference is ok) on the local file system.
</mas>
If you are interested in doing the UI work, the best place to float a
proposal is in platform-ui-dev.
Dave
masn@xxxxxxxxxxxxxxxxxxxx
m To:
platform-core-dev@xxxxxxxxxxx
Sent by: cc:
platform-core-dev-admin@e Subject:
[platform-core-dev] eclipse as a general
clipse.org application framework
12/04/01 10:31 PM
Please respond to
platform-core-dev
Hi,
I asked the same question in the news group and was advised to direct the
question to the mailing list. So here it goes.
What I am thinking for is the possibility of using the eclipse as a general
application framework. In particular, I am looking for a feature that does
not tie the data model with the local file system. For example, say I have
a domain model that's been stored in a database. I want to retrieve the
information from the database, turn them into objects, and present to the
user, either for viewing or editing purpose. The object model has similar
Project and Folder concepts, but the File does not map to the object
nicely. In addition, when objects (folder or file) is introduced into a
project, the current implementation stores this relationship into the local
file system (.meta folder)(???), which is not desirable.
My question is, how to deal with this situation? I understand eclipse is
not design for this purpose, but is it possible to extend the current
framework to cover the situation? Ok, it's possible. How easy is it? I
really like the whole thing and I am willing to spend time on it to make it
work, if it's not too hard. If doable, where should I start?
Your help is much appreciated.
shaohua
_______________________________________________
platform-core-dev mailing list
platform-core-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-core-dev
_______________________________________________
platform-core-dev mailing list
platform-core-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-core-dev
