18 Dec
2009
18 Dec
'09
11:58 a.m.
Hi devs,
right now we have 2 ways to get (some) information about the current document in
javascript:
* the meta tags (which store the page, the space, the wiki, version, etc) -- set
in htmlheader.vm
* the XWiki object set in xwiki.js and filled in with info in javascript.vm
which contains currentWiki, mainWiki, currentSpace, action, etc, but *not* the
currentPage.
Between the two, I propose to use the second as the 'recommended' way to get
information about XWiki in some javascript in a document (the action, the wiki,
the space, etc) and, to make it complete, to add a currentPage to it.
WDYT?
Thanks,
Anca
18 Dec
18 Dec
12:25 p.m.
+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.
Jerome.
On 12/18/09 11:58 AM, Anca Luca wrote:
Hi devs,
right now we have 2 ways to get (some) information about the current document in
javascript:
* the meta tags (which store the page, the space, the wiki, version, etc) -- set
in htmlheader.vm
* the XWiki object set in xwiki.js and filled in with info in javascript.vm
which contains currentWiki, mainWiki, currentSpace, action, etc, but *not* the
currentPage.
Between the two, I propose to use the second as the 'recommended' way to get
information about XWiki in some javascript in a document (the action, the wiki,
the space, etc) and, to make it complete, to add a currentPage to it.
WDYT?
Thanks,
Anca
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
12:39 p.m.
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.
Marius
Jerome.
On 12/18/09 11:58 AM, Anca Luca wrote:
Hi devs,
right now we have 2 ways to get (some) information about the current document in
javascript:
* the meta tags (which store the page, the space, the wiki, version, etc) -- set
in htmlheader.vm
* the XWiki object set in xwiki.js and filled in with info in javascript.vm
which contains currentWiki, mainWiki, currentSpace, action, etc, but *not* the
currentPage.
Between the two, I propose to use the second as the 'recommended' way to get
information about XWiki in some javascript in a document (the action, the wiki,
the space, etc) and, to make it complete, to add a currentPage to it.
WDYT?
Thanks,
Anca
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 
4:39 p.m.
On 12/18/2009 12:39 PM, Marius Dumitru Florea wrote:
Jerome Velociter wrote:
+1 for having a JS clone of the Java model after the Java model is close
to being finalized.
-1 for deprecating the meta information.
+0 for temporarily adding a currentDocument property in the XWiki global
object.
+1 for deprecating the inline code from javascript.vm
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.
+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.
>
> Jerome.
>
> On 12/18/09 11:58 AM, Anca Luca wrote:
>> Hi devs,
>>
>> right now we have 2 ways to get (some) information about the current document in
>> javascript:
>>
>> * the meta tags (which store the page, the space, the wiki, version, etc) -- set
>> in htmlheader.vm
>> * the XWiki object set in xwiki.js and filled in with info in javascript.vm
>> which contains currentWiki, mainWiki, currentSpace, action, etc, but *not* the
>> currentPage.
>>
>> Between the two, I propose to use the second as the 'recommended' way to
get
>> information about XWiki in some javascript in a document (the action, the wiki,
>> the space, etc) and, to make it complete, to add a currentPage to it.
>>
>> WDYT?
>>
>> Thanks,
>> Anca
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
4:47 p.m.
On 12/18/09 4:39 PM, Sergiu Dumitriu wrote:
On 12/18/2009 12:39 PM, Marius Dumitru Florea wrote:
Should it be an exact clone ?
Jerome Velociter wrote:
+1 for having a JS clone of the Java model after the Java model is close
to being finalized.
+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 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.
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.
> Jerome.
>
> On 12/18/09 11:58 AM, Anca Luca wrote:
>
>> Hi devs,
>>
>> right now we have 2 ways to get (some) information about the current document in
>> javascript:
>>
>> * the meta tags (which store the page, the space, the wiki, version, etc) -- set
>> in htmlheader.vm
>> * the XWiki object set in xwiki.js and filled in with info in javascript.vm
>> which contains currentWiki, mainWiki, currentSpace, action, etc, but *not* the
>> currentPage.
>>
>> Between the two, I propose to use the second as the 'recommended' way to
get
>> information about XWiki in some javascript in a document (the action, the wiki,
>> the space, etc) and, to make it complete, to add a currentPage to it.
>>
>> WDYT?
>>
>> Thanks,
>> Anca
>>
6:09 p.m.
On 12/18/2009 04:47 PM, Jerome Velociter wrote:
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.
On 12/18/09 4:39 PM, Sergiu Dumitriu wrote:
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...).
On 12/18/2009 12:39 PM, Marius Dumitru Florea
wrote:
Should it be an exact clone ? Jerome Velociter wrote:
+1 for having a JS clone of the Java model after the Java model is close
to being finalized.
+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
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. 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/
6:15 p.m.
On 12/18/09 6:09 PM, Sergiu Dumitriu wrote:
On 12/18/2009 04:47 PM, Jerome Velociter wrote:
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?
On 12/18/09 4:39 PM, Sergiu Dumitriu wrote:
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...).
On 12/18/2009 12:39 PM, Marius Dumitru Florea
wrote:
Should it be an exact clone ?
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.
-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.
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.
>
19 Dec
19 Dec
3:04 a.m.
On 12/18/2009 06:15 PM, Jerome Velociter wrote:
On 12/18/09 6:09 PM, Sergiu Dumitriu wrote:
Yes, that is one of the problems, but my main concern is that old custom
skins won't have this meta information. In the compatibility code we
could fallback to URL parsing as a backup, when the meta is not available.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
On 12/18/2009 04:47 PM, Jerome Velociter wrote:
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?
On 12/18/09 4:39 PM, Sergiu Dumitriu wrote:
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...).
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 ?
-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.
18 Dec
18 Dec
4:42 p.m.
+1,
For now we need to add the XWiki.currentPage variable to access the current
xwiki document name.
Variables in javascript should be more OO, in XWiki namespace and each
module/application in their own namespace inside XWiki namespace.
As for XWiki.
XWiki.doc.id
XWiki.doc.name
XWiki.doc.space
XWiki.doc.wiki
XWiki.doc.fullName and/or XWiki.doc.getFullName = function() { return
XWiki.doc.space + '.' + XWiki.doc.name; }
/*
also action variable can be restricted to valid actions... or just leave
it this way
*/
XWiki.doc.getURL = function(action) { return 'xwiki/bin/' + action + '/'
+
XWiki.doc.space + '/' + XWiki.doc.name; }
/* attachment is the name of the attached file to the current xwiki
document */
XWiki.doc.getAttachmentURL = function(filename) { return return
'xwiki/bin/download/' + XWiki.doc.space + '/' + XWiki.doc.name +
'/' +
filename; }
On Fri, Dec 18, 2009 at 1:39 PM, Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com> wrote:
Jerome Velociter wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Cu stima,
Flavius Olaru
+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.
Marius
Jerome.
On 12/18/09 11:58 AM, Anca Luca wrote:
> Hi devs,
>
> right now we have 2 ways to get (some) information about the current
document
in
> javascript:
>
> * the meta tags (which store the page, the space, the wiki, version,
etc) --
set
> in htmlheader.vm
> * the XWiki object set in xwiki.js and filled in with info in
javascript.vm
> which contains currentWiki, mainWiki,
currentSpace, action, etc, but
*not* the
> currentPage.
>
> Between the two, I propose to use the second as the 'recommended' way to
get
> information about XWiki in some javascript in
a document (the action,
the wiki,
the
space, etc) and, to make it complete, to add a currentPage to it.
WDYT?
Thanks,
Anca
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
6:02 p.m.
On 12/18/2009 04:42 PM, Flavius Olaru wrote:
+1,
For now we need to add the XWiki.currentPage variable to access the current
xwiki document name.
Variables in javascript should be more OO, in XWiki namespace and each
module/application in their own namespace inside XWiki namespace.
As for XWiki.
XWiki.doc.id
XWiki.doc.name
XWiki.doc.space
XWiki.doc.wiki
XWiki.doc.fullName and/or XWiki.doc.getFullName = function() { return
XWiki.doc.space + '.' + XWiki.doc.name; }
/*
also action variable can be restricted to valid actions... or just leave
it this way
*/
XWiki.doc.getURL = function(action) { return 'xwiki/bin/' + action + '/'
+
XWiki.doc.space + '/' + XWiki.doc.name; }
This is wrong, /xwiki/ is pretty often customized, and the /bin/ is also
customizable. And either of them can also be missing.
/* attachment is the name of the attached file to the
current xwiki
document */
XWiki.doc.getAttachmentURL = function(filename) { return return
'xwiki/bin/download/' + XWiki.doc.space + '/' + XWiki.doc.name +
'/' +
filename; }
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
1:25 p.m.
Hi Jerome,
On 12/18/2009 01:25 PM, 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 agree we need to define it better.
My idea was to maintain this API and rely on it and add functions and data to
make it usable (minimal, of course, until we define the xwiki model), rather
than go for the metatags.
Thanks,
Anca
Jerome.
On 12/18/09 11:58 AM, Anca Luca wrote:
Hi devs,
right now we have 2 ways to get (some) information about the current document in
javascript:
* the meta tags (which store the page, the space, the wiki, version, etc) -- set
in htmlheader.vm
* the XWiki object set in xwiki.js and filled in with info in javascript.vm
which contains currentWiki, mainWiki, currentSpace, action, etc, but *not* the
currentPage.
Between the two, I propose to use the second as the 'recommended' way to get
information about XWiki in some javascript in a document (the action, the wiki,
the space, etc) and, to make it complete, to add a currentPage to it.
WDYT?
Thanks,
Anca
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5385
days inactive
5386
days old
10 comments
5 participants
participants (5)
-
Anca Luca -
Flavius Olaru -
Jerome Velociter -
Marius Dumitru Florea -
Sergiu Dumitriu