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

[Rich Kulp <richkulp@xxxxxxxxxx>]

Hi,

It's been two weeks and David's comment
was the only one. So I've decided to use a conservative approach. That
approach is to leave them API but clean them up so that they only work
with project resources and not just any URI, and clean up the javadoc so
that is apparent that it should only be project resource URI's. And I will
add the one API for getting the IFile from the URI without causing an XML
file to be loaded.

Thanks,
Rich

Rich Kulp/Raleigh/IBM@IBMUS
Sent by: ve-dev-bounces@xxxxxxxxxxx

09/23/2005 12:26 PM

Please respond to
Discussions people developing code for the Visual Editor project

To	ve-dev@xxxxxxxxxxx, Chuck Bridgham/Raleigh/IBM@IBMUS, David M Williams/Raleigh/IBM@IBMUS
cc
Subject	[ve-dev] 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_______________________________________________
ve-dev mailing list
ve-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ve-dev