Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[wtp-dev] Re: Virtual API progress

Michael,

We are beginning to lean
towards making the models wholly internal to allow us the freedom to make
changes in the next release of WTP if necessary. Are there any opinions out
there about this?

Yes, I strongly encourage you to do exactly that. Exposing the model in any way simply locks you into EMF forever and forces all the API clients to learn that technology. I definately support your virtual path API rather than something that is model-centric.

We are also considering changing our use of the EMF URI object to use
the more Eclipse-friendly IPath object to model path structures within the
model. By making the models internal, we allow ourselves the opportunity to
make this change at a later time (e.g. R1.1), but are considering making
this change as quickly as this Friday. Any thoughts?

IPath is already well-understood by Eclipse developers so using it instead of an EMF URI would make training unnecessary and provide the API with a much more natural feel to existing Eclipse developers. Personally, I'd like to see that change as soon as possible also.

Overall, the closer the API looks to what the platform already uses allows developers to leverage what they already know much more effectively, so any change in this direction is highly desirable, IMO.

Regards,
Todd
________________________
Todd E. Williams
VP - Technology
Genuitec, LLC
Office: 972-691-5717
Cell: 817-247-2034
mailto:todd@xxxxxxxxxxxx
http://www.genuitec.com

----- Original Message ----- From: "Michael Elder" <mdelder@xxxxxxxxxx>
To: <wtp-dev@xxxxxxxxxxx>
Cc: <kosta@xxxxxxx>; <Ted.bashor@xxxxxxx>
Sent: Tuesday, March 29, 2005 8:53 AM
Subject: [work] [wtp-dev] Virtual API progress



Extended Team:

     We have been making progress on the proposal to expose a "Virtual
Path API" to allow clients to browse flexible project structures without
dealing directly with the underlying EMF models. We are beginning to lean
towards making the models wholly internal to allow us the freedom to make
changes in the next release of WTP if necessary. Are there any opinions out
there about this?

     The initial cut of the API is already available in CVS under the
modelcore plugin
(wst/components/org.eclipse.wst.common.modulecore/modulecore-src/org.eclipse.wst.common.modulecore.internal.resources).
We are targeting this weeks Integration Build to have the API tests in
places and most if not all of the javadoc. The one thing that hasn't yet
been addressed is how we intend to expose the Referenced Components
(formerly Dependent Workbench Modules) through the Virtual Path API. We
started by coping the IResource, IContainer, IFolder, and IFile, and then
pruning those down to methods that deal with navigation. The javadoc is not
yet ready, so any docs that are there are left over from Eclipse Platform.
We also added methods that were more specific that we thought would be
helpful: getWorkspaceRelativePath(), getProjectRelativePath() [as in
Platform], getRuntimePath(), getRealFile(s)/Folder(s)(), and
getComponentName().

     We are also considering changing our use of the EMF URI object to use
the more Eclipse-friendly IPath object to model path structures within the
model. By making the models internal, we allow ourselves the opportunity to
make this change at a later time (e.g. R1.1), but are considering making
this change as quickly as this Friday. Any thoughts?


-------------------------------------------------------------------------
Kind Regards,

Michael D. Elder
Rational Studio / J2EE Tools Development
IBM RTP Lab
Ext: (919) 543-8356
T/L:  441-8356
mdelder@xxxxxxxxxx


_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev






Back to the top