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