JamieMagee

Comments

1 - Hi Jamie! Good to see you posting. Well, it wasn't me, but here's a good link / comment thread re views and the use of @Today:

{ Link }

Posted by Ben Poole At 11:11:50 AM On 01/30/2008 | - Website - |

2 - Great session. I'm looking at page 17 of the PDF. On the subject of @Userroles you have "Use in a computed field, then reference from elsewhere".

Will that work correctly? Or will it give a person viewing the doc the same user roles as the last person who caused the document to be computed?

My own testing has indicated that I need to make the field "Computed for display" to make this work.

Thoughts?

Posted by Timothy Briley At 01:31:59 PM On 01/30/2008 | - Website - |

3 - Great to see you blogging. I look forward to reading more (and will add you to my blogroll which is currently somewhat sparse).

Posted by Julian Woodward At 02:00:22 PM On 01/30/2008 | - Website - |

4 - @2 - Hi Tim, thanks for attending the session. Yes, it would have to be a CFD field if you want it to compute when the document is opened. Note that @UserRoles is not necessarily recomputed at each occurence as of ND7. Therefore, also note that we actually had removed that slide from our presented version. We had to turn in the Lotusphere version a couple of months earlier and before we had tested as thoroughly on ND7 and ND8.

Posted by Jamie Magee At 02:15:22 PM On 01/30/2008 | - Website - |

5 - No wonder I didn't remember that slide from the session. I was wondering how I missed that.

"Note that @UserRoles is not necessarily recomputed at each occurence as of ND7."

Which means I shouldn't try to use this at all or ...?

Posted by Timothy Briley At 03:31:11 PM On 01/30/2008 | - Website - |

6 - @1 - Ben, that's a great thread, thanks for pointing that out. I like the @Text( ) method, which is also similar to just making the View refresh frequency set to "Manual" instead of the default "Automatic". I've seen that before, but wonder if there's a drawback when using it with @Now in the freshness of the view calculations. Looks like you'd have to manually trigger the view to refresh if the data was not automatically being updated regularly.

@5 - it's still good practice to write your logic in one place (CFD field) and reference it as often as needed. But my comment about ND7 is that consolidating such @UserRoles calls into once place is no longer a performance gain as far as I understand it. Lotus made Domino faster by caching @UserRoles called more than once on the same form.

Posted by Jamie Magee At 07:27:32 PM On 01/30/2008 | - Website - |

7 - @6 - Ah. Thanks for the clarification. Since we are on ND7.02, I'm not going to gain anything by rewriting my existing H/W formulas. I was about to do a lot of work for nothing.

On a separate note, but the same presentation, you mentioned how expensive db.GetView is if you use aliases. Well everybody I talk to was pretty stunned by this because we all use aliases due to the business owners always wanting to change view names. Obviously I can avoid this by never using public views for lookups, but that requires duplicating views and that cure appears worse that the disease in terms of overall server performance.

Any idea if there has every been talk of adding "db.GetViewByAlias" or a server setting to first search for the view by alias, then by view name? Or is there a better way?

Posted by Timothy Briley At 11:11:04 PM On 01/30/2008 | - Website - |

8 - I got the heads up from my mate Bill

Welcome to the Blogging world !

Coatsie

Posted by Coatsie At 04:31:33 AM On 01/31/2008 | - Website - |

9 - Mick Baitinger whispered this to me during your session but maybe someone else had the same idea.

Posted by Jim Knight At 08:12:30 AM On 01/31/2008 | - Website - |

10 - @7 - Tim, the effect is most noticeable from Notes (not as much from web), hundreds of views, when you are using a case-mismatched alias, and when the server is overloaded. Case matched alias is one fewer pass at the view list, but still two more than getting by the view name. And of course, you don't want to include getView in a loop where it could be set once instead. I suggest profiling your code to see your actual getview timing. It's one of those tradeoff situations between maintainability and performance. If you don't see a problem, then I'd stick with the alias.

Posted by Jamie Magee At 08:55:49 AM On 01/31/2008 | - Website - |

11 - @10 - Thanks.
I don't have hundreds of views in one db (you do mean in just one db right?) and I never write case-mismatched anything (too anal-retentive), so maybe it doesn't matter, but only profiling will tell.

But it does appear that Lotus is penalizing those who are using what would otherwise be best practice.

Since I always want to have my cake and eat it too, I'm tempted to propose a optional parameter for getview: db.GetView(string, [aliasfirst])

Posted by Timothy Briley At 01:38:00 PM On 01/31/2008 | - Website - |

12 - Andre Guirard has more good points on this topic here:
{ Link }

Posted by Jamie Magee At 07:23:34 AM On 02/01/2008 | - Website - |

13 - One problem/issue. I guess if you rely on a view that has it's formula programatically changed by an overnight agent, if you ever replaced the design of that database during the day from a template, you'd have to make sure that the agent runs at the time the design is replaced. Otherwise the view will be incorrect.

Posted by Richard Shergold At 08:12:07 AM On 02/01/2008 | - Website - |

14 - @13 - Hi Richard, that's true. One way you could do this is to have a database postopen event check one such known view, then set a flag in a db profile doc (to prevent that process from checking again next time). Not pretty, but it would automate the rollout step you identify. See some of Andre's points above (12) for other ways to do this, as well.

Posted by Jamie Magee At 04:55:15 PM On 02/01/2008 | - Website - |

15 - I think the way it works is if the agent is scheduled and enabled in the template, when you refresh the design the agent will run in the target database. Most people disable agents in templates because of this (as well as not wanting agents to run in templates), but you could use it to your benefit here.

Posted by Charles Robinson At 05:50:25 PM On 02/03/2008 | - Website - |

16 - an option might be having an agent that moves documents to s specific folder in stead of using a field with a flag ?

Posted by Patrick Kwinten At 04:03:56 AM On 02/06/2008 | - Website - |

17 - Hi Jamie, welcome to the Blogosphere! Funny thing about this place is that rule #1 here is similar to that for public speaking: "Some else in the Blogosphere has probably already blogged your topic."

In this case, Sean Burgess posted code { Link } last year that does exactly what you describe here using a hard-coded date and scheduled agent. This is something I picked up on { Link }
with the goal of making an "improvement" to the approach that was designed to handle different international date formats, only to be informed by Andre Guirard that it was unnecessary.

I liked this approach so much I incorporated it into SuperNTF. I'll probably now have to implement Charles suggestion to enable that agent in the template.

All goes to show great minds DO think alike

Posted by Kevin Pettitt At 09:21:45 AM On 02/07/2008 | - Website - |

18 - @16- Patrick, Not sure what you're asking/telling, but one way is to use an agent to set a field to cause documents to display their time value (e.g., "5 days overdue". However, this causes additional replication. Another way is to use a folder to move docs into or out of a folder, which is then used in place of the view when you need to see time critical documents. this has virtually no replication effects because documents are not modified when they are moved between folders. The other way mentioned here in this post works well in some cases. In most cases, simply changing the Index refresh frequency (e.g., to "Auto- at most every 24 hours") in the View design element is sufficient. See Andre's post in #1 above.

@17 Pettitt - you are so right. I'm still catching up on good stuff from a year ago. thanks for the comments.

Posted by Jamie Magee At 10:30:05 AM On 02/08/2008 | - Website - |