Allow customized override of template/field.xhtml from <crank:form>

[GoogleCodeExporter]

We want a feature whereby an application can specify an alternate resource
to be applied from within <crank:form> to render either a specific field or
to render each of the fields.

For example an application developer defines "/templates/myfield.xhtml" in
his webapp, and then calls <crank:form> like this to app:

  <crank:form
      crud="${petClinicLeadCrud.controller}"
      parentForm="petClinicLeadListForm"
      propertyNames="name,inquiry"
      customField="/templates/myfield.xhtml" />

or for individual fields:

  <crank:form
      crud="${petClinicLeadCrud.controller}"
      parentForm="petClinicLeadListForm"
      propertyNames="name,inquiry"
      property.inquiry.customField="/templates/myfield.xhtml" />

For some background on how to accomplish this, see http://tinyurl.com/6o9cnw

Original issue reported on code.google.com by james.ju...@gmail.com on 27 Jul 2008 at 6:07

[GoogleCodeExporter]

Here is an implementation which performs the above feature.  I didn't get 
around to
doing anything property-specific, but it should be straight-forward to add it.

A 
crank-jsf-support/src/main/java/org/crank/crud/jsf/support/OverridableTagHandler
.java
 a UserTagHandler which switches between altResource and a default facelet.

A 
crank-jsf-support/src/main/java/org/crank/crud/jsf/support/FieldTagHandler.java
 make <crank:field> switch on altResource for an alternate facelet.

M crank-jsf-support/src/main/resources/META-INF/template/form.xhtml
 pass ${customField} through as altResource attribute on <crank:field>

M crank-jsf-support/src/main/resources/META-INF/crank.taglib.xml
 <crank:field> is now handled by FieldTagHandler.

A examples/crank-crud-webapp/src/main/webapp/templates/myfield.xhtml
 a custom implementation for a field (adds "XXX"s to field label)

M examples/crank-crud-webapp/src/main/webapp/pages/crud/Role/Form.xhtml
 use the custom myfield.xhtml for all <crank:form> fields.

Original comment by james.ju...@gmail.com on 27 Jul 2008 at 8:26

Attachments:

• field-override.patch

[GoogleCodeExporter]

Here is an updated patch.  I've added support to OverridableTagHandler to allow 
a
given tag's template source to be globally specified from within 
faces-config.xml
and/or Spring application context to apply to all instances of that tag within a
given application.  I've also re-implemented crank.taglib.xml as 
CrankTagLibrary, and
made every template customizable.

I don't understand why ELResolver (which is a SpringBeanVariableResolver) 
doesn't
pick up page-scope jstl <c:set> variables.  I would have thought the underlying 
JSF
implementation of ELResolver would expose e.g. the "/foo.xhtml" from <c:set
var="customField" value="/foo.xhtml">.

I spent a little time verifying that only a minimal performance penalty is 
incurred
by using this feature, and came up with a slight optimization.

The only think I'm not feeling 100% positive about this change is that 
"Overridable"
hurts to read and say.  Maybe "CustomHandler" or some other name might be 
better.

By what process does something like this get included into this project?

Original comment by james.ju...@gmail.com on 31 Jul 2008 at 4:22

Attachments:

• overridable.patch