- From: Lars Windauer <lars.windauer@betterform.de>
- Date: Wed, 21 Nov 2012 11:43:11 +0100
- To: Erik Bruchez <erik@bruchez.org>, <public-forms@w3.org>
- CC: "public-xformsusers@w3.org" <public-xformsusers@w3.org>
Eric, I see that there are still issues with load-embed. But there are issues with other XForms techniques / controls as well and they are in the recommendation (xf:range). I do think that most of the open questions could be solved quickly. At betterFORM we have flags to control if CSS and JS of the subforms should be included or not, the only real problem in my point of view are ID clashes. Id clashes are a real (but more theoretical) issue, but in practice I never had to deal with them at all. It is quite easy for XForms authors to avoid them and there are far more complex issues in XForms an author has to take care of writing XForms. In the end it's the same like having duplicate ids in a single form, which is as likely if you have to move all your (sub-)forms in a single big form. I'm writing this because my daily work is to design and implement XForms based enterprise applications (including forms validated by MBs of schema data, XML instances with much more than 10.000 LoC..) and I don't see how to do this without load-embed or at least some kind of analogue mechanism to dynamically load forms into forms. Personally I can live without having load-embed in the XForms recommendation since it is already available as a betterFORM extension. Like all our implementations do have custom extensions. But as said before, I really do think that "load-embed" takes XForms a big step forward regarding enterprise applications and that the XForms community should focus much more on issues like this (e.q. model two model communication, interoperability of XForms and XQuery and other enterprise questions) since this is an area where XForms is the answer to insufficient HTML(5) forms. If I remember correctly XForms is supposed to be the successor of HTML forms, not it's straggler. Cheers Lars __ betterFORM; Lars Windauer Hohenzollerndamm 7 10717 Berlin fon: +49(0)30 83 22 55 50 fax: +49(0)30 83 22 55 04 mobile: +49(0)17 05 87 13 00 skype: windauer twitter: windauer lars.windauer@betterform.de www.betterform.de Sitz: Berlin Inhaber: Lars Windauer Steuer-Nr.: 24/593/00349 Ust-IdNr.: DE262104908 On 21.11.12 07:05, "Erik Bruchez" <erik@bruchez.org> wrote: >All, > >The XForms WG has an editorial meeting this week and we have been >discussing the proposed XForms 2.0 sub-forms feature with >`show="embed"`. > >There are issues with specifying this feature properly, as discussed >in the past, in particular in this thread [1]. In short, sub-forms >raise issues related to isolation, such as visibility of ids, event >propagation, and applicability of CSS styles. > >One possibility would be to completely ignore these issues, and just >specify plain inclusions (for which there are clearly valid use >cases). However the working group thinks that this falls a bit short >of a solid "sub-forms" feature. > >There is some pretty exciting work going in the HTML world with Web >Components [2], and in particular the Shadow DOM. [3] These efforts >are essentially a continuation of the ideas found in XBL (without the >XML part) and aim at addressing the need for a component model. Taking >care of isolation is a central part of this work. > >While we are not discussing the inclusion of a full component model >with the sub-forms feature, trying to address any of the >isolation-related issues of sub-forms would probably end up >overlapping with the Web Components/Shadow DOM work, which we clearly >don't want to do. > >So the working group's current proposal is that it is better to defer >this feature to a further version of XForms. Then it could possibly >leverage the Web Components/Shadow DOM efforts. > >Thoughts welcome. > >-Erik > >[1] >http://lists.w3.org/Archives/Public/public-xformsusers/2012Jun/0015.html >[2] http://www.w3.org/TR/2012/WD-components-intro-20120522/ >[3] >http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html > >
Received on Wednesday, 21 November 2012 10:43:42 UTC