Extensibility is the hallmark of Quadralay’s publishing products. Invariably, if we didn’t ship a given feature with the product, someone, somewhere found a way to add it to the mix. Whether on Publisher 2003 or ePublisher, customers found a way to be happy and successful.
Until upgrade time.
The Publisher 2003 line took the approach of never (well, almost never) removing or changing functionality. Users could take a Publisher 3.5 project, open it up in Publisher 8.6, and obtain consistent results.
No new features, but hey, everything still works.
For ePublisher, we took a different approach and really focused on creating an easy upgrade path for casual users. This approach is great for anyone who limited their changes to the ePublisher UI, page templates, and CSS files. However, when users customize XSL code, we run into the issue of incompatible code.
To address this, we introduced ePublisher Stationery in the ePublisher 9.2 release. ePublisher Stationery allows users to mimic Publisher 2003’s trick:
No new features, but hey, everything still works.
When users do need to resolve incompatible code issues, ePublisher’s override mechanism clearly separates Quadralay code from user code. This approach enables formats and targets to exhibit different behaviors as necessary. It also works well for non-XSL files.
Until you want to share your cool feature.
I ran into this problem while working on a customer request from RoundUp for printable reports. I didn’t need to modify any existing XSL, just add to it. So, I created my new XSL stage, overrode the “format.wwfmt” file, and Bang!, I’m done. But how could I deploy this to a customer who might be using WebWorks Help or another using Microsoft HTML Help? Changing the “format.wwfmt” file basically defines a brand new format. What do I do if I create yet another new feature that requires a similar change?
Looking around at various plug-in architectures gave me a few clues. Eclipse has one way to do it, but it seems to be really focused on UI interactions, drag-drop behaviors, etc. Mozilla’s FireFox browser has a nice interface to plug-ins. Just add the feature and go. I like that! Finally, the DITA Open Toolkit defines a plug-in architecture. The DITA-OT approach requires a user action to enable your plug-in (ant integrate). Then the DITA-OT build script rewrites XSL files with user extensions added, etc. The problem is that you can only extend where DITA-OT gives you an extension point. There are proposals to enhance the capabilities of DITA-OT plug-ins ala this one, Making plugins more useful.
So what about ePublisher?
In ePublisher, the reposibilities that Ant handles for DITA-OT are split between the format definition file, “format.wwfmt”, and XSL extensions. “format.wwfmt” expresses dependency information only. It defines relationships only. No processing. That’s a bit easier than working with arbitrary Ant build files. Good! So then what ePublisher needs is a way to build the “format.wwfmt” file on the fly. ePublisher can then integrate modules before initiating the publishing process. The first step towards ePublisher plug-ins is to define the module layout and see if we can script the “format.wwfmt” compile step.
Jesse and I talked about this before Christmas. I’m wondering what he might cook up over the holidays.
P.S. I see the Apache folks are working on something similiar for Ant called Ivy. Looks like I have more research to do.
