Introducing the Remote Embedded View Manager v0.1
Category Domino
Do you use Embedded Views in your Notes applications? Did you know that you can, at your own risk, have your embedded views reside in another database? Do you use templates for your development? Do you use development 'best practices' and have your development work reside on a different server and contain a different replication ID? Do you ever have to create new database from templates?
Do you see this...
when you want to see this...
If you answer yes to any of these questions, some day you will need the 'Remote Embedded View Manager' that I am releasing to open source via the OpenNTF community.
I have begun work on a very complicated application that make use of remotely embedded views in a big way. I knew about the limitation of remotely embedded views when I architected my application and I knew how to fix it...so I figured I just have to write a tool to manage the embedded views. While I was writing the utility it occured to me that other might make use of it so I decided to turn it into open source work.
Without this new utility to help me out, I would need to go to every form/subform where I have a remotely embedded view (and by the way, there is no way to tell an embedded view is a remote embedded view by looking at the embedded view...how nice.), check out the property settings, delete the embedded view object, and then re-embed it and make sure that I get all of the properties set correctly. Joy oh Joy!
The alternative is to use Notes native DXL (Domino XML 'language') tools to create an XML instance of the form/subform, search for the 'old' replicaID, modify it to the new replicaID and re-import it into the database to over write the current-bad form description. Except that the Notes client does not 'expose' the DXLImporter tool...how nice. But you can write an agent to DXLImport your modified file(s).
So I took the 'long-term' view and wrote a dynamic utility since my business plan calls for me doing this hundred and hundred of times over the next few years (in my wildest dreams!)
In the first iteration, the tool is very simple and manual in nature, especially in regards to setup up what I call an 'embedded view registration' document that describes the form/subform that the view is embedded into and how it should be changed.
In later releases I hope to have a more automated process that will allow a developer/administrator to point at a database, collect the forms/subforms with remotely embedded views, identify the current remote databases and the new database targets, and make the whole selection process more point and click versus the current typing-required process.
Do you use Embedded Views in your Notes applications? Did you know that you can, at your own risk, have your embedded views reside in another database? Do you use templates for your development? Do you use development 'best practices' and have your development work reside on a different server and contain a different replication ID? Do you ever have to create new database from templates?
Do you see this...
when you want to see this...
If you answer yes to any of these questions, some day you will need the 'Remote Embedded View Manager' that I am releasing to open source via the OpenNTF community.
I have begun work on a very complicated application that make use of remotely embedded views in a big way. I knew about the limitation of remotely embedded views when I architected my application and I knew how to fix it...so I figured I just have to write a tool to manage the embedded views. While I was writing the utility it occured to me that other might make use of it so I decided to turn it into open source work.
Without this new utility to help me out, I would need to go to every form/subform where I have a remotely embedded view (and by the way, there is no way to tell an embedded view is a remote embedded view by looking at the embedded view...how nice.), check out the property settings, delete the embedded view object, and then re-embed it and make sure that I get all of the properties set correctly. Joy oh Joy!
The alternative is to use Notes native DXL (Domino XML 'language') tools to create an XML instance of the form/subform, search for the 'old' replicaID, modify it to the new replicaID and re-import it into the database to over write the current-bad form description. Except that the Notes client does not 'expose' the DXLImporter tool...how nice. But you can write an agent to DXLImport your modified file(s).
So I took the 'long-term' view and wrote a dynamic utility since my business plan calls for me doing this hundred and hundred of times over the next few years (in my wildest dreams!)
In the first iteration, the tool is very simple and manual in nature, especially in regards to setup up what I call an 'embedded view registration' document that describes the form/subform that the view is embedded into and how it should be changed.
In later releases I hope to have a more automated process that will allow a developer/administrator to point at a database, collect the forms/subforms with remotely embedded views, identify the current remote databases and the new database targets, and make the whole selection process more point and click versus the current typing-required process.
|
Permalink
| Comments (3)
| TrackBacks (0)
Bookmark :
Comments
I got 2 or 3 on different tabs...
Fred
Posted by Fred Janssen at 11:34:11 AM on 09/09/2007 | - Website - |
I have Lotus Notes version 8.01
Posted by Ales Vychodil at 09:32:48 AM on 05/29/2008 | - Website - |
Posted by Andy at 01:20:25 PM on 05/29/2008 | - Website - |