Re: Proposal on @for and @lang on meta-controls


Thanks - I was beginning to think this had slipped into oblivion.

You bring up some very good points. I'll try to address them inline.


1. "When the @for binding is in place, then the evaluative context of the
> meta-control would no longer be the context of it's container, but instead
> would be the context of the bound control "
> This would be very confusing. XPath scoping should remain lexical.

The problem with the lexical scoping occurs when you have a @for binding in
a label where the label is outside a repeat and the control is within the
repeat (which would be the case for tabular content, for instance). There
are multiple instances of the control for a given id, and the correct
instance would be the one that has the current index. Unfortunately, because
the @for is outside of the repeat, if it wasn't in the control's context
then it would have no way of knowing the specific index of that control.
That's why the label would have to be in the control's context.

> 2. <xf:for> element
> I am not convinced that the use case is very compelling for this.
> This said, if there are compelling use cases, then as usual I would rather
> favor an AVT approach for all dynamic attributes:
> <xf:label for="{controlIdentifierExpr}">
> Or generalize the idea that you can either use an AVT or a child element
> with the same name and keep this philosophy throughout XForms.

The use of the <for> element is simply to provide consistency with the model
that is currently in 1.1, where dynamic properties are assigned via a child
element with the appropriate value label. IF AVT was supported, that would
be preferable, obviously, but as it's not, we seem to be moving towards a
static attribute/dynamic element model.

> 3. @language attribute
> It's a bit confusing to have both a @lang (known in HTML) and a @language
> attribute. Can't we just use @lang?
> Also, in XForms models introduce some issues as they don't follow lexical
> scoping: top-level models are typically "next to each other", but controls
> associated with those models are not descendants of the xf:model element,
> obviously.
> On the other hand, something like @xml:lang is supposed to apply following
> the structure of the XML document.
> It might be better to just use @lang, not apply language on a model basis,
> but on the host language or XForms grouping elements, e.g.:
> <html lang="es">
>    applies to the whole document unless overridden on descendant elements
> <group lang="en">
>    applies to the whole subtree unless overridden on descendant elements 
> etc.
> If you are going to have multiple regions on a page binding to multiple
> models, you will typically do this anyway:
> <group model="model1">
> So you can as well do:
> <group model="model1" lang="zh">
> In our implementation BTW we already support using <html lang="">, even
> with an AVT as value, which allows dynamically changing some i18n features.

I chose @language as the attribute to match on models to indicate that this
was essentially the language to match, rather than the language that was
matching, but that's not a strong argument. My thinking was that you would
in fact have a cascading of languages:

<html xml:lang="en-us">
            <model lang="fr">
            <label lang="en-us">..</lang>

In this case, if @xml:lang was present on the HTML element, then it would
hold throughout. If it wasn't, but the corresponding attribute was on the
model, then the model would overrule. I don't feel strongly about this
either way, just thinking about potential cases where the host language
isn't html and doesn't support @xml:lang. I do agree that if the language is
defined at the document level, then it should override everything else.

> 4. @for on xf:model
> Here you don't make a case for label/@for. What would this do? I understand
> the case for help/@for, but then why not:
> <group>
>   <help></help>
> I think it would be better to keep associating LHHA elements to user
> interface controls, again unless a strong use case shows up.

The primary use case I can see for label/@for on models is for different
language support. You would have different labels associated with different
languages that would display based upon  the language that was selected at
the document (or model) level. This is, admittedly, a fairly weak case; it's
most relevant use case would be one where the document could be changed by
code (or by an AVT) and all of the relevant content for all languages would
still be contained on the page. This makes the most sense in those
situations where you're dealing with a client side only solution, as a
server side solution would likely just re-render the page with the new label


Received on Wednesday, 16 February 2011 04:03:12 UTC