Yes the general pattern is one Click Page class per Velocity page template
(*.htm).  These are associated using automapping, following the convention
over configuration pattern. This is extremely productive, reduces bugs and
know where to find stuff.

Alternatively you can share Click Page classes between templates but you
need to configure them in the click.xml file

Regarding the benefit of a Page oriented architecture, its a much more
natural way to think about web applications.  When we are scoping and
estimating work this is generally how we do it.

Please note a page oriented design does not preclude Velocity templating
features, we use a border-template.htm pattern extensively, where by all the
page chrome and menus are in the border template. While the actual page
content is in a #parse() included page *.htm file.  Works great.

The Click Examples provide a good illustration of this:

http://www.avoka.com:8080/click-examples

Also note the ClickServlet was derrived originally from the VelocityServlet
and Click also uses the Velocity Tools WebappLoader.

regards Malcolm Edgar

On Feb 5, 2008 8:44 AM, Claude Brisson <[EMAIL PROTECTED]> wrote:

> A new java object for each page? It's even worse! Well, thanks,
> anyway...
>
>  Claude
>
>
> Le lundi 04 février 2008 à 21:51 +0100, Ahmed Mohombe a écrit :
> > > Thanks, Ahmed, but I've already read it. My point here is that -unless
> I
> > > missed something- Click forces me to at least tweak its configuration
> > > file each time I create a new velocity template page.
> > Maybe you should take a look at the examples too:
> > - you are not forced. There's a "automapping" feature that does this
> mapping
> > automatically:
> > http://click.sourceforge.net/docs/best-practices.html#automapping
> >
> > In most applications I've made, I did the configuration at project start
> > and never changed it (except for the "logging" mode from "development"
> to "production")
> >
> > Ahmed.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Reply via email to