[Catalyst-dev] Idea for a new kind of Catalyst::View

[Sebastian Willert]

Hi all,

I've been getting my feet wet with Catalyst for a few months now, after
I decided to ditch my own framework that was based on MasonX::WebApp.
One of the reasons to do so was that Catalyst seemed flexible enough to
support most of my coding habits and after some porting effort even the
more obscure modules from my web development toolbox.

I've been pondering to release one of these modules for a longish time
now and hope to do so as a Catalyst::View class, but I feel I need a lot
of help to do so.

But first things first: I needed a way to build highly dynamic web-pages
(think kd's on-line survey app extended with some fancy item attributes
like complement pairs and inline items) without sacrificing separation
of concerns. This could have been done with Mason but would yield either
a to fine grained and presentation centric back-end, or templates that
are mostly perl anyways. Both approaches didn't satisfy me so I tried to
figure out what was needed to make me happy and came up with a template
'engine', where templates basically looks like this:

---
package MyApp::View::DataSource;

use base 'Catalyst::View::MyView';
use strict;

our ( $c, $m );          # needed to pass strict

sub item {
  my %p = args( 'action' );
  begin( 'cdbi_form', title => 'DataSource', action => $p{action} );
  hidden( id => 'DatasourceID' );
  text_input( id => $_ ) for qw/DSN Username Password/;
  textarea   ( id => 'Description' );
  end( 'cdbi_form' );
}
---
Corresponding Mason-Widgets:
  widgets/cdbi_form.mhtml
  widgets/cdbi_form
  widgets/cdbi_form/text_input.mhtml
  widgets/cdbi_form/hidden.mhtml
  widgets/cdbi_form/textarea.mhtml
---

As you can see, this is all very perlish. In fact it is valid perl all
the way, due to some black-symbol-stash-magic. Basically I am parsing a
hierachical tree of Mason widgets (the tree can be changed at runtime to
allow for themes) and and exporting them into the name-space of the View
in question (no autohandlers are involved). IMO this allow for a very
readable and flexible 'two-tier' view concept and I am using a variant
of this engine in a production environment for years now.

If someone is interested to mentor me along the way to get this in shape
for CPAN I'd gladly release this, but I fear I would be overtaxed to do
so on my own. Given that the idea of such a system isn't brain-dead to
begin with or I suffer from some serious misconceptions or have simply
not understood HTML::Widget, or ...

Cheers,
  Sebastian

P.S. Before someone asks: its a pity that the survey engine is to
burdened with company secrets to release right away, I won't get the
permission to do so. I've been planning to separate it from the original
app but this won't happen anytime soon :(

P.P.S. I hope this is the right list. It felt unappropriate for the
users list somehow.