You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@click.apache.org by Ari <ar...@composersnotebook.com> on 2010/08/21 17:06:15 UTC
templates for components
Hi,
I'm pretty happy with what I've seen of the Click framework so far -- it's
actually the ONLY java framework I've yet found (and I've used/evaluated
most of them) that comes close to doing things in a logical and sensible
way, according to my sense of logic and sensibility.
One strange design decision that I don't understand however is why ordinary
components can't also use the same elegant auto-mapping of java-to-htm files
that the Page classes use. I assume I must be missing/overlooking
something, so maybe someone can clarify.
Section 3.7 of the User Guide presents what to me are two rather
unsatisfactory approaches to custom-rendering a Form -- it says you can
either create a custom template for the entire Page on which the form is
used (meaning the Form's presentation can't be reused elsewhere else), or
you can programmatically embed the display code in the Form subclass itself
(which throws away all the nice benefits of a dedicated view template).
But why is it only Pages that can be auto-mapped to view templates? Why
can't individual components also auto-map (or even manually map) to their
own template, so you can reuse them anywhere without having to redefine
their display? For example, you could define the class MyEmployeeForm
extends Form, and then have a template called my-employee-form.component.htm
which controls its display.
That way you can include it in anywhere in a Page template with the simple
$myEmployeeForm syntax.
It seems so straightforward that I assume I must have misunderstood
something and this is probably already possible. Can someone point the way?
Thanks
Re: templates for components
Posted by Bob Schellink <sa...@gmail.com>.
On 17/09/2010 22:42, Ari wrote:
> Hi Bob,
>
> Thanks for the reply.
>
> Manually applying a Velocity template seems like something I could do with or without Click... the
> auto-wiring I thought was part of the value that Click adds. Offhand it seems sensible to me to
> provide an auto-wiring mechanism for any component, not just Pages, but maybe there are internal
> reasons not to do this.
Components were designed to draw themselves, through their toString methods. There have been talks
about adding pluggable renderers to controls, however I don't think its a good idea for Click to
automatically override control rendering from arbitrary templates. While pages are managed by Click,
controls are not, which includes their rendering. In a sense this type of feature would be too
powerful and could lead to some nasty surprises.
Kind regards
Bob
>
> Anyway the Panel class sounds like it basically provides what I'm looking for, in that any display
> components (or group of components) that I'd like to reuse across pages I can just dump into a
> Panel, then auto-wire that panel to a template.
>
> Could I suggest adding a note about the Panel-based approach to section 3.7.1 of the user guide?
> Section 3.7.2 also somewhat misleadingly states "However once your custom layout components are in
> place, it can be reused across your project and boost productivity" -- making it seem as though
> reuse across pages is not possible with the template-based approach presented in 3.7.1, which it is
> contrasting against.
>
> From what I understand, a Panel-based approach would let you use the template-based layout style
> from 3.7.1 AND let you easily reuse across pages -- best of both I'd say.
>
> Thanks again for all the great work,
>
> Ari
>
>
> On Sat, Aug 21, 2010 at 5:10 PM, Bob Schellink <sabob1@gmail.com <ma...@gmail.com>> wrote:
>
> Hi Ari,
> Comments inline.
>
> On Sunday, August 22, 2010, Ari <ari@composersnotebook.com <ma...@composersnotebook.com>>
> wrote:
> > Hi,
> >
> > I'm pretty happy with what I've seen of the Click framework so far -- it's actually the ONLY
> java framework I've yet found (and I've used/evaluated most of them) that comes close to doing
> things in a logical and sensible way, according to my sense of logic and sensibility.
> >
> > One strange design decision that I don't understand however is why ordinary components can't
> also use the same elegant auto-mapping of java-to-htm files that the Page classes use. I assume
> I must be missing/overlooking something, so maybe someone can clarify.
>
> Controls are rendered (drawn) by overriding their toString() method.
> Whether the toString is hardcoded or uses a Velocity template is up to
> the developer. I'd say it is an implementation detail rather than a
> design constraint. As an exmple, Panel uses this approach. The Context
> object provides a renderTemplate method specifically for this use
> case[1].
>
> Hope this helps.
>
> Kind regards
> Bob
>
> [1]:
> http://click.apache.org/docs/click-api/org/apache/click/Context.html#renderTemplate(java.lang.String
> <http://click.apache.org/docs/click-api/org/apache/click/Context.html#renderTemplate%28java.lang.String>,
> java.util.Map)
>
> >
> > Section 3.7 of the User Guide presents what to me are two rather unsatisfactory approaches to
> custom-rendering a Form -- it says you can either create a custom template for the entire Page
> on which the form is used (meaning the Form's presentation can't be reused elsewhere else), or
> you can programmatically embed the display code in the Form subclass itself (which throws away
> all the nice benefits of a dedicated view template).
> >
> > But why is it only Pages that can be auto-mapped to view templates? Why can't individual
> components also auto-map (or even manually map) to their own template, so you can reuse them
> anywhere without having to redefine their display? For example, you could define the class
> MyEmployeeForm extends Form, and then have a template called my-employee-form.component.htm
> which controls its display.
> >
> > That way you can include it in anywhere in a Page template with the simple $myEmployeeForm syntax.
> >
> > It seems so straightforward that I assume I must have misunderstood something and this is
> probably already possible. Can someone point the way?
> >
> > Thanks
> >
> >
>
> --
> http://incubator.apache.org/click/
>
>
Re: templates for components
Posted by Bob Schellink <sa...@gmail.com>.
On 17/09/2010 22:42, Ari wrote:
>
> Could I suggest adding a note about the Panel-based approach to section 3.7.1 of the user guide?
Done.
> Section 3.7.2 also somewhat misleadingly states "However once your custom layout components are in
> place, it can be reused across your project and boost productivity" -- making it seem as though
> reuse across pages is not possible with the template-based approach presented in 3.7.1, which it is
> contrasting against.
>
> From what I understand, a Panel-based approach would let you use the template-based layout style
> from 3.7.1 AND let you easily reuse across pages -- best of both I'd say.
Thanks Ari, I've incorporated your suggestions into the docs.
Kind regards
Bob
Re: templates for components
Posted by Ari <ar...@composersnotebook.com>.
Hi Bob,
Thanks for the reply.
Manually applying a Velocity template seems like something I could do with
or without Click... the auto-wiring I thought was part of the value that
Click adds. Offhand it seems sensible to me to provide an auto-wiring
mechanism for any component, not just Pages, but maybe there are internal
reasons not to do this.
Anyway the Panel class sounds like it basically provides what I'm looking
for, in that any display components (or group of components) that I'd like
to reuse across pages I can just dump into a Panel, then auto-wire that
panel to a template.
Could I suggest adding a note about the Panel-based approach to section
3.7.1 of the user guide? Section 3.7.2 also somewhat misleadingly states
"However once your custom layout components are in place, it can be reused
across your project and boost productivity" -- making it seem as though
reuse across pages is not possible with the template-based approach
presented in 3.7.1, which it is contrasting against.
>From what I understand, a Panel-based approach would let you use the
template-based layout style from 3.7.1 AND let you easily reuse across pages
-- best of both I'd say.
Thanks again for all the great work,
Ari
On Sat, Aug 21, 2010 at 5:10 PM, Bob Schellink <sa...@gmail.com> wrote:
> Hi Ari,
> Comments inline.
>
> On Sunday, August 22, 2010, Ari <ar...@composersnotebook.com> wrote:
> > Hi,
> >
> > I'm pretty happy with what I've seen of the Click framework so far --
> it's actually the ONLY java framework I've yet found (and I've
> used/evaluated most of them) that comes close to doing things in a logical
> and sensible way, according to my sense of logic and sensibility.
> >
> > One strange design decision that I don't understand however is why
> ordinary components can't also use the same elegant auto-mapping of
> java-to-htm files that the Page classes use. I assume I must be
> missing/overlooking something, so maybe someone can clarify.
>
> Controls are rendered (drawn) by overriding their toString() method.
> Whether the toString is hardcoded or uses a Velocity template is up to
> the developer. I'd say it is an implementation detail rather than a
> design constraint. As an exmple, Panel uses this approach. The Context
> object provides a renderTemplate method specifically for this use
> case[1].
>
> Hope this helps.
>
> Kind regards
> Bob
>
> [1]:
> http://click.apache.org/docs/click-api/org/apache/click/Context.html#renderTemplate(java.lang.String<http://click.apache.org/docs/click-api/org/apache/click/Context.html#renderTemplate%28java.lang.String>
> ,
> java.util.Map)
>
> >
> > Section 3.7 of the User Guide presents what to me are two rather
> unsatisfactory approaches to custom-rendering a Form -- it says you can
> either create a custom template for the entire Page on which the form is
> used (meaning the Form's presentation can't be reused elsewhere else), or
> you can programmatically embed the display code in the Form subclass itself
> (which throws away all the nice benefits of a dedicated view template).
> >
> > But why is it only Pages that can be auto-mapped to view templates? Why
> can't individual components also auto-map (or even manually map) to their
> own template, so you can reuse them anywhere without having to redefine
> their display? For example, you could define the class MyEmployeeForm
> extends Form, and then have a template called my-employee-form.component.htm
> which controls its display.
> >
> > That way you can include it in anywhere in a Page template with the
> simple $myEmployeeForm syntax.
> >
> > It seems so straightforward that I assume I must have misunderstood
> something and this is probably already possible. Can someone point the way?
> >
> > Thanks
> >
> >
>
> --
> http://incubator.apache.org/click/
>
Re: templates for components
Posted by Bob Schellink <sa...@gmail.com>.
Hi Ari,
Comments inline.
On Sunday, August 22, 2010, Ari <ar...@composersnotebook.com> wrote:
> Hi,
>
> I'm pretty happy with what I've seen of the Click framework so far -- it's actually the ONLY java framework I've yet found (and I've used/evaluated most of them) that comes close to doing things in a logical and sensible way, according to my sense of logic and sensibility.
>
> One strange design decision that I don't understand however is why ordinary components can't also use the same elegant auto-mapping of java-to-htm files that the Page classes use. I assume I must be missing/overlooking something, so maybe someone can clarify.
Controls are rendered (drawn) by overriding their toString() method.
Whether the toString is hardcoded or uses a Velocity template is up to
the developer. I'd say it is an implementation detail rather than a
design constraint. As an exmple, Panel uses this approach. The Context
object provides a renderTemplate method specifically for this use
case[1].
Hope this helps.
Kind regards
Bob
[1]: http://click.apache.org/docs/click-api/org/apache/click/Context.html#renderTemplate(java.lang.String,
java.util.Map)
>
> Section 3.7 of the User Guide presents what to me are two rather unsatisfactory approaches to custom-rendering a Form -- it says you can either create a custom template for the entire Page on which the form is used (meaning the Form's presentation can't be reused elsewhere else), or you can programmatically embed the display code in the Form subclass itself (which throws away all the nice benefits of a dedicated view template).
>
> But why is it only Pages that can be auto-mapped to view templates? Why can't individual components also auto-map (or even manually map) to their own template, so you can reuse them anywhere without having to redefine their display? For example, you could define the class MyEmployeeForm extends Form, and then have a template called my-employee-form.component.htm which controls its display.
>
> That way you can include it in anywhere in a Page template with the simple $myEmployeeForm syntax.
>
> It seems so straightforward that I assume I must have misunderstood something and this is probably already possible. Can someone point the way?
>
> Thanks
>
>
--
http://incubator.apache.org/click/