- From: Erik Bruchez <ebruchez@orbeon.com>
- Date: Fri, 24 Aug 2007 18:06:49 +0200
- To: public-forms@w3.org
I think that we are talking about different things here: * Being able to specify directly on a control whether, e.g., it is read-only, something like: <xf:input readonly="normalize-space(../first-name) = ''" ...> Of course, extend this to other properties. This is I think along the lines of the "simplification" we want to do for 1.2. This would be excellent in my opinion. The indirection through the model is often very heavy and hard to maintain, and it often doesn't bring much benefit. And I don't see a contradiction with having a concept of model with quite rich features, while allowing the user to specify more stuff in the UI. * Supporting local models within the UI, or within components used in the UI. This is to me more important from a perspective of reusability of parts of the UI, and I know that some implementators have looked at this already, for example in the context of XBL. At any rate, in both cases, that's good stuff to think about. -Erik Mark Seaborne wrote: > You know, I think you have hit upon something there. This discussion > had been leading me to think along similar lines. > > Models within models, within models, and so on as far as you need :-) > > All the best > > Mark > >> *** off-topic warning *** >> In last consequence the whole discussion for me seems to underline >> the wish of many XForms authors to take a more UI-centric approach on >> XForms authoring. The accepted need for something like XForms >> Transitional underlines this thesis. >> >> Being involved with XForms for years i'm lately more and more >> concerned about the complexity XForms grew into. - Though descriptive >> it's not really fun to understand, refactor or extend a complex form >> that you've written weeks ago. Mainly the indirections between >> controls and binds make it a lot harder to see the picture. >> UI-centric code in contrast can be read more or less sequentially. >> >> It's not that i'm promoting to move away from XForms principles >> developed so far (in contrast) but to offer an alternative that >> ideally can co-exist with (or at least be transformed into) XForms >> FULL and does not break with the idea of using a Model. >> >> Other MVC languages can give interesting inspiration on how to design >> this - e.g. Java Swing knows control-level models - each control has >> it's own micro model but manipulates that by using the same interface >> as the control would use to speak to the frame level model (and >> triggering same events). In XForms speak that would mean that every >> XForms control has its own micro model and communicate with the >> XForms model (if any) in a defined way. >> >> Sorry for interruption - think i needed to say that once ;) >> >> >> Regards, >> >> Joern >> >> >> Nick_Van_den_Bleeken@inventivegroup.com wrote: >>> Erik & all, >>> >>> I included my comments inline >>> >>> >>>> Nick & all, >>>> >>>> A few comments on Nick's issues below: >>>> >>>> > 4.4.11 The xforms-readonly Event and 4.4.12 The xforms-readwrite >>>> > Event >>>> >>>> > Is group not a valid target for the xforms-readonly and >>>> > xforms-readwrite events? >>>> >>>> It probably should IMO, if as a rule we adopt that every control with >>>> a single-node can be a target for UI events. The same would go for >>>> xforms:switch then, but not xforms:repeat, which does not have a >>>> single-node binding. >>>> >>>> > 6.1.2 The readonly Property >>>> >>>> > Previously section 6.1.2 The readonly Property[1] clearly stated >>>> > that "When evaluating to true, this model item property indicates >>>> > that the XForms Processor should not allow any changes to the bound >>>> > instance data node." And I know for certain that Chiba, the Firefox >>>> > extension,… block the setvalue action from changing read-only >>>> > content. I know that it is hard to enforce this if you provide >>>> > direct access to the DOM through script. But I don't think we should >>>> > sacrifice the nice separation in our MVC architecture, the model >>>> > needs to be the one that enforces the read-only property both to the >>>> > View (the UI) and the controller (the actions). I know that the >>>> > previous wording needs some tweaking because it doesn't say if a >>>> > submission is allowed to replace inside read-only content, and if it >>>> > isn't allowed what exception is dispatched. But it clearly states >>>> > that no changes are allowed, we should think twice before changing >>>> > this. It breaks backwards compatibility, is counter intuitive (at >>>> > least for me) and in my personal view breaks the principle that data >>>> > integrity is enforced by the model. If we really want a UI read-only >>>> > attribute it should live in the UI and be an attribute on the form >>>> > control and not on the binding in the model. >>>> >>>> I am not sure what to think of this, especially since I had never >>>> considered that xforms:setvalue should be prevented to change a >>>> read-only value. However I understand now, by reading the text more >>>> carefully, how Chiba and other implementations have decided to enforce >>>> this. >>>> >>>> This said, if *really* we want xforms:setvalue to honor the readonly >>>> MIP, *then* we need to specify that before running, if the recalculate >>>> flag is set, a recalculation is performed (and probably if the rebuild >>>> flag is set, rebuild should be performed as well before). Otherwise, >>>> the number of situations where the readonly property will be out of >>>> date will be quite large, and that would make the readonly constraint >>>> unreliable. >>>> >>>> (As a side note, and as I have said before, I don't like this type of >>>> unreliability, which gives form authors misplaced confidence, which is >>>> why we need to review completely our system of UI events, but that's a >>>> digression.) >>> I don't see it like that, it is well defined in the spec when >>> recalculations happen and you can see a sequence of actions inside >>> another action as a transaction. This allows for example changes to >>> the newly inserted nodes until the transaction is closed (read the >>> outermost action is terminated). As I heard this has been up for >>> debate numerous times in WG and it has be estabilished what the >>> correct behavior was : >>> - setvalue can't update a read-only element >>> - you can not insert or delete in a read-only node >>> - pre xforms 1.1 submission could replace readonly nodes, because >>> it replaced the instance (not the subtree) so you got a new instance >>> This also resulted in the clear text : "When evaluating to true, >>> this model item property indicates that the XForms Processor should >>> not allow any changes to the bound instance data node." The last >>> point about submission needs be revisted because we can now have the >>> result of a submission to be stored somewhere inside the instance. I >>> personally think that replacement should be allowed if the node that >>> you try to replace isn't read-only, it should be disallowed if the >>> node your try to replace is read-only. >>> >>>> On the other hand, my fear is that requiring that xforms:setvalue >>>> honor the flags can be extremely costly in long sequences of actions, >>>> as each setvalue itself will cause the recalcuate flag to be set. So a >>>> long sequence of setvalue will be hashed with recalculations. >>>> >>>> If existing implementations that implement this behavior do not set >>>> the recalculate flag, then IMO they are in error as the readonly MIP >>>> will be unreliable. >>>> >>>> In addition, assume you have a readonly node, say: >>>> >>>> <first-name/> >>>> >>>> <xforms:bind nodeset="first-name" readonly="true()"/> >>>> >>>> Now what if you xforms:delete that node: are you allowed to do so? >>>> What about deleting a parent element of <first-name/>? >>>> >>>> What then about inserting a new <first-name/> element? What about >>>> instance replacement upon submission, which now allows replacing a >>>> subtree and therefore is equivalent to xforms:insert/xforms:delete? >>>> What about (ouch) xforms:copy? >>>> >>>> I am trying to show here that things are not as simple as saying that >>>> setvalue just looks at the current readonly MIP before deciding what >>>> to do. >>>> >>>> In addition, I have to say that I have not had personally a practical >>>> use case for setvalue to behave this way, so I have a little bias >>>> against this functionality. >>>> >>>> In addition, allowing setvalue to, well, change a read-only value, >>>> does not appear to be as heretical as that: the readonly MIP is the >>>> only way we have to mark a control as read-only in the UI, and to >>>> prevent that control, temporarily or not, to write values to an >>>> instance node. This responds to an important use case. >>> I personally think that we need the ability to mark a form control >>> as read-only, but this is a new feature and something that is up for >>> discussion in XForms 1.2. You can also have a use case where two >>> inputs bind to the same data node, but one input needs to appear >>> read-only and the other one appearing read-write. >>> >>>> On the other hand, a form user cannot perform an xforms:setvalue >>>> action. He can only interact with the form through the UI. So in the >>>> end, while it would be maybe desirable in certain cases to protect the >>>> form author against certain mistakes, the form author has control over >>>> his source code anyway. >>>> >>>> And of course, enforcing this feature, besides the relative complexity >>>> and performance implications of a *correct* implementation, also >>>> prevents certains use cases. >>>> >>>> For example, say the form author wants to make a control read-only to >>>> present information retrieved from a database with a submission from >>>> being changed by a user who does not have the right to change that >>>> data: you will use the readonly MIP in that case. But the what if you >>>> want to update that data with the result from another submission? You >>>> may be prevented to do just that, or you will have to make the code >>>> much more complex by creating flags controlling the readonly MIP >>>> property, set that flag, modify the value with setvalue, and reset >>>> that flag. In the meanwhile, you hope that XForms processing will not >>>> allow that temporarily disabled read-only-ness of the associated >>>> control to show the control as read-write (this should be ok as this >>>> should happen only during a refresh). >>> This can be achieved by the 'new' UI read-only attribute. >>> >>> >>>> I am sure there are better use cases, but I just wanted to show that >>>> in certain situations, as a form author you would like the power to >>>> change instance data in the background, while you still want the user >>>> not to have write access to that data. >>>> >>>> All this said, it is important that we consider this topic and discuss >>>> it thoroughly. >>>> >>>> >>>> -Erik >>>> >>>> -- >>>> Orbeon Forms - Web Forms for the Enterprise Done the Right Way >>>> http://www.orbeon.com/ >>>> >>>> >>>> >>> Regards, >>> >>> Nick Van den Bleeken >>> >>> >>> >>> -------------------------------------------------- >>> Inventive Designers' Email Disclaimer: >>> >>> http://www.inventivedesigners.com/email-disclaimer >> > Mark Seaborne > Senior Standards Architect > PicoForms > web: http://www.picoforms.com > e-mail: mark.seaborne@picoforms.com > tel: +44 131 2080031 > mobile: +44 787 2180215 > > -- Orbeon Forms - Web Forms for the Enterprise Done the Right Way http://www.orbeon.com/
Received on Friday, 24 August 2007 16:07:03 UTC