轻松重现“第一次使用共享、桌面私有”功能意见
我有一些在选择公式中使用@UserName 的视图。为此,视图必须是“共享,第一次使用时桌面私有”。那没问题。
但这个视图会经常被悄悄地重新设计。
由于这是一堆视图,因此用户删除每个视图并通过设计更改从头开始重新创建是非常不舒服的。
我尝试了不同的方法来与代理一起完成这项工作,但没有人是万无一失的,并且会给出一些奇怪的结果(有时甚至不更新设计)。
迄今为止最好的结果是从工作区中删除图标并再次打开应用程序。这(直到现在)始终有效。但这对于最终用户从(深层)服务器文件夹重新打开应用程序来说非常烦人。
还有其他方法可以更新“第一次使用时私有”视图的设计吗?
I have some views that uses @UserName in the selection formula. For working that, the view must be "Shared, Desktop Private on 1st use". That is no problem.
But this views are going to be redesigned quiet often.
As this is a bunch of views it is very uncomfortable for the user to delete each of this views to recreate from scratch with design changes.
I try different things to get that done with an agent but no one is fool-proof and give some strange results (sometimes even do not update the design).
Best result so far is to delete the icon from the workspace and open the application again. That works (until now) always. But this is so annoying for end users to reopen the app from the (deep leveled) server folders.
Any other method to update the design of "private on 1st use" views ?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(6)
正如您所注意到的,维护私有视图是一件很痛苦的事情。为什么不换一种方式来解决你的问题呢?
创建一个分类视图,其中第一个分类列包含您与当前解决方案中的用户名进行比较的字段。
然后将该视图作为“单一类别嵌入视图”嵌入到表单中,并使用 @username 作为类别。
急速。现在您拥有的视图仅显示当前用户的文档,并且您可以随时更改设计。
Mick Moignard 在网上有一篇关于该主题的好文章:Notes 中的动态视图过滤。
另请参阅 Lotus Domino Designer 帮助,主题“在嵌入视图中显示单个类别"
As you noticed, private views are a pain to maintain. Why not go a different way to solve your problem?
Create a categorized view, where the first, categorized column contains the field you compare the username in your current solution to.
Than embed that view into a form as a "single category embedded view" and use @username as the category.
Presto. Now you have a view that only shows documents for the current user and you can change the design whenever you like.
Mick Moignard has a good article on that topic online: Dynamic view filtering in Notes.
See also the Lotus Domino Designer Help, Topic "To show a single category in embedded views"
我尝试解决同样的问题,最终做了两件事 - (1) 自动向用户发送一封包含数据库链接的电子邮件,并要求他们删除数据库图标,以便删除私有视图;(2) 发出警报当私有视图的设计发生变化时用户。
第一部分相当简单 - 我编写了一个 LotusScript 函数,它将向当前用户发送一封电子邮件,其中包含指向当前数据库(包含私有视图的数据库)的链接,以及一些有意义的文本和数据库信息。用户所要做的就是退出数据库,删除数据库图标,打开他们刚刚收到的电子邮件,然后使用链接再次打开数据库。无需导航服务器文件夹或想知道要转到哪个服务器。它可以单独使用,例如在按钮中,但我最终将它与一些更棘手的东西结合起来。
第二部分是设计一种方法来提醒用户他们正在打开的视图的设计已经过时。棘手的部分是检测视图的设计是否已更改。使这种情况成为可能的原因实际上是导致该问题的原因 - Notes 缓存了私有视图。缓存私有视图时,Notes 还会缓存视图事件中的脚本引用的常量,这些常量是视图使用的 LotusScript 库的一部分。
以下是我使用的设计的描述:
PrivateViewsCode
。PrivateViewsCode
的(Declarations)
中声明Const DESIGN_VERSION = "1.0"
。PrivateViewsCode
中声明函数myQueryopen
。myQueryopen
接收的参数之一是字符串designVersion
。Queryopen
事件中调用myQueryopen
,将DESIGN_VERSION
传递给designVersion
。由于此代码位于缓存的视图中,DESIGN_VERSION
将包含缓存视图设计时(用户首次打开它时)的常量值,在本例中 -“1.0”
。在
myQueryopen
中将designVersion
与DESIGN_VERSION
进行比较。由于
myQueryopen
是PrivateViewsCode
脚本库的一部分,因此您实际上在这里比较DESIGN_VERSION
(在私有视图中缓存,然后传递给myQueryopen
)从PrivateViewsCode
到DESIGN_VERSION
,该代码始终是最新的。DESIGN_VERSION
后重新编译视图(Tools\Recompile all LotusScript)。我希望这能解释设计,它是如何工作的:
对私有视图设计进行更改后,您可以更改版本:
<前><代码>DESIGN_VERSION =“1.1”
DESIGN_VERSION
的新值一起缓存(此处为"1.1"< /代码>)。
(designVersion <> DESIGN_VERSION)
现在产生false
。一切都恢复正常,直到下次更新。Ken 处理此问题的方法的主要优点是完全不涉及用户。这对我来说不是一个选择,因为我更改视图的频率(应用程序刚刚部署,我有很多更改视图的请求)以及应用程序中的大量私有视图。
(编辑)
我假设您有特定的原因使用私有视图,但自从它可用以来,我在嵌入视图中使用了“显示单一类别”(正如 leyrer 所建议的那样),并且对此非常满意。如果您发现使用“显示单个类别”选项有任何限制,我会尽力帮助您。
I have tried to solve the same problem and ended up doing two things - (1) automatically send the user an email with a link to the database and ask them to remove the database icon so that the private views get deleted and (2) alert the user when the design of a private view has changed.
The first part was fairly simple - I wrote a LotusScript function that would send the current user an email message containing a link to the current database (the one that contains the private views), along with some meaningful text and database information. All the user had to do then was exit the database, remove the database icon, open the email they just received and open the database again using the link. No need to navigate the server folders or wonder which server to go to. This can be used on its own, e.g. in a button, but I ended up combining it with something a little more tricky.
The second part was devising a way to alert the user that the design of the view they are opening is outdated. The tricky part was detecting that the design of the view has changed. What made this possible was what actually caused the problem in the first place - the fact that Notes caches the private view. When caching the private view, Notes also caches constants that the script in the view events refer to, that are part of LotusScript libraries the view uses.
Here's a description of the design I used:
PrivateViewsCode
.PrivateViewsCode
's(Declarations)
declareConst DESIGN_VERSION = "1.0"
.PrivateViewsCode
declare functionmyQueryopen
. One of the parametersmyQueryopen
receives is stringdesignVersion
.Queryopen
event callmyQueryopen
, passingDESIGN_VERSION
todesignVersion
. Since this code is in the view that is cached,DESIGN_VERSION
will contain the constant value as it were in the moment the view design was cached (when the user first opened it), in this case -"1.0"
.In
myQueryopen
comparedesignVersion
toDESIGN_VERSION
.Since
myQueryopen
is part ofPrivateViewsCode
script library, here you actually compare theDESIGN_VERSION
(as cached in the private view and then passed tomyQueryopen
) toDESIGN_VERSION
fromPrivateViewsCode
, which is always current.DESIGN_VERSION
.I hope this explains the design, here is how it works:
After making changes to private views design you change the version:
DESIGN_VERSION
(here,"1.1"
).(designVersion <> DESIGN_VERSION)
now yieldsfalse
. Everything is back to normal until the next update.Ken's way of handling this has the major advantage of not involving the users at all. This wasn't an option for me because of the frequency with which I made changes to the views (the application was just deployed and I had many requests for changes to the views) as well as the big number of private views in the application.
(Edit)
I assumed you had a specific reason to use private views, but I used the "Show Single Category" in an embedded view (just as leyrer suggests) ever since it became available and was quite happy with it. If you see any limitations to using the "Show Single Category" option, I'll try to help you with that.
我找到了一种将痛苦从最终用户转移到开发人员身上的方法。我将导航设计为使用轮廓,以便我可以控制用户导航到视图时的去向。注释大纲条目可以更改,而用户无需经历删除图标然后重新打开数据库的麻烦。
当我需要更新私有视图的设计时,我也会重命名它,并更新注释大纲条目中对其的引用。在用户桌面上,当他们下次打开数据库时,将为他们创建一个新的私有视图。我的大多数(或全部)用户从未注意到任何事情,至少他们从未提及过!
这个过程对于开发人员来说相当容易,但也很容易忘记。此外,用户的工作空间最终将有大量对旧的未使用的私有视图的引用,如果它们的尺寸很大,可能会成为一个问题。例如,如果您更改视图二十次,或更改二十次视图,则可能需要删除图标以清除它们。对我来说,这些变化非常罕见,所以这并不重要。
I found a way that moves the pain from the end user to the developer. I designed the navigation to use outlines so I can control where the user goes when they navigate to a view. Notes outline entries can be changed without the user needing to go through the delete-icon-then-reopen-database hassle.
When I need to update the design of the private view, I rename it as well and also update the reference to it in the notes outline entry. At the users desktop, when they next open the database, a new private view will be created for them. Most (or all) of my users never noticed anything, at least they never mentioned it!
The process is fairly easy for the developed but also fairly easy to forget. Also, the user's workspace will end up having a lot of references to old unused private views, which if they are large in size might become a problem down the line. If you change the view twenty times, or change twenty views, for example, it may be time to delete the icon to clear them out. For me the changes were rare enough for this not to matter.
解决你的困境的办法并不是太难解决,而是有点乏味。有一个关于以编程方式简单删除私有视图的技术说明。这是开发人员常见的设计问题。
我必须采用以下方法来管理多个私有视图,这些视图在任何时候都会经历多个版本。
秘诀是检查 DatabaseOpen 事件,因为它是本地客户端上保存的视图,因此您需要通过用户的 UI 活动来执行此操作。只要您的 Lotus Notes 客户端群运行的是 6.5.x 版本,您就可以尝试以下操作。为了简洁起见,我概述了您需要做什么。
将您的私有视图命名为“yourPrivateViewName_1.0|yourPrivateViewName”
创建一个数据库配置文件,其中包含一个包含当前私有视图名称的字段,例如“youPrivateViewName_1.1”
在数据库上,通过视图打开循环,查找私有视图,然后将该名称与数据库配置文件中的名称进行比较。命名约定旨在使版本检查成为可能。如果版本不匹配,请删除视图。当用户下次打开该视图时,它应该获取您已发布的当前版本。
还有其他方法,例如检查私有视图和模板上的时间戳,但仍然需要一种方法来挑选私有视图。但我发现这种方式很容易管理。
The solution to your dilemma is not too hard to solve, but a little tedious. There is a technote on simply removing private views programmatically. It is a common design issue for developers.
I have had to take the following approach to manage multiple private views which were all going through multiple versions at any one time.
The secret is to do a check on the DatabaseOpen event, as it's a view held on the local client so you need to do this through user's UI activity. As long as your Lotus Notes client fleet is at running version 6.5.x you could try the following. To be concise, I have outlined what you need to do.
Name your private view "yourPrivateViewName_1.0|yourPrivateViewName"
Create a database profile document that has a field with the current private view name, eg "youPrivateViewName_1.1"
On DatabaseOpen loop through the views, finding the private view(s) then compare the name to the one in the database profile. The naming convention is designed to make it possible to do a version check. If the versions don't match, remove the view. When the user opens that view the next time it should grab the current version you have released.
There are other ways as well, like checking the timestamps on the private view and the template, but it still requires a way to single out the private view. But I found this way easy enough to manage.
谢谢大家!
我最终得到了以下结果:
创建一个从关闭数据库的菜单运行的代理
在数据库关闭事件中邮寄数据库链接并发送要从工作区中删除的密钥
(你们都得到了赞成票,但 ai 标记为最低代表的答案。积分用户。)
Thank you all !
I finally ended up with the following:
Create an Agent running from menus that close the database
In the database close event mail a database link and send keys to remove from workspace
(You all got your upvotes but a i mark as answer for the lowest rep. points user.)
由于 Domino 已被 IBM 出售给 HCL,IBM 已删除了 Domino 内容。
幸运的是,HCL 发布了一篇关于此问题的文章:如何管理或删除个人视图和管理员端的个人文件夹
它列出了使用服务器代理以 LotusScript 方式手动检查和删除私有视图的方法。我已根据需要将其调整为我在设计更改时运行的代理。
Hristo 提出的关于常量的问题的附录:一个鲜为人知的事实是 LotusScript 库可以有一个属性,如下所示
:避免了Const缓存问题。
请注意,模块级属性例程默认为私有,这很好。
在实现设计器清理代理时,我得到了一个想法,当从数据库脚本中的初始化子程序调用此例程时,该例程也可以工作,如果数据库脚本有代码,则该例程在数据库打开时运行:
这将为每个打开数据库并清理的用户运行提出他们的看法。如果您想清理所有内容,请将子程序放入在服务器上运行的计划(计划可以永远不会手动触发它)代理中,由服务器签名,以便它在第一次使用视图时看到所有私有视图。我通过缩短主名称来测试它(它有一个很长的名称,这是我从 HCL 文章中收集的,出于设计缓存的原因,您不应该这样做)。刷新数据库设计后,发现没有主副本(因为名称已更改)并将其删除。
通过比较副本的 Created 日期时间与主文件的 LastModified 日期时间来确定是否检测到已更改的主文件。
没有主控的副本或在主控上次更改之前创建的副本将被删除。将 sub 放入 ScriptLib 中允许代理和 dbscript 共享定义。警告:在服务器上,输出将发送到 Domino 日志,您可能需要进行调整。需要以提升的权限运行代理,请参阅代理的安全属性。
Since Domino has been sold by IBM to HCL, IBM has deleted the Domino content.
Luckily, HCL has posted an article about this: How to manage or remove Personal Views and Personal Folders on the Administrator side
It lists both a method to check for and remove the Private views manually as a LotusScript approach using a server agent. I have adapted this to an agent I run on design changes as needed.
Addendum to issue Hristo raised about constants: A liittle know fact is that a LotusScript Library can have a Property, like so:
This avoids the Const cache problem.
Note that module level Property routines are Private by default, which is good.
While implementing a Designer cleanup agent, I got an idea which also works when this routine is called from the Initialize sub in the Database script, which is run on Database open if it has code:
This will run for every user opening the db and clean up their views. If you want to cleanup for all, put the sub in a scheduled (schedule can be never to manually trigger it) agent run on the server, signed by the server so it sees ALL private on 1st use views. I tested it by shortening my master name (it had a long name which I gathered from the HCL article you should not do for Design cache reasons). AFter refreshing the design of the database, it found the copy with no master (because the name changed) and deleted it.
Detection of a changed master is determined by comparing the Created datetime of the copy to the LastModified datetime of the master.
Copies without a master or created before the master was last changed are deleted. Putting the sub in a ScriptLib allows the agent and dbscript to share the defition. Caveat: On the server, the output goes to the Domino Log, you may want to adapt. Need to run the agent with elevated authority, see Security properties for the agent.