For what it's worth I implemented a simple Tapestry ComponentClassProvider class that replaces the default one for the hivemind service tapestry.page.NamespaceClassSearchPageClassProvider - this provides case-insensitive page names for our developers.
It also matches page names such as 'login' to classes called 'LoginPage' so that we can provide neater URLs but keep some naming conventions (had problems before where a page class had the same name as a data class that was used inside it). So pretty much what you've suggested, and I agree that it's much nicer. It's a pretty easy thing to achieve to - it simply keeps a little cache of page names -> page classes and searches sensibly on the first access. > -----Original Message----- > From: Don Ryan [mailto:[EMAIL PROTECTED] > Sent: 26 January 2007 12:06 > To: Tapestry development > Subject: Idea for case-insensitive URLs > > Hi, > > I'd like to float an idea relating to the notion of case in URLs. > Howard (or whoever) may deem it daft/impractical/whatever but > I'll float it anyway. The idea stems from two distinct > issues. One is a long-standing reservation I've had about the > appearance of uppercase characters in Tapestry URLs and > template filenames. The other is the recently-mentioned > requirement that Howard has for case-insensitivity of Tapestry URLs. > > Although it's never been anything approaching being a > show-stopper, the appearance of uppercase characters in > Tapestry URLs (in segments like page=BookMatches etc.) has > always looked odd to me. They are an artifact of the > capitalization convention used in a particular programming > language surviving into an entirely different namespace (the > URL namespace), where, in most circumstances, they tend to be > rare. Note that such uppercase characters appear even in the > "friendly URL" alternative. Given that the primary > characteristic of a friendly URL is to be humanly readable, > one good way of assessing a URL's friendliness is to try > reading it down a phone to someone. > Having to verbally indicate the case of particular characters > is awkward and breaks the flow, so is less friendly. For a > similar reason, HTML designers typically have an in-built > aversion to using an uppercase character in the filename of > something they produce, so it seems strange to them that you > want a template called BookMatches.html. (Certainly in the > production of static HTML content, it would be very strange > to name things like that.) As I said, it hasn't been a biggie > by any means, but even so I have typically tried to allow > HTML designers to name templates in the manner they would > normally prefer. Broadly speaking, there are only four main > capitalization conventions (omitting schemes that have really > serious readability problems). > > (i) CamelCaseWithUppercaseInitialCharacter > (ii) camelCaseWithLowercaseInitialCharacter > (iii) ALL_UPPERCASE_WITH_UNDERSCORE_SEPARATORS > (iv) all_lowercase_with_underscore_separators > > Java uses the first three for different kinds of identifier > and the first for filenames. If a framework required a Java > developer to adopt something different in any of these cases, > the developer would probably feel uneasy about doing so. HTML > designers (in my > experience) have a bit of a tendency to favor the fourth > convention for filenames. Consequently, as a way of avoiding > the imposition of a new convention on them, I have tended to > name pages using (iv) above and used the class attribute of > the page-specification element to specify the corresponding > page class, which would obviously use (i) above. So, if I use > book_matches as the name of the previously mentioned page, > the template and specification will be book_matches.html and > book_matches.page respectively, and the latter will contain: > > <page-specification class="pages.BookMatches"> > > Now, this is a clear DRY violation, and immediately suggests > a "convention over configuration" solution. The translation > from page name to page class name would be trivial to do in > code, stripping out underscores and uppercasing certain > characters. All that would be required would be to adopt the > rule/convention that pages should be named using (iv) above > and page classes would then have the corresponding name using > (i) above. The translation would be automatic in the > framework. (And the greenfield approach to Tapestry > 5 would make this possible.) The neat thing here is that you > get case insensitivity thrown in for free. It would require > nothing more than having the translation include the initial > step of lowercasing the URL segment in question. > > In some sense, this approach borrows from one aspect of > convention over configuration as it is implemented in Rails. > The aspect in question is that the convention is not a crude > "use the same identifier" approach, but that the framework > undertakes to do the translation from what would be a natural > identifier in one domain to the corresponding natural > identifier in another. (E.g. plurals on table names becomes > singular for class names, as that is more > natural.) It's this extra level of automatic translation that > makes the convention over configuration seamless. And, in the > above case, it buys you case-insensivity for next to nothing. > > If the basic idea was deemed to have merit, there is a > variation that would be worth giving consideration to as > well. This would be to have the translation include the the > extra step of appending a -Page suffix to get the page class > name (with the corresponding modification to the naming > convention for page classes). This would resolve a minor > naming anomaly in Tapestry, whereby a page class, as > something that represents a page, should naturally be named > using a - Page suffix. (The anomaly is evident from the fact > that the historical base classes for page classes, > AbstractPage and BasePage, do use a -Page suffix, but derived > classes do not.) One consequence of this naming anomaly is > that Tapestry applications have often had pairs of classes > with the same name, one representing a domain object (say > Product) and the other representing the page that provides a > view on that object. To minimize any ambiguity, Tapestry > developers have resorted to using package names to indicate > which is which, say model.Product and pages.Product > (something which I think is being formalized in Tapestry 5). > While I favor the idea of standard packages, the idea of > identically named classes does seem unfortunate. The rigorous > side of me (which is often absent) would want to ask: "What > abstraction does this class represent? Does it represent a > product or a product page?" (And then name it Product or > ProductPage accordingly.) So a HTML designer could produce > product.html while the Tapestry developer was working on > ProductPage.java, and the framework would automatically > associate them. Something analogous would apply to component > classes, although I can immediately foresee some people > feeling uneasy about that one, for no other reason than the > character count in the suffix - Component. I personally > wouldn't have any issue with it as I tend to feel that > precise naming is more important than saving keystrokes. In > any case, this is just a variation on the basic idea, which > can stand on its own. > > Regards, > > Don Ryan. > > This message has been scanned for content and viruses by the > DIT Information Services MailScanner Service, and is believed > to be clean. > http://www.dit.ie > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
