in reply to
modules, auto generated code and content management
Thanks, monks for the replies so far, especially
Tanktalus and santonegro. Since the crux of my
question is primarily contingent upon the nature of
'republishing' and 'auto-generation' (non-standard terms) here is a quick
update to further illustrate what is going on. To make
it as straightforward as possible, I will do a quick
sketch of what the application is all about. Skip ahead
to the Summary for the quick punch line.
1 Text Nodes: The application consists of numerous text 'nodes'.
Each node consists of a 'body' (i.e., random text blurb) plus 'metadata' (e.g., creation date
original author, last mod date, caption, description ...). Each text node (body + metadata)
should be easily viewable with all its information in one place.
2 Node Groups: Text nodes are grouped together such that all nodes with the same
'subject matter' can be organized into a single file. Currently these 'subject areas'
are called 'domains' and there are dozens of them. Each domain is implemented
as a perl module (e.g., CustomerModule, EmployeeModule, MainCompanyModule, ...
3 Node Group Manipulation: Text node groups (aka domains) are separated
into individual files. Some of these domain files are managed by hand, but others are populated
automatically from a database. Since the hand-edited domain files may sometimes get messed up,
it is necessary to be able to 'reshuffle' all domain files. Such 'reshuffling' may consist
of sorting the text nodes in alphabetical order by caption, or by date created. Other reshuffling may
be to make sure they all have unique 'captions'.
The process of 'reshuffling' the content of a domain file is called "republishing".
The process of creating the database-dependent domain files is called "auto-generation".
4 Node Interpolation: Text nodes can contain variables and expressions. This
makes it easy to automatically include simple calculations, date and time, inside
both the body and metadata of text nodes.
5 Node Inheritance: Text nodes can contain variables and expressions from the
MainCompanyModule. This makes it possible to put standard boilerplate in the body
of text nodes without having to reproduce it everywhere.
6 Node Referencing: Text nodes can be called from code using a standardized
scheme. Each node has a special 'codename' that allows it to be uniquely identified
within its domain.
This prints out the complete body of the 'Customer 30 days past due' node, with all
body variables interpolated and expanded.
7 Body Armoring:
It is important to be able to put *any* kind of text content
inside the body of a text node (e.g., Wiki, XML, HTML, Perl, TT, Mason are all fair game).
Thus, the syntax used to delimit the node body must be strong enough that it does not break or cause
no matter what the content of the body happens to be. Currently, this
requirement is met simply by using the 'quotelike' feature of perl, along with a strategically
chosen quotelike delimiter that never clashes with the body. (Note: solutions such as
CDATA sections or converting node body to Base64 are deemed inadequate, indentation is deemed
Considering the requirements (esp. 'Body Armoring' and 'Node Referencing') the choice
was to use perl modules as the syntax to store the text nodes. The pm files work well,
but the 'republishing' problem still persists (i.e., how can we regenerate the code in
the pm files such that all the text nodes appear in alphabetical order, and the body
content does not get interpolated and expanded). I had already considered other options,
so the following comparison table may also give some useful info.
So far, only pm files have all
'yes' values, with the obvious exception that motivated me to post this question.
FeatureNumber: 1 2 3 4 5 6 7
Perl Modules y y ! y y y y
TemplateToolkit y y ? y y n y
Class::Phrasebook y y ? ? n ? n
YAML y y y n n y y
XML y y y n n n n
The search for wisdom continues ...