[Catalyst] CMS

[Matt S Trout]

On Sat, Aug 25, 2007 at 12:41:11AM +0900, Matt Rosin wrote:
> 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.

Reaction's action reflector plus the ActionForm viewport

> - 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.

Reaction's action reflector plus the ListView, ActionForm and CRUDController
classes.

> 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.

Done.

> 1b. Online asset manager to CRUD them, with a file upload widget might
> also be nice.

Mostly done.

> 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.

Doable using metaprotocol introspection. Right now you need to feed Moose the
info by hand but in DBIC 09 it'll be baked in.

> 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.

I'm mostly just using the i18n plugin plus a tree of files under svn for this
but our designer learned svk shortly after wiping windows in favour of ubuntu
in a fit of anger with it during LugRadio Live.

> 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).

Agreed. The new reaction widget model works towards the latout part, I was
planning to hook Class::Workflow to handle the scripty bit.

>  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. :)

I'd love to see the code publically, even if it isn't re-used it's instructive
to see how other people do it.

In the same spirit: http://trout.me.uk/scsite.tgz is the Shadowcat website
code base running on svn reaction from http://code2.0beta.co.uk/reaction/svn
and I intend to artistic license the site codebase (not sure what we'll do
about the content and layout yet, but I don't imagine our website copy
is of great re-use value to anybody else anyway :)

-- 
      Matt S Trout       Need help with your Catalyst or DBIx::Class project?
   Technical Director    Want a managed development or deployment platform?
 Shadowcat Systems Ltd.  Contact mst (at) shadowcatsystems.co.uk for a quote
http://chainsawblues.vox.com/                    http://www.shadowcat.co.uk/