16 Jun
2012
16 Jun
'12
2:28 a.m.
Hi devs,
Now that all the scripts on the Internets are implemented as jQuery
plugins, should we bite the bullet and make it easier for extensions
developers to integrate such scripts ?
Note it would not necessarily mean we use it ourselves in web/XE.
If we don't do something about it, there is the risk that many extensions
bring their own jQuery to the party, which will translate in slower page
loads and more importantly a less enjoyable extension developer experience.
An alternative idea would be an "official" jQuery extension (with a JSX)
that other extensions can depend upon, should they need jQuery.
What do you think ?
Jerome
16 Jun
16 Jun
3:01 a.m.
+1
We are missing out a lot by not offering a supported way of using jQuery in
XWiki.
Thanks,
Eduard
On Sat, Jun 16, 2012 at 3:28 AM, Jerome Velociter <jerome(a)winesquare.net>wrote;wrote:
Hi devs,
Now that all the scripts on the Internets are implemented as jQuery
plugins, should we bite the bullet and make it easier for extensions
developers to integrate such scripts ?
Note it would not necessarily mean we use it ourselves in web/XE.
If we don't do something about it, there is the risk that many extensions
bring their own jQuery to the party, which will translate in slower page
loads and more importantly a less enjoyable extension developer experience.
An alternative idea would be an "official" jQuery extension (with a JSX)
that other extensions can depend upon, should they need jQuery.
What do you think ?
Jerome
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
9:17 a.m.
On Sat, Jun 16, 2012 at 2:28 AM, Jerome Velociter <jerome(a)winesquare.net> wrote:
Hi devs,
Now that all the scripts on the Internets are implemented as jQuery
plugins, should we bite the bullet and make it easier for extensions
developers to integrate such scripts ?
Note it would not necessarily mean we use it ourselves in web/XE.
If we don't do something about it, there is the risk that many extensions
bring their own jQuery to the party, which will translate in slower page
loads and more importantly a less enjoyable extension developer experience.
An alternative idea would be an "official" jQuery extension (with a JSX)
that other extensions can depend upon, should they need jQuery.
Depends. Do you think we would loose much in performances if it's done
as a JSX compared to integrated to the WAR ?
The idea sounds better in theory if we don't plan to use it ourself in
XE at least. Another good thing with extension is that it would make
easier to have jQuery version you need for your extension and not have
to wait that XE embeds it.
What do you think ?
+1 in general to make jQuery users life easier
Jerome
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
8:29 p.m.
On 06/15/2012 08:28 PM, Jerome Velociter wrote:
Hi devs,
Now that all the scripts on the Internets are implemented as jQuery
plugins, should we bite the bullet and make it easier for extensions
developers to integrate such scripts ?
Note it would not necessarily mean we use it ourselves in web/XE.
If we don't do something about it, there is the risk that many extensions
bring their own jQuery to the party, which will translate in slower page
loads and more importantly a less enjoyable extension developer experience.
An alternative idea would be an "official" jQuery extension (with a JSX)
that other extensions can depend upon, should they need jQuery.
What do you think ?
Jerome
Using jQuery in XWiki is not a very easy task, so indeed it's a good
idea to provide our own integration known to work.
Personally I'm not a fan of jQuery, but I agree that it's the most
popular JS framework, and most JS widgets/libraries are built on top of
it, so you have my +1.
Packaging, I think that it should be placed on the filesystem in
resources/js/jquery/, it shouldn't be used by default, and we try to
bundle the most recent version available at the time of the release. If
someone needs a more recent version, they should update XWiki as well.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
2 Jul
2 Jul
7:32 p.m.
On Sat, Jun 16, 2012 at 8:29 PM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote:
On 06/15/2012 08:28 PM, Jerome Velociter wrote:
Not a huge fan either, though there are some interesting things prototype
does not have, like the "live" observers.
Hi devs,
Now that all the scripts on the Internets are implemented as jQuery
plugins, should we bite the bullet and make it easier for extensions
developers to integrate such scripts ?
Note it would not necessarily mean we use it ourselves in web/XE.
If we don't do something about it, there is the risk that many extensions
bring their own jQuery to the party, which will translate in slower page
loads and more importantly a less enjoyable extension developer
experience.
An alternative idea would be an "official" jQuery extension (with a JSX)
that other extensions can depend upon, should they need jQuery.
What do you think ?
Jerome
Using jQuery in XWiki is not a very easy task, so indeed it's a good idea
to provide our own integration known to work.
Personally I'm not a fan of jQuery, but I agree that it's the most popular
JS framework, and most JS widgets/libraries are built on top of it, so you
have my +1.
Packaging, I think that it should be placed on the filesystem in
resources/js/jquery/, it shouldn't be used by default, and we try to bundle
the most recent version available at the time of the release. If someone
needs a more recent version, they should update XWiki as well.
When you say bundled, you mean its script tag in the rendered pages ? Or
just present in the resources/ folder on the FS ?
I would say, script tag included, otherwise it does not solve much.
Jerome
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
______________________________**_________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/ma…
--
Jérôme Velociter
Winesquare
http://www.winesquare.net/
9:17 p.m.
On 07/02/2012 01:32 PM, Jerome Velociter wrote:
On Sat, Jun 16, 2012 at 8:29 PM, Sergiu Dumitriu
<sergiu(a)xwiki.com> wrote:
When I say "bundled", I mean that it's going to be present in the
resources directory in the XE builds.
On 06/15/2012 08:28 PM, Jerome Velociter wrote:
Not a huge fan either, though there are some interesting things prototype
does not have, like the "live" observers.
Hi devs,
Now that all the scripts on the Internets are implemented as jQuery
plugins, should we bite the bullet and make it easier for extensions
developers to integrate such scripts ?
Note it would not necessarily mean we use it ourselves in web/XE.
If we don't do something about it, there is the risk that many extensions
bring their own jQuery to the party, which will translate in slower page
loads and more importantly a less enjoyable extension developer
experience.
An alternative idea would be an "official" jQuery extension (with a JSX)
that other extensions can depend upon, should they need jQuery.
What do you think ?
Jerome
Using jQuery in XWiki is not a very easy task, so indeed it's a good idea
to provide our own integration known to work.
Personally I'm not a fan of jQuery, but I agree that it's the most popular
JS framework, and most JS widgets/libraries are built on top of it, so you
have my +1.
Packaging, I think that it should be placed on the filesystem in
resources/js/jquery/, it shouldn't be used by default, and we try to bundle
the most recent version available at the time of the release. If someone
needs a more recent version, they should update XWiki as well.
When you say bundled, you mean its script tag in the rendered pages ? Or
just present in the resources/ folder on the FS ? I would say, script tag included, otherwise it does
not solve much.
I'm not sure yet... On one hand I agree that it's not really going to
solve the problem if users have to use a specific jsfx call with
parameters to get it working, but on the other hand loading a pretty
significant JS library all the time just for some potential custom
extensions isn't a smart move for performance.
I would prefer a very simple mechanism to trigger the activation of
jQuery, but I can't find one simple and generic enough.
The most basic thing would be to hard-code some behavior in the JSFX
plugin implementation, so that a simple $jsfx.use('jquery') would use
the right path and the right parameters (defer=false), and make sure
that one is listed before the other extensions.
Jerome
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
18 Jun
18 Jun
8:53 a.m.
On Jun 16, 2012, at 2:28 AM, Jerome Velociter wrote:
Hi devs,
Now that all the scripts on the Internets are implemented as jQuery
plugins, should we bite the bullet and make it easier for extensions
developers to integrate such scripts ?
Note it would not necessarily mean we use it ourselves in web/XE.
If we don't do something about it, there is the risk that many extensions
bring their own jQuery to the party, which will translate in slower page
loads and more importantly a less enjoyable extension developer experience.
An alternative idea would be an "official" jQuery extension (with a JSX)
that other extensions can depend upon, should they need jQuery.
What do you think ?
I agree about the need. My preference would go to a jquery extension that you would
install explicitly or you would simply install some extension that depends on jquery (for
example my latest fullcalendar extension would have an extension dependency on jquery).
However ATM we're not able to create extensions that contribute resources on the file
system (@thomas: do you have a plan to make this possible? - We've several use cases
where it would be nice to have it: skins for example too).
So +1 to bundle it in XWiki platform ATM with the goal of making it an extension as soon
as we can have that.
BTW could someone tell me the cons of using a JSX to bundle JQuery vs filesystem?
The JSX can be cached with "long" so in term of performance is should be
comparable no?
The "cache" is a local client browser cache right? (not a server-side cache)
So if we don't have much difference in performance/memory I'd be +1 to bundle it
as an on-demand JSX.
Thanks
-Vincent
9:49 a.m.
On Mon, Jun 18, 2012 at 8:53 AM, Vincent Massol <vincent(a)massol.net> wrote:
On Jun 16, 2012, at 2:28 AM, Jerome Velociter wrote:
No plan right now, concentrating on other things. The main issue is
that it's not that easy to do something which is working all the time
since you can't write in a WAR for example and even in a expended WAR
you don't really have any official API allowing to do that.
Hi devs,
Now that all the scripts on the Internets are implemented as jQuery
plugins, should we bite the bullet and make it easier for extensions
developers to integrate such scripts ?
Note it would not necessarily mean we use it ourselves in web/XE.
If we don't do something about it, there is the risk that many extensions
bring their own jQuery to the party, which will translate in slower page
loads and more importantly a less enjoyable extension developer experience.
An alternative idea would be an "official" jQuery extension (with a JSX)
that other extensions can depend upon, should they need jQuery.
What do you think ?
I agree about the need. My preference would go to a jquery extension that you would
install explicitly or you would simply install some extension that depends on jquery (for
example my latest fullcalendar extension would have an extension dependency on jquery).
However ATM we're not able to create extensions that contribute resources on the file
system (@thomas: do you have a plan to make this possible? - We've several use cases
where it would be nice to have it: skins for example too).
So +1 to bundle it in XWiki platform ATM with the goal of making it an extension as soon
as we can have that.
BTW could someone tell me the cons of using a JSX to bundle JQuery vs filesystem?
The JSX can be cached with "long" so in term of performance is should be
comparable no?
The "cache" is a local client browser cache right? (not a server-side cache)
So if we don't have much difference in performance/memory I'd be +1 to bundle it
as an on-demand JSX.
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
10:02 a.m.
On Jun 18, 2012, at 9:49 AM, Thomas Mortagne wrote:
On Mon, Jun 18, 2012 at 8:53 AM, Vincent Massol
<vincent(a)massol.net> wrote:
Well you do something similar for jars already since you're saving them in the work
directory.
What I was thinking is that we could modify Environment to support having several
Resources directories (and to be able to add resource directories) and to have the EM
register a new resource dir at app init time.
In Environment, when looking for a resource we would check each resource dir in turn,
looking for the asked resource.
WDYT?
Thanks
-Vincent
On Jun 16, 2012, at 2:28 AM, Jerome Velociter wrote:
No plan right now, concentrating on other things. The main issue is
that it's not that easy to do something which is working all the time
since you can't write in a WAR for example and even in a expended WAR
you don't really have any official API allowing to do that. Hi devs,
Now that all the scripts on the Internets are implemented as jQuery
plugins, should we bite the bullet and make it easier for extensions
developers to integrate such scripts ?
Note it would not necessarily mean we use it ourselves in web/XE.
If we don't do something about it, there is the risk that many extensions
bring their own jQuery to the party, which will translate in slower page
loads and more importantly a less enjoyable extension developer experience.
An alternative idea would be an "official" jQuery extension (with a JSX)
that other extensions can depend upon, should they need jQuery.
What do you think ?
I agree about the need. My preference would go to a jquery extension that you would
install explicitly or you would simply install some extension that depends on jquery (for
example my latest fullcalendar extension would have an extension dependency on jquery).
However ATM we're not able to create extensions that contribute resources on the file
system (@thomas: do you have a plan to make this possible? - We've several use cases
where it would be nice to have it: skins for example too). > So +1 to bundle it in XWiki platform ATM with the
goal of making it an extension as soon as we can have that.
>
> BTW could someone tell me the cons of using a JSX to bundle JQuery vs filesystem?
> The JSX can be cached with "long" so in term of performance is should be
comparable no?
> The "cache" is a local client browser cache right? (not a server-side
cache)
>
> So if we don't have much difference in performance/memory I'd be +1 to bundle
it as an on-demand JSX.
>
> Thanks
> -Vincent
10:11 a.m.
On Mon, Jun 18, 2012 at 10:02 AM, Vincent Massol <vincent(a)massol.net> wrote:
On Jun 18, 2012, at 9:49 AM, Thomas Mortagne wrote:
Sure there is things to do but what I said is that it require changes
in the platform itself before doing something in EM. I just don't have
time to look at it yet.
On Mon, Jun 18, 2012 at 8:53 AM, Vincent Massol
<vincent(a)massol.net> wrote:
Well you do something similar for jars already since you're saving them in the work
directory.
What I was thinking is that we could modify Environment to support having several
Resources directories (and to be able to add resource directories) and to have the EM
register a new resource dir at app init time.
In Environment, when looking for a resource we would check each resource dir in turn,
looking for the asked resource.
On Jun 16, 2012, at 2:28 AM, Jerome Velociter wrote:
No plan right now, concentrating on other things. The main issue is
that it's not that easy to do something which is working all the time
since you can't write in a WAR for example and even in a expended WAR
you don't really have any official API allowing to do that. Hi devs,
Now that all the scripts on the Internets are implemented as jQuery
plugins, should we bite the bullet and make it easier for extensions
developers to integrate such scripts ?
Note it would not necessarily mean we use it ourselves in web/XE.
If we don't do something about it, there is the risk that many extensions
bring their own jQuery to the party, which will translate in slower page
loads and more importantly a less enjoyable extension developer experience.
An alternative idea would be an "official" jQuery extension (with a JSX)
that other extensions can depend upon, should they need jQuery.
What do you think ?
I agree about the need. My preference would go to a jquery extension that you would
install explicitly or you would simply install some extension that depends on jquery (for
example my latest fullcalendar extension would have an extension dependency on jquery).
However ATM we're not able to create extensions that contribute resources on the file
system (@thomas: do you have a plan to make this possible? - We've several use cases
where it would be nice to have it: skins for example too).
WDYT?
Thanks
-Vincent
--
Thomas Mortagne
> So +1 to bundle it in XWiki platform ATM with
the goal of making it an extension as soon as we can have that.
>
> BTW could someone tell me the cons of using a JSX to bundle JQuery vs filesystem?
> The JSX can be cached with "long" so in term of performance is should be
comparable no?
> The "cache" is a local client browser cache right? (not a server-side
cache)
>
> So if we don't have much difference in performance/memory I'd be +1 to bundle
it as an on-demand JSX.
>
> Thanks
> -Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 
3:03 p.m.
On 06/18/2012 04:11 AM, Thomas Mortagne wrote:
On Mon, Jun 18, 2012 at 10:02 AM, Vincent Massol
<vincent(a)massol.net> wrote:
I think we should put some thought into whether we want to provide relatively raw
filesystem access,
there are some questions which it brings up like how do we support clustering?
IMO it's a pretty important architectual decision.
Thanks,
Caleb
On Jun 18, 2012, at 9:49 AM, Thomas Mortagne wrote:
Sure there is things to do but what I said is that it require changes
in the platform itself before doing something in EM. I just don't have
time to look at it yet. On Mon, Jun 18, 2012 at 8:53 AM, Vincent Massol
<vincent(a)massol.net> wrote:
Well you do something similar for jars already since you're saving them in the work
directory.
What I was thinking is that we could modify Environment to support having several
Resources directories (and to be able to add resource directories) and to have the EM
register a new resource dir at app init time.
In Environment, when looking for a resource we would check each resource dir in turn,
looking for the asked resource.
On Jun 16, 2012, at 2:28 AM, Jerome Velociter wrote:
> Hi devs,
>
> Now that all the scripts on the Internets are implemented as jQuery
> plugins, should we bite the bullet and make it easier for extensions
> developers to integrate such scripts ?
> Note it would not necessarily mean we use it ourselves in web/XE.
>
> If we don't do something about it, there is the risk that many extensions
> bring their own jQuery to the party, which will translate in slower page
> loads and more importantly a less enjoyable extension developer experience.
>
> An alternative idea would be an "official" jQuery extension (with a JSX)
> that other extensions can depend upon, should they need jQuery.
>
> What do you think ?
I agree about the need. My preference would go to a jquery extension that you would
install explicitly or you would simply install some extension that depends on jquery (for
example my latest fullcalendar extension would have an extension dependency on jquery).
However ATM we're not able to create extensions that contribute resources on the file
system (@thomas: do you have a plan to make this possible? - We've several use cases
where it would be nice to have it: skins for example too).
No plan right now, concentrating on other things. The main issue is
that it's not that easy to do something which is working all the time
since you can't write in a WAR for example and even in a expended WAR
you don't really have any official API allowing to do that.
WDYT?
Thanks
-Vincent
> So +1 to bundle it in XWiki platform ATM with
the goal of making it an extension as soon as we can have that.
>
> BTW could someone tell me the cons of using a JSX to bundle JQuery vs filesystem?
> The JSX can be cached with "long" so in term of performance is should be
comparable no?
> The "cache" is a local client browser cache right? (not a server-side
cache)
>
> So if we don't have much difference in performance/memory I'd be +1 to bundle
it as an on-demand JSX.
>
> Thanks
> -Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
3:18 p.m.
On Jun 18, 2012, at 3:03 PM, Caleb James DeLisle wrote:
On 06/18/2012 04:11 AM, Thomas Mortagne wrote:
Sure but it's not very different from what we already do with extensions ATM.
Thanks
-Vincent
On Mon, Jun 18, 2012 at 10:02 AM, Vincent Massol
<vincent(a)massol.net> wrote:
I think we should put some thought into whether we want to provide relatively raw
filesystem access,
there are some questions which it brings up like how do we support clustering?
IMO it's a pretty important architectual decision.
On Jun 18, 2012, at 9:49 AM, Thomas Mortagne wrote:
Sure there is things to do but what I said is that it require changes
in the platform itself before doing something in EM. I just don't have
time to look at it yet. On Mon, Jun 18, 2012 at 8:53 AM, Vincent Massol
<vincent(a)massol.net> wrote:
>
> On Jun 16, 2012, at 2:28 AM, Jerome Velociter wrote:
>
>> Hi devs,
>>
>> Now that all the scripts on the Internets are implemented as jQuery
>> plugins, should we bite the bullet and make it easier for extensions
>> developers to integrate such scripts ?
>> Note it would not necessarily mean we use it ourselves in web/XE.
>>
>> If we don't do something about it, there is the risk that many extensions
>> bring their own jQuery to the party, which will translate in slower page
>> loads and more importantly a less enjoyable extension developer experience.
>>
>> An alternative idea would be an "official" jQuery extension (with a
JSX)
>> that other extensions can depend upon, should they need jQuery.
>>
>> What do you think ?
>
> I agree about the need. My preference would go to a jquery extension that you would
install explicitly or you would simply install some extension that depends on jquery (for
example my latest fullcalendar extension would have an extension dependency on jquery).
>
> However ATM we're not able to create extensions that contribute resources on the
file system (@thomas: do you have a plan to make this possible? - We've several use
cases where it would be nice to have it: skins for example too).
No plan right now, concentrating on other things. The main issue is
that it's not that easy to do something which is working all the time
since you can't write in a WAR for example and even in a expended WAR
you don't really have any official API allowing to do that.
Well you do something similar for jars already since you're saving them in the work
directory.
What I was thinking is that we could modify Environment to support having several
Resources directories (and to be able to add resource directories) and to have the EM
register a new resource dir at app init time.
In Environment, when looking for a resource we would check each resource dir in turn,
looking for the asked resource. Thanks,
Caleb
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
WDYT?
Thanks
-Vincent
> So +1 to bundle it in XWiki platform ATM with
the goal of making it an extension as soon as we can have that.
>
> BTW could someone tell me the cons of using a JSX to bundle JQuery vs filesystem?
> The JSX can be cached with "long" so in term of performance is should be
comparable no?
> The "cache" is a local client browser cache right? (not a server-side
cache)
>
> So if we don't have much difference in performance/memory I'd be +1 to bundle
it as an on-demand JSX.
>
> Thanks
> -Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
4:12 p.m.
On Mon, Jun 18, 2012 at 3:03 PM, Caleb James DeLisle
<calebdelisle(a)lavabit.com> wrote:
On 06/18/2012 04:11 AM, Thomas Mortagne wrote:
We already have extensions on the filesystem. What happen is that when
you execute a EM request it's sent to all the members of the cluster.
On Mon, Jun 18, 2012 at 10:02 AM, Vincent Massol
<vincent(a)massol.net> wrote:
I think we should put some thought into whether we want to provide relatively raw
filesystem access,
there are some questions which it brings up like how do we support clustering?
IMO it's a pretty important architectual decision.
On Jun 18, 2012, at 9:49 AM, Thomas Mortagne wrote:
Sure there is things to do but what I said is that it require changes
in the platform itself before doing something in EM. I just don't have
time to look at it yet. On Mon, Jun 18, 2012 at 8:53 AM, Vincent Massol
<vincent(a)massol.net> wrote:
>
> On Jun 16, 2012, at 2:28 AM, Jerome Velociter wrote:
>
>> Hi devs,
>>
>> Now that all the scripts on the Internets are implemented as jQuery
>> plugins, should we bite the bullet and make it easier for extensions
>> developers to integrate such scripts ?
>> Note it would not necessarily mean we use it ourselves in web/XE.
>>
>> If we don't do something about it, there is the risk that many extensions
>> bring their own jQuery to the party, which will translate in slower page
>> loads and more importantly a less enjoyable extension developer experience.
>>
>> An alternative idea would be an "official" jQuery extension (with a
JSX)
>> that other extensions can depend upon, should they need jQuery.
>>
>> What do you think ?
>
> I agree about the need. My preference would go to a jquery extension that you would
install explicitly or you would simply install some extension that depends on jquery (for
example my latest fullcalendar extension would have an extension dependency on jquery).
>
> However ATM we're not able to create extensions that contribute resources on the
file system (@thomas: do you have a plan to make this possible? - We've several use
cases where it would be nice to have it: skins for example too).
No plan right now, concentrating on other things. The main issue is
that it's not that easy to do something which is working all the time
since you can't write in a WAR for example and even in a expended WAR
you don't really have any official API allowing to do that.
Well you do something similar for jars already since you're saving them in the work
directory.
What I was thinking is that we could modify Environment to support having several
Resources directories (and to be able to add resource directories) and to have the EM
register a new resource dir at app init time.
In Environment, when looking for a resource we would check each resource dir in turn,
looking for the asked resource.
Thanks,
Caleb
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
WDYT?
Thanks
-Vincent
> So +1 to bundle it in XWiki platform ATM with
the goal of making it an extension as soon as we can have that.
>
> BTW could someone tell me the cons of using a JSX to bundle JQuery vs filesystem?
> The JSX can be cached with "long" so in term of performance is should be
comparable no?
> The "cache" is a local client browser cache right? (not a server-side
cache)
>
> So if we don't have much difference in performance/memory I'd be +1 to bundle
it as an on-demand JSX.
>
> Thanks
> -Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
4:33 p.m.
On 06/18/2012 03:49 AM, Thomas Mortagne wrote:
On Mon, Jun 18, 2012 at 8:53 AM, Vincent Massol
<vincent(a)massol.net> wrote:
Actually it is possible, jsrx offers files from inside jars.
On Jun 16, 2012, at 2:28 AM, Jerome Velociter wrote:
No plan right now, concentrating on other things. The main issue is
that it's not that easy to do something which is working all the time
since you can't write in a WAR for example and even in a expended WAR
you don't really have any official API allowing to do that. Hi devs,
Now that all the scripts on the Internets are implemented as jQuery
plugins, should we bite the bullet and make it easier for extensions
developers to integrate such scripts ?
Note it would not necessarily mean we use it ourselves in web/XE.
If we don't do something about it, there is the risk that many extensions
bring their own jQuery to the party, which will translate in slower page
loads and more importantly a less enjoyable extension developer experience.
An alternative idea would be an "official" jQuery extension (with a JSX)
that other extensions can depend upon, should they need jQuery.
What do you think ?
I agree about the need. My preference would go to a jquery extension that you would
install explicitly or you would simply install some extension that depends on jquery (for
example my latest fullcalendar extension would have an extension dependency on jquery).
However ATM we're not able to create extensions that contribute resources on the file
system (@thomas: do you have a plan to make this possible? - We've several use cases
where it would be nice to have it: skins for example too). >
> So +1 to bundle it in XWiki platform ATM with the goal of making it an extension as
soon as we can have that.
>
> BTW could someone tell me the cons of using a JSX to bundle JQuery vs filesystem?
> The JSX can be cached with "long" so in term of performance is should be
comparable no?
> The "cache" is a local client browser cache right? (not a server-side
cache)
>
> So if we don't have much difference in performance/memory I'd be +1 to bundle
it as an on-demand JSX.
>
> Thanks
> -Vincent
>
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
6:02 p.m.
On Mon, Jun 18, 2012 at 4:33 PM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote:
--
Thomas Mortagne
On 06/18/2012 03:49 AM, Thomas Mortagne wrote:
That's for on demand skin extensions but Vincent was talking about
installing a full filesystem skin or adding more things in resources/
folder.
On Mon, Jun 18, 2012 at 8:53 AM, Vincent Massol <vincent(a)massol.net>
wrote:
Actually it is possible, jsrx offers files from inside jars.
On Jun 16, 2012, at 2:28 AM, Jerome Velociter wrote:
No plan right now, concentrating on other things. The main issue is
that it's not that easy to do something which is working all the time
since you can't write in a WAR for example and even in a expended WAR
you don't really have any official API allowing to do that. Hi devs,
Now that all the scripts on the Internets are implemented as jQuery
plugins, should we bite the bullet and make it easier for extensions
developers to integrate such scripts ?
Note it would not necessarily mean we use it ourselves in web/XE.
If we don't do something about it, there is the risk that many
extensions
bring their own jQuery to the party, which will translate in slower page
loads and more importantly a less enjoyable extension developer
experience.
An alternative idea would be an "official" jQuery extension (with a JSX)
that other extensions can depend upon, should they need jQuery.
What do you think ?
I agree about the need. My preference would go to a jquery extension that
you would install explicitly or you would simply install some extension that
depends on jquery (for example my latest fullcalendar extension would have
an extension dependency on jquery).
However ATM we're not able to create extensions that contribute resources
on the file system (@thomas: do you have a plan to make this possible? -
We've several use cases where it would be nice to have it: skins for example
too). >
> So +1 to bundle it in XWiki platform ATM with the goal of making it an
> extension as soon as we can have that.
>
> BTW could someone tell me the cons of using a JSX to bundle JQuery vs
> filesystem?
> The JSX can be cached with "long" so in term of performance is should be
> comparable no?
> The "cache" is a local client browser cache right? (not a server-side
> cache)
>
> So if we don't have much difference in performance/memory I'd be +1 to
> bundle it as an on-demand JSX.
>
> Thanks
> -Vincent
>
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 
9:16 a.m.
+1
Thanks,
Marius
On Sat, Jun 16, 2012 at 3:28 AM, Jerome Velociter <jerome(a)winesquare.net> wrote:
Hi devs,
Now that all the scripts on the Internets are implemented as jQuery
plugins, should we bite the bullet and make it easier for extensions
developers to integrate such scripts ?
Note it would not necessarily mean we use it ourselves in web/XE.
If we don't do something about it, there is the risk that many extensions
bring their own jQuery to the party, which will translate in slower page
loads and more importantly a less enjoyable extension developer experience.
An alternative idea would be an "official" jQuery extension (with a JSX)
that other extensions can depend upon, should they need jQuery.
What do you think ?
Jerome
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
10:42 a.m.
+1
Best Regards,
/Andreas
2012-06-16 02:28, Jerome Velociter skrev:
Hi devs,
Now that all the scripts on the Internets are implemented as jQuery
plugins, should we bite the bullet and make it easier for extensions
developers to integrate such scripts ?
Note it would not necessarily mean we use it ourselves in web/XE.
If we don't do something about it, there is the risk that many extensions
bring their own jQuery to the party, which will translate in slower page
loads and more importantly a less enjoyable extension developer experience.
An alternative idea would be an "official" jQuery extension (with a JSX)
that other extensions can depend upon, should they need jQuery.
What do you think ?
Jerome
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
.
10:53 a.m.
Hi,
+1 as well, jQuery the de facto standard for many web applications today.
Guillaume
On Mon, Jun 18, 2012 at 10:42 AM, Andreas Jonsson <aj(a)member.fsf.org> wrote:
+1
Best Regards,
/Andreas
2012-06-16 02:28, Jerome Velociter skrev:
Hi devs,
Now that all the scripts on the Internets are implemented as jQuery
plugins, should we bite the bullet and make it easier for extensions
developers to integrate such scripts ?
Note it would not necessarily mean we use it ourselves in web/XE.
If we don't do something about it, there is the risk that many extensions
bring their own jQuery to the party, which will translate in slower page
loads and more importantly a less enjoyable extension developer
experience.
An alternative idea would be an "official" jQuery extension (with a JSX)
that other extensions can depend upon, should they need jQuery.
What do you think ?
Jerome
______________________________**_________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/ma…
.
______________________________**_________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/ma…
11:21 a.m.
Good day,
One of the strongest "as-sure-as-possible" +1 I ever had to share with you.
Fully on board since I tried this on my own and ran into a few issues when
I tried to go beyond the basics.
Let me know if and how I can contribute to this, for me it's close to a
Christmas present: it would allow to deploy a series of essential / classic
extensions and be able to both suggest and implement on my own solutions
based on the plethora of plugins based on jQ.
Thank you Jerome for the initiative!
On Mon, Jun 18, 2012 at 11:53 AM, Guillaume Lerouge <guillaume(a)xwiki.com>wrote;wrote:
Hi,
+1 as well, jQuery the de facto standard for many web applications today.
Guillaume
On Mon, Jun 18, 2012 at 10:42 AM, Andreas Jonsson <aj(a)member.fsf.org>
wrote:
http://lists.xwiki.org/mailman/listinfo/devs>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Ionut MAXIM
- - - - - - - - - - - - - - - - - - - - - - - -
Web Designer @ XWiki SAS
- - - - - - - - - - - - - - - - - - - - - - - -
+40755120711 | www.xwiki.com
+1
Best Regards,
/Andreas
2012-06-16 02:28, Jerome Velociter skrev:
Hi devs,
>
> Now that all the scripts on the Internets are implemented as jQuery
> plugins, should we bite the bullet and make it easier for extensions
> developers to integrate such scripts ?
> Note it would not necessarily mean we use it ourselves in web/XE.
>
> If we don't do something about it, there is the risk that many
extensions
> bring their own jQuery to the party, which
will translate in slower page
> loads and more importantly a less enjoyable extension developer
> experience.
>
> An alternative idea would be an "official" jQuery extension (with a JSX)
> that other extensions can depend upon, should they need jQuery.
>
> What do you think ?
>
> Jerome
> ______________________________**_________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/**mailman/listinfo/devs<
http://lists.xwiki.org/mailman/listinfo/devs>
.
______________________________**_________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/**mailman/listinfo/devs<
11:30 a.m.
On Jun 18, 2012, at 11:21 AM, Ionut Maxim wrote:
Good day,
One of the strongest "as-sure-as-possible" +1 I ever had to share with you.
Fully on board since I tried this on my own and ran into a few issues when
I tried to go beyond the basics.
Let me know if and how I can contribute to this, for me it's close to a
Christmas present: it would allow to deploy a series of essential / classic
extensions and be able to both suggest and implement on my own solutions
based on the plethora of plugins based on jQ.
Thank you Jerome for the initiative!
Ionut, btw you can already do this by installing this extension which brings JQuery 1.7.2
for you:
http://extensions.xwiki.org/xwiki/bin/view/Extension/jQuery+Helpers
So if you package a new extension all you have to do ATM is to mark the jquery helpers
extension as a dependency and it'll get installed automatically when users install
your extension.
Thanks
-Vincent
On Mon, Jun 18, 2012 at 11:53 AM, Guillaume Lerouge
<guillaume(a)xwiki.com>wrote;wrote:
> Hi,
>
> +1 as well, jQuery the de facto standard for many web applications today.
>
> Guillaume
>
> On Mon, Jun 18, 2012 at 10:42 AM, Andreas Jonsson <aj(a)member.fsf.org>
> wrote:
>
>> +1
>>
>> Best Regards,
>>
>> /Andreas
>>
>> 2012-06-16 02:28, Jerome Velociter skrev:
>>
>> Hi devs,
>>>
>>> Now that all the scripts on the Internets are implemented as jQuery
>>> plugins, should we bite the bullet and make it easier for extensions
>>> developers to integrate such scripts ?
>>> Note it would not necessarily mean we use it ourselves in web/XE.
>>>
>>> If we don't do something about it, there is the risk that many
> extensions
>>> bring their own jQuery to the party, which will translate in slower page
>>> loads and more importantly a less enjoyable extension developer
>>> experience.
>>>
>>> An alternative idea would be an "official" jQuery extension (with a
JSX)
>>> that other extensions can depend upon, should they need jQuery.
>>>
>>> What do you think ?
6:39 p.m.
On 06/18/2012 05:21 AM, Ionut Maxim wrote:
Good day,
One of the strongest "as-sure-as-possible" +1 I ever had to share with you.
Fully on board since I tried this on my own and ran into a few issues when
I tried to go beyond the basics.
Let me know if and how I can contribute to this, for me it's close to a
Christmas present: it would allow to deploy a series of essential / classic
extensions and be able to both suggest and implement on my own solutions
based on the plethora of plugins based on jQ.
Thank you Jerome for the initiative!
Well, even if jQuery will be bundled in the platform, this doesn't mean
that we'll start using it. It's just there for third party extension
writers, but for the official platform Prototype will continue to be the
official library, at least for the short future.
On Mon, Jun 18, 2012 at 11:53 AM, Guillaume Lerouge
<guillaume(a)xwiki.com>wrote;wrote:
> Hi,
>
> +1 as well, jQuery the de facto standard for many web applications today.
>
> Guillaume
>
> On Mon, Jun 18, 2012 at 10:42 AM, Andreas Jonsson <aj(a)member.fsf.org>
> wrote:
>
>> +1
>>
>> Best Regards,
>>
>> /Andreas
>>
>> 2012-06-16 02:28, Jerome Velociter skrev:
>>
>> Hi devs,
>>>
>>> Now that all the scripts on the Internets are implemented as jQuery
>>> plugins, should we bite the bullet and make it easier for extensions
>>> developers to integrate such scripts ?
>>> Note it would not necessarily mean we use it ourselves in web/XE.
>>>
>>> If we don't do something about it, there is the risk that many
> extensions
>>> bring their own jQuery to the party, which will translate in slower page
>>> loads and more importantly a less enjoyable extension developer
>>> experience.
>>>
>>> An alternative idea would be an "official" jQuery extension (with a
JSX)
>>> that other extensions can depend upon, should they need jQuery.
>>>
>>> What do you think ?
>>>
>>> Jerome
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
7:05 p.m.
I know, I wasn't expecting magic to happen over night. A smooth base is
welcomed, steps ahead on a designer friendly path are a plus for sure. Glad
to see all the support thus far.
On Mon, Jun 18, 2012 at 7:39 PM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote:
On 06/18/2012 05:21 AM, Ionut Maxim wrote:
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
______________________________**_________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/ma…
--
Ionut MAXIM
- - - - - - - - - - - - - - - - - - - - - - - -
Web Designer @ XWiki SAS
- - - - - - - - - - - - - - - - - - - - - - - -
+40755120711 | www.xwiki.com
Good day,
One of the strongest "as-sure-as-possible" +1 I ever had to share with
you.
Fully on board since I tried this on my own and ran into a few issues when
I tried to go beyond the basics.
Let me know if and how I can contribute to this, for me it's close to a
Christmas present: it would allow to deploy a series of essential /
classic
extensions and be able to both suggest and implement on my own solutions
based on the plethora of plugins based on jQ.
Thank you Jerome for the initiative!
Well, even if jQuery will be bundled in the platform, this doesn't mean
that we'll start using it. It's just there for third party extension
writers, but for the official platform Prototype will continue to be the
official library, at least for the short future.
On Mon, Jun 18, 2012 at 11:53 AM, Guillaume Lerouge <guillaume(a)xwiki.com
wrote:
Hi,
>
> +1 as well, jQuery the de facto standard for many web applications today.
>
> Guillaume
>
> On Mon, Jun 18, 2012 at 10:42 AM, Andreas Jonsson <aj(a)member.fsf.org>
> wrote:
>
> +1
>>
>> Best Regards,
>>
>> /Andreas
>>
>> 2012-06-16 02:28, Jerome Velociter skrev:
>>
>> Hi devs,
>>
>>>
>>> Now that all the scripts on the Internets are implemented as jQuery
>>> plugins, should we bite the bullet and make it easier for extensions
>>> developers to integrate such scripts ?
>>> Note it would not necessarily mean we use it ourselves in web/XE.
>>>
>>> If we don't do something about it, there is the risk that many
>>>
>> extensions
>
>> bring their own jQuery to the party, which will translate in slower page
>>> loads and more importantly a less enjoyable extension developer
>>> experience.
>>>
>>> An alternative idea would be an "official" jQuery extension (with
a
>>> JSX)
>>> that other extensions can depend upon, should they need jQuery.
>>>
>>> What do you think ?
>>>
>>> Jerome
>>>
>>
4512
days inactive
4528
days old
21 comments
10 participants
participants (10)
-
Andreas Jonsson -
Caleb James DeLisle -
Eduard Moraru -
Guillaume Lerouge -
Ionut Maxim -
Jerome Velociter -
Marius Dumitru Florea -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol