Re: Sub-forms feature

Lars,

Thank you for the reply. Scared was the wrong word I guess ;) I agree with you that XForms need a feature like embedded forms. But I'm been using an XForms component approach for years now. And really love it, and can't live without it ;). It supports embedding the same component multiple times, support insertion points (you can create tab components, …), strong encapsulation, communication with events but also with bindings.

The AVTs, variables, xpath 2.0 (repeat over sequences), property child of dispatch and json makes creating forms in XForms 2.0 a lot easier for XForm authors. Not having the embedded forms functionality is a pity, but something we can do for XForms 2.1 (static inclusion can already be done with XInclude or alike). I think we should embrace the release early, release often strategy. Therefore I think we should try to finish XForms 2.0 as soon as possible, and start working on the next iteration, which should definitely include embedded forms.

Kind regards,

Nick Van den Bleeken
R&D Manager

Phone: +32 3 425 41 02
Office fax: +32 3 821 01 71
nick.van.den.bleeken@inventivegroup.com<mailto:nick.van.den.bleeken@inventivegroup.com>
www.inventivedesigners.com


[cid:image001.png@01CBF2F8.1DA19110][cid:image002.png@01CBF2F8.1DA19110][cid:image003.png@01CBF2F8.1DA19110]

On 21 Nov 2012, at 13:29, Lars Windauer <lars.windauer@betterform.de<mailto:lars.windauer@betterform.de>> wrote:

Nick

Sorry if I might get a little bit sarcastic in this mail, I really do appreciate a lot what you guys at the Forms WG are doing and I'm grateful for it. But you are writing that your are "scared that everybody in the near future wants nicely encapsulated sub-forms in XForms ..", sorry, this is nothing to be scared of but the best thing that could happen!. Just imagine, everyone want's XForms, people getting excited about XForms…. haven't have that for quite a while, what a big step forward.

And do we really have to support everything in first place, what's the problem about having a very small loead-embed feature set (implementors "must" support) at the beginning (no repeated subforms, no inclusion of JavaScript / CSS) and other features declared as "should"…. I think it would not be the first time this happens.

My experience with load-embed is, that Joern and I tried to solve all problems regarding load-embed at once and in theory. The result was that we had to give up for the same reasons you mention here. But a week later we focused on what we really do need in our projects and left the rest aside and it worked out great. And as mentioned in my last mail, I have not written a single XForms application in the last three years without using load-embed. And the funny things, all these features we had in mind load-embed should support as well, they were never needed until today, there was always an elegant workaround. And by the way, utilizing load-embed in various projects without changing the implementation over more than three years makes it kind of future proof for me..

I can't say it often enough, for me it's not about if "load-embed" is in the recommendation or not but about if I do think that XForms is the right choice to build XML based enterprise(!) applications.

Kind regards

Lars



I also definitely see the value of form embed, even more for custom components (in which you can define insertion points e.g.: for things like tab controls).

But I do think that if we specify something in the spec, we need to have a clear interoperable answer to all the questions:
•  styling
• the styling of the subform should not interfere the styling of the outer form?
• maybe you want to be able to style the subform from the outer form?
• event propagation
• it is likely that if the events in the subform start from the root of the outer form, the outer form starts to behave unexpected
• do we support sending events to arbitrary elements inside de sub-form?
• can we send events from inside the sub-form to everywhere in the outer form?
• how does embedding/referring host language depended resources (javascript,…) behave? They probably should only effect the subform.
• How to embed the same sub-form multiple times (inside and outside a repeat)

I know that if you are the implementor of a solution of embedded forms you know the ins-and-outs of the feature and know how everything behaves, but if you're a plain XForms author the behaviour should also make sense and it should be future proof.

I'm really scared that everybody in the near future wants nicely encapsulated sub-forms in XForms with an *easy* way to communicate from and to the subform (events, bindings, …), the current proposal will prevent us from specifying something like this. One of the main reasons in my opinion, that we are currently hesitated to define a nicely encapsulated sub-form model, is that it is damn hard to implement in one of the main host-languages of XForms, but this is changing.

Kind regards,

Nick Van den Bleeken
R&D Manager

Phone: +32 3 425 41 02
Office fax: +32 3 821 01 71
nick.van.den.bleeken@inventivegroup.com<mailto:nick.van.den.bleeken@inventivegroup.com>
www.inventivedesigners.com<http://www.inventivedesigners.com>


<image001.png><image002.png><image003.png>

On 21 Nov 2012, at 11:43, Lars Windauer <lars.windauer@betterform.de<mailto:lars.windauer@betterform.de>> wrote:

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<mailto:lars.windauer@betterform.de>
www.betterform.de<http://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<mailto: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






--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



________________________________

Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer

--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.
<image001.png><image002.png><image003.png>


________________________________

Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer