[Catalyst] CMS

[Matt Rosin]

Catalyst::Plugin::I18N::DBIC (and Mango::Catalyst::Plugin::I18N) is
maybe a crosscutting thing like Zbigniew mentions with some useful
concepts.

I'm not looking to build Drupal or a blog platform but I have nothing
against them per se. I was thinking more of a tool to reduce the
amount of Catalyst code I type by identifying patterns.

For example:
- A multiuser pattern in which a site is separated into public, admin
and registered user portals (of which the latter two need to edit lots
of pesky data like their profiles, their "virtual holdings" like
coupons/listings/catalogs/resumes/banners//video clips, etc.).
Currently I would do this with a formbuilder form, view and save subs,
and TT template for each page.
- Another pattern might be to get one or a list of objects a user
owns, make a list of them and create an interface allowing them to
edit and save the data. We all keep reinventing the wheel with this.
Currently I would look at similar subs I'd made and well reinvent the wheel...

I have 3 ideas at the moment.

1a. A standard object editor with rich editor and maybe some widgets.
It would render a complex form as necessary, given the object to be
edited. I once wrote something like this that would just let you edit
object data fields with text input boxes, it's not rocket science.
1b. Online asset manager to CRUD them, with a file upload widget might
also be nice.

2a. Reduce the set of all information assets a user owns into a single
tree that may span many tables, allowing each asset (object, data
field, etc.) to be called from templates by name (could use namespaces
and dot notation maybe). This is probably most useful in the context
of having a tree of all text snippets, etc. used in display of the
public site.
2b. This reduces templates to a list of assets (snippets) called by
name interspersed with HTML tags and TT directives. Text snippets
would reside in a database and could be edited in a CMS, at least like
the utility of 1a/b above. Image pathnames or a single DIV's HTML
could also all be stored in the db. The template would just pull the
snippets out with a simple $c method like loc in the above I18N
modules. A standard facility for editing these things (a module and TT
templates) would also be useful.

3. Beyond this, I see an awful lot of programming and design going
into solving similar basic interface problems over and over. It would
be useful to provide some basic TT layouts and scripted user
interactions (I don't mean write perl script, I mean just write the
basic plot, preferably as an interpreted string of text but even yaml
could be used).  Currently we sometimes reuse templates (for example I
have a general modal dialog), but we don't really have smart systems
that DWIM the user interaction for basic data editing. For one thing,
we all look at each other's public sites but not the admin or user
portal pages which could require more programming work. Contributing
to solving repeated patterns once well will make Catalyst even more
powerful I think. A repository of such interface snippets (combination
of TT code, perl code, etc.) could be run on the dev site maybe.  At
the risk of sounding like I'm all talk I'm willing to provide my
current admin and customer portals to the project, possibly the TT
templates would be useful. Anyway they do look a little like the
Catalyst startup page. :)

Um, that was a bit long, sorry!

Regards,

Matt Rosin