12-01-2011 06:16 PM
I am working on developing a content view for an extended email folder.
I'm using the mail_listing layout.
And the following as entries for the template resource in the layout widget widget editor:
I can see the fields etc dc:title, mail:sender in the folder associated with this content view using Nuxeo Shell.
Question is: What form should the field entries take in the layout widget editor?
I've tried:
dc:title #{dc:title} "dc:title"
Thanks,
Karl Harris
12-02-2011 08:28 AM
Here you're configuring a layout listing, not a form layout, so i believe you should be using:
<field>data.dc.title</field>
Note that {dc:title} and "dc:title" are not potential ways of writing this.
Here's an explanation of why the "data" information is needed on layout listings.
Usually, when working with layout forms, the object passed to the layout is the document model itself. The field configuration is then used to generate an EL expression that will take care of binding the field to the JSF component rendering it (so it'll be able to call a getter and a setter on it).
So in a layout form, the following syntaxes would be accepted:
<field>dc.title</field>
(native resolution of the title property for the EL resolver named DocumentModelResolver)<field>dublincore.title</field>
(native resolution too, using the schema name instead of its prefix)<field>dc:title</field>
(alternative way of configuring the mapping, kept as it's easier to use the property name, and that also fits sub properties mapping using the xpath syntax)<field schema="dublincore">title</field>
(old syntax kept for compatibility, that is not used anymore because it's less confusing to use the standard prefixed property name instead)On a listing layout, each row is rendered using the iteration item. Because content view results often need to handle selection, the content view rendering maps the layout objet not to the document itself, but to a wrapping of it inside a PageSelection item (see API here)
So to get back the document resolution, you need to start your field mapping by the "data" object, so that the widget holding the checkbox for row selection can use the field mapping <field>data.selected</field>
.
I hope this is clear enough. Note that you can also take examples on existing listing widget types configuration, see for instance:
12-02-2011 08:28 AM
Here you're configuring a layout listing, not a form layout, so i believe you should be using:
<field>data.dc.title</field>
Note that {dc:title} and "dc:title" are not potential ways of writing this.
Here's an explanation of why the "data" information is needed on layout listings.
Usually, when working with layout forms, the object passed to the layout is the document model itself. The field configuration is then used to generate an EL expression that will take care of binding the field to the JSF component rendering it (so it'll be able to call a getter and a setter on it).
So in a layout form, the following syntaxes would be accepted:
<field>dc.title</field>
(native resolution of the title property for the EL resolver named DocumentModelResolver)<field>dublincore.title</field>
(native resolution too, using the schema name instead of its prefix)<field>dc:title</field>
(alternative way of configuring the mapping, kept as it's easier to use the property name, and that also fits sub properties mapping using the xpath syntax)<field schema="dublincore">title</field>
(old syntax kept for compatibility, that is not used anymore because it's less confusing to use the standard prefixed property name instead)On a listing layout, each row is rendered using the iteration item. Because content view results often need to handle selection, the content view rendering maps the layout objet not to the document itself, but to a wrapping of it inside a PageSelection item (see API here)
So to get back the document resolution, you need to start your field mapping by the "data" object, so that the widget holding the checkbox for row selection can use the field mapping <field>data.selected</field>
.
I hope this is clear enough. Note that you can also take examples on existing listing widget types configuration, see for instance:
12-02-2011 08:30 AM
The studio widget editor needs the xml field tags as well as the field prefix
Find what you came for
We want to make your experience in Hyland Connect as valuable as possible, so we put together some helpful links.