Lookup & Search Redux

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/


-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0709&bid&3057&dat1642