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/ _______________________________________________ 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/