You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: src/docs/guide/customizingFieldRendering.adoc
+72-77Lines changed: 72 additions & 77 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -27,7 +27,7 @@ names are summarized below:
27
27
28
28
29
29
Users upgrading to 1.5 from a previous version should either rename their templates (recommended) or add the following
30
-
to `grails-app/conf/application.yml` to change the default templates names to the old names
30
+
to `app/conf/application.yml` to change the default templates names to the old names
31
31
32
32
[source,groovy]
33
33
----
@@ -46,42 +46,42 @@ grails:
46
46
47
47
The template for a field is chosen by a convention using the names of the controller, action, bean class, bean property, theme, etc. All the tags will look for templates in the following directories in decreasing order of preference:
@@ -123,7 +123,7 @@ All class names are camel-cased simple forms. For example `java.lang.String` bec
123
123
124
124
Templates are resolved in this order so that you can override in the more specific circumstance and fall back to successively more general defaults. For example, you can define a field template for all `java.lang.String` properties but override a specific property of a particular class to use more specialized rendering.
125
125
126
-
Templates in plugins are resolved as well. This means plugins such as `Joda Time` can provide default rendering for special property types. A template in your application will take precedence over a template in a plugin at the same 'level'. For example if a plugin provides a `grails-app/views/_fields/string/_widget.gsp` the same template in your application will override it but if the plugin provides `grails-app/views/_fields/person/name/_widget.gsp` it would be used in preference to the more general template in your application.
126
+
Templates in plugins are resolved as well. This means plugins such as `Joda Time` can provide default rendering for special property types. A template in your application will take precedence over a template in a plugin at the same 'level'. For example if a plugin provides a `app/views/_fields/string/_widget.gsp` the same template in your application will override it but if the plugin provides `app/views/_fields/person/name/_widget.gsp` it would be used in preference to the more general template in your application.
127
127
128
128
For most properties the out-of-the-box defaults should provide a good starting point.
129
129
@@ -135,45 +135,45 @@ Imagine an object of class `Employee` that extends the class `Person` and has a
135
135
136
136
You can override the template `f:field` uses with any of these:
During template development it is usually recommended to disable template caching in order to allow the plugin to recognize new/renamed/moved templates without restarting the application. See the "Performance" section of the guide for the exact settings.
179
179
@@ -194,8 +194,7 @@ grails:
194
194
----
195
195
196
196
197
-
=== Default Behaviour - Using Grails Widget Tags
198
-
197
+
=== Default Behaviour - Using Grace Widget Tags
199
198
200
199
If no template override is found the plugin will use the standard grails input tags (e.g. `g:select`, `g:checkbox`, `g:field`) for rendering input controls.
201
200
Using `f:field` you can pass extra arguments (e.g. `optionKey`, `optionValue`) through to these tags by prefixing them with `widget-`, e.g.
@@ -208,7 +207,6 @@ Using `f:field` you can pass extra arguments (e.g. `optionKey`, `optionValue`) t
208
207
209
208
=== Template parameters
210
209
211
-
212
210
The `f:field` and `f:widget` tags will pass the following parameters to your templates or to the body of `f:field` if you use one:
213
211
214
212
.Template Parameters
@@ -276,7 +274,6 @@ NOTE: If the `bean` attribute was not supplied to `f:field` then `bean`, `type`,
276
274
277
275
=== Field labels
278
276
279
-
280
277
If the `label` attribute is not supplied to the `f:field` tag then the label string passed to the field template is resolved by convention. The plugin uses the following order of preference for the label:
281
278
282
279
* An i18n message using the key '_beanClass_._path_`.label`'. For example when using `<f:field bean="personInstance" property="address.city"/>` the plugin will try the i18n key `person.address.city.label`. If the property path contains any index it is removed so `<f:field bean="authorInstance" property="books<<0>>.title"/>` would use the key `author.books.title.label`.
@@ -286,7 +283,6 @@ If the `label` attribute is not supplied to the `f:field` tag then the label str
286
283
287
284
=== Locating Field Templates Directly
288
285
289
-
290
286
Rather than relying on the convention described previously to locate the template(s) to be used for a particular field, it is
291
287
instead possible to directly specify the directory containing the templates. This feature was introduced in version 1.5.
Copy file name to clipboardExpand all lines: src/docs/guide/embeddedProperties.adoc
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -12,6 +12,6 @@ Embedded properties are handled in a special way by the `f:field` and `f:all` ta
12
12
</fieldset>
13
13
----
14
14
15
-
You can customize how embedded properties are surrounded by providing a layout at `grails-app/views/layouts/_fields/embedded.gsp` which will override the default layout provided by the plugin.
15
+
You can customize how embedded properties are surrounded by providing a layout at `app/views/layouts/_fields/embedded.gsp` which will override the default layout provided by the plugin.
16
16
17
17
When you use the `f:all` tag it will automatically handle embedded properties in this way.
Plugins can include field and/or input level templates to support special UI rendering or non-standard property types. Just include the templates in the plugin's `grails-app/views` directory as described in the <<customizingFieldRendering,Customizing Field Rendering>> section.
3
+
Plugins can include field and/or input level templates to support special UI rendering or non-standard property types. Just include the templates in the plugin's `app/views` directory as described in the <<customizingFieldRendering,Customizing Field Rendering>> section.
4
4
5
5
WARNING: If you supply templates in a plugin you should consider declaring a `<%@page defaultCodec="html" %>` directive so that any HTML unsafe property values are escaped properly regardless of the default codec used by client apps.
The _Fields plugin_ allows you to customize the rendering of input fields for properties of domain objects, command beans and POGOs based on their type, name, etc. The plugin aims to:
4
+
5
+
* Use good defaults for fields.
6
+
* Make it very easy to override the field rendering for particular properties or property types without having to replace entire form templates.
7
+
* Not require you to copy and paste markup for containers, labels and error messages just because you need a different input type.
8
+
* Support inputs for property paths of arbitrary depth and with indexing.
9
+
* Enable other plugins to provide field rendering for special property types that gets picked up automatically (e.g. the _Joda Time_ plugin can provide templates for the various date/time types).
10
+
* Support embedded properties of _GORM_ domain classes.
Copy file name to clipboardExpand all lines: src/docs/guide/scaffolding.adoc
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,12 +1,12 @@
1
1
Scaffolding templates based on the _Fields_ plugin are quite powerful as they will pick up field and input rendering templates from your application and any plugins that provide them. This means that the useful life of scaffolding templates should be much longer as you do not need to replace the entire _create.gsp_ and/or _edit.gsp_ template just because you want to do something different with a certain property of one particular class.
2
2
3
-
The plugin makes the _renderEditor.template_ file used by standard Grails scaffolding redundant. This template was very limited because it could not be extended by plugins or applications (only replaced) and was unable to support embedded properties of domain classes.
3
+
The plugin makes the _renderEditor.template_ file used by standard Grace scaffolding redundant. This template was very limited because it could not be extended by plugins or applications (only replaced) and was unable to support embedded properties of domain classes.
4
4
5
5
The _Fields_ plugin includes scaffolding templates you can use in your application by running:
6
6
7
7
[source,groovy]
8
8
----
9
-
grails install-form-fields-templates
9
+
grace install-form-fields-templates
10
10
----
11
11
12
12
This will overwrite any _create.gsp_ and _edit.gsp_ files you have in `src/templates/scaffolding`.
0 commit comments