Monday, November 17, 2008

those other files....

Anyone who has looked at the contents of an NSF in one of the Eclipse navigators rather than Designer's navigator knows that we've added a few extra files (stored as hidden file resource design elements) to make each nsf a good Eclipse citizen. And if you've worked with xpages and have wanted to include some java classes, you've discovered that you can just add in files to the nsf in the projected hierarchy through standard Eclipse mechanisms.

Which leaves me with a dilemma. These extra things really are file design elements, except that their path is not relative to the Resources\Files juncture in the virtual file system. They are also something that not everyone wants or cares to see. I'm worried that users who have worked with "traditional" file resources might be a bit annoyed to see stuff they didn't create show up there.

I'm leaning towards adding a separate category called "Project Files" (or something like that) that contains these other files, so they'd be accessible from the Designer navigator. And I believe whether or not that category is presented in the navigator ought to be controlled by a preference. These files would have paths relative to the project root - so if you wanted to add a file there, you would just type the relative path you wanted.

But others have said we should just dump them in with the other file resources. A file is a file, so why make an artificial difference?

I could use a sanity check here to see if I'm making an artificial distinction or a helpful separation - please let me know what you think (and an answer of it doesn't really matter is also helpful information!) Thanks!


Kevin Pettitt said...

Maureen, please forgive my ignorance as I'm not yet familiar with the notion of Eclipse navigators. Do I understand correctly that these "hidden files" are essential under certain circumstances and if absent will cause all manner of problems? If so putting them in the same place as "optional" elements seems to unnecessarily invite some newbie to delete them when "cleaning up".

It almost sounds like a situation similar to the About/Using docs (which are "special" form elements) and the database script. They don't need to be actually present in the nsf but there are reserved places in the designer that serve as reminders to the developer that they *could* be there. In addition that approach obviates the need to name the element some special way (e.g. "$$ViewTemplateDefault").

If these files are always the same, unlike the about/using/db script elements which are designed to be customized, the problem seems easier to solve. Maybe Designer could automatically add them when certain things happen, such as an ODS upgrade or the addition of an XPage.

Since presumably they would end up showing up in your Eclipse navigator as "just another file", perhaps you could name them so as to indicate their importance (e.g. "").

I guess my main concern boils down to helping developers avoid breaking something by making it too easy to do so.

Peter Presnell said...

Hi Maureen,

If I am to assume that moving forward we may start to collect a growing number of design elements specific to the Eclipse environment, then perhaps it would be a good idea to create a new category of designer element - "Eclipse" - under which these components are displayed when using the non-eclipse IDE.

Rob McDonagh said...

I don't think they belong with traditional File Resources at all. Especially not the ones that are created automagically behind the scenes...

So, no, you're not inventing an artificial distinction. You're completely correct. Exactly how you deal with it may require some thought, but there's definitely an issue to deal with.

jota said...

I've been using the eclipse based designer in R8.5 for a while now;
and it seems good to me as it is working now.
In fact, I don't care about how the files are internally organized.

jonvon said...

well you could handle them like file resources, but gray them out, so they show up as hidden files (perhaps based on that preference you mentioned?), and then give a warning if someone opens one, or make them read only, if that is needed. it boils down to, is there a situation where it will be helpful for us to see them? sometimes we really need a notespeek kind of view to figure something out.

Stephan H. Wissel said...

I like the idea of a "Project Files" element (how exactly to label it would be subject to more research), since the files are really special (from a Notes POV). Eventually we could have a menu item like in the Notes client "Show advanced Items" to show/hide them. Also to be discussed: Should this "Project Files" be a sub-item of "Resources" or would it be a top level entry?

jens said...

I would definitely not put then with the other file resources.
I would be ok with "Project Files" but I also don't mind using the Package Explorer or a different perspective to get to that stuff.
If they are included in the Designer Navigator I would prefer to get a warning if I try to modify/delete/move/whatever these files since this action can break things badly.