[ve-dev] Re: JEM - Deprecate some API

[Rich Kulp <richkulp@xxxxxxxxxx>]

David,

This is for the "platform:/resource"
and "yada/yada" type URI's. The same class that getResource(URI)
is in is there to specifically handle these kind of URI's. The class also
handles IFiles of these kind of requests. Eclipse platform has no concept
what-so-ever of this kind of URI. This format of URI ("yada/yada")
is here because of WTP compatibility with older style WTP files from WSAD
days. So the requirement is for WTP usage and not general usage since it
is specific to these special forms for WTP.

Rich

David M Williams/Raleigh/IBM

09/23/2005 01:04 PM

To	Rich Kulp/Raleigh/IBM
cc	Chuck Bridgham/Raleigh/IBM@IBMUS
Subject	Re: JEM - Deprecate some APILink

Sounds good to me, on all counts. 

I guess my only concern is you adding
function like 
getIFile(URI)
seems it really should be "in the
base platform"?
Has anyone proposed it to them?

David

Rich Kulp/Raleigh/IBM

09/23/2005 12:26 PM

To	ve-dev@xxxxxxxxxxx, Chuck Bridgham/Raleigh/IBM@IBMUS, David M Williams/Raleigh/IBM@IBMUS
cc
Subject	JEM - Deprecate some API

Hi,
Three API changes I would like to make
to JEM:

--- First question:

There are a few API that I want to deprecate
or change because they are actually dangerous. The problem is they are
used to get resources based upon a URI, BUT it is expected that the URI
represents a workspace resource (either with "platform:/resource/...."
or just "yada/yada") and they barf if not. Either that or I can
narrow the API to be exactly certain of what is returned.

• getResource(URI uri) - This one is particularly bad because it is plain wrong and will throw an NPE every time for any URI that is not "platform:/resource". It calls WorkspaceResourceHandler.getResource(resourceSet, URI). But it calls it with a null resourceset. This method would only return a "platform:/resource" or if not, then in this case, an NPE. It does not understand "yada/yada" as a platform resource.
• getResource(URI, boolean load) - This one will actually work, and it will mostly work for resources that are of the form "platform:/resouce" or "yada/yada", though it needs some fixing up to understand those that are not "yada/yada". It could accidentally return the wrong one if the first segment of the path was a valid name project. But it won't NPE.

So I would suggest either we deprecate
these or fix them up so that they only work with, and check for  "platform:/resource"
and "yada/yada" and return null for anything else. The API javadoc
for getResource(URI) simply states it gets the resource, BUT javadoc for
getResource(URI, boolean) is more specific and says it only gets "platform:/resource"
form.

So which do you think I should do:

1. deprecate them
2. fix them so that they will only work with "platform:/resource" or "yada/yada" and return null for anything else.

---- Next question:

Also, should I clear up the javadoc
on the following because they don't specifically say they are for "platform:/resource"
or "yada/yada" format, but their implementation works only for
that?

1. getExistingOrCreateResource(URI uri)
2. getExistingOrCreateResource(URI uri, ResourceSet set)

---- Final question:

By the way, this problem showed up because
someone was using getResource(URI) to simply get the IFile that the URI
was representing. It didn't actually need to load the resource. I would
like to add an API:  getIFile(URI) which returns just the IFile
if a valid workspace resource format or null otherwise for people to use
instead of trying to load the resource just to get the IFile.


Thanks,
Rich