>>> 1) what is used to wrap a file access in a standard way? We had >>> something like a datasource which just decided if it was a file: or smb: >>> or http: and had facilities to get readers, writers, stream and so. I'm >>> sure this is also in udig, but I can't find it. If not, what is the >>> logic to follow? >> I don't have a good answer here. Jody? > I have looked at catalog implementations that take this approach; uDig > does not provide this kind of low level support. It is more a platform > for visually integrating what you already have. Thinking ...
Alright, it was just that I didn't feel good to use File and BufferedReader or RandomAccessFile without thinking about remote files. However a JGrass database will always be local, so I don't think there will be problems. But you never know :) > If you look at recent eclipse builds they have done a neat trick. They > have methods on their IResource instances that return something that is > "almost" like a Java File. Pretty sure this is in Eclipse 3.2? > > Can you look at this facility and see if it works for you? I would like > to stick with normal eclipse constructs as often as possible. I would be delighted, but I need a clearer direction to look at. I'm an eclipse framework newbie... >>> 2) how to properly throw exceptions? When to send in red to the >>> statusbar? Is there a way to open a dialog with the error description >>> and a log to send? How is this dealth with in general? > We follow eclipse conventions; usually each extension point lets you > know what you are allowed to do. My preference is to have the extension > point processor take care of error reporting, setting a warning in the > status bar (or simply attaching a warning to a GeoResource etc...). > > Can I ask for the specific context in which you are trying to handle the > Exception? For a uDig operation you should just be able to "throw" and > uDig will take care of the notification. Great. That is perfect. > For Tool things are a bit more > scary (since an error may be in the event loop). >> We haven't nicely come up with a solution to this yet. The main thing >> we do is add a logging method in the Activator class of the plugin and >> directly log to that. There are a few areas that you can put errors. >> One place is on the GeoResource or Service. There is an error message >> and a Throwable that you can set. If you are in a renderer you just >> have to throw an exception and it will be set in the status bar for >> that layer. Layers also have a status and a status message. This >> is an issue that needs to be better discussed at some point as it is >> kind of ad hoc now. I think Cory started an ErrorManager but it is a >> long way from complete. > Hi Jesse :-) You are on the same page as me. Andrea we can check our > eclipse books again to see if there is any best practice we have missed > out on. But so far normal Framework advice is the best (capture the > error handling as part of managing the extension point and don't force > any error handling code on contributors). Yes, that is very nice, if you are a contibutor like me :) You were talking about eclipse books. Could you give me some reference to a good book that also covers SWT? I think copy and paste won't be enough at a certain point. :) Andrea _______________________________________________ User-friendly Desktop Internet GIS (uDig) http://udig.refractions.net http://lists.refractions.net/mailman/listinfo/udig-devel
