On top of all my top-secret work on Designer “Next”, this week I also had to track down the history of a feature change from Designer 7.1 to Designer 8.0 which was causing grief for a customer. After tracking down the change, I also looked into potential workarounds and re-discovered a feature in Designer that I had completely forgotten about (hey – in a tool as big and advanced as Designer, there’s lots and lots of features – it’s not that hard to lose track of the littler ones.) It was an interesting case and I thought I’d share it on this blog.
Our story starts with an email from a customer (that came to R&D through the Technical Account Manager and our internal eTech group) saying that when they upgraded from Designer 7.1 to Designer 8.2, a feature that they depended on for their workflow was no longer available. Here’s an extract of the email:
They are looking to create 3 different types of Object Libraries:
- Libraries accessed by the entire office
- Team-specific libraries
- Individual libraries
They just recently moved to LiveCycle Designer 8.2 and when an end user removed a category from the Object Library palette, it actually deleted the files from the drive (folder) it was located in, which then caused everyone to lose access to the library. A particular example, the end user added the Administration category to her Object Library palette for a specific project. Once she was done with that project, she removed the category from her Object Library palette as she didn’t want to see it or need it anymore. At this point, everyone lost access to the Administration category when she removed it from her Designer client because it deleted the objects from their team’s shared folder (M: drive). They want to be able to add and remove categories without affecting other users as their team work on different projects. With Designer 7 we could do this as they would chose the Remove the group option as shown below:
In Designer 8.0 and above, you now get the following pop-up. The end user had instinctively clicked on the first entry which subsequently removed the group and all its objects as it states.
Anyone know why this behavior changed and what if any other alternatives they have going forward?
This is an interesting scenario. Anyway, the first order of business was to try to track down that particular change, to find clues as to why we would have removed the original “Remove [but don’t delete] Group” option. A quick search through our source code repository found the history of this change, which I will share for people who are interested in the gory details of development work:
12/1/2005 4:01:29 PM
– Defect #yyyyyyyyy – Very Difficult to Recover Barcode Library if Removed
I believe that when the “Restore Standard Objects” feature was implemented, we only had one “factory installed” library tab. We now have three (standard, barcodes and custom; four if you count the potential SAP.) The restore standard objects did not really work correctly anymore, as it has not been updated in a long time and the library itself has changed a lot in that time.
In order to make the restore objects feature more universal and more easily maintainable I have put in place the following changes:
– The application now considers the object libraries installed in the app folder (taking language into account of course) to be the “factory installed default” objects. The application now takes these libraries as being default and will restore the objects in any one of them. In the past, the mechanism was to embed the object files into our resources and query there for the defaults. The old method required a lot more maintanance (which I note has not been done in the intervening time), requires more complex code for managing and does not really offer any more benefit than using the installed files.
– When removing groups, there are now 2 options instead of three: delete and move & delete. The deletion now removes the underlying data directory from the file system. (Leaving the directory there was causing problems with the file restore algorithm.)
I bolded the last paragraph, because it contains the key information about why this change was made in the first place: just removing the group but leaving a directory there was breaking the “restore defaults” functionality.
After first reading this, then thinking about the above customer problem, I thought “Uh-oh. We goofed and unthinkingly destroyed a customer workflow without providing an alternative.” However, this didn’t feel right to me off the bat – the development team is usually very hesitant to remove any features/options/commands from Designer for exactly this type of reason – once it’s in place, odds are someone, somewhere depends on the feature and will be unhappy with the change.
I’m the person who made the change described in the change list text above: when I started nosing around the code, lots of the details came back to me and I remembered more about the whole “Object Library Group Management” feature. And it turns out that there’s a specific feature to manage the scenario this customer is describing. The feature isn’t as fully-developed as I would like, but even without full UI support, it’s the way you are supposed to use shared Object Libraries.
So the Object Library has two kinds of groups: “Groups” and “Shared Library Locations”.
This is the Object Library’s menu. The options we care about here are “Add Group…” and “Shared Library Location…”
In this customer’s scenario, individual libraries should be created and managed by “Add Group”; shared libraries should use the “Shared Library Location”. Some notes about the “Shared Library”: the shared library is configured by one XML file; you can have lots of shared “groups” but they’re all managed by one library. Also you can’t, in Designer, remove just one shared group – you’ll disconnect the whole library if you try (although you won’t delete it or the files – just disconnect).
Here’s what you have to do:
The shared library file should have exactly the same format as the LocalLibrary.xml file which can be found in the user’s Designer data directory (i.e. c:\users\youruserid\Appdata\…\Adobe\Designer\9.0\EN\Objects)
Here’s what you could create:
SharedLibrary.xml – save it somewhere (reliable and safe – like \My Documents) on your system:
<?xml version="1.0" encoding="UTF-8"?> <objectLibraryTabSet> <tab name="Shared Accounting Objects" directory="M:\SomeDirectory\Objects" permission="adm"/> <tab name="Shared Form Team Objects" directory="\\SomeSharedComputer\Designer\objects" permission="adm"/> </objectLibraryTabSet>
This file can contain as many
<tab> entries as required. The
<tab> entries should be changed to reflect the location/names of shared object resources on the network. The directory can point to relative paths, absolute paths, absolute paths to mapped drives (like the shared “M:” drive in the example above), and network paths.
To access the shared objects, choose “Shared Library Location…” and navigate to the SharedLibrary.xml file and press OK. There should now be tabs that have a special icon denoting their “shared” status in the object library:
To get back to the example above: in this scenario, what you want is that each user has their own SharedLibrary.xml file on their own computer. Each person would add
<tab> entries to their own file: one entry per shared object location they need to access. So you would have a bunch of entries for enterprise level objects and a bunch of entries for team level objects. Your own personal objects would continue to use the “Group” option, not the “Shared Library” option. If you no longer want certain groups (say you’ve changed teams), then you would edit SharedLibrary.xml and remove all the
<tab> entries that you don’t want anymore.
You could also have one SharedLibrary.xml file that everyone has to use on a shared drive somewhere. That has the benefit that only one person would need to manage the ShareLibrary.xml file, but the drawback is that each user does not have a customized set of shared objects – it’s all or nothing.
I don’t know how widespread the use of shared object library resources is: if it’s very common and lots of people were relying on the same functionality as the customers in the email above, it could be worth it for us to add more UI and functionality to manage shared object libraries…