Tease: Refresh Design via HTTP
Category show-n-tell thursday
This week's SnTT is actually just a tease for next week's. Sorry, I know that's kind of lame. But I just got the idea a couple hours ago and haven't gotten all the code in place yet. So this week I'll describe the premise, next week I'll post the actual code. Schedule willing... I've been busy with other stuff, and haven't made as much progress on XIDED as I'd hoped to by now. This latest idea is actually for a feature that I've decided to include in XIDED, but wanted to share with y'all in case you have a need for it in your own apps.
Anyhoo, now that I've been actively using several OpenNTF applications for a few years, I've been itching for an easier way to upgrade to newer versions of them than the standard approach (download the new template, update the ACL, sign all the elements, replicate it to the server, refresh the design of the database from the new replica), and I've come up with a way to do just that. The basic premise is the creation of an HTTP-based update process for Domino apps that functions similarly to the Eclipse Update Manager. It would contain two main pieces: an upgrade form residing in the database to be updated (and an agent to process submission), and code residing in the hosting database to serve up the XML. I haven't decided yet exactly how the latter should be structured and would welcome feedback on this.
One approach would be to have "version" documents in the hosting database that store one or more XML files, which the upgrade form would retrieve and import into its parent database. Another would be an "upgrade.xml" agent that retrieves, and then serves, the XML dynamically. I can see advantages and disadvantages to each approach. What I'm leaning toward at the moment is a combination: version documents store the location of the source database and a list of NoteIDs to include in that version, then the agent retrieves the XML to return by exporting a NotesNoteCollection consisting of those design elements.
The end result is that the target database (i.e. the one from which the upgrade form is launched) will retrieve the XML from the source database and import it as DXL into itself. As long as the server the target database runs on has authority to sign agents and script libraries, this process should be all-inclusive. If you're intrigued, stay tuned for next week's episode...
This week's SnTT is actually just a tease for next week's. Sorry, I know that's kind of lame. But I just got the idea a couple hours ago and haven't gotten all the code in place yet. So this week I'll describe the premise, next week I'll post the actual code. Schedule willing... I've been busy with other stuff, and haven't made as much progress on XIDED as I'd hoped to by now. This latest idea is actually for a feature that I've decided to include in XIDED, but wanted to share with y'all in case you have a need for it in your own apps.
Anyhoo, now that I've been actively using several OpenNTF applications for a few years, I've been itching for an easier way to upgrade to newer versions of them than the standard approach (download the new template, update the ACL, sign all the elements, replicate it to the server, refresh the design of the database from the new replica), and I've come up with a way to do just that. The basic premise is the creation of an HTTP-based update process for Domino apps that functions similarly to the Eclipse Update Manager. It would contain two main pieces: an upgrade form residing in the database to be updated (and an agent to process submission), and code residing in the hosting database to serve up the XML. I haven't decided yet exactly how the latter should be structured and would welcome feedback on this.
One approach would be to have "version" documents in the hosting database that store one or more XML files, which the upgrade form would retrieve and import into its parent database. Another would be an "upgrade.xml" agent that retrieves, and then serves, the XML dynamically. I can see advantages and disadvantages to each approach. What I'm leaning toward at the moment is a combination: version documents store the location of the source database and a list of NoteIDs to include in that version, then the agent retrieves the XML to return by exporting a NotesNoteCollection consisting of those design elements.
The end result is that the target database (i.e. the one from which the upgrade form is launched) will retrieve the XML from the source database and import it as DXL into itself. As long as the server the target database runs on has authority to sign agents and script libraries, this process should be all-inclusive. If you're intrigued, stay tuned for next week's episode...
Comments
Posted by Bruce Perry At 09:51:01 PM On 05/02/2006 | - Website - |