Skip to main content

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

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
IBM RTP Lab
Ext: (919) 543-8356
T/L:  441-8356
mdelder@xxxxxxxxxx




Back to the top