Comments on Maureen's blog: those other files....

I would definitely not put then with the other fil...

2008-11-30T15:39:00.000-05:00

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.

I like the idea of a "Project Files" element (how ...

2008-11-18T05:04:00.000-05:00

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?

well you could handle them like file resources, bu...

2008-11-17T23:27:00.000-05:00

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.

I've been using the eclipse based designer in R8.5...

2008-11-17T15:58:00.000-05:00

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.

I don't think they belong with traditional File Re...

2008-11-17T13:49:00.000-05:00

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.

Hi Maureen,

If I am to assume that moving f...

2008-11-17T12:17:00.000-05:00

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.

Maureen, please forgive my ignorance as I'm not ye...

2008-11-17T11:10:00.000-05:00

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. "DO_NOT_DELETE_file1.xyz").

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