--- Matt S Trout <[EMAIL PROTECTED]> wrote:
> 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,
Actually I personally appreciate the download. One of
the biggest problems I have trying to find I good
entry point to Reaction is that there is a lot of
things and ideas new to me that I need to grasp, and
having something more than the source and the tests
helps me a lot.
Right now I typically first reimplementing a half
baked version of something and only then do I
understand why something was written the way it was in
Reaction.
--John
____________________________________________________________________________________
Be a better Globetrotter. Get better travel answers from someone who knows.
Yahoo! Answers - Check it out.
http://answers.yahoo.com/dir/?link=list&sid=396545469
_______________________________________________
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
