On 12/18/09 6:09 PM, Sergiu Dumitriu wrote: > 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. >
You think about the fact that currently variables are populated as the HTML is streamed, versus on DOM loaded with the new strategy ? Personally I'd say it's ok to drop compatibility on that. WDYT? > >> 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. >>> > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
