Ethan Jucovy
2010-09-12 12:50:50 UTC
An OpenCore installation puts a lot of site content directly into templates,
hard-coding the text of important pages and blocks -- like the "About" page
(/@@about), the "You want to *make a difference*, we want to *make it easy*"
block on the homepage, etc.
There are some advantages to doing it this way -- the text can use the
built-in i18n framework, and there's no need to fill in any content when you
install a new site. It's simple.
But when you install an OpenCore site you'll probably want to change that
text sooner or later. And you'll probably want to treat it as managed
content, rather than template text -- so that it can be edited by people
without filesystem access; so that edits can go live immediately without
restarting the server; and so that you're not forking files in the opencore
codebase.
So, I've built a plugin that can be installed into an OpenCore site to turn
those blocks into managed content:
https://svn.openplans.org/svn/opencore/plugins/opencore_contentviews/trunk/
The approach is to re-use wiki pages inside projects for this purpose.
Rather than adding content on a site level, and worrying about granting site
admin privileges, and building new UIs for dealing with site-level content.
A site admin can designate a project that will be building the site content,
and the site admin designates which wiki page within the project should be
used for each site content block (about page, "you want to make a
difference" block, etc). There are no special privileges created -- the
designated project's members just manage their team and security settings as
normal.
Under the hood, the plugin defines a ZCML directive <opencore:contentView>
which will register a browser:page that, when called, returns the raw
content of its designated wiki page instead of rendering a template.
The site admin will go to /openplans/@@manage-site-content-blocks to set the
project & wiki pages to be used for each contentView.
The plugin provides an overrides.zcml which sets up contentViews in place of
some of opencore's views, like the ones I mentioned above. If you install
the plugin into your opencore environment, its overrides.zcml will be
auto-loaded on startup.
I'll make a 0.1 release soon. It depends on opencore trunk, where I
refactored some page blocks into separate views so that this plugin could
override them piece-by-piece.
I'll also start using it on CoActivate.org soon, so the current default text
in opencore could be rewritten, if somebody has an idea for more generic /
helpful / interesting text to put in those places in a new installation.
The downside to this approach is no i18n -- because OpenCore has no built-in
l10n system for user content. But, this is something worth looking into
separately, whether with LinguaPlone or some other way.
--
Archive: http://www.coactivate.org/projects/opencore/lists/opencore-dev/archive/2010/09/1284295871261
To unsubscribe send an email with subject "unsubscribe" to opencore-dev-***@public.gmane.org Please contact opencore-dev-manager-81qHHgoATdGNjXQcXLqYpGD2FQJk+8+***@public.gmane.org for questions.
hard-coding the text of important pages and blocks -- like the "About" page
(/@@about), the "You want to *make a difference*, we want to *make it easy*"
block on the homepage, etc.
There are some advantages to doing it this way -- the text can use the
built-in i18n framework, and there's no need to fill in any content when you
install a new site. It's simple.
But when you install an OpenCore site you'll probably want to change that
text sooner or later. And you'll probably want to treat it as managed
content, rather than template text -- so that it can be edited by people
without filesystem access; so that edits can go live immediately without
restarting the server; and so that you're not forking files in the opencore
codebase.
So, I've built a plugin that can be installed into an OpenCore site to turn
those blocks into managed content:
https://svn.openplans.org/svn/opencore/plugins/opencore_contentviews/trunk/
The approach is to re-use wiki pages inside projects for this purpose.
Rather than adding content on a site level, and worrying about granting site
admin privileges, and building new UIs for dealing with site-level content.
A site admin can designate a project that will be building the site content,
and the site admin designates which wiki page within the project should be
used for each site content block (about page, "you want to make a
difference" block, etc). There are no special privileges created -- the
designated project's members just manage their team and security settings as
normal.
Under the hood, the plugin defines a ZCML directive <opencore:contentView>
which will register a browser:page that, when called, returns the raw
content of its designated wiki page instead of rendering a template.
The site admin will go to /openplans/@@manage-site-content-blocks to set the
project & wiki pages to be used for each contentView.
The plugin provides an overrides.zcml which sets up contentViews in place of
some of opencore's views, like the ones I mentioned above. If you install
the plugin into your opencore environment, its overrides.zcml will be
auto-loaded on startup.
I'll make a 0.1 release soon. It depends on opencore trunk, where I
refactored some page blocks into separate views so that this plugin could
override them piece-by-piece.
I'll also start using it on CoActivate.org soon, so the current default text
in opencore could be rewritten, if somebody has an idea for more generic /
helpful / interesting text to put in those places in a new installation.
The downside to this approach is no i18n -- because OpenCore has no built-in
l10n system for user content. But, this is something worth looking into
separately, whether with LinguaPlone or some other way.
--
Archive: http://www.coactivate.org/projects/opencore/lists/opencore-dev/archive/2010/09/1284295871261
To unsubscribe send an email with subject "unsubscribe" to opencore-dev-***@public.gmane.org Please contact opencore-dev-manager-81qHHgoATdGNjXQcXLqYpGD2FQJk+8+***@public.gmane.org for questions.