click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adrian A." <a.adrian.t...@gmail.com>
Subject Re: Confusing page class mapping
Date Sun, 20 Jun 2010 12:02:29 GMT
>> 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.


Mime
View raw message