Tip Four: More on Views and @ViewTitle
Were you expecting this week's run of tips to revolutionise the way you develop? Sorry! They're just some little odds and ends I though I'd pass on. The really good stuff is being reserved for the articles I've got in the pipeline.
Continuing the view theme, here's a little tip I discovered completely by accident. In Domino 6 you can drag and drop view columns, in Designer, from one position to another. No need to cut and paste them when the powers be decide they're in the wrong order. Nice.
And another view tip. If you've got a database with thirty views, you probably don't want to create thirty "$$ViewTemplate for XXX" forms. Instead you can simply create a $$ViewTemplateDefault form. To help customise this a little add a Computed Value above the $$ViewBody field and add the following formula:
@ReplaceSubstring( @Subset( @ViewTitle; 1); "\\"; " - ");
This way, at least the user knows what the name of the view is.
And yet another view tip. Say you've got thirty views but you only want to allow web visitors to see four of them. Create "$$ViewTemplate" forms for these four views and then create a "$$ViewTemplateDefault" form, making sure you don't actually add a view to it. Instead, add a message about not being allowed to see the view. When the visitor opens a view other than the four they are allowed to they will see this message.
Some of you might be thinking these tips are merely "blog-fill". Well, they are. I'm too busy at the moment to think about aything interesting to blog about. Instead of a blank space I thought you'd prefer to read some tips. Send your own in, if you have any...
Skip to the 
You can subscribe to an individual
Jake,
Another fairly useful variant is to define a list of "allowed" views and have your $$ViewTemplateDefault "restrict" access to the non-allowed views.
Can you explain it a little more Dave? What do you mean by "define a list"? How do you get the default form to restrict access? etc
humm, i am wondering, if in the $$viewbody field, we have a hidewhen formula and put the
@Subset( @ViewTitle; -1) != 'viewName'
then, we could have the view disappear for certain views. ofcourse, one could expand this to work with multiple view names and having the view names soft coded somewhere in the documents.
havenot tried this, but i think it might work.
good job on the tips jake. also, thanks a bunch on the RSS feed lists. btw, am always in two minds when i have to thank you for an earlier blog of yours. should i do it in the latest blog or go to the old one and post it there.
Sounds like it should work veer.
I don't mind where you post the *positive* feedback ;o)
Another tip that I finally figured out after wondering about for some time.
In several websites I have developed, I wanted to be able to use a Domino form as the home page of the site. As we all know, there is no "Open designated Form" for the "When opened in a browser" field on the Launch tab of a Notes database. So I have always used some kind of kludge.
Initially, I had created a page called "autolaunch" which used a META tag to immediately redirect to a form as soon as it was opened. However, this resulted in a noticable "flashing" effect in the browser (especially over dial-up connections) and wasn't very elegant.
The best way to do this is probably obvious to most, but wasn't to me for so long that I thought i'd share it. This method works similarly to how you can specify a "$$ViewTemplate for xx" form to format views on the web.
1. Create a Navigator (in the Other > Navigators section in Designer 6). I called mine "homepage". The navigator is just a placeholder, so it can be completely empty.
2. Create a form and specify "$$NavigatorTemplate for homepage" as the name or alias.
3. In the database launch properties, select "Open designated Navigator..." as the "When opened in a browser" option. Then select the navigator you created in Step 1. as the choice.
When the database is displayed in a browser, Notes will effectively launch the designated form as your database homepage. This is because whenever Notes launches a navigator on the web, it will first look for a form called "$$NavigatorTemplate for xx" and display that if it exists.
Dave L, a classic. Why don't you try searching this site for it. You may find this tip posted years ago ;)
Still a good one though, and a welcome mind-refresher.
Thanks Dave. It could be that you read it here {Link}
Although it's a widely used tip, I think this was the first place it was posted.
I've been using the page redirect method myself. I just tried using the $$NavigatorTemplate method noted above. It worked ok, except that my form no longer opens in edit mode. Is it supposed to do this?
Never mind. I found the answer in Jake's link above.
Here's another view tip using the "$$ViewTemplate for XXX" forms. You can use view aliases as a way to get common views to use the same "$$ViewTemplate for XXX" form.
To do this, give all of the views that need to share the same form the same alias. Your "$$ViewTemplate for XXX" form will now be used for all views using the same alias.
For example: You may have a database where a group of views are used by admins, another group of views are used by the accounting department, and another group of views are used by the hr depart.
Create these forms:
1) "$$ViewTemplate for admin"
2) "$$ViewTemplate for accounting"
3) "$$ViewTemplate for hr"
Now, on all admin views, give them an alias of "admin". On all accounting views, give them an alias of "accounting", and finally, for all hr views, give them an alias of hr.
When any of the accounting views are opened, they will use the "$$ViewTemplate for accounting" form and so on for the rest.
Jack. Nice idea. However, is it a good idea giving three views the same alias? Sounds messy. A better approach may be to give *one* $$ViewTemple form *three* aliases. i.e:
"$$ViewTemplate for admin | $$ViewTemplate for accounting | $$ViewTemplate for hr"
Yes, giving the same alias is messy. When I first started most of our users had notes mail licenses so we were restricted to using lotus signed databases. Adding a $$viewtemplate default would have broken the signature. Instead there was already a $$view template for all - so I gave most views the alias 'all'. It works but when you use the designer to refer to view (links/embedding/framesets etc)It (unbeknown to the developer) reverts to the alias when saved. Thus, accessing on the web, the damn thing didn't know which 'all' to open.
Jake,
I think Veer hit most of this, but in the interests of full disclosure...
1) define a list of views in a control doc (this is where you get to say that you don't favor mixing design with data)
2) have your hide-when exclude the $$ViewBody when the current view's name isn't in the "looked up" list of views.
How is using the same alias name messy? You don't use that alias name when accessing it.
For example, if you had the following views:
LatePayments | accounting
Orders by Customer | ordersByCust | accounting
You would access the first view by db/LatePayments?OpenView and the second view by db/ordersByCust?OpenView
both views would use the same "$$ViewTemplate for accounting" form.
Maybe not messy but surely it's not "good" design practice. It's a hack is what it is.
Read Ian B's comment for a reason against its use.
Jake, I wouldn't call it a hack or a "bad" design practice. It's just another way of doing things.
Your comment earlier about putting different alias names in the $$ViewTemplate form has its limits. For one, it makes it more difficult to determine which $$ViewTemplate a view is using when its buried on the name line of the form and secondly, there is a 255 character limit to the name of a form and thus you are limited to how many views you can define to use the same form.
As for Ian comments, I've never run into the problem(s) he refers to.
Well Jack, others (including myself) feel a little uncomfortable with this, as Notes usually takes the alias (even if the name doesn't imply it) for the "real" name for almost all it's internal processings and the name for some kind of "display" name.
The last time I felt like I needed this, I went away with one $$ViewTemplate for DisplayName and used 12 different views, all with the same DisplayName but with different aliases. You could easily argue against that approach as well, but at least it's another working way to do the same thing.
Another thing I do very often is not to use the $$ViewBody field, but an embedded view instead, even in $$ViewTemplate forms. This might be partly due to the fact, that I didn't do any serious web programming before the advent of R5, but there is one real advantage: If you enter an empty string in the "Embedded selection" property, you can have the advantage of one $$ViewTemplate for multiple views (as stated above) along with my all-time favorite "Show single category".
And by the way, pals: We're talking R6 here, so @ViewTitle[1]; is just fine. ;-)
What I find to be a shameless oversight on IBM / Lotus part is that the Restrict to Category can't accept a list. What if I want to show 2 out of 5 categories? I'm left doing something ugly like using an agent to render my selected view categories instead of built-in functionality. :-P
I stumbled upon this limitation when I thought it would be great to have a checkbox field at the top of a view template form which would be the category column. The Selected Category field for the embedded form reflects the value of the checkbox field. It would be a nice way to allow quick filtering of a view... if it worked. As it stands, you need to call it a radiobutton field and use the same methodology.
I should note, re: my above posted... this is in R5, havn't tried in R6 yet.
Where I said, "Selected Category field for the embedded form" I meant to say, "Show Single Category formula for the embedded View". I also was using this in the Notes client, not the web. I'm going to recommend this as a feature for the web facing portion of the app as it doesn't seem doable in R5 client, but will at least be possible on the web.