Re: repeats

fair enough,
	but the new spec does demand that an xform is necessarily longer then 
previously required, with scope for lining origins to wrong binds etc 
and since it is still ONLY in draft form I'd like to see v1.0 amended to 
be useful again.

> Your analysis is correct. John's solution is good and deserves being
> exposed, but as you point out it has some drawbacks as well.

I'd argue strongly about its "good-ness", but hey, its a neat trick if 
you dont mind changing your data, storing senseless data, and dont want 
to use both insert before and after from an arbitrary user selected node.

> In my opinion an excellent solution is provided by XForms 1.1 with the
> @origin attribute on xforms:insert. With that attribute:
> 
> o You create insertion templates in separate instances.
> 
> o You don't have a discrepancy between your instance at runtime in the
>   form and your instance as it is submitted or restored.

This discrepancy only exists if you dont use the form itself to load new 
instance data (ie direct ssi situation). If the form is initialised with 
  representative instance data then the result is identical to the 1.1 
option. having said that I'm not bent on restoring this aspect since 
even I have acknowledged in previous posts that xforms inserts are 
viable again in 1.1, but I still think that having an insert do nothing 
if there is no node is bizarre. Not from the point of view of that there 
is no data, but that any user would just not expect this in any active 
use. I'm surprised that everyone hasn't implemented the 1.1 insert 
attributes given the mess that the 1.0 version leaves us with, but then 
again it is only draft. The version of Chiba I've been using is still a 
draft implementation of 1.0 as far as the insert behaviour goes and that 
changed radically in the final spec, so theres no guarantee and little 
incentive I would have thought to implement anything until the latest 
draft is finalised.

On the new prototypical data requirements, isnt it kind of weird that an 
xform instance can have a schema, and a prototypical instance? why not 
just enforce a schema definition for an xform's data?, wouldn't that 
achieve the same thing as prototypical data but with capacity to also 
specify datatype/node ranges etc? and again delete the requirement to 
specify an origin for most inserts?

> 
> o You always deal with perfectly clean instances that validate as you
>   expect with schemas and don't need to contain extra content.
> 
> o You have code that is easier to write and understand.

I'll agree here - certainly easier to understand, esp for newbies, but I 
maintain that if you were always building your forms with prototypical 
data in your instances (which I quickly discovered was the ONLY way to 
build useful forms) then you always had perfectly clean instances, and 
there was no problem except the unfortunate hack required to delete any 
initially unwanted nodes on xforms-ready, the result is identical to the 
1.1 solution with less code. I never liked the "old" notion much but I 
like even less the ramifications to insert that not having it brings about.

> I am convinced that the 1.1 solution not only cover the requirements
> for repetition but it leads to elegant code and architecture. I don't
> find any fault with it. It certainly does not lead to the confusion of
> the original XForms 1.0 behavior, or to the remaining drawbacks (that
> you exposed) of the XForms 1.0 Second Edition behavior. There is do
> doubt in my mind that the worse thing we could do would be to go back
> to the original XForms 1.0 behavior.

it just seems that with the new solution, people will be required to 
manually specify the source for every element, and 99% of the time the 
information is already there. perhaps insert should always have 
duplicated nodes as empty nodes. None of this helps any with attribute 
management either, which is something I have great trouble with in 
Xforms. I really don't like having to maintain empty attributes just to 
keep from breaking a form, so the idea of necessarily copying an entire 
element again doesn't sit well with me. The schema notion might also fix 
this by allowing attributes to be defined as not required. but thats 
another story.

Jason.

Received on Monday, 6 November 2006 23:00:09 UTC