Thursday, March 01, 2007

"CoolMail" Demo Deconstructed

OK...A couple of people asked me about the post from last Friday, so I thought I'd detail the technique here. There are a couple of other things going on in that movie which I left out and also a reader suggested a neat trick which I have some future ideas for.

The actual implementation of this functionality is fairly simple. First, you add the buttons, drop down box, , etc., to the form. In the picture below, you see the button to add and remove the star and a combo box.



Remember that these elements are on the form and will be exposed in the embedded editor. Thus, the code should be written with this frame of reference in mind. For example, the code behind the "Remove Star" button is simply:

@SetField("Star"; "0");
@PostedCommand([FileSave])

On the UI form of the application, I have a simple embedded view/embedded editor combo. Again, there's really nothing special happening here, just the standard functionality where the embedded editor is wired to the embedded view. The only difference is in the way the form is exposed. Usually, you think of embedded editors exposing fields that the user can edit text in. In this case, I'm just showing some controls to do something to the underlying document. All of the design elements on the embedded form are hidden when embedded except for that top line with the buttons.


Et voilĂ !

Here's something you might have missed. See the links on the side and how the highlighted element blends right into the container for the embedded view? This is kind of like the idea of vertical tabs. Unfortunately, doing this with a tabbed table isn't so easy. I think the implementation in the Notes client is not really that good. Instead, I did this with a simple embedded outline. This is a nice technique, since it affords you so many formatting options. I placed the outline in a table and abutted it to the container cell, then just used an image well to color the selected element. The sweet thing about Notes, of course, is that you could do this in several ways.


I was also asked about coloring the lines in the view, so here is my approach. First, I created a color column in the view and set the value to the field called "num_ViewColor". This is a field on the embedded form whose value is computed. The formula behind the "num_ViewColor" field is:

colRed := 255 : 225 : 220 : 0 : 0 : 0;
colBlue := 224: 241: 255 : 0 : 0 : 0 ;
colGreen := 224: 255 : 223 : 0 : 0 : 0;
colYellow := 255 : 255 : 208 : 0 : 0 : 0;
colClear := "";

@If(MoreActions = "More actions...";
@Return(@ThisValue);
"");

Choice := @Right(MoreActions; "...Set ");

Selection := "col" + Choice;

@Eval(Selection);

Basically, what this formula is doing is checking the "MoreActions" field, which is the combobox exposed in the embedded editor. If the "MoreActions" field is set to its default value, then the formula just keeps the value of "num_ViewColor" as is. If, however, the user selects a new color from the combobox, the color name is extracted from the user's choice and @Eval sets the new value of "num_ViewColor" to one of the options defined at the beginning of the formula.

One other trick is happening here. If you make a change to an embedded editor and then try to select another document in the embedded view without saving, you get the following error message:


To avoid this, I save the document on PostRecalc event which gets triggered on every change of the combobox. In addition, to make sure the combobox gets reset to "More actions..." after each time the user makes a selection, the QuerySave event includes the line @SetField("MoreActions"; "More actions...").

To wrap up, I wanted to share an idea that was sent to me by Marcos Romero. He commented that you could also perform the action to turn the star on and off by clicking on it, just like in Gmail. To do this, you would use an editable column and InViewEdit feature of the view. To get some insight into how this works, check out the "Rules" folder in your mail file. The icon that denotes whether or not a rule is enabled can be clicked to toggle the rule on or off. This is a cool concept and I have a few ideas of where this could be really useful.

I hope this helps and I look forward to hearing from you on how you might use similar techniques. Until next time...

10 comments:

Vitor Pereira said...

Just brilliant!
I recently stopped adding your posts to the favorites folder on my feed reader since I realized all your post were there. ;-)

Anonymous said...

This is a nice method for toggling form data. I noticed that the embedded editor only shows the form used in creating the view and that you cannot use another form as you can with the view form formula. Would it be possible for a form to *know* that it was an embedded form and use hide whens to show the appropriate controls?

Wayne

Nathan T. Freeman said...

A) Chris has already shown a hack to do this by interrogating the source.document.universalID against the NotesUIWorkspace.currentDocument.document.universalID if they're different, you're in an embedded context.

And B) I've requested from IBM Westford that the embedded view properly recognize a form formula, in which case this would be ultra-easy. I have not yet been able to coax out of them an answer. We'll see.

NotesNana said...

Chris - reading your posts is beginning to feel like opening a Christmas present! Thank you.

I'm glad someone has asked IBM to honor the form formula of the view tied to an embedded editor. Your work around of hiding fields based on whether or not the form is embedded is appreciated - but on a form that already has a lot of hiding going on based on other conditions it can make that approach a bit awkward.

Anonymous said...

Nathan, Thanks for the update. I found some references on Lotus Developer forums as well.
My plan was to use a tabbed table and show the appropriate tab based on whether the form was embedded or not.
And yes, It does take some forthought and planning.

Wayne

Chris Blatnick said...

See...I never have to worry about being away for a day or two, since Nathan usually beats me to answering questions anyway! Thanks, Nathan. :-)

@Wayne - That technique that Nathan mentioned may have gotten lost in the post-Lotusphere noise. I plan on doing a short post just on that in case people missed it.

nathan t. freeman said...

No problem, Chris. I'm all about taking credit for your fine work. ;-)

Wayne Sobers said...

Chris, The technique Nathan mentioned is in your "Enhancing A Template UI" blog entry. The rush of LotusSphere info meant I didn't read the entry all the way through. My bad.
Thanks again..

Wayne

Mike Kinder said...

Though Form Formula is ignored, if the documents do not have a FORM field, the editor will use the default form. So I am creating a fairly complex "Default Form" to use as my embedded editor. All other documents will use a "Type" field for the form designation, and all my views will have a form formula of type (where appropriate). The default form will use the type field plus others to determine what is visible in the embedded editor document. Hope this helps someone else out there, the Form Formula business is a big let down with this.

Mike Kinder
mkinder@acadiasolutions.com

Chris Blatnick said...

@Mike...that's a really great idea! Thanks for sharing. I'm going to be sure to try this!