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.

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

Reply via email to