« Odd Behaviour of LotusScript Function Not Returning NotesDocument | Blogs | Making the Flyout Menu Work in IE 6 - JavaScript »
Flyout Admin Menu: Coding the Server-Side
Having looked at the browser side of the flyout admin menu we need to look at the server side of things now.
It's all very basic, but clever, kind of. In the demo there are two flyouts - one for login and one for admin. Both are subforms and the one that appears is controlled by a simply formula. Content of both subforms is HTML and based around a single LI element. You can see what I mean below with the login subform.
It's a similar case with the admin menu, below:
The key to a useful admin menu is to make sure it contains all the links the user might possibly need. That set of links is not only made up of the basics but, more importantly, the document-specific options.
If you look at the admin popup's HTML above you'll see that the LI elements containing the basic links (new article, view settings etc) are prepended with a Computed Value. This computes to the value of a field called AdminLinks, which provides form-specific links.
The AdminLinks field is Computed For Display and lives on all forms (or you can leave it off if you only want the basic links, like on the demo's homepage form). Typically the value of the field is something like below:
@If(isAdmin | DocAuthor=@UserName; ""; @Return("")); @If( @IsDocBeingEdited; ""; "<li><a href=\"0/"+@Text(@DocumentUniqueID)+"?EditDocument\"> Edit This Document</a></li>" + @NewLine ) + @If( @IsNewDoc; ""; "<li><a onclick=\"return confirm('Are you sure?');\" href=\"all/"+@Text(@DocumentUniqueID)+"? DeleteDocument\">Delete This Document</a></li>" )
You get the idea — build a list of links based on what type of document it is and what roles/access the user has. What links you provide depends on what you're coding. There's no need to stop at simple edit and delete links. You could put links to anything in there. If the field were on a $$ViewTemplate form then you could add links to create the documents contained within. Etc.
It's a simple approach but it's powerful nonetheless and provides for all scenarios. Tomorrow I'll summarise the whole thing and get a download posted. I bet you can't wait.
Comments
Dragon Cotterill (Thu 7 Feb 2008 04:56 AM) website / e-mail
Doesn't your login box break web apps? If you use standard forms with ?OpenForm your additional <form> tags will break the existing document form since one is nested inside the other.
Jake Howlett (Thu 7 Feb 2008 05:09 AM)
Yes and no. Refer to the earlier post on that (last week sometime).
Alan Harris (Thu 7 Feb 2008 06:00 AM) e-mail
Am looking forward to this...big time !!
Cheers Jake.
Matt (Thu 14 Feb 2008 06:08 PM) website
I couldn't figure out why there was so much talk about fly-out menus until I logged into my brand-spanking new Prominic account.
Viola - there it was, a shiny red fly-out login-form jumping out at me saying "login-in here!!"
Good stuff, though I still think it's a bit more than necessary.
In my book, It's one of those things that you do just to say you've done it, and as of yet, I haven't.
Good stuff Jake.
Add your response here:
