In EclipseIDE there was a bug[1] where the absolute classnames was used in
click.xml even when the
page packages was defined. The problem comes from XmlConfigService which
automatically prefixes
classnames with the package name to create the absolute class name. The
Netbeans plugin has the same
problem.
Our docs isn't very clear on this issue either, some snippets uses absolute
classnames and others
use relative classnames.
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).
I think the Click documentation is quite correct and detailed:
http://click.apache.org/docs/user-guide/html/ch04s02.html#application-automapping
but we could emphasize that the "package" attribute is a *prefix* that
will always be appended.
Eclipse is not doing it quite right in
https://issues.apache.org/jira/browse/CLKE-39:
-----------
<pages package="org.test" autobinding="annotation">
<page path="home.htm" classname="Home"></page>
</pages>
----------
-> makes no sense since the "home.htm" path and the classname are the
same name, and since *automapping* was used, that <page/> tag is
redundant and should not be generated by Eclipse at all.
In case of active automapping, only if the page name differs, does
it makes sense to be generated ('index.htm' -> Home):
-----------
<pages package="org.test" autobinding="annotation">
<page path="index.htm" classname="Home" />
</pages>
----------
If the user switches the automapping
back and forth, IMHO Eclipse should be smart enough to generate and
remove those <page/> tags accordingly (based on what Pages and *.htm
files that it does have in the project).
also for this snippet from CLKE-39:
------------
<pages package="org.test" autobinding="annotation">
<page path="home.htm" classname="org.test.Home"></page>
</pages>
------------
it is correct how Click appends them
"org.test.org.test.Home"
Because the intended usage of this behavior was to be used as a common
prefix. E.g.:
<pages package="my.too.deep.structure" automapping="false"
autobinding="annotation">
<page path="index.htm" classname="Home" />
<page path="subirectory/one.htm" classname="subdirectory.One" />
<page path="other/two.htm" classname="other.Two" />
</pages>
so the appending is correct.
> This all makes me think that XmlConfigService should be enhanced
slightly to load page classes in
> the following order:
>
> 1. prefix the page classname with the package and attempt to load it
> 2. if #1 fails use the classname "as is" and attempt to load it
> 3. if both #1 and #2 fails throw a RuntimeException with a message
that neither classes were found
> on the classpath.
>
> Thoughts?
IMHO Click should not be changed, but the Eclipse plug-in should get
smarter.
I think, only for an "advanced module support", there's a need to
improve how mappings from different "modules" behave and interact, and
how conflicts are solved.
Adrian.
