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

[Andrew Sterling Hanenkamp]

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 {
                        $result->content('proxy_granting_ticket');
                    };
                }
            };
        }

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

                $result->error;
            };
        }
    };
};

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
revision.

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?