On 07/05/2009 02:27:23 PM, [email protected] wrote:
> Since there wasn't much criticism on the list, I felt obliged to
> reply
Very welcome. Now I get to be defensive and dismiss everything you
wrote ;)
> First, site structure. You happily use several different file
> extensions (html, mhtml, comp) without explaining why you chose to
> name the file one way or the other.
I guess I didn't consider that important since I said you could call
the files whatever you like, and I didn't want to sound like my naming
conventions were necessary by being pedantic about them. But there is
a convention there (I call a fresh page .mhtml and a component of a
page .comp; I just used .html for the index since apache will want
that), so maybe I will add a note to this effect.
>I'd also appreciate a small graph of the database structure.
The script that produced the db is there, which is pretty much all the
information you could need.
> Second, you only use <%perl> blocks. You should, at the very least,
> introduce the <%init> block and the <%args> block. Your handling of
> component parametres (without the proper <%args> block) felt rather
> ad hoc.
The tutorial was NOT intended to stand alone, as I said in the intro,
so I didn't feel obliged to rehash every possibility especially if it
is covered in the first few chapters of the on-line Mason book. By my
reading of that, the <%args> block is not a requirement but an
*optional* convenience. I have only used it to simplify notation when
passing hashes or arrays, which does not happen in the tutorial (altho
if I expand it, this is probably a good topic). When passing single
parameters, just using the %ARGS hash seems fine; perl programmers are
used to not using function prototypes, which is a parallel to this.
> Your code is rife with SQL injection and cross-site scripting
> vulnerabilities. Here's a quick refresher:
>
> Bad:
> $db->do("insert into animals (name, class_id, cage_id) values
> ('$ARGS{name}','$class','$ARGS{cage}')");
> $sql = $db->prepare("update cages set species=species+1 where
> id='$ARGS{cage}'");
> $sql->execute;
> <% $somevar %>
>
> Good:
> $db->do("insert into animals (name, class_id, cage_id) values
> (?,?,?)", $ARGS{name}, $class, $ARGS{cage});
> $sql = $db->prepare("update cages set species=species+1 where id=?");
> $sql->execute($ARGS{cage});
> <% $somevar |h %>
I'm almost as new to SQL as I am to Mason! If you could explain the
significance of this difference to me, or at least point me to some
explanation, I will bring the code up to par...
> Things you could consider adjusting:
> - a little less ajax
One of my intentions was to incorporate ajax and SQL stuff since these
are common elements of a "web app" not even mentioned in the on-line
"Mason Book". I was actually going to call it "Using Ajax with
Mason" but decided not to since that is a vast topic, and I didn't want
to waste time explaining ajax too much as that is amply covered
elsewhere on-line. I just wanted to demonstrate some simple
"combinations" for people googling around, presuming that the reader is
more likely to be familiar with ajax than with mason (so you get that
something familiar in a new context).
> - line 22 of style.css has a syntax error
Yep! Thanks much for that!
> - autohandler instead of header.comp
Hmmm. Sounds like a TIMTOWTDI thing, I guess hearing some options on
the pros and cons would be interesting.
Thank again -- MK.
------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/blackberry
_______________________________________________
Mason-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mason-users
