|[wtp-dev] Re: Virtual API progress|
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 makechanges in the next release of WTP if necessary. Are there any opinions outthere 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 thenpruning those down to methods that deal with navigation. The javadoc is notyet 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 themodel. By making the models internal, we allow ourselves the opportunity tomake 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