Re: [Catalyst] Loading template according to request path
On Tue, Aug 11, 2009 at 8:11 PM, J. Shirleyjshir...@gmail.com wrote: The fact that Chained doesn't render template from PathPart, but from the action name? :) It would be content/html.tt -- not content/as/html.tt not really: # insert jshirley's end action here -- Eden Cardim Need help with your Catalyst or DBIx::Class project? Code Monkeyhttp://www.shadowcat.co.uk/catalyst/ Shadowcat Systems Ltd. Want a managed development or deployment platform? http://edenc.vox.com/http://www.shadowcat.co.uk/servers/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Loading template according to request path
On Wed, Aug 12, 2009 at 9:58 PM, Richard Thomasr...@mac.com wrote:
Matt,
I don't know if any of this is useful to you. We do something that sounds a
bit like what you're after, by tweaking the template include_path with each
request. It's a classic path setting algorithm, working back from most
specific to least specific location.
ie, a template that says PROCESS something.tt that is the end result of
the URI /myapp/xx/yy/zz will look for something.tt in tt/xx/yy/zz, then
tt/xx/yy, then tt/xx, or tt/base. This gives us enormous flexibility to
tweak the output at any node or leaf of the tree.
You can create empty something.tt files in various places too, that has a
negating effect.
MyApp/C/Root.pm contains
sub auto {
...
$c-stash-{reportfolders} = split('/',$c-req-path);
...
}
MyApp/V/TT.pm contains
sub process {
my ($self, $c) = @_;
if (my $reportfolders = $c-stash-{reportfolders}) {
my @orig_path = @{$self-include_path};
my @this_path = ();
for my $orig_entry (@orig_path) {
for (my @folders = @$reportfolders; @folders; pop @folders) {
push @this_path, join('/', $orig_entry, '..', @folders);
}
push @this_path, $orig_entry;
}
�...@{$self-include_path} = @this_path;
#$c-log-debug(sprintf('%s:process: dynamic include_path is %s.',
__PACKAGE__, join(':',@{$self-include_path})));
$self-SUPER::process($c);
�...@{$self-include_path} = @orig_path;
} else {
$self-SUPER::process($c);
}
}
Hope that's useful.
The problem with that approach is that your view is now heavily
coupled to your controller semantics. Whenever the semantics change,
you'll run into refactor hell making the template paths match. Also,
if you have arguments in your paths, say, /foo/*/bar/*, you'll be
allowing the addition of per-record customization templates, which
leads to refactor hell once again when your underlying model changes.
Of course, this problem also exists with the traditional
template-by-action-name approach. This is why, theoretically, views
are supposed to be dispatch-agnostic and it's specifically the
controller's job to tell the view how to render data.
--
Eden Cardim Need help with your Catalyst or DBIx::Class project?
Code Monkeyhttp://www.shadowcat.co.uk/catalyst/
Shadowcat Systems Ltd. Want a managed development or deployment platform?
http://edenc.vox.com/http://www.shadowcat.co.uk/servers/
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] XSD Validation of Forms
Ok, this is what I do, so to spark some ideas. I can't disclose many
details because of legal issues but generally speaking
XXXLIB is a special module (can't disclose it's name) where all the
XML stuff is done. It uses LibXML as backend (gnome libxml2 via XS).
xxxapp is the app name
xxx_xsd is the XSD file
1) Figure out if the request is HTML or XML. Note XHTML is considered as HTML.
sub xxxmethod : Local {
my ( $self, $c ) = @_;
# figure out request type (html | xml)
$c-forward('get_req_type');
# xml lib object
my $dx = xxxapp::Controller::Util::XXXLIB-new(
encoding = $c-stash-{encoding},
schema = $c-config-{root}.$c-config-{xxx_xsd},
);
2) Process the request data. If it's XML is goes directly. If it's
HTML is goes through an HTML param to XML conversion. Perhaps by using
XFORMS and making XHTML mandatory I could have simplified the code
even more.
# process request data
my $req_data = undef;
# these couple of methods validate xml using the xsd
# xml request is processed directly by the xml parser
if($c-stash-{xmlreq}) {
$req_data = $dx-process_omreq_xml($c-req-body,'xxxmethod');
}
# html request is converted into equivalent xml
else{
# transforms params into a simple xml
$req_data = $dx-process_omreq_html($c-req-params,'xxxmethod');
}
# data did not pass check
unless($req_data){
$c-stash-{error} = $dx-{error};
# code injection check
unless($dx-{inject}){
$c-stash-{form_action} = $c-request-base.'xxxcont/xxxmethod';
$c-detach('exception/omx/0');
}
else{
$c-stash-{form_action} = '';
$c-detach('exception/sys/1');
}
}
3) From here on $req_data is a normalized hash... and that's it!
[snip]
} # end of controller method
sub get_req_type : Private {
my ( $self, $c ) = @_;
my $encoding = $c-req-content_encoding;
# assume UTF-8 if not specified (application/x-www-form-urlencoded)
$c-stash-{encoding} = $encoding ? $encoding : 'UTF-8';
$c-stash-{xmlreq} = undef;
my $ct = $c-req-content_type;
# XML Request
if($ct =~ m/text\/xml/i){
my $dx = cqridmp::Controller::Util::XXXLIB-new(encoding =
$c-stash-{encoding});
my $dom = $dx-slurp_file($c-req-body);
my $root = $dom-documentElement;
#XHTML is HTML
unless($root-nodeName =~ /.*html.*/i){
$c-stash-{xmlreq} = 1;
}
}
}
On Tue, Aug 11, 2009 at 8:36 PM, Chrishutchinson.ch...@gmail.com wrote:
My comment was perhaps more oriented to using a common declarative
validation idiom such as an xml schema because with this particular
project, I found myself maintaining FormBuilder YAML files and XSDs.
Then I decided to convert HTML to XML and use the common XSD for both.
Since most decent XML parsers already perform the validation, and they
are usually quite fast, I thought that perhaps something similar to
the FormBuilder plug-in could be built that used an XML approach.
I like the idea of a single 'base format' which can be used to drive
the validation and the form layout too.
Is your scheme a format which, when rendered as html, defines the form
and, when parsed appropriately, provides the form validation too?
As in:
form
input type=text id=abc format=integer /br /
input type=submit /
/form
- Chris
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
