Antonio Gallardo wrote:
Hi Marc!
Because seems like you will start soon. I will not miss the oportunity to get into. So here we go! ;-D
starting soon?
http://www.nederlands.nl/nedermap/gedichten/gedicht/32123.html?zoekresultaat=ja
(there is no way to translate, sorry, well, maybe if you get enough booze in me at the next get together and only after we had all the dull yank and aussie jokes...)
<snip/>
In the case of nested childs I meet the situation where we often wrote:
<fb:value id="key1" path="key1"/> <fb:value id="key2" path="key2"/> ...
So the question is:
Can we "save" typing by defining a default value for @path. That way we can also write:
<fb:value id="key1"/> <fb:value id="key2"/>
And in this way the machine will fill the @path for me.
hm, I'm -0 on the same arguments Joerg just gave (automagical stuff)
<snip content="explanation on case 1 and 2 that probably wasn't clear"/>
OK. As posted before (2) = extension of (1). If this is true, then we can avoid the introduction if the new: "@clear-items-on-save". The detection can be the same as ((1) && (<fb:on-insert/> || <fb:on-delete/>)
Because the <fb:on-insert> and <fb:on-delete> can be optional.
not sure:
the @clear-items-on-save is a clear indication that you delibarately want to ignore possibly sparse bound items, there is nothing in case1 that would make it do that by clearing the on-insert/on-delete
when we concluded that (2) == (1) it was only about the fact that the strategy algorithm would be the same AND surely implied 'only after clear of items'
Suppose a form that allow a user just to insert/edit items and other form for of the same data that allow user only delete items. ie: a very simple ticket system when the receptionist assign new tickets and the service personal delete them. Of course I know tickets system that store each ticket forever (knowledge DB), but it is OT here.
in your example I take it you are talking about two distinct use cases with persistent storage (and thus binding) in between
supposing your tickets don't have explicit identity (odd? if they have you should conmsider case3 or 4) I assume the only thing to consider is sparse binding support... if you need it, you'll need case1 for sure, else it doesn't really matter
so yeah: your developer would not use @clear-items-on-save but I don't think it is prove that nobody else needs it :-)
in any case I wanted to explicitely include the counterpart of what is now the simple-repeater
I think the similarities between case 1 and 2 are just stating that there is a basis for combining the code in one binding-element
-o0o-
[case 3] DESCRIPTION: - items have an explicit identity and can be sparsly bound - form-model can add/remove/reorder the rows - the sequence editing of the rows need to be reflected onto the items
PROPOSED SYNTAX: <fb:repeater id="rep-id" parent-path="." row-path="item" > <!--required elements for this case --> <fb:identity>...</fb:identity> <fb:on-bind>...</fb:on-bind> <fb:on-insert>..</fb:on-insert> <fb:on-delete>..</fb:on-delete> </fb:repeater>
EXPECTATION DETECTION: <fb:identity> is present
STRATEGY on 'save': - backup all items to a list OriginalItems - foreach row in the repeater - if row-identity-match in OriginalItems - move item back into the context and bind - else - use on-insert and on-bind to create and bind - for the items still left in the OriginalItems - use the on-delete
I would define <fb:on-bind> and <fb:on-delete> as optionals. Currently I meet situations when there is a predefined list to be filled and I don't need to add or delete row at all. Example: A user fill a form while it
touche. that is indeed a case I've missed in my explicit listing
it's something like case 1 but WITH an explicit identity
in any case it should be covered by the algorithm in this case 3: there would just be no rows/items to use on-insert/on-delete on
fill the form the number of row of the repeater is defined. Then we use other form for users that evaluate the filled form. In this case we already know how many items are in the repeater (because the system automatically build the evaluation form) and we don't allow to delete or add new items. The evaluating user just can fill/edit the predefined widgets in the form. No add or delete allowed. It is tipical in goverment, when one people fill forms and other review the forms.
and sparse binding should be supported for people that don't get to see/edit all properties of the item
-o0o-
[case 4] (aka current RepeaterBinding) DESCRIPTION: - items have an explicit identity and can be sparsly bound - form-model can add/remove but should not allow reordering of the rows - the original sequence of the items is to be maintained at all times (on-insert really is more of an on-append: no new ones can be inserted in between the old ones)
PROPOSED SYNTAX: not clear yet, I tend towards:
<fb:repeater id="rep-id" parent-path="." row-path="item" row-path-insert="newItem"> <!--required elements for this case --> <fb:identity>...</fb:identity> <fb:on-bind>...</fb:on-bind> <fb:on-insert>..</fb:on-insert> <fb:on-delete>..</fb:on-delete> </fb:repeater>
EXPECTATION DETECTION: fb:identity plus the presense of a @row-path-insert seems to indicate that the new ones need to go into a different space then the exisiting ones, and thus denying the approach expressed in case3 (i.e. even if it would read the same as row-path! so there would be a difference between explicitely stating it as the same, and defaultly assuming it is the same)
STRATEGY on 'save': - foreach row in repeater - if identity match found in items - bind to that - add it to the set of updatedItems - else - add it to some list of rowsToInsert - run through items - if NOT found in updatedItems - add to list of toDeleteItems (ndx will do) - register the on-insert as factory - foreach row in rowsToInsert - create and bind it - foreach ndx in toDeleteItems in reverse order - use on-delete to remove/mark
Don't know the current RepeaterBinding do that! It distribute the result on 3 diferent sets? It would be useful in some cases.
like Joerg pointed out, this is indeed what it is doing
-o0o-
For completion: implementation of the above assumes the refactoring of the current identity approach towards the earlier mentioned IdentityBinding interface.
see: http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107955523607012&w=2
(Joerg, if you're ok, I'll start doing it when this discussion (if any) converges)
While writing up this proposal I end up questioning a number of (historically chosen) names that could change:
- repeater/@parent-path --> repeater/@path for consistency with the order bindings
repeater/@base-path
I'm with Joerg here, if we change it it should be to @path to align with the current value and context bindings
hm, if we go for base-path here then the drive for consistency would force us to change @path to @base-path on all context/composed bindings
- repeater/@row-path --> repeater/@item-path since it is pointing to items, not rows
Here I will propose just repeater/@path. The same name as in <fb:value>.
well, no. this @row-path today is pointing to the items (relative to the context narrowed by the parent-path), the counterpart on the repeater-side are the (implicit) rows
It would be fine. While starting using Cforms I often found myself asking by the right name. I cannot stop thinking in the repeater as a List.
yes, a list of rows
- on-insert is actually more of a on-create ('insert' seems to exclude 'append', while create is more nutral to exactly where the newly created is added, it is also more in sync with the actual factory registration IMHO )
+1 or on-add (it is shorter) :-P
- repeater/@row-path-insert --> repeater/@new-item-path which would be syncing up with the last two changes and arguments
[EMAIL PROTECTED] [EMAIL PROTECTED] abort, retry, fail?.... Please found a name for me. Here is 2:15 a.m. I need to sleep a little bit. :-D
new-item-path reads as the path (relative to parent-path) where new items will be added
Best Regards,
Antonio Gallardo
hope this clarifies some -marc= -- Marc Portier http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
