Ben Langhinrichs

Photograph of Ben Langhinrichs

IBM Champion logo

E-mail address - Ben Langhinrichs







Recent posts

Wed 13 Feb 2019

@MQRY and on-the-fly data retrieval



Mon 11 Feb 2019

Formula language in a JavaScript world: JSON db lookups



Thu 7 Feb 2019

Could working with rich text really be RESTful?


March, 2019
SMTWTFS
     01 02
03 04 05 06 07 08 09
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31

Search the weblog





























Genii Weblog

CoexEdit AutoUpdate: provisioning by magic

Thu 21 Feb 2008, 09:41 AM



by Ben Langhinrichs
A few people have asked for a more complete explanation for the "magic step", as one person described it, in my recent video Henry's Dojo SpeedGeeking to CoexEdit in 40 minutes.  For those who don't want to watch the whole seven and a half minutes, here is the 25 second snippet with no audio which just shows the magic provisioning: Show snippet

But what exactly is happening?  All you see is a blank form with the name "CoexEdit AutoUpdate" being saved and magically forms, views, image resources, etc. populate the database.  It happens almost instantly, which is why it was described as the "magic step".  Contrary to another person's belief, I didn't simply edit the video either.  What you are seeing is a new feature in CoexEdit 2.0.  If you designate a database as the auto update db in the NOTES.INI on your server, in a line such as this from my server:

CoexEditAutoUpdateDB=coexedit\CXEIntegration.nsf

then CoexEdit watches for a form being saved with the name "CoexEdit AutoUpdate"  (or a different name I'll show you in a moment).  It doesn't matter that there is anything in the form, just that it is saved.  This save kicks in the auto-provisioning step.  Every design element in the designated auto update database is checked.  If it has a comment, and if the comment starts with the string "CoexEdit AutoUpdate", that design element is a candidate for copying over.  See an example below:




But first, the target database (where the form was added) is checked to see if the design element already exists.  If it does, it is left alone, so it is safe to do this different times and only new design elements will be copied in.  In this way, all the image resources, views, forms, subforms, pages, style sheets, file resources, etc. which might be needed by CoexEdit are added to the target database.  If your company has some additional elements you would like to go into every CoexEdit-enabled database, just add it to the auto update database with the comment starting with "CoexEdit AutoUpdate", and those elements will be provisioned as well.

What is more, if you later want to update some such elements, simply name the form "CoexEdit AutoUpdate Replace" instead.  Any new design elements will be copied in as before, but in a new twist, any existing design element will be overwritten, but only if the comment in the target database still has the comment string "CoexEdit AutoUpdate".  This way, if you modifiy the doclink selection view, for example, or customzie some element, you can just remove the comment and it will be preserved.

But what about the standard template system?  There is nothing in the provisioning which prevents your adding the elements with a designation that they should inherit (individually) from a specific template.  Then, in that template you remove the comments, and after the first design refresh, all of the design elements will inherit from the template as some companies might well want, but the difficult job of knowing which elements to copy in has already been done for you.

So, as a magician never should, I've revealed the secret of the magic trick.  Still, it looks slick even if you know how it works.  Watch the video again.  What do you think?

Copyright © 2008 Genii Software Ltd.

What has been said:


692.1. Ben Poole
(27/02/2008 14:45)

I think you're using some cunning CGI there