click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adrian A." <>
Subject Re: Confusing page class mapping
Date Sun, 20 Jun 2010 08:26:49 GMT
> 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
> 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:

but we could emphasize that the "package" attribute is a *prefix* that 
will always be appended.

Eclipse is not doing it quite right in
<pages package="org.test" autobinding="annotation">
     <page path="home.htm" classname="Home"></page>
-> 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" />

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>
it is correct how Click appends them

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" 
     <page path="index.htm" classname="Home" />
     <page path="subirectory/one.htm" classname="subdirectory.One" />
     <page path="other/two.htm" classname="other.Two" />
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 

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.


View raw message