The idea is that any attribute xpath="foo:/" is implicitly really
this: xpath="global:foo:/".
We'd introduce the "global:" so that the idiom could be made explicit.
Then, in the first release, your example would be legal, but would
really mean:
<dataset name="foo" id="foo"/>
<!-- elsewhere -->
<datapointer xpath="global:foo:/"/>
In the next release, perhaps, it would still be legal but would
trigger a compiler warning.
Then in a final release, it would no longer be legal. You'd have to
write the explicit form.
This introduces some inconvenience for folks used to using global
datasets, but the benefit would be that there'd be more symmetry
between local and global datasets. I think the learnability would be
better too, especially with a more data-driven revision of the
components.
I'm not too attached to the idea of making the "local:" axis the
default. Quite possibly it would be better to require that they both
be explicit.
jim
On May 1, 2006, at 2:54 PM, Adam Wolff wrote:
> do you want to change this?
>
> <dataset name="foo"
> <!-- elsewhere -->
> <datapaointer xpath="foo:/"/>
>
> If not, you need someplace (even hidden) where parsed xpaths can
> look for
> named datasets.
>
> A
>
> On May 1, Jim Grandy wrote:
>
>> Yes, it would be an incompatible change. We could deprecate
>> implicit-global in
>> 4.0 and either remove or switch the default in a later release.
>>
>> What do you think of the proposal otherwise? Should we write it up
>> more
>> formally?
>>
>> On May 1, 2006, at 1:56 PM, Henry Minsky wrote:
>>
>>> Swapping the default for the scope
>>> of the dataset name in the xpath query from global to local would
>>> be a pretty incompatible change in terms of existing
>>> code, I dunno if that would be a
>>> 4.0 kind of thing or not.
>>>
>>>
>>>
>>> On 5/1/06, John Sundman <[EMAIL PROTECTED]> wrote:
>>> OK.
>>>
>>> if this is going into 3.3 I need to get right on it.
>>>
>>> Just to be sure I understand this, can I see some examples please?
>>>
>>> jrs
>>>
>>> On May 1, 2006, at 3:58 PM, Jim Grandy wrote:
>>>
>>>> I'd be in favor of the following:
>>>>
>>>> - add a 'global:' axis to match the 'local:' axis
>>>>
>>>> - force use of @id attribute for global datasets -- that is, don't
>>>> register in global/canvas namespace at all unless @id is given
>>>>
>>>> We could add the 'global:' axis in 3.3 with declaration without @id
>>>> deprecated in that release, and then require @id for global
>>>> datasets
>>>> in 4.0. We'd also make 'global:' the default in 3.3, and
>>>> 'local:' (or
>>>> neither) the default in 4.0.
>>>>
>>>> I think this would be the cleanest and simplest -- @id is how you
>>>> namebind in global namespaace, period. Just like HTML/CSS. Also,
>>>> making 'local:' axis the default would match our move in the
>>>> components to more data-driven design -- local datasets should
>>>> be more
>>>> common in 4.0 than global datasets.
>>>>
>>>> I haven't thought deeply about the compat issues here, but I think
>>>> this is pretty straightforward.
>>>>
>>>> jim
>>>>
>>>>
>>>> On May 1, 2006, at 9:59 AM, Henry Minsky wrote:
>>>>
>>>>> Tucker asked at one point if we could cut down the number of
>>>>> different places
>>>>> we put in a pointer to a dataset.
>>>>>
>>>>> We've got these three in the LzDataset.setName method:
>>>>>
>>>>> if ( this.oncanvas ){
>>>>> global[ name ] = this;
>>>>> canvas[ name ] = this;
>>>>> } else {
>>>>> // it's local - add the parent's UID
>>>>> name = this.parent.getUID() + '.' + name;
>>>>> }
>>>>>
>>>>> canvas.datasets[name] = this;
>>>>>
>>>>> Would this be a good time to clean this up a little and pick
>>>>> one (or
>>>>> two) of the these choices?
>>>>>
>>>>>
>>>>> --
>>>>> Henry Minsky
>>>>> Software Architect
>>>>> [EMAIL PROTECTED]
>>>>>
>>>>> _______________________________________________
>>>>> Laszlo-dev mailing list
>>>>> [email protected]
>>>>> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
>>>>
>>>> _______________________________________________
>>>> Laszlo-dev mailing list
>>>> [email protected]
>>>> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
>>>
>>>
>>>
>>>
>>> --
>>> Henry Minsky
>>> Software Architect
>>> [EMAIL PROTECTED]
>>>
>>
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
