One Form To Rule Them All
The application I'm working on at the moment is different from all others I've been involved with, in that there's not a single ?OpenView URL used. It was only yesterday that I had a real eureka moment of enlightenment and I don't think I'll ever use ?OpenView again!
Imagine the scenario: you've got a Form called "Person". You then add a set of views to show these people - "peoplebyfirstname", "peoplebylastname", "peoplebycountry", "peoplebycompany" etc etc.
To display the first view on the web you create a Form called "$$ViewTemplate for peoplebyfirstname". You then have to display all the other views as well. What do you do: Create a $$ViewTemplate form for each one or add aliases to the original Form so it looks like "$$ViewTemplate for peoplebyfirstname | $$ViewTemplate for peoplebyfirstname | $$ViewTemplate for peoplebyfirstname | $$ViewTemplate for peoplebyfirstname" ?? With the former you end up with loads of Forms that are hard to maintain. With the latter you soon get to the limit of the number of characters allowed for a Form name. Either way it's a complete mess!
Even when you think you've taken care of all the views you can guarantee you'll be asked to add another ("peoplebystarsign"). We need a simpler way of displaying these views.
Here's the alternative method I've come up with: use one form for all the views. Call it "People" and open it using the ?ReadForm URL command. In this form is an embedded view which is based on a formula. The formula works out which view to show based on a URL parameter passed to it. For example - "people?ReadForm&view=peoplebycountry" or "people?ReadForm&view=peoplebystarsign". Each time you add a new view you don't have to create anything new. You just need a new URL.
It's wonderfully simple isn't it. Well, that's because I've over-simplified the description of how it works. Obviously there's a little more to it. My new "View Forms" have some other fields on them (ViewName, IsCategorised, Categories etc) and use other bits of trickery to make it a truly expandable solution. In theory you could use one Form to display all Views in a database, no matter what documents they contain.
Anyway, it's going to be the next article I write. As soon as I've finished the one I promised recently. In the mean time you can do me a favour and help populate the views. Fill in your details below and press submit (you should end up back here).
Fill in as many as you like. Even if the names are made up (I've done Tony, George, Mickey and Donald already). Here's the view as it stands. I just want a widespread set of names, covering as much of the alphabet as possible. Adthanksvance.
Skip to the 
You can subscribe to an individual
Wouldn't it be simpler to add an alias to each view? What I do is give the view a name that is meaningful in designer, and then give it 2 aliases - the first one is one that can be referenced by script, formula, etc., and the second one that is a common alias for all views that are associated with a particular $$ViewTemplate. Means that I only need one template, and all views use it because their last alias is the $ViewTemplate name. Means no faffing about with URL parameters too.
Model-View-Controller design comes to Domino. I had experimented with something like this a while back but could not get it to work under all circumstances. Look forward to the article!
Interesting Greg. I'd never thought of that method. I'll have to have a play and see if it can do everything I'm doing with my new method. If so, it's all been pointless ;o)
It should be able to I think. After all you can still pass URL parameters to ?OpenView if you need to for other things. It means one less parameter messing up your URL though.
Gotta agree with Greg.
See here:
{Link}
I like Greg's approach for the cleanness of the URL but I like the ability to totally choose whichever view I like with whichever view template, which is what it appears Greg's method locks you into. So it's good in some situations and not so good in others.
Maybe I'm missing something, but why not just create a single $$ViewTemplateDefault form?
Gotta agree with Chris.
Surely the best solution is the $$ViewTemplateDefault for all of the default views then just add additional $$ViewTemplates for special cases.
Mark
I tend to only us $$viewtemplatedefault as a "catch all" to stop people opening views that may have been "accidently" left open to web!
Just put a nice message there instead of a view, like "Oi bog off and stop trying to open something your not supposed to!!"
Ok, maybe not quite that phrase...
I don't like the idea to pass a ressource name to include thru the URL. It makes me think of.. well, the common flaw in some scripting languages where beginners set a filename as parameter (foo.php?inc=contact.php, which can easily be replaced with foo.php?inc=/etc/passwd).
What if you got - like most of notes databases - an "All" view, through which people might discover sensitive data ? I guess it can lead to security issues.
Hmm, obviously I didn't think this one through 100%.
Greg's method of one common alias sounds a lot tidier and is the kind of approach I'd prefer to use. However, there are other aspects to my method that I want to talk about, which are useful. As always there's more than one way to skin a cat.
YoGi. If a view needs to be secure it should be secured.
Just an idea:
instead of using ?ReadForm, why not open a document. You could create 2 forms (one for the client, one for the web) and then configure all aspects of the view to show
- coloring
- menu at left/right
- text around etc
From the values entered in the form you compute the html that gets displayed around the view..
PM me for the sample DB...
;-) stw
I used to use a common alias for our views, which works really well, but found it caused an unforseen problem which took ages to pin down to the view. Can't for the life of me think *exactly* what it was though! IIRC, whenever you picked the view from a notes dialogue box it would actually refer to the alias without you knowing. All my links ended up showing the same view! This may have been fixed in newer versions.
Agree with Chris B. How does $$ViewTemplateDefault not meet the criteria?
@Chris H. - $$ViewTemplateDefault should never be used to control access to documents. There are just too many ways to easily bypass.
Jake,
Why not AJAX? I am doing a similar functionality using AJAX and it just plain rocks!
@Yogi, you are going to have the same issue no matter what approach you take. Your application is either secure or it is not. I never have an "ALL" or "(ALL)" view.
Cheers!
Rob. The ViewTemplateDefault is probably just as good at the job. Personally I'd rather have a form to show the views for each kind of document in a database. Makes it more flexible.
Christopher. AJAX is very cool. Although I don't think rendering a view is putting it to its best use though. Use AJAX where nothing else will do. Don't use it for the sake of it.
All of our production Domino web applications use this technique. It's also included in a sample database posted in the Code Bin on OpenNTF.org --> {Link}
Great find Curtis!!
I chose the $$ViewTemplatedefault approach for my rewrite of DomBlog. It makes for much more consistent presentation (though sometimes inadequate) and you can completely leave the ?open parm out if you choose, though I didn't carry it to that end.
I think the opportunities here are in
* cleaning up your URLs,
* consolidating your design, and
* avoidance of being overly reliant on server side processing of query args which add a smidge to performance drag.
Keeping those goals in mind, as Jake says, there are more than one way to skin a cat - use what suits your situation best.
There is one huge flaw to having a commons alias amongst all of your views so they can share one view template.
If you have one of these views set to prohibit refresh design, all of the views will not update if you needed to push a change.
Greg-
Great idea, I had tried this once before but couldn't get it to work, seeing your comment lead me to do try it again. It appears (6.5 client/server) that it only works if you use the generic name as the first alias. This makes it hard to see your real alias name in designer because it only shows the first alias name in the view listing.
For those questiong why not just use $$ViewTemplateDefault consider this common scenario:
I have a 100% web based applications with ~10 views for the customer side of the app, these are (now) displayed using $$ViewTemplate for cust, There is also an admin side that is (now) displayed with $$ViewTemplate for admin, $$ViewTemplateDefault is the same form as $$ReturnGeneralError to help secure lookup views from being exposed.
All of my views have three names 1)User Friendly 2)View type (cust,admin,sys) 3)Alias for script access.
The only minor drawback is that if you want to NOT use the $$ViewTemplate for cust you have to remove the cust alias. I tried using $$ViewTemplate for User Friendly and $$ViewTemplate for ScriptName to override the $$ViewTemplate for cust, neither worked.
Niel,
After considering your common scenario ;-) I still don’t see why you don’t use $$ViewTemplateDefault for your customer views, 1 $$ViewTemplate for admin and hide the lookup views from the web if you have a concern for people trying to open them.
Making sure only the views you actually want visible on the web is good practice. Trawl through all of those crazy lookup views and use the design properties box – your lookups will still work.
Jake I am not sure how having a separate form is any different to the $$ViewTemplateDefault after all it is a form isn’t it ? I can understand if you want to use editable fields but you could do this anyway couldn’t you as in your Simple Search box.
One other thing, I understand some search engines are not overly happy following parameterised URLs which could lead to problems (if this is important to you).
Mark
I think this is a pretty good idea. However I'm sure that it won't satfisfy every requirement. I did something similar to this (although not quite as advanced) back in the late 90's and it worked well for that particular company.
I like the idea of having one form for each type or category of information. I can see that this would be very useful in many apps.
I look forward to seeing the article.
Ethan
Mark-
I didn't realize you could disable the view for web access and still use it for lookups on web based forms. Thanks!
Yes, two $$VT will work.
...but there are still views used in the app that need to be exposed that you wouldn't want people to access directly.
example app.nsf/myview/dockey?OpenDocument
I don't want someone to be able to access app.nsf/myview?OpenView
Ahh,
I understand. No views at all.
Why not app.nsf/0/unid?opendocument then ?
Mark
My 2p
A one form design is easily acheivable although it has the downside of old "max lines" problem to contend with.
$$ViewTemplateDefault allows you to get around the max lines problem with some sensible computed navigation links and generally works fine except for one of Domino's idiosycracies (is that spelt correctly?)
This being the inclusion of <meta name="robots" content="noindex"> which is automatically inserted by the server when it displays a "view". Whereas a form (or page)with an embedded view has no such annoying html inserted into it.
Why annoying ? Because use of $$ViewTemplateDefault seems to stop Google indexing a site and that is the only significant difference I can see
Hi Jake, I was developing such a view, but then I discovered tha when you have a standard categorized view, when you expand or collapse the view, the querystring which I passed (like: viewname=ByCompany), Lotus overwrites the URL with the expand, start etc. variables.
Do you know how to catch this?
Thanks in advance
Hi Mo. No, I don't know of any way round this. My approach is to pretend these options don't exist and not use them.
Hi Jake:
Please, I would like to know if you can help me How Can I do your cathegorized view by LastName(alphabetic list) ?...because I'm building something similar but with countries............
1000 thanks,
Carlos.
Dear Jake,
I was very happy and surprised, when I found your blog site (www.codestore.net).
It is a very interesting and helpfull site for webdomino designers.
I have some problems with the domino views and I found solutions for those on your blog site.
May I have a question to you: Where could I download the (viewform.nsf) example file?
..and please, updating the link of your donate.
Many thanks,
Zoltan