On 12/18/2009 04:47 PM, Jerome Velociter wrote:
> On 12/18/09 4:39 PM, Sergiu Dumitriu wrote:
>> On 12/18/2009 12:39 PM, Marius Dumitru Florea wrote:
>>
>>> Jerome Velociter wrote:
>>>
>>>> +0.5 to add "currentPage", since it's obviously missing with regard to
>>>> the other current* APIs.
>>>>
>>>> Now in the future I think we should define cleaner APIs for retrieving
>>>> infos about the model.
>>>> I propose that we wait for the discussion about new Java APIs of
>>>> xwiki-model to be a bit more advanced, then based on that see what's the
>>>> good way to have this in JS.
>>>>
>>> I fill the same way. The JavaScript API should be more object oriented
>>> (e.g. have some of the objects available in velocity context, like $doc,
>>> "available" also in the JavaScript context, in a XWiki namespace to
>>> avoid collisions). For now, the currentPage information needs to be
>>> added to the XWiki object.
>>>
>>>
>> +1 for having a JS clone of the Java model after the Java model is close
>> to being finalized.
>>
>
> Should it be an exact clone ?

Not really. The current model has much too much behavior in it. I'd like 
the new model to be more like a collection of beans, with data access as 
the main goal. And the JS API should only reflect stuff that makes sense 
in Javascript, which is mostly plain metadata access (getSpace, getName, 
getTitle...).

>> -1 for deprecating the meta information.
>>
>
> Agreed.
>> +0 for temporarily adding a currentDocument property in the XWiki global
>> object.
>>
>> +1 for deprecating the inline code from javascript.vm
>>
>
> Agreed too, but I'd say we should do that at the same time we introduce
> the new model.

This can be done at any moment. It would be simple to move some of the 
initialization in there to xwiki.js + access to the meta. The only 
problem is backwards compatibility.

> Jerome.
>
>> To explain the last point: inline javascript is bad. The more stuff we
>> put in there, the larger the response size, the more the parsing and
>> processing time, the lower the throughput, and the lower the SEO score
>> (since the real content starts somewhere deep in the response). Since
>> the information is already available in the meta fields, we should
>> populate the JS object using it.

-- 
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs

Reply via email to