I've improved the error message if the classname cannot be loaded. I also agree that we should update the docs and add the pages element where absolute page classnames are specified.
Kind regards Bob On 20/06/2010 22:02, Adrian A. wrote: >>> I always thought that the whole point of "package" attribute was to be >>> used in conjunction with automapping, and when automapping is false, >>> than just to shorten the code by specifying the "common" package part of >>> all pages only once (since there might be hundreds of pages). >> >> >> This isn't correct. The package is used whether automapping is on or off. > Yes, in both cases but only as a "prefix" - this is how I understood it > from the author of automapping idea. > >> I don't think anyone would >> switch off automapping so we can just assume it is always true. > For most cases it's true (since it's an incredible time saver), but this > feature was made "switchable" because of use cases where automapping > wouldn't give the desired URLs, or where they need to be changed, but a > refactoring of the page names or structure isn't an option. > >> The question comes with how the >> manual mapping occurs inside the pages element: >> >> <pages package="org.mycorp.page"> >> <page path=".." classname="Index"/> >> <page path=".." classname="customer.MyPage"/> >> </pages> >> >> The "classname" Index looks OK, but "customer.MyPage" doesn't. Calling >> it "classname" is misleading >> because it is neither the full nor the simple classname. Its more of a >> postfix. > Exactly. It's a suffix (or the 'stem' since the package is the prefix :) > ), and if I got > it right, this was also the very intention of it. > > Given the naming of some attributes was not the luckiest, but > 'automapping' was also a made up word with meaning in Click only. > > The "classname" parameter was there even before automapping was > introduced, and kept that way for comapatibility reasons (and also > because not better wording was found). > Naming that parameter "classname" also had the advantage that (some) > IDEs offered class completion in click.xml without any further plug-ins > or configuration :). > >> If you look around the docos you'll see many references to absolute >> classnames eg: >> >> <page path="error.htm" classname="org.mycorp.ErrorPage"/> > Yes, you are right, this is misleading, but I suppose this is because > the "package" is not present in the snippet, so it's considered empty. > IMHO absolute class names should be changed in the docs, or in the > snippets the package attribute must be visibly empty or missing. > >> Where the confusion seems to come in is people interpret the classname >> as absolute even when the >> package is specified, at which point the classname becomes relative. > Maybe we should emphasize one more time in the documentation that the > "package" is a prefix, so whenever present > it will be "appended*. > >> My suggestion is that we load the class with the package prefix as we >> do now and if it isn't found, >> try against the given classname. >> This should clear up the confusion. > I'm not sure if this change would clear up the confusion, since: > - the 'path' might point to another page class in the structure this > way, so instead of failing early as it does now, the user will discover > the error much later. > - the users have to learn one more exception from the rule about how > Click automapping is working. IMHO the less exceptions to memorize, the > faster is the learn process :). > > Adrian. > >
