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 <[email protected]> wrote: > Hi Ari, > Comments inline. > > On Sunday, August 22, 2010, Ari <[email protected]> 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/ >
