[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cdt-core-dev] CDT ResolverModel vs ContentTypeManager
|
+1
We've run into situations where CDT functionality runs head on into
platform technology. It will make our lives a lot easier in the long run
to make use of the platform frameworks as much as we can. Maybe if the
platform guys like our UI, we can push that down too :)
Doug Schaefer
Ottawa Lab, IBM Rational Software Division
"Alain Magloire" <alain@xxxxxxx>
Sent by: cdt-core-dev-admin@xxxxxxxxxxx
02/23/2005 04:54 PM
Please respond to
cdt-core-dev
To
cdt-core-dev@xxxxxxxxxxx
cc
Subject
[cdt-core-dev] CDT ResolverModel vs ContentTypeManager
Bonjour,
The good folks from Timesys contributed the framework for file type
resolution,
it contained UI(preference and property page) settings and Core
Api(ResolverModel class).
This was done before, the platform IContentTypeManager framework.
A plan item for CDT-3.0 is to provide an adapter between the two worlds,
but looking closer at the IContentTypeManager framework, it provides all
that is
needed now so we can now use the is framework as the backend, with a few
caveats:
a) The content-type mappings are global i.e. it can not be set on a per
project basis.
But so far, I've not see a real case where it is usefull.
Note: there is an enhancement PR
for this.
b) The content-type framework does not come with a UI
But we can still use the old UI and only change the backend to use the
IContentManager.
Note: There is an example plugin provided by the platform/Core folks,
hopefully it will
make its way down to the code in the future.
The big advantage; the CDT will no longer be playing alone in its sandbox,
so
integration with other Eclipse components will be easier.
Any objection to morph this plan item ?
Comments/Feedbacks ?
--
au revoir, alain
_______________________________________________
cdt-core-dev mailing list
cdt-core-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-core-dev