IdeaJam(tm) feed for Dwain Wuerfel

Domino Designer / : Form Properties

Tue, 01 Apr 2008 14:00:55 +0000

Author: Dwain Wuerfel
Tags: Form Properties
Idea:

Make available an option to never save a form on the form properties so that whether the form is closed via a button or the ' X ' for the database tab you don't have to worry about coming up with some ingeniuos programming to prevent the user from being prompted to save changes

re: Form Properties

Tue, 01 Apr 2008 15:42:36 +0000

Author: Matt White
Comment: I can see the attraction of moving SaveOptions to the properties dialog, so as long at the functionality stays the same as the current implementation offers then a promote from me.

re: Form Properties

Tue, 01 Apr 2008 14:59:02 +0000

Author: Grant Lindsay
Comment: A "SaveOptions" field, with a value of "0" (text value of zero) does this. Personally, I like its flexibility.

re: Form Properties

Wed, 02 Apr 2008 04:45:11 +0000

Author: Rob Goudvis
Comment: I prefer Lindsay's method.

re: Form Properties

Wed, 02 Apr 2008 09:50:46 +0000

Author: Paul Davies
Comment: as long as it simply sets SaveOptions as a default, in the same way that setting Anonymous form just sets the $Anonynous field then yes. In fact it seems odd that it has been ommitted from the form properties

re: Form Properties

Thu, 10 Apr 2008 17:48:27 +0000

Author: David Lundy
Comment: I agree with Paul and Matt. Making it a property would be more useful (and more obvious) than having to code around it.

Domino Designer / : Hotspot Formula Pop-Up

Thu, 15 May 2008 18:13:07 +0000

Author: Dwain Wuerfel
Tags: Hotspot Pop-Up
Idea:

In version 7.0.3 when you want to create a formula pop-up hotspot you only have the option of using formula language. Allow for the use of any supported language.

Domino Designer / : Dialog List Choices

Wed, 21 May 2008 21:14:37 +0000

Author: Dwain Wuerfel
Tags: DialogList
Idea:

Please allow LotusScript to be used as a choice rather than just formula. This will allow for using fields from profile documents in other databases for the field.

re: Dialog List Choices

Mon, 26 May 2008 13:01:03 +0000

Author: Axel Janssen
Comment: I think for simple things as dialog list choices formula languages qualifies as "Domain Specific Language". Its ok.
Things get nasty when you have to fix/enhance an old database whith really huge formula-scripts.

re: Dialog List Choices

Thu, 22 May 2008 05:01:25 +0000

Author: Rob Goudvis
Comment: I am in favour for everthing that allows to use Lotusscript (and Javascript).

re: Dialog List Choices

Thu, 22 May 2008 10:14:22 +0000

Author: Jos� Manuel Rodriguez Moreno
Comment: We should be able to use a language everywhere.
This is a clear example where you can use Formula but not LotusScript.

I would like to standardize all my development in 1 language (Java), so I can do a faster development reusing code (not coding the same in Java, LotusScript and Formulas in different places of my application). But the problem is that in some places we can only use Formulas, in other places we can only use LotusScript (as in many events of the "Database Script"), etc...

So, I promote this idea and propose to extend it to the Java language also.

re: Dialog List Choices

Mon, 26 May 2008 13:03:51 +0000

Author: Axel Janssen
Comment: A self respecting jee application does also require more than just "java knowledge", but also sql, different types of xml configuration stuff/annotations, etc.

Domino Designer / : Table Width Property

Wed, 10 Jun 2009 18:03:43 +0000

Author: Dwain Wuerfel
Tags: Tables Table Properties
Idea:

When creating a button you have the option of making the width 'Fit to Content'. It would be nice to allow a columns width to also have this option as tables are commonly used to keep multi-value fields in alignment

re: Table Width Property

Mon, 06 Jul 2009 09:27:12 +0000

Author: Theo Heselmans
Comment: You'll end up having a UI that is different from one doc to another. Very messy and confusing for a user. I vote against.

re: Table Width Property

Wed, 29 Jul 2009 13:19:17 +0000

Author: Aigars Perkons
Comment: Option is an option. Don't like it? Don't use.
Someone can make UI to coloured and confuse users. Let's go back to grayscale?

Notes Client / Other: Workspace chicklets

Sat, 23 Oct 2010 06:53:27 +0000

Author: Dwain Wuerfel
Tags: workspace icons chicklets
Idea:

You have the option of displaying the server name on the workspace chicklets, yes I use the workspace religiously, and if you right click an application in the bookmarks you can also view the applications properties to see the server name. However, if you create an application object for the 'desktop8.ndk' or 'bookmark.nsf', then get a view, and finally get a document you have no option of seeing the server.

Not sure how this is, but it would be awesome if there was a method to create a collection of bookmark/desktop applications that are referencing old servers. With this ability we, the developers, can assist our admin friends by writing a little code to cleanup the user workspace and eliminate many issues/calls.

Notes Client / Other: Document Locking

Thu, 04 Nov 2010 17:17:37 +0000

Author: Dwain Wuerfel
Tags: database properties box document locking
Idea:

There is a serious need for IBM to come up with a fix related to document locking and this is not a fix, but will allow some relief to the administrators/developers.

Currently, only those identified as having Manager level access can actually unlock a document and in our organization we don't make employees manager of anything other than their mail file to prevent accidentally deleting a database. So, maybe the below improvements could help:

1) give the unlocking option to editor and above

2) provide an ACL type option so that when you enable document locking you can specificy specific individuals, groups, or roles that are allowed to unlock a document and the developer can specify the number of hours to keep a document locked that works with #3

3) have a server task that will compare the time a document was locked to current and unlock if it meets a set number of hours as determined by the developer on a one off database case

I would think #1 is a quick fix that can be deployed with version 8.5.3, but the others I can see taking a litle longer.

re: Document Locking

Thu, 04 Nov 2010 18:48:51 +0000

Author: Peter Neidhart
Comment: Giving Editors (=Users) the ability to unlock is like putting the fox in charge of the henhouse.

re: Document Locking

Thu, 04 Nov 2010 22:45:43 +0000

Author: Dwain Wuerfel
Comment: Peter, I can see your point depending on how your organization sets up the ACL. For out organization editors are typically the database admins and others have Author or less rights. However, what do you think about the other 2 options?

re: Document Locking

Fri, 05 Nov 2010 11:28:04 +0000

Author: Vlad Sh
Comment: My opinion - you need to develop applications so that documents are properly unlock themselves at the end of a process.
I am categorically against the first paragraph - this is contrary to the ideology of access; sense from a lock, if it can remove another regular user?

Want to unlock documents automatically on the server, write an agent who will do it 1 time per hour.
Want to have a certain group of people (editors) could unlock the documents - give the group the ability to run agents on the server, access to the visibility of a special action, and when it is pressed, call the same agent with RunOnServer.
That's all you can do yourself in 10 minutes.