Ticket #319 (closed task: fixed)
Enable use of relative paths in kauri-layout
| Reported by: | sdm | Owned by: | mpo |
|---|---|---|---|
| Priority: | major | Milestone: | 0.4 |
| Component: | modules/kauri-forms | Version: | |
| Keywords: | kauri-layout relative path | Cc: | kauri-discuss@… |
Description
It would be useful if we could specify relative paths in the kauri-layout attribute of a collection-control instead of an absolute path.
For example, if you need to reuse a collection-control, you should be able to specify a relative path for kauri-layout:
<tr>
<td>Maandag</td>
<td kauri-idref="week1/monday">
<t:include src="scheduleCollControl.xml" />
</td>
<td kauri-idref="week2/monday">
<t:include src="scheduleCollControl.xml" />
</td>
</tr>
scheduleCollControl.xml contains:
<table kauri-idref="schedule" kauri-type="collection">
<tbody kauri-role="container">
<tr kauri-layout="schedule/#">
<td kauri-idref="id" kauri-type="integer">
<select class="input" kauri-role="input" />
</td>
<td kauri-idref="start" kauri-type="time">
<input class="input" kauri-role="input" />
</td>
</tr>
</tbody>
</table>
By using the relative path "schedule/#", the following kauri-layouts will be assumed:
/week1/monday/schedule/#
/week2/monday/schedule/#
Change History
comment:2 Changed 3 years ago by freya
But now, the kauri-layout elements are grouped per child of a collection (e.g. /weeks/#). By making the kauri-layout relative to the current kauri_index, they won't be grouped in case of nested collections. So the suggestion you made, won't work in case the weekdays would also be a collection.
Needs some investigation or rethinking.
comment:3 Changed 3 years ago by freya
- Status changed from new to closed
- Resolution set to fixed
using relative paths is possible since r1541 for kauri-layout and kauri-cursor
Example:
<table kauri-idref="countries" kauri-type="collection" >
<tbody kauri-role="container" >
<tr kauri-layout="#">
<td >
<input kauri-idref="name" kauri-type="string" kauri-role="control"/>
</td>
<td>
</tr>
</tbody>
</table>
To be clear: this means we would expect the 'relativity' to work versus the current kauri_index value (which is in turn the absolute variant of the kauri_idref)
or to be overly clear: we shouldn't build a separate kauri_layout_index
(at least that's the feeling I'm getting from reading this suggestion)