Re: CMS

Catalyst::Plugin::I18N:BIC (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

_______________________________________________
List: Catalystlists.rawmode.org
Listinfo: ht
tp://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-
archive.com/catalystlists.rawmode.org/
Dev site: http://dev.catalyst.per
l.org/

Re: CMS

Thread: Re: CMS