Re: [Catalyst] Recommended OS for Catalyst?
I'm using debian stable since 3.0 after being pissed by RedHat shipping unicode-horror perl 5.8.0 with custom + backported patches instead of 5.8.6 which was the newest stable version available at that time. Never regretted it! Am Donnerstag, den 06.08.2009, 12:50 +0200 schrieb Octavian Rasnita: Hi, Can you recommend a Linux distribution for production for Catalyst apps? ...and a version of Perl? Thanks. -- Octavian -- Alex *** T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien Handelsgericht Wien, FN 79340b *** Notice: This e-mail contains information that is confidential and may be privileged. If you are not the intended recipient, please notify the sender and then delete this e-mail immediately. *** ___ 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
- Original Message From: Chris hutchinson.ch...@gmail.com To: The elegant MVC web framework catalyst@lists.scsys.co.uk Sent: Tuesday, August 11, 2009 8:36:22 PM Subject: Re: [Catalyst] XSD Validation of Forms 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. I think the mozilla people did something with XUL... maybe we can leverage that stuff? I've done a few firefox plugins and really thought the way it's internal templating worked was quite elegant. I'd love something similar for Catalyst. The way overlays worked, for example fit my brain a lot better than the way we generally use includes in TT. Is your scheme a format which, when rendered as html, defines the form and, when parsed appropriately, provides the form validation too? As in: - 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/
Re: [Catalyst] Loading template according to request path
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.
cheers
RET
Illegitimi non carborundum
On 12/08/2009, at 3:15 AM, Matt Whipple wrote:
Thanks everyone for your input, I'm certainly gathering that there
is nothing preexisting that does what I'm looking to do. I'll
continue to clean up my version and throw it on CPAN if it seems
appealing enough. As a quick overview the basic premise is a more
direct link from the path to the template which would be used for
those times when the URI path determines presentation after passing
through a reusable action handler which tailors content (and doesn't
necessarily have to worry about the template selection). This is
presently done in the auto action so that overriding the behavior is
natural and any extended logic can be handled when and where desired.
http://blog.afoolishmanifesto.com
___
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/
