Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [wtp-dev] Request for Feedback for ModuleCore/Flex Project API


From your description, it looks like you are proposing to provide alternate implementations of IResource and it's subclasses. Is this what you are intending to do? The javadoc of IResource clearly states that it cannot be implemented by clients. I think you will need to define your own interfaces and not make use of IResource. I guess another alternative would be to push to have the API restriction changed. I can't comment of the probablity of this happening at some point but I can say that it will not happen for 3.1 since the API freeze is next week.


wtp-dev-admin@xxxxxxxxxxx wrote on 23/03/2005 10:35:46 AM:

> Extended Team:
> The Overview:
>       As we have been developing the ModuleCore API (the API which allows
> interaction with flexible project structures), we've found that our
> internal usage of it is bulkier than we would like. The bulk tends to come
> from EMF model management that surrounds working with the flexible
> structures. To correct this, we are considering (and have begun
> prototyping) an implementation based off of the Platform/Core APIs. We have
> begun to implement these (IResource, IContainer, IFile, IFolder) and back
> their navigational/structural methods from the underlying EMF models.
>       For those that were involved in the flexible project discussion at
> Eclipse Con, we are going to continue to use the models that were
> discussed, with the renames that were discussed. We are simply looking to
> expose API for clients that would make it easier to create mappings and to
> browse or change the actual structures without needing to know "what
> element do I need to insert into the EMF model?".
>       Code that tests this approach has been released. See
> org.eclipse.wst.common.tests/...ModuleCoreAPITests for examples.
>       We would like feedback from potential consumers of the API regarding
> this approach. We have also run into some cases where an API method could
> have a couple of meanings, and we would like feedback on which approach
> seems most intuitive. We may find that following the Platform APIs are not
> the most effective solution, but we expect to provide some form of browsing
> APIs that hide the EMF model from view.
> The Details:
>       We have mapped IContainer to a "WorkbenchComponent" (formerly
> referred to as a "WorkbenchModule"). IContainer can provide files
> (getFile(..)), folders (getFolder()), and members (members()). Each method
> returns a handle object(s) that represents a "virtual" or "runtime" path
> ("virtual" is used for this discussion, but the path is backed by the
> ComponentResource.getRuntimePath() : formerly
> WorkbenchModuleResource.getDeployedPath()).
>       IFile and IFolder represent ComponentResources. However, unlike the
> sparse EMF model, each of these will have an exact virtual path. That
> virtual path may be backed by multiple real resources in the project. For
> instance, if two folders are mapped to root, and you are dealing with an
> IFolder that represents root, then IFolder.members() will return members
> from both real folders in the project.
>       Now, for clients that want to create a ComponentResource that maps
> the real folder "/MyProject/Web1/graphics/images" to the virtual folder
> "/images" contained by the "Web1" component:
>             IProject containingProject =
> ResourcesPlugin.getWorkspace().getRoot().getProject("MyProject");
>             // get the virtual container that represents the component,
> backed by the EMF model
>             IContainer component = ModuleCore.create(containingProject,
> "Web1" );
>             // create a virtual folder from the component with runtime path
> "/images"
>             IFolder images = component.getFolder(new Path("/images"));
>             // notice that the real path is always project relative
>             images.createLink(new Path("/Web1/graphics/images"), 0, null);
>       Any thoughts?
> More to follow ....
> -------------------------------------------------------------------------
> Kind Regards,
> Michael D. Elder
> Rational Studio / J2EE Tools Development
> Ext: (919) 543-8356
> T/L:  441-8356
> mdelder@xxxxxxxxxx
> _______________________________________________
> wtp-dev mailing list
> wtp-dev@xxxxxxxxxxx

Back to the top