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

[Jesse Vincent]

On Jul 13, 2007, at 11:25 PM, Andrew Sterling Hanenkamp wrote:

> 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:
>

Yes! I'd love to see a T::D subclass to do this.


> 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?
> _______________________________________________
> jifty-devel mailing list
> jifty-devel at lists.jifty.org
> http://lists.jifty.org/cgi-bin/mailman/listinfo/jifty-devel
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.bestpractical.com/pipermail/jifty-devel/attachments/20070716/005c21c9/PGP.pgp