G'day Marius / Mason Users, Marius Feraru wrote:
> LOL, are you trying to revive the Mason style guide thread? Nice, I like > this kind of threads ;-) I certainly consider this to be a related topic, yes. I like discussing stylistic issues. > Pitifully, your courses are still not available online o:-) With the exception of Damian's notes, most of our course materials are available online. http://perltraining.com.au/notes.html contains a number of our course manuals. The web development timeline ended up getting pushed out, but as the notes are going to the printers tomorrow I imagine they'll be available on the web in a few weeks, after we've had time to integrate changes and updates from any course feedback. Do feel free to nudge me if it looks like things are taking too long. Our intention is to get all the Perl Training Australia manuals on-line. > > 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). I may not have been entirely clear (or perhaps I've misunderstood). I'm only advocating the use of .mhtml and friends for components that should *never* be accessible by end users, and should only ever be called by other components. At the very least this makes it easy to write access controls to prevent arbitrary Mason components from being served to the user. .mhtml should never be appearing in a URI. I do like the idea of prepending underscores to names to indicate a private component. While it's something that I've used in coding for years, I've never considered it with regards to using it for Mason components. Thank-you very much for the suggestion! > 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. :) I agree entirely. If you can detect that a component, subroutine, module, or other piece of code is being used incorrectly, then throwing an exception is almost certainly a good idea. > 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_.*". Very good. So far I haven't had any objections to suggesting a /_?filters/ prefix for component calls with content. :) All the very best, Paul -- Paul Fenwick <[EMAIL PROTECTED]> | http://perltraining.com.au/ Director of Training | Ph: +61 3 9354 6001 Perl Training Australia | Fax: +61 3 9354 2681 ------------------------------------------------------------------------- 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
