Re: Lookup & Search Redux

First, sorry for taking some time to reply, was "stuck" with my mother
in-law all Sunday. I guess it comes with the package when u get married, i
just wish i could implement some test cases on this before getting into it
:o)


That will work for IntelliJ also. In IntelliJ there's the VirtualFile that
all file inherit from. If the file it's in a jar then it will be an instance
of com.intellij.openapi.vfs.impl.jar.VirtualFileImpl otherwise it be an
instance of com.intellij.openapi.vfs.impl.local.VirtualFileImpl, both extend
VirtualFile.

On 5/8/06, Geoff Longman <[email protected]> wrote:
>
> Ok, I'm up to my ears in Search and Lookup again.
>
> Lookup is ok. I'm not looking to change it in any way.
>
> Search is a bit of a pain. As you recall Search was only going to be
> used to find any Tapestry files in a project, regardless of their
> visibility in a classpath like world. Search does not find Resources,
> it finds 'files'.
>
> I don't want to change that either. :-)
>
> Going forward I'll call it 'resource path' instead of classpath - with
> the understanding that a resource path works in the same way as
> classpath*
>
> There are a few things that are complicated by this and I'm hoping
> that a few simple changes can fix it.
>
> IProblemPeristManager, you provide an implementation that stores
> problems related to a Tapestry file. However, currently the interface
> methods take Resources and I think this is wrong wrong wrong.
>
> Exactly which file a Resource refers to is not fixed. Changing the
> resource path may mean a completely different file might be picked up
> instead.
>
> But I think it's important that when problems are persisted, they are
> persisted against real files and not Resources. User's work with real
> files and it does not make sense for an error marking to jump to a
> different file just because the resource path changes. This might
> introduce another problem - error on files that Tapestry would no
> longer see - but I'm going to add a "rule for implementors' that will
> prevent this**.
>
>
> So in the current code Search and ISearchAcceptor work on Objects
>
> I'm changing IProblemPeristManager to work with only ITapestryProjects
> and Objects too.
>
> So, what if all you have is a Resource and you want to record an
> error? Luckily ICoreResource has the method getUnderlier(). When you
> implement your Resource classes getUnderlier() is supposed to return
> the underling file that the Resource represents.
>
> So I think that will work out ok.
>
> But, having these classes and interfaces work with Objects is a bit
> clunky. Why not just uses java.io.File objects? Well, I don't know how
> IntelliJ represents source files but Eclipse does not used
> java.io.Files! It uses org.eclipse.resources.IFile's for physical
> files and another class altogether for files in jars.
>
> Since the decision to tie the core to JDK 1.5 was made a long time
> ago, why not parameterize these interfaces and let the IDE implementor
> decide?
>
> This works fine for me an Eclipse as the is one super interface
> (org.eclipse.resources.IStorage) that is the super interface of IFile
> and the jar file class.
>
> My question is: Does this paramterization Iimit you, Hugo? Is there an
> equivalent super interface in IntelliJ that can represent both a
> physical file and one found in a jar?
>
> One could argue that it's pretty difficult to 'mark' a file in a jar
> and it might also be argued that since one can't edit the file anyway
> why bother?
>
> Thoughts?
>
> Geoff
>
> *Works the same way as classpath in that some files may be hidden
> depending on the structure of the classpath. The term 'Resource path'
> is more generic as there is no reason why the context resource path
> may not be implemented in a classpathy way.
>
> **The rule is simple, if the resource path changes (context or
> classpath), simply throw out any build state including any error
> markings, and build again.
> --
> The Spindle guy. http://spindle.sf.net
> Blog:                  http://jroller.com/page/glongman
> Other interests:  http://www.squidoo.com/spaceelevator/
>