Where to Put JS and CSS Resources in Domino
The other day I got asked a couple of questions in an email, which I said I'd answer here as others might be interested in the answers:
- Q1) Why do we put .css files in the Pages area of the databases and not in the Style Sheets area?
- Personally I prefer Pages as they are easier to edit. Style Sheet Libraries are a nice idea but not much use in practice. They're only of any use if you simply want to upload a CSS file you've had written and can't see yourself ever wanting to edit it. If you're developing your CSS in your database as you go then you should use Pages.
- Q2) Why do we sometimes put .js files in the Script Libraries area and sometimes in the Files area?
- Again it's for ease of editing. In this case the Script Libraries are easier to edit and better for when you're developing as you go. If you merely uploading something like a plugin or JavaScript framework then use the Files area as you're unlikely to need to change them.
As somebody who likes to learn other platforms I know all too well how confusing it can be to try and learn from example when the examples seem to conflict with the obvious. If you were new to Domino you'd expect the Style Sheet and Script Library area to be the place to keep the respective bits of code. To see others going against this convention and without explanation or obvious reason can throw you off the scent sometimes.
Maybe newbies to Domino (if there is such a thing) need to understand there isn't really a conventional way of doing things. Lots of it is just down to how you're happy doing it. Such is Domino's flexibility.
Skip to the 
You can subscribe to an individual
I take your last point - there are many ways and reasons.
I actually prefer to use Stylesheet DB Elements because I like to use TopStyle to edit my CSS, it's quicker. BUT I prefer to store my JS as plain text files in the server HTML folder (I like using the JSEclipse IDE for JS).
There's a good reason for this: most of my dev work has been on the company intranet where all the DBs are on the same server, the CSS often changes between DBs, but there's a lot of reuse of JS between DBs
There is such a thing as a Domino Newbie, and it's hard to get out of calling yourself that... I've been working with Domino for 5 months now, and everyday I come across something that makes me wonder why something works the way it does... Thanks for providing such a great resource here Jake... You've helped me immensely in such a few short months...
Jake,
I would like to add as well that domino does not really give you a cool possibility of in-line editing - you have these buttons for editing which never quite work as you expected. At least, I expected double click, css file opens in the editor of my choice, then I close the file, and hey presto. But no bananas, so Pages it is.
Another advantage to using Page elements for CSS (or even JS) is the option to include computed text. For example, you can insert lookups to a configuration / profile document, which allows you to provide a non-technical user a data-driven interface that they can understand for controlling portions of the application's behavior and layout. This kind of flexibility is more difficult when attaching static CSS / JS as database resources.
@Andrew Tetlaw: Just out of curiosity, what do you mean when you say "it's quicker" when referring to editing CSS via TopStyle?
Surely the process of
- Clicking "Open" or "Open With" (from within the Style Sheets section)
- selecting TopStyle as the app to use
- finding and editing the piece of CSS
- saving the file
- refreshing the file back into the database
is slower (not quicker) than simply having a page in the db which you can edit and save in place?
Unless I misunderstood your comment?
Cheers,
Lee
Another option, and one I use frequently is to store CSS and Script as documents within the database. This allows you to make changes to these files in environments where making design changes can be cumbersome. It also allows Script and CSS to be dynamic using computed text values. It can also be quite useful if your using any form of version management on your CSS.
I think the newbie needs to know that pages and script libraries are possible places (if (s)he has to maintain existing apps) and then move on. Once you activated webDAV on your development server all the resources just show up in a folder where you can directly edit them. Good enough for me (of course the editor of your choice needs to support webDAV).
:-) stw
When using computed text, remember that profile documents are cached and it may be a while before changes appear on your site. You can test this out with DWA (iNotes). Change your signature several times in the text field of preferences. Then create email messages and watch as you get "random" signatures.
This bit me when I used a profile document to store color theme information and computed text to determine which CSS file to use when rendering the page.
I don't like to use the built-in editor to edit javascript. It is a personal preference in that I prefer Textpad. The color encoding, the ability to indent blocks of code...
One thing to be aware of is that Domino set cache headers for JavaScript libraries and CSS resources (and image resources too) properly. It does not do so for pages and other types of files.
Also, I prefer to edit and keep my text files outside of domino, in a nice folder structure, and then edit them with Notepad++ or TopStyle. Then I can just hit refresh in the designer, since it will usually remember the last position.
I have found that WebDAV puts components of the same type into different locations. With images it puts JPEGs and GIFs into the Image Resource area but PNGs into the files area.
The project that I am working on we are trying to standardise the locations. Outside of that issue we decided that imported libraries and images from stuff like EXT and non-Domino specific libraries stay in the resources areas and the Domino specific JS goes into the script libraries. However there are cases when you need to generate JS/CSS on the fly and in that case it can come from other sources such as pages or documents in the database.
@Lee, well when I say 'quicker' I mean quicker for me. But here's what I do:
I have one folder location for all the CSS files I have in DBs on the intranet, so I don't go through the 'select app to use' silliness. I just edit them direct and refresh in the DB. I find it quicker to manage CSS with a proper CSS editor than editing by hand on page elements and such.
I should mention this is only for the unique CSS for each DB, all the common intranet CSS is hosted as static files in the HTML folder on the Domino server.
I only use CSS on a page when I want it to be editable by an end-user (like the database manager). He / she can edit CSS settings in a profiledocument and these settings are being used in the CSS page (@getprofilefield).
As professional webdeveloper I think I should also use professional tools to set up my CSS file. There I prefer a stylesheet editor above CSS on a page because this gives me a bit more control.
I always create my CSS with Firebug (or sometimes with Web Developer Toolbar). So using pages it's the best option. As Lee said, using CSS resources is much slower when you are in the process of defining them.
I use Javascript libraries, though. It's just as convenient as using pages (you can edit the code directly with Designer) and you get a validator for free. Also, I always have the (vain, I know) hope that someday IBM will automatically compress JS Libraries when Domino sends them to the browser. You know, like most every other Web server does...
One cool thing of using pages to store CSS, JS, XSL, and so on, is the ability to use sections to organize your code (be aware of set "auto-expand section" when Opened for reading).
I use it a lot, and it makes my code very clear.
I think the reasons for people using different combinations of pages, script libraries, files, style sheets, etc. are primarily due to the growth of the product.
Meaning, "newbie" developers are more likely to use the shared resources (files and style sheets) and javascript libraries simply because those design elements are available to them. This isn't meant as a pejorative statement; because "newbie" developers have the tools available, they haven't had to figure out the workarounds (such as pages, and using complex cfd fields in forms and subforms before pages were available) that those of us who have been developing on the platform (since R3 for me) for a long time.
Truth be told, I have made a conscious effort to move away from using pages and files for my css or javascript and towards using the Shared Resources | Style Sheets or Script Libraries | Javascript Libraries primarily because it is easier (for me) to keep everything organized.
-Devin.
If you (as I do) use different stylesheets for screen (media=screen) and print (media=print) you're forced to put your CSS in Pages. Remember to set the page content type to text/css.
@Kurt: not true -- you can still create your own media-specific stylesheet links to resources. It's only the Insert->Resource method that has any limitation.
@Bjorn: using @SetHTTPHeader in a computed text formula whose last line results in "" will set the appropriate cache-control & expires values if you need them.
Personally, my tack is to use Pages (or Forms, specifically $$NavigatorTemplates) when the content of the item is variable. I use Pages when the content is controlled by a database config document in order to take advantage of server-side cacheing. If the content varies by user (such as local date-time formatting when using accept-language), then I'll use a Form in order to get around the cache (and use @SetHTTPHeader in order to get around proxy cache).