hi all,
here are some rough notes on the design of cms::simple. i am sure to not
cover everything here and make some mistakes but the design concepts
should be clear enough. we will go over this in much more detail at the
meeting and as this project evolves.
the primary goal of C::S is to generate static output pages (e.g. html)
from a collection of content documents. it supports sharing content
across multiple pages (e.g. headers, footers, nav bars), custom
filtering of data for each page, default templates and some other
things. it is configured right now with a bunch of data structures
passed into the constructor and making that easier to do (maybe external
config files?) could be one design improvement. i will show the setup
for the perlhunter.com site during the talk and will post it here too.
there are 4 primary phases in running C::S.
first, content is loaded. these are text files in some known format
which are loaded and parsed into a perl data tree. currently the only
supported format is one i created for this module and denoted by the
.cont suffix. i designed it to be very easy for non-coders to edit and
it has nesting levels, lists, and a few other things. it would be easy
to support any other format given a suffix, parser and such. one thing i
love about perl OO is how easy it is to plugin in things. content is
loaded into a hash with each content file having its own key. there is
no organization of content in this phase, just loading and parsing.
the second phase is building the content data tree for each page to be
produced. this is a simple hash tree which has tokens for where content
parts are to be inserted into the page. content is fully copied (no
shared refs) so each page can be filtered (next phase) independently.
this phase has some tricks to have default content (headers, footers,
etc.) so you don't need to map these in over and over. also there are
ways to insert content at the top level of a page. when this is done,
each page will have its own data tree of content ready to be filtered.
the third phase and likely the most useful one is filtering. the
constructor is given a list of filter subs to be executed when a given
key (a token/key in a content data tree) is found. the value of the
subtree is given to the filter and its return values replaces the
original value. filters can be simple text mungers, do html entity stuff
(this is the correct phase to do that), or complex stuff like munging a
single list of street addresses to a 2 deep list sorted by state and
town. more than one filter can work on any given content value and they
are ordered by the ordering in the config. there are some existing html
entity filters that work on text nodes and filter stuff like [BR] to
<br> and other simple html stuff. the content style i have supports [FOO
blah] style markup and filters to convert that to html. useful for
links, mailto, html you want in the content, etc. this eliminates the <
to > timing issue you see everywhere. content has no html and can be
filtered here to what you want and them passed cleanly to the template
phase.
the final phase is simple. each page has a template designated for it
(or a default one) and that is used to render the page given its current
page data content. of course it uses Template::Simple to render as i
like my own dog food.
so this is as i call it a CMS but very simple to use but does a good
amount of what you need to generate static content for sites. it is very
fast, a low dependency tree (template::simple, file::slurp) and those
who have looked at it think it is interesting. it is not competing with
the behemoth cms systems out there but like template::simple it is not
competing there either. there are needs for simpler modules doing useful
stuff without loading half of cpan.
hopefully this will raise more interest and attendence. this module has
work needed at all possible skill and interest levels but it works now
and is used in production (perlhunter.com). so you can lurk, take on a
small task, write tons of pod, whatever you want. we as a group will get
this ready for releasing to cpan.
thanx,
uri
_______________________________________________
Boston-pm mailing list
[email protected]
http://mail.pm.org/mailman/listinfo/boston-pm
