On Mon, Jun 18, 2012 at 3:03 PM, Caleb James DeLisle <[email protected]> wrote: > > > On 06/18/2012 04:11 AM, Thomas Mortagne wrote: >> On Mon, Jun 18, 2012 at 10:02 AM, Vincent Massol <[email protected]> wrote: >>> >>> On Jun 18, 2012, at 9:49 AM, Thomas Mortagne wrote: >>> >>>> On Mon, Jun 18, 2012 at 8:53 AM, Vincent Massol <[email protected]> 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. >> >> 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. > > 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.
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. > > Thanks, > > Caleb > >> >>> >>> 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 >>> [email protected] >>> http://lists.xwiki.org/mailman/listinfo/devs >> >> >> > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
