Re: Sub-forms feature

Nick,

first of all - how nice we're having this discussion. It's great that 
the WG is openly discussing such things.

Lars already mentioned the most prominent points (which i 100% agree 
with) and i'll try to get not too redundant here but there might some 
other aspects...

Am 21.11.12 12:41, schrieb Nick Van den Bleeken:
> 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).

Cause it touches various aspects of the problem i'd like to raise the 
point if the understanding of what a subform actually is is probably one 
cause for our different view on the topic. What i mean by that:
do we want a subform mechanism or a component model? IMO this is 
something (somewhat overlapping) but completely different.

A subform as we understand it is a form that ideally even works as a 
standalone form if called directly from the browsers location bar. So 
it's self-contained with a Model and UI and be considered to completely 
handle a certain aspect (data entity) of a bigger application. It 
applies the constraints to this segment and takes responsibility to 
ensure consistency of the data it manages.

It's currently *not* a mechanism to handle components if understood as 
building blocks for a form. So it handles a different level of 
granilarity. The use cases sometimes come even close to those of 
components which is where the deviding line blurs a bit.

If understood 'our way' it already has a big impact on what you can do 
with XForms in building applications but it's not currently intended to 
handle components of UI markup for instance.

With component models you normally associate things like encapsulation. 
This concept IMO not necessarily holds (or needs to be true) for 
subforms in the same manner.

When we talk about embedding we understand that as adding some DOM (the 
subform DOM) into another DOM (the host DOM). IFAIK it's still a dream 
to encapsulate the embedded DOM within the host DOM and events will get 
magically be stopped and CSS rules will stop matching. The browser 
technology is still some steps away of offering this (out of the box) if 
don't miss something. But you'll definitely need such things to build a 
full component model.

But putting both (subforms and components) into one bucket probably 
leads to shoting the wrong target. Subforms even if not encapsulated in 
a component-like manner already give us:
- modularization
- maintainability
- improved performance
- scalability
- a way to devide responsibilities between a set of models

While components try to address a ideally broad range of use cases 
subforms do not necessarily do so. Our most common use case is to 
support and implement complex XML document editors (think of HL7, AIXM, 
DITA or other complex XML-based standards). This kind of 'document 
fragment editors' often need to encapsulate complex logic and/or 
constraints and they contain certain data structures. A subform here 
'encapsulates' complex, domain-specific logic and is not usable in 
another context but gives us a chance to support complex document 
editors and do so in manageable, performant and modular way.

This of course does not say that a component model for XForms wouldn't 
be a good thing just a different.

But of course all these issues can also be overcome with the existing 
mechanisms by applying some architecture to your application.


>
> 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?
Lars mentioned that i think... we have a custom child element to specify 
if to import the styles in a subform or not. Same applies to JS.

CSS 'encapsulation' can be handled by using some conventions e.g. by 
using the respective subform id for avoid rules matching clashes with 
the host document styles:

#mySubformId [some matcher]{ myrules }

> • maybe you want to be able to style the subform from the outer form?
easily possible as matching rules in the hosts CSS will match too when 
the embedded DOM is imported.
> • event propagation
Confessed that this might happen for certain events/situations (e.g. 
focus events) but even in more than 3 years of experience with subforms 
we have *very rarely* hit that problem and it can even be overcome with 
already existing feature (XML Events - observers, targetid, capturing 
and cancellation).

It certainly would be good to give that some extra consideration though 
and i can imagine that simply scoping xml events dispatched from a 
processor always in the scope of their respective model could resolve 
those issues without the magic of shadow DOMs and so on.

> • 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
see above - passing the originator context model id into xml events 
would give us the opportunity to fire handlers or not.

And it's really an exgaggeration to say 'it's likely' - i can't remember 
a single case where we ran into that problem.

> • do we support sending events to arbitrary elements inside de sub-form?
Exchanging events between host and subform is IMO an important feature 
for communicating between models within a page. We have another 
extension of the xf:dispatch action esp. targetted for the use with 
subforms. It allows to send arbitrary params along with the event and is 
a IMO clean way to pass data between models (an essential feature)

<xf:dispatch name="myEvent">
   <xf:param name="myParam1" value="xpathexpr"/>
....

*However* this does not necessarily means that we need dispatching of 
events *inside* or into the subform. It's sufficient to have the root 
node of a subform (which we know by id) to dispatch event to.


> • can we send events from inside the sub-form to everywhere in the outer
> form?
By 'model-scoping' events we have the choice...
> • how does embedding/referring host language depended resources
> (javascript,…) behave? They probably should only effect the subform.
Again i think this hard to achieve with current browser technology (and 
if you have to deliver cross-browser solutions today) but can be 
addressed in quite the same way as in CSS by applying certain good 
practices.

It becomes common knowledge in the JS world that it's probably a good 
idea not to pollute the global namespace and use a package loader like 
require.js or similar. Using such tools solves the problem by avoiding 
clashes between host and subform javascript - btw, a 'detail' you have 
to watch in any serious web app (XForms or not).

We just load subform javascript when it's embedded if the load action 
says so and also unload it again when the subform is unloaded. This 
perfectly does the job for us.

> • How to embed the same sub-form multiple times (inside and outside a
> repeat)
Of course the most challenging part as of the id problem and i have to 
confess that we still not have a better way than to say: 'watch id 
collisions and avoid them'. Again when coding in today's javascript 
world this is nothing new to developers. When hacking ajax apps which 
create UI dynamically you'll have the same problem potentially.

>
> 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.
Agreed.
>
> 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.
Again agreed. But i'd rather prefer not to wait for e.g. shadow DOMs 
being available everywhere and to broaden the scope for XForms 
applicability today.


Thanks for listening and apologies for the long and probably redundant read.

Best regards,

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

Received on Wednesday, 21 November 2012 21:26:03 UTC