1Declan Lynch  10/08/2006 14:10:41 GMT   Future and Language protecting your Notes Application

I would also suggest that you find a naming convention and try stick to it. For view's I normally put 'vw' infront of the alias unless it's a lookup view and that i use 'lkp', for forms I use 'fm' unless it's a dialog box and I use 'dlg'.

Whatever naming convention you use the more you stick to it the easier your translations can be applied and also it's easier when you come back to the application after a long while to be able to quickly figure out what some of the code might be doing.

Did you know you can Double Alias forms and views by using a second pipe symbol?

2Sean Burgess  10/08/2006 17:25:13 GMT   Future and Language protecting your Notes Application

I cannot tell you how many times I have used aliases and been so thankful because the client wants to change the name of the form or the view. For views, I try to make the name really descriptive, expecially if it is hidden, and make the alias nice and short for use in formulas. I am always amazed when I go into a database that doesn't use aliases.

One caveat with keyword lists is that you have to be careful when accessing the values via Javascript. Getting used to the text vs value attributes can be unnerving.

Sean---

3Steve Castledine  10/08/2006 18:51:37 GMT   Future and Language protecting your Notes Application

@Declan - yes I was aware of that - but never used it - have you? Yes I "mostly" prefix everything vView or fForm etc which is also good practice.

@Sean - I am always amazed when people do not use aliases for anything. es javascript you have to watch - together with any view categorisation as you need to replace your field values with the text descriptions etc

4Rich Waters  10/08/2006 19:32:26 GMT   Future and Language protecting your Notes Application

Double aliases on views can be really handy, the first name being descriptive that can easily change, the second is what you use to refer to it in code. For the third I pick a keyword and use the same value across multiple views then create a view template for that keyword. Just a nice way to have multiple views use the same view template.

Another note about aliases in fields is that you can have the pipe in a calculated view column then pull the list of choices in via dbcolumn

5Torley Linden  11/08/2006 06:05:43 GMT   Future and Language protecting your Notes Application

I don't understand what's behind this, but I really like the graphics--may I please ask how you did the jagged "tear-off" edges of the screen captures? They have a really nice look to them that's *not* a faded edge!

6Wild Bill  11/08/2006 11:21:40 GMT   D’oh!

I've just finished a 70-odd page on "LotusScript Best Practices" for the View in Vegas in October (And Vienna in November) and guess what I forgot to put in!

:-)

Oh. One thing I've seen work very well, is just numbering the alias version of the view - v0101 - for instance. Far easier to code to, and no trying to remember what "vwSysLookupDialogFoobarByCategory" actually means...

---* Bill

7Wild Bill  11/08/2006 11:22:43 GMT   Future and Language protecting your Notes Application

In terms of Screenshots, I use SnagIt - { Link } Our manual at { Link } has over 450 screenshots and by god does a tool like this help....

Course I dont do anything quite as "Southern" as "jagged edges"..

:-)

--* Bill

8Steve Castledine  11/08/2006 11:39:09 GMT   Future and Language protecting your Notes Application

I've seen that alias numbering as well Bill - used it a few times (I should use it more).

It makes documentation a lot easier to read when referring to views especially that way.

I used snagit as well - excellent piece of screen capture kit!

9Torley Linden  12/08/2006 22:02:03 GMT   Future and Language protecting your Notes Application

Thanx Bill and Steve--good to know!

10Michael  13/08/2006 08:58:23 GMT   Future and Language protecting your Notes Application

Well, I'm not a "everywhere an alias" fan neither a prefix everything fan. Why ?

- system design elements (lookup views etc) need to only have a system name, they won't be translated

- prefixing everythings makes finding design elements harder when sorting in designer. Same goes with giving design elements a "functional" name (cause functional name can change bases on customer request...)

- outlines and window Title events allow us to translate those parts that the user sees

and most of all, aliases are a performance penatly. When looking up a design element, domino always try to find it by name (with correct case, then case insensitive then via alias...)

In the end, in most of my dev, I use alias in Keywords field and some views, that's it.

PS : of course one can use some aliases in $$ViewTemplatefor xxx so this can be used for multiple view etc...but that's not a pb of translation ;)

11Karl Martinsson  15/08/2006 21:59:35 GMT   Future and Language protecting your Notes Application

One thing to remember is that when you do a db.GetView() that Notes look for teh view in the following order (if I remember it right from the performance session at Lotusphere 2005):

1) Viewname case matching

2) Viewname case not matching

3) Alias case matching

4) Alias case not matching

So it will look through the database up to 4 times before finding the view if you call the alias and not spell it exactly the same (upper/lowercase).

E.g. you have a view called "FooBar" with the alias "Barf", of you do set view = db.GetView("barf"), it will take four searches to get the view handle...

12Martin  16/08/2006 16:25:29 GMT   Future and Language protecting your Notes Application

Double (or triple and so on) aliases are fine and I use them quite often. Just a shame, that in Designer is visible just the first one.

But are you aware of the same when it came to the values in field names? It's working a little bit different there, and sometimes it's useful.

13Corey Kimball  17/08/2006 13:34:46 GMT   Future and Language protecting your Notes Application

I've used aliases since the v3 days, and I think they are definately the way to go. Many times I've had a user come to me and say, "I know we talked about naming the form x, but now I want to call it z". Simple thing to fix, because I had an alias.

One caveat about field aliases though. I was working at one company where we were using field aliases, and when the user was searching for data in a specific field, the search didn't work. The reason it didn't work was because the user was searching for the word that they had selected from the keyword list ("foo"), but the data that was stored was "f", so the search didn't find what was typed in.

Otherwise, I really like using aliases.