[jifty-devel] Idea for Template::Declare::XML
Jesse Vincent
jesse at bestpractical.com
Mon Jul 16 13:39:47 EDT 2007
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
More information about the jifty-devel
mailing list