Re: Need for a 'global instance' function [was Re: i18n, componentized forms and multiple models]

Mark,

I think you make a good case for encapsulation in your other post, and 
that should help many other XForms users design similar types of 
encapsulation.

My only attempt at using several models for modularity in a fairly large 
form was not very successful, mainly because of difficulties handling 
the current context in the controls (xforms:variable would have been 
perfect to solve that problem).

I did think about a function to get an instance from any model (as 
opposed to an instance in the "current" model, as the standard 
instance() function works), but so far we have resisted implementing it 
since the "ideal" way of using multiple models didn't seem to be that 
clear. It is getting clearer now I think.

But wouldn't allowing this function to be called from a model encourage 
breaking encapsulation? Wouldn't events be enough as a mechanism to 
communicate between models?

For use within controls I don't disagree though. Maybe the instance() 
function could simply take an optional second parameter, that would 
indicate if the search for instances should be global:

   instance('my-instance', true())

Alternatively, it could take the id the model to search:

   instance('my-instance', 'my-model')

-Erik

Mark Birbeck wrote:
> 
> Steven/Erik,
> 
> Just so that we don't lose one of Andrew's key points though, he does
> rightly flag up that there is no way in XForms to get values from one
> model into calculations in another model, or to use another model to
> provide template nodes for copying via xf:insert, and so on. There is
> no reason not to allow this, and in fact there are many, many
> situations where we positively need it.
> 
> I would say that the main justification *for* is that once you get to
> forms of a certain complexity they are just far too difficult to build
> and maintain by hand. At this point you need to generate them, and to
> do that you will invariably want to use models to provide
> encapsulation. As it happens, even if your forms aren't that complex,
> if you want to reuse features across many forms, it makes sense to use
> multiple models.
> 
> For a fuller description of using models to provide encapsulation and
> reuse, see my previous post at the end of the following thread, on
> "Use cases for multiple models":
> 
>  http://lists.w3.org/Archives/Public/www-forms/2006Jul/0014.html
> 
> By the way, I'm not saying that we should allow cross-model
> dependencies... well, I'm not saying that today, at least ;). In
> formsPlayer we provide a globalInstance() function that allows you to
> make a reference to an instance that is in any model, but as with
> calling the now() function, it's not dynamic, and so the author needs
> to be aware that they may need to use rebuild in certain situations.
> But in simple situations like the one we have here, where you just
> want to use a model to hold the user's preferences which are in turn
> used for submissions, then rebuild is simply not a problem, and
> globalInstance can be used straightforwardly.
> 
> Regards,
> 
> Mark
> 
> 
> On 24/07/06, Erik Bruchez <ebruchez@orbeon.com> wrote:
>>
>> Andrew,
>>
>>  > I'm testing the form on both Orbeon's Presentation Server (current
>>  > release) along with Mozilla XForms 0.5 (0.6 said it had an invalid
>>  > checksum and wouldn't install for me) in case it matters.  I don't
>>  > really think it does, because one of the points in Dubinko's book
>>  > was "options for cross-model communication are limited."
>>  > Unfortunately, I can't find much on what those options are.  I
>>  > suppose I could resort to using some JavaScript to solve the
>>  > problem, but I would really rather not do it that way.
>>
>> If you download the latest OPS nightly build [1], go to the DMV Forms
>> example, and open a form, you will see there what I think is a really
>> cool illustration of i18n with a dropdown allowing you to switch at
>> runtime between English and French resources (he he, this is not
>> something you see often, to say the least, and XForms makes it a
>> breeze to achieve).
>>
>> As suggested by others, simply load your initial resources into an
>> instance (alternatively, you can run a submission upon xforms-ready):
>>
>>    <xforms:instance id="resources-instance" src="resources_en.xml"/>
>>
>> There is another instance holding the current language:
>>
>>    <xforms:instance id="language-instance">
>>        <language xmlns="">en</language>
>>    </xforms:instance>
>>
>> There is an xforms:select1 to change the language:
>>
>>    <xforms:select1 ref="instance('language-instance')">
>>        <xforms:label
>> ref="instance('resources-instance')/labels/language-choice"/>
>>        <xforms:item>
>>            <xforms:label>en</xforms:label>
>>            <xforms:value>en</xforms:value>
>>        </xforms:item>
>>        <xforms:item>
>>            <xforms:label>fr</xforms:label>
>>            <xforms:value>fr</xforms:value>
>>        </xforms:item>
>>        <xforms:send ev:event="xforms-value-changed"
>> submission="update-language-submission"/>
>>    </xforms:select1>
>>
>> which runs a submision that updates the resources:
>>
>>    <xforms:submission id="update-language-submission"
>> ref="instance('language-instance')"
>>            action="/forms/service/resources/{.}" validate="false"
>>            method="get" replace="instance" 
>> instance="resources-instance"/>
>>
>> All the internationalized resources in the page are referred to with
>> things like:
>>
>>    <xforms:output ref="instance('control-instance')/message"/>
>>    <xforms:label
>> ref="instance('resources-instance')/labels/language-choice"/>
>>
>> This is much more flexible than to hardcode xml:lang in the page, and
>> it works like a charm.
>>
>> I hope this helps,
>>
>> -Erik
>>
>> [1] http://forge.objectweb.org/nightlybuilds/ops/ops/
>>
>> -- 
>> Orbeon - XForms Everywhere:
>> http://www.orbeon.com/blog/
>>
>>
>>
> 
> 


-- 
Orbeon - XForms Everywhere:
http://www.orbeon.com/blog/

Received on Monday, 24 July 2006 22:06:26 UTC