Re: repeats

> You don't need any binds at all on the template. You just use it as a
> data template.

But I think binds SHOULD be used. binds prevent the mess of xpath 
littering the view, and I think its just good practice to use them.


>  > and a few binds or controls dont match
> 
> Again you would not need any bind on the template, and you would not
> bind any controls to it either. It's just a data template whose sole
> purpose is to be available for insertion.

again - if you dont use binds here then you dont use them anywhere, so 
why bother with them at all?

>  > So copying from arbitrary nodes probably wont work anyway, so we've
>  > really only added complexity here.
> 
> Here I disagree strongly. You are talking about a situation (old 1.0)
> where you cannot control what you are inserting and where the template
> to copy comes from an instance that does not exist anymore (it is the
> initial content of that instance that you had to save, not the current
> content or that instance). To me, that is very confusing. The syntax
> may have one attribute less, but the processing model is more complex
> to understand and explain.

no - I was talking about a situation where you have a bound node. so 
when an arbitrary insert occurs any bind in a control/repeat/whatever 
would break if you insert arbitrary data that doesnt match the 
bind(extra attributes/whatever) - wouldnt it? perhaps not, maybe this is 
just a hangover of my experience to date?


> It's just one @origin attribute that you are adding, and to me the
> benefit is clarity, not only of the code as you read it, but also of
> the processing model which only deals with the current content of the
> instances.

I dont have any problem at all with the origin attribute. Its great. It 
just shouldnt be required. And if its not required then insert can work 
again. but I submit on this, its clearly a lost cause.

>  > but it would contain those templates if you, as the xforms designer,
>  > recognised this (and you clearly do!) and included a properly
>  > representative initial instance, just as you are forced to do with
>  > 1.1 - its just the same!!!
> 
> If it's the same, your argument can be turned around in favor of the
> 1.1 way ;-)

except that with 1.1 theres more code required for the same job.


> Well we don't want XForms to be more verbose than necessary (although
> the XML syntax does cause some verbosity, for better or for worse),
> but here we just make things clearer with an @origin attribute.
> 
> But I also think that reading existing code is made easer when
> constructs and names are explicit rather than implicit.

so maybe you'll like my suggestion of an explicitly defined prototype?

> 
> You can get by with a single document prototype and a schema. Then you
> can have of course 10000 "concrete" documents that you want to edit
> with XForms and that validate with the schema.
> 
> It would be of course nice if a schema could allow to do without a
> document template. I am not a Schema specialist, but I don't think
> that there is a simple schema-based solution to create documents in a
> way that would satisify most use cases. For now it's probably better
> to leave that kind of functionality to external tools.

I was suggesting perhaps schema could replace the prototype for instance 
data, not be used as the basis for a complete xform. As you say there 
are external tools that try to do just that.



> So to summarize:
> 
> o There is not much difference in the code one must write between the
>   "old" 1.0 behavior and 1.1.
> 
> o 1.1 does add the @origin attribute on xforms:insert, which I see as
>   a benefit for code clarity.

I see as a benefit for code flexibility. I'm not convinced on the clarity.

> o The "old" 1.0 behavior requires to think about the "initial" and
>   "current" state of instances. 1.0 Second Edition and 1.1 completely
>   do away with that, and I think this makes things simpler.

1.0se is utterly broken, and so I dont think should even be compared. My 
left boot doesnt make me think about initial states either, but it 
doesnt help my xforms development!
And 1.1 makes you think about initial states just as much as 1.0, 
probably more because you must define your target and your source node 
for every insert.

> 
> o Contrary to what you suggested, there are no extra binds or controls
>   to add on the template.

If you try to use binds as I think best practice suggests, then you do 
need extra binds, otherwise the xpath clutter only gets worse.
> 
> o The @origin attribute is generic and has other uses besides
>   inserting data templates within a repeated section. So it is good to
>   have it.

not arguing that it shouldn't exist - I love it!, jeez, I do, I really do.

> o Unfortunately I dont think we can avoid using data templates, in a
>   form or another, for repeated sections.
> 
> But it may just be a matter of taste and we should probably just agree
> to disagree ;-)

yep. I think we'll have to. If the origin option werent introduced and 
xforms had been left in the 1.0se state with respect to insert then I 
would have given up completely.

Jason.

Received on Wednesday, 8 November 2006 01:28:32 UTC