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 [email protected] http://lists.jifty.org/cgi-bin/mailman/listinfo/jifty-devel
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ jifty-devel mailing list [email protected] http://lists.jifty.org/cgi-bin/mailman/listinfo/jifty-devel
