On 25 Jun 2008, at 01:12, Filip S. Adamsen wrote:
As long as it's configurable, I'm fine with it. :)
Except you lose some of the intrinsic simplicity of convention over configuration when you decide to offer both. Note that, depending on how it's implemented, this change need not break any existing Tapestry 5 applications. If the page class has a -Page suffix, then Tapestry would map to that. (You might have to throw an exception if Foo and FooPage both existed under the pages package hierarchy.)
On the naming issue itself, I think it would be a positive development. I think the historical convention of using entity-like names for pages is a regrettable fuzziness. I've shown Tapestry to some undergraduate students and a common beginner's mistake is to put code in a page class that really belongs in an entity class. The naming didn't help there. I'm sure something similar would apply with junior developers in a software house. There's very little point in making the hurdles any higher for people learning their craft.
To really set the cat amongst the pigeons (and infuriate the keystroke tax collectors), I think a similar mapping of a -Component suffix would be good for components (again optional). Although it's unfortunately a longer suffix, the conceptual clarity would probably be worth it. (Why refer to something as, say, an "account component" when discussing it but refuse to actually call it that. Because it's too long?)
Lastly, I don't think I would go along with Hugo's idea of list of optional suffixes. I can't imagine any sensible suffix for pages and components other than -Page and -Component. (Although that could just be my limited imagination.) :-)
Don. This message has been scanned for content and viruses by the DIT Information Services E-Mail Scanning Service, and is believed to be clean. http://www.dit.ie --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
