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.
