[jifty-devel] Idea for Template::Declare::XML

Andrew Sterling Hanenkamp sterling at hanenkamp.com
Fri Jul 13 23:25:44 EDT 2007

I was thinking of porting CAS+ from Mason to Template::Declare, but
I'd have to use something like XML::Writer to handle the XML pages.
That's not so bad really, but it's not quite as nice as the typical
Template::Declare templates. So, I was trying to think of a way to get
something better going. I tried to emulate the Jifty::DBI::Schema and
Jifty::Action::Param declarations.

Here's a sample of what I was thinking:

use Template::Declare::XML;
use Jifty::View::Declare schema {
    namespace cas => 'http://www.yale.edu/tp/cas';
    default_prefix is 'cas';

    tag serviceResponse =>
        is not_empty;

    tag authenticationSuccess =>
        is not_empty;

    tag user =>
        is data;

    tag proxyGrantingTicket =>
        is data;

    tag authenticationFailure =>
        attributes {
            attribute code =>
                is required;
        is not_empty;

template 'serviceValidate' => sub {
    my $result = get 'result';

    xml_decl { version => 1.0, encoding => 'UTF-8' };

    serviceResponse {
        if ($result->success) {
            authenticationSuccess {
                user { $result->content('username'); };

                if ($result->content('proxy_granting_ticket')) {
                    proxyGrantingTicket {

        else {
            authenticationFailure {
                attr { code => $result->content('code') };


Not shown are some additional properties like:

tag 'serviceResponse' =>
    prefix is 'cas',
    local_name is 'serviceResponse',
    is not_empty;

With the default_prefix I show, the prefix property would be assumed.
The local_name is inferred from the tag name, but can be overridden
for some cases, like if:

tag 'service_response' => local_name 'service-response';

An addition heuristic would be handling prefixes in the tag name like:

tag 'cas_serviceResponse' =>
    is not_empty;

If there's a namespace prefix "cas" then it can infer this to be shorthand for:

tag 'cas_serviceResponse' =>
    prefix 'cas',
    local_name 'serviceResponse',
    is not_empty;

The "not_empty" and "data" provide simple validation checks to warn
you when a tag is expected to have content, but didn't have any or
when a tag contained tags and only text nodes were expected. An
addition "empty" could also be used to indicate that a tag is expected
to be empty. These wouldn't need to be implemented in the first

I'm not certain that the "attributes" property is really necessary
either, but it could again provide an extra validation check to let
the engine know that things are sane.

Questions? Comments?

More information about the jifty-devel mailing list