click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bob Schellink <>
Subject Re: Confusing page class mapping
Date Mon, 21 Jun 2010 23:44:16 GMT
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


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="">
>>    <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.

View raw message