On Jun 18, 2012, at 3:03 PM, Caleb James DeLisle 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.

Sure but it's not very different from what we already do with extensions ATM.

Thanks
-Vincent

> 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

_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs

Reply via email to