I'm all for abstracting away EMF specific
A question about the 'Virtual' API.
It seems like a good amount of the IFile API is duplicated in the
IVirtualFile API. I'm not sure I understand why a client would want
to access some of this IVirtualFile API. Just as an example,
why would a client obtain a IVirtualFile object and then call virtualFile.getCharset()?
Wouldn't a client simply call virtualFile.getRealFile().getCharset()
Rational Studio XML Web Services
Internal Mail: D3/RY6/8200 /MKM
Phone: (905) 413-3918 TL: 969-3918 FAX: (905) 413-4920
Internet: csalter@xxxxxxxxxx Notes: Craig Salter/Toronto/IBM@IBMCA
Michael Elder <mdelder@xxxxxxxxxx> Sent by: wtp-dev-bounces@xxxxxxxxxxx
03/29/2005 09:53 AM
Please respond to
"General discussion of project-wide or architectural issues."
[wtp-dev] Virtual API progress
We have been making progress on the proposal to expose
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
there about this?
The initial cut of the API is already available in
CVS under the
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
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
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
model. By making the models internal, we allow ourselves the opportunity
make this change at a later time (e.g. R1.1), but are considering making
this change as quickly as this Friday. Any thoughts?