Re: repeats

 >> And then, upon xforms-ready, override that instance with the
 >> document you load from the database.
 >
 > which you are doing anyway (loading the new data I mean).

Yes in this particular use case, and I agree that it is a common use
case. But you may have other use cases where you want to allow the
user to manipulate data with insertions and deletions without loading
external data.

 > yep - so we are at square 1 - exactly the same as the previous 1.0
 > example. you have defined everything you need in your form - just as
 > you have in 1.0 - zero difference so far.

True. Which doesn't go against the 1.1 solution either, you realize!

 >> <xforms:insert context="instance('employees')" nodeset="employee"
 >>                origin="instance('employee-template')"/>
 >
 > yep - so now you need to know what node you are copying from -
 > previously it was inherent and impossible to copy from the wrong
 > node.

I don't know why I would copy from the wrong node. Sure you can make a
mistake. But on the other hand I make it very explicit that I want to
insert a new "employee" at that spot.

 > but you can always see the initial state in your xform with 1.0 just
 > as you can in your 1.1 variation. they are identical, but you have
 > to manually assign the origin for 1.1

Which I personally don't see as a drawback.

 >> <xforms:instance id="employees-template">
 >>   <employees>
 >>     <employee>
 >>       <first-name/>
 >>       <last-name/>
 >>     </employee>
 >>   </employees
 >> </xforms:instance>
 >
 > now we are exactly at 1.0 - if you do this as your instance data in
 > 1.0 you never have any trouble and you also never have to specify
 > origin nodes and potentially all those extra binds (if you choose to
 > use them)

I consider using @origin as a benefit, because it is more
explicit. Also, if you have have an "employee" type that is reused in
several places in your document, and then you can get by with a single
template for that employee type.

 > plus any binds to employees-template + hopefully working lazy binds
 > to instance employees (or else we need to duplicate our instance
 > employees-template in instance employees just to use binds for that
 > too)

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

 > 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.

 > 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.

I believe the 1.1 approach is more straightforward and I very much
prefer the fact that it only deals with the current content of the
instances and the fact that you are explicitly pointing to the data to
be inserted.

 > Unless an instance has nothing directly interested in it (via binds,
 > controls etc) then copying arbitrary stuff to it doesnt get you any
 > further than insert+setvalue I dont think its really any clearer and
 > it will certainly make building xforms with all the appropriate new
 > origin/target linkages on the fly more complex

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.

 > 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 ;-)

 > I read somewhere once that it takes an average programmer an average
 > 1 hour to fully debug and document every 10 lines of code,
 > irrespective of the language. So I've always thought that the more
 > you can get done in one line, the less time it takes to complete a
 > project. I have no idea if this is true however ;-) but it seems
 > about right to me.

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.

 > recursion would be bad, but you could allow the xforms processor to
 > default to the minimal insertion, allow it to be happy about ignoring
 > binds that dont exist (say to an attribute that wasnt initially created)
 > and to be happy to add them as required by form useage.
 > My point was only that there is now triple redundancy in data
 > definition. The instance (potentially but not mandatory), the new
 > prototype, plus any schema if used. I'm not wild about schema's but if
 > the problem is rooted in the allowed data definition then it seems a
 > viable solution.

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.

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.

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.

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

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.

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 ;-)

-Erik

-- 
Orbeon Forms - XForms Everywhere
http://www.orbeon.com/blog/

Received on Tuesday, 7 November 2006 13:58:50 UTC