Re: repeats

ok - having calmed down I realise that all is not lost in the long term, 
  I am just stuck until chiba implements the 1.1 insert features, or my 
clients are ready to use a clientside implementation (they are 
definitely not!)
to be fair, when I was first learning to use xforms I couldnt understand 
why there wasnt a prototype (or a way to set up a pseudo one) as it 
would have made the xforms-ready hack redundant for initially clearing 
nodes, and made everything a bit clearer. I certainly like that the 
option now exists but resent being forced to use it. But having now got 
used to the idea that I need to set my initial instance data to act as 
an effective prototype I can see that both options can work together 
without any conflict and without forcing a given form to carry a 
suitable prototype to match any loaded data. I havent really thought 
about it yet but I think at least this may lead to problems where a 
loaded prototype doesnt match loaded data for a given view so great care 
would need to be taken when updating/loading new data, especially if the 
same form is intended to handle subtly different datasets.

John Boyer wrote:
> 
> When you say "all this complexion in design", would you mind giving an 
> example or being more specific.

I know this was not directed at me but I'd like to add something. I 
think Xforms probably is more complex than it needs to be and more 
restrictive than it should be, but generally I have liked the track its 
taken.
Complexity comes particularly for me because I often cant do things I 
expect i could - like to simply use toggle based on instance data eg: 
<xf:toggle id="toggle-something" xf:case="bind or xpath expression" 
defaultcase="someknowncase" /> - or to be able to dynamically set a bind 
  in a view control(that would enable proper treewalking i think).
This must be the case for most people because there are lots of 
"techniques" that get listed in order to workaround problems and acheive 
basic goals and many of them are quite cryptic.
I must admit that I find it difficult to really fault 1.1 because I am 
just not very familiar with actually using it (I do think that the 
'insert for the zero case does nothing' should be amended though).
These are not necessarily "complexity in design" issues, but are some 
thoughts on what makes forms complex to create and to maintain.
Generally I find it very difficult to reuse code with xforms - every 
time I choose to use a switch I end up reproducing some code for each 
case. It would be nice if there was a way to include/call sub functions 
without needing to resort to generating/trapping events which gets 
really complicated fast. You always need to be aware of everything at 
once when you start playing with events so I have avoided using them as 
much as possible.
I truly cringe everytime I have to enter an xpath inside the 'at' clause 
of an insert etc - why cant I select an existing bind reference? after 
all I already typed that path once. perhaps I'm looking at binds all 
wrong, but I thought they were intended to help isolate the model from 
the view so that the same view could be used with different models and 
schemas as long as the binds were compatible. I also thought binds were 
there to act as prototypes in the case where no data exists at all. at 
the very least I ought to be able to leverage the inherent xpath 
represented by a bind everywhere possible. This complicates things 
because the xpath varies depending on the current context, but a bind is 
a bind - so changes to instance structure typically for me require 
changes throughout the view as well.
I recently saw a form generated via the ibm form builder tool thingo - 
it was a single form a mile long for tax calculation. I dont know how it 
could be reasonably maintained or worked on by multiple people, and 
looking at the actual code - well u just dont want to think about it.

> This is where your message gets confusing to me.  This is because it is 
> signficantly *easier* for the
> implementer to obtain the insert node by simply obtaining the last node 
> of its nodeset or, 1.1, from
> the node returned by the origin expression.  

These both seem much the same to me. I thought from an implementors 
perspective that for the case of "using a prototype from initial 
instance data" you'd just copy the initial instance data into memory 
somewhere so you always have a reference -so you are basically in the 
same position as 1.1 - if the fine folks at chiba could manage it then 
why not everyone else? It took the XSLT implementors ages to get fully 
working processors but I never noticed reasonable spec features alter to 
suit implementors.

> The original idea of taking an initial instance prototype proved 
> challenging to implement.  For
> example, if your insert nodeset results in empty nodeset, you have no 
> nodes, right? Which means
> you have no starting point to figure out how to get from a nodeset in 
> live data to a node in the
> prototypical data.  It gets more fun when you try to figure out the 
> prototypical node to use when
> you're dealing with an inner repeat on the K^th row of an outer repeat.  

sure - but far from impossible. I agree that it would be nearly 
impossible if Xforms allowed the freedom it should to create and manage 
arbitrary XML in the model, but it doesn't. there is no scope for 
generating random child elements and attributes at runtime, so tracking 
the original nodeset and the actual instance ought not be too difficult, 
and if it turns out that a parent node (or perhaps better, no 
identifiable ancestor) is missing then in that case fine -do nothing on 
an insert because that makes sense, but to change the spec to read 
'insert does nothing when all the nodes are gone' is totally 
counterproductive and really does add complexity.

> And then people started sending prepopulation data,e.g. here's where you 
> left your shopping cart.
> When that happened, new shopping cart items were initialized based on 
> the last item in the cart
> because that was the initial data referenced by the src or put in place 
> by the jsp or what have you.

ok - but if people are dynamically creating xforms (even changing 
instance data via jsp etc is actually rewriting your form!) then they 
need to expect that because in effect they are creating forms with 
errors - but if you are using an xform in a way that it was presumably 
intended then your initial form remains constant - prototype in place - 
and any data loaded by the form itself doesn't cause any grief at all.

> So, it worked for toy forms, but not for generalized web applications. 
>  We fixed in in 1.0 to reflect
> A) what implementers were doing anyway, and B) in favor of at least 
> being *able* to create
> correct applications.  We fixed it further in 1.1 to make it easier for 
> the form author to express
> the correct applications.

I'm afraid I have to disagree. I really do consider Xforms 1.0 totally 
broken in this respect since it is nigh on impossible to use the 
insert/delete/repeat cycle for anything practical. It is now ONLY useful 
for toy forms and forms that dont attempt to add/remove data. I'd argue 
that "correct" but useless applications ought not be a strong focus. 
Probably the primary reason I choose to use xforms over anything else is 
to be able to easily manage forms that represent datasets that change 
size. 1.1 makes it again possible to build practical forms, although 
necessarily slightly longer forms.

> But our focus is on designing the language so that the features don't 
> break when they are used
> in any but the most rigid and contained scenarios.

I had thought your focus would be on creating an elegant forms platform 
first, and then if something does turn out to be impossible or 
impractical to implement then it should be addressed?

I do think to a large extent you have very much succeeded in creating a 
useful platform with xforms, please dont give up the search.

Cheers
Jason.

Received on Saturday, 4 November 2006 00:44:01 UTC