Discussion:
further exploration of the error I posted
Dana Hudes
2005-02-02 03:48:19 UTC
Permalink
so I have this short program to sanity-check the YAML:

use YAML qw(Dump Load LoadFile);
use Data::Dumper;
print Dumper(LoadFile("photogallery.yaml"));
print "\n";
print Dump(LoadFile("photogallery.yaml"));



the Dumper output looks quite reasonable on first glance.
However, on closer examination and comparison with the
docs of Maypole::Plugin::Untaint I see some slight difference
at the top level.

I also see a sequence difference: in the perldoc for Plugin::Untaint,
it shows setup invoked AFTER untaint. This makes little
sense, how can you establish constraints in CDBI if you
haven't built the tables yet! You can't very well build tables
w/o the DSN. The YAML shows the dsn section first, but
the perl for that version omits Loader.
Removing Loader from my code doesn't change the error message.

The difference I see in the data structure is that
in the POD for Maypole::Plugin::Untaint the perl version is
an array of hashes (since arguments to a method are in list context):
MyApp->config->untaint_columns(
table1 => { html => [qw(name email)] },
table2 => { printable => [qw(lalala)] }
);

However the resultant data structure of YAML is in hash context:
'untaint_columns' => {
'websites' => {
'html' => [
'site_name',
'subjects_template',
'gallery_template',
'css'
],
'Filenames' => [
'doc_root',
'secured_root',
'galleries_dir',
'gallery_thumbs_path',
'subject_thumbs_path',
'gallery_list',
'subject_list'
],
'url' => [
'secured_url'
]
},
etc.
}


Now, I found another reason I really don't like YAML:
Use of of white space to indicate hierarchy. The Filenames
was a few spaces left of its proper position
and that made a problem.
Say what you will, you wouldn't have such a problem with XML.
Simon Flack
2005-02-02 20:07:01 UTC
Permalink
Post by Dana Hudes
use YAML qw(Dump Load LoadFile);
use Data::Dumper;
print Dumper(LoadFile("photogallery.yaml"));
print "\n";
print Dump(LoadFile("photogallery.yaml"));
the Dumper output looks quite reasonable on first glance.
However, on closer examination and comparison with the
docs of Maypole::Plugin::Untaint I see some slight difference
at the top level.
I also see a sequence difference: in the perldoc for Plugin::Untaint,
it shows setup invoked AFTER untaint. This makes little
sense, how can you establish constraints in CDBI if you
haven't built the tables yet! You can't very well build tables
w/o the DSN.
I've not used M::Plugin::Untaint, but it looks like you need to /define/
your untaint constraints before the call to setup(), so the
untaint_columns can be configured individually for each table once
they've been loaded.
Post by Dana Hudes
The YAML shows the dsn section first, but
the perl for that version omits Loader.
Removing Loader from my code doesn't change the error message.
The difference I see in the data structure is that
in the POD for Maypole::Plugin::Untaint the perl version is
MyApp->config->untaint_columns(
table1 => { html => [qw(name email)] },
table2 => { printable => [qw(lalala)] }
);
I think that's a POD error. Maypole::Config doesn't have an
'untaint_columns' attribute, but if it did it'd probably be in hash context.
Post by Dana Hudes
'untaint_columns' => {
'websites' => {
'html' => [
'site_name',
'subjects_template',
'gallery_template',
'css'
],
'Filenames' => [
'doc_root',
'secured_root',
'galleries_dir',
'gallery_thumbs_path',
'subject_thumbs_path',
'gallery_list',
'subject_list'
],
'url' => [
'secured_url'
]
},
etc.
}
I think that looks ok. Again, I've not used M::Plugin::Untaint, but from
glancing at the source, it should dereference the hash when it sets
[My::Table]->untaint_columns(). I think that was the source of your
error message "Can't coerce array into hash"
Post by Dana Hudes
Use of of white space to indicate hierarchy. The Filenames
was a few spaces left of its proper position
and that made a problem.
Say what you will, you wouldn't have such a problem with XML.
I've not really looked into YAML, but it sounds like it would irritate me :)

Simon

Loading...