Mailing-List: contact dev-help@click.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@click.apache.org
Received-SPF: pass (athena.apache.org: domain of sabob1@gmail.com designates
 209.85.212.170 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject
         :x-enigmail-version:content-type:content-transfer-encoding;
        b=tumuEZvuYZQXRse0V0ZPYNiozG0vioS1VtkdVhzwRMCTyy/YkP8d0B1Zb92UviFJz3
         FtajP0v6zATHZPr0iMyB6e2TTEbUwrNCwP+P+xt8OY9+Z8kXyX0rxvDINoATWfS5DfIX
         E7eOwPKRn2zBRyPbuD1aRjYTOOPEt5POwI/Y8=
Message-ID: <4C1D9790.2090205@gmail.com>
Date: Sun, 20 Jun 2010 14:22:40 +1000
From: Bob Schellink <sabob1@gmail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US;
 rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5
MIME-Version: 1.0
To: dev@click.apache.org
Subject: Confusing page class mapping
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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.

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?

Bob

[1]: https://issues.apache.org/jira/browse/CLKE-39