-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
LOL, are you trying to revive the Mason style guide thread? Nice, I like
this kind of threads ;-)
For those who missed it, search your archives for Subject: "Mason style
guides?", available online at:
http://marc.theaimsgroup.com/?l=mason&m=112804611513526
Pitifully, your courses are still not available online o:-)
Paul Fenwick wrote:
> As per the discussion in HTML::Mason::Admin, I'm advocating the use of
> .html for top-level components, .mhtml for components that generate
> HTML, .mtxt for ones that generate text, and .mpl for ones that execute
> code (but do not generate content).
And me against it, for the same reasons as the others folks already said
("technology exposure", "URIs NEVER change", etc). Or, if I may, even if
I don't care about this Microsoft-ish file extension convention, at
least because of the web established naturalness, as in "tell me what
you give me" (another/the-same Microsoft-ish convention/flaw promoted by
their Internet Explorer product). So, abiding by these "rules", I tend
to stick (_when_ necessary, as I prefer to follow "the no file extension
cargo cult") to "it's a web page?" - ".html", "it's a script" - ".js",
"it's a stylesheet?" - ".css", etc.
As for mason components, prepending a "_" to their names (you know, the
usual Perl convention for naming "private" methods) it's good enough for
me. If there are too many (cluttering that folder), I'd group them in
some "private" folder (something with the same "_" in front).
OFC, I'd recommend using Perl modules instead, but I can cope with
laziness (at least until Dave & Ken find some time to do a "next
generation" Mason Book, describing their current approaches).
> However I've hit a bit of a snag when it comes to calling components
> with content
> [...]
> I'm not suggesting that .with_content be used as a suffix, but I am very
> curious to know what naming conventions others have used to denote
> components that require content to operate. I usually place them all in
> their own directory (often called '/filters'), but I can see perfectly
> good arguments for other conventions as well.
>
> Feedback, ideas, comments, suggestions and discussions are all very much
> appreciated.
My resolution is: "throw". Exceptions are good (even if Exception::Class
can be a bitch sometimes). Throw a meaningful error every time your
programmers miss-use your method/component so they will see it (and fix
it) in no time. :)
OFC, this exception triggering approach is not a "different" approach,
just a "complementary" one. Meaningful method/component names always
help, so your "/filters" (or "/_filters") suggestion sounds good.
If it's just one lonely filter, it could be named as "_filter_.*".
cheers
- --
Marius Feraru
-----BEGIN PGP SIGNATURE-----
iD8DBQFE5cYNtZHp/AYZiNkRAuMFAKCrnZjPoOM5m/XbGyWIaG5S0mtVdwCgjpS0
M/YwRKvBAAegg8/YwcpgF10=
=wqLy
-----END PGP SIGNATURE-----
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Mason-users mailing list
Mason-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mason-users
