22 Sep
2011
22 Sep
'11
3:52 p.m.
On Thu, Sep 22, 2011 at 3:40 PM, Vincent Massol <vincent(a)massol.net> wrote:
OK, I didn't understand it like this, sorry about that. Indeed I don't think
it's good to have hooks for external extensions. (my vision is: XE is the
product we ship right now, and it's ok to make sacrifices like we did for
forgot username/reset password application to make a better product)
Jerome.
On Sep 22, 2011, at 3:25 PM, Jerome Velociter wrote:
Could you explain again because I don't remember it and I don't see it your
previous email?
First, as I said, it makes the extension code awkward. Injecting UI elements
from JavaScript might keep the platform code clean, it makes the extension
code dirty.
Second, IMO if all (bundled) extensions were to do this, you would have a
very clumsy page load, especially on low end machines running a (relatively)
old browser. You would have a latency of couple of seconds between the time
you think the page is loaded and the time you can actually interact with the
page. Especially if some of those extensions do perform AJAX requests, like
the annotations extension is doing right now. In my opinion this is bad, and
as much as possible the DOM sent to the browser should be complete (there is
almost no extra cost to do such in comparison with the initial cost of the
HTTP request). Right now you don't feel it because only annotations are
build this way. Make it 10+ such extensions on IE8 on a not so powerful
machine and you will feel it, I'm pretty sure.
On Thu, Sep 22, 2011 at 3:18 PM, Vincent Massol
<vincent(a)massol.net>
wrote:
>
> On Sep 22, 2011, at 3:12 PM, Jerome Velociter wrote:
>
>> On Thu, Sep 22, 2011 at 12:08 PM, Vincent Massol <vincent(a)massol.net>
> wrote:
>>
>>>
>>> On Sep 22, 2011, at 11:46 AM, Guillaume Lerouge wrote:
>>>
>>>> Hi,
>>>>
>>>> On Thu, Sep 22, 2011 at 1:45 AM, Sergiu Dumitriu
<sergiu(a)xwiki.com>
>>> wrote:
>>>>
>>>>> On 09/21/2011 03:41 PM, Vincent Massol wrote:
>>>>>> Hi Eddy and all,
>>>>>>
>>>>>> On Sep 21, 2011, at 6:43 PM, Eduard Moraru wrote:
>>>>>>
>>>>>>> Hi devs,
>>>>>>>
>>>>>>> As part for the 3.2 Roadmap, the plan for the workspaces
feature
was
>>> to
>>>>> add
>>>>>>> some hooks into the platform that could accept a workspaces
> extension
>>> if
>>>>> an
>>>>>>> admin decided to install it.
>>>>>>>
>>>>>>> Without adding these hooks, there currently isn`t any
mechanism
> (like
>>>>>>> Interface Extensions, but not limited to that) that allows a
simple
>>>>>>> application to modify
whatever it wishes (like user profile
> sections,
>>>>>>> administration sections, top menu, etc.) so I went ahead and
added
>>> some
>>>>> code
>>>>>>> into the platform that executes only when the workspaces
extension
>>> (wiki
>>>>>>> pages and component/service) is installed.
>>>>>>
>>>>>> I don't like this too much for 2 reasons:
>>>>>> 1) the workspaces app is not part of the platform ATM. It would
be
> like
>>>>> someone we don't know coding an application and sending us a
patch
to
>>> modify
>>>>> the platform code to test if his own personal app is installed or
not
>>>>>> 2) it keeps adding
kludges instead of finding a real solution
>>>>>>
>>>>>> To help with point 1), we could vote the fact that we're ok
to have
>>>>> workspaces in the platform but that doesn't solve 2).
>>>>>>
>>>>>> We could look at it point by point and find a solution for each
> point.
>>>>>>
>>>>>> IMO ATM you should use jsx to add those entries so that no change
is
>>>>> required in the platform. I
know some of you don't like this
solution
>>> but
>>>>> IMO the best right now when the application is not part of the
> platform.
>>>>>>
>>>>>> Then we need to open a discussion for adding extension points
for
> each
>>>>> location where you need it.
>>>>>>
>>>>>> One solution would be to use XClasses to provide extension
points.
>>>>>>
>>>>>> Point 1: Ability to add User tabs. There are several ways in
which
> this
>>>>> can be achieved.
>>>>>> Example solution: Introduce a UserTabClass and add as many tabs
as
>>> there
>>>>> are UseTabClass objects in the wiki
>>>>>>
>>>>>> Point 2: Ability to add menu entries in the top level menu.
>>>>>> Example solution: Have a MenuEntryClass and a
MenuItemEntryClass,
> each
>>>>> having 2 fields: one field for the menu entry name and one for the
>>> position.
>>>>> The construct the menu dynamically
>>>>>>
>>>>>> The issue with these solutions is performance. A solution would
be
to
>>> add
>>>>> a module and have java listener listening to object changes + an API
> to
>>>>> return the data. However this maybe slightly too complex. BTW it
could
>>> be
>>>>> interesting to offer a generic script service to do this (the idea
>>> would be
>>>>> to offer an active cache that would refresh when an XObject is
> updated).
>>>>>>
>>>>>> Of course another solution would simply be to bite the bullet
and
> start
>>>>> implementing IX… ;) (I need to read again Sergiu's design doc
about
it
>>> since
>>>>> I have forgotten how Sergiu planned to implement it)
>>>>>
>>>>> The major blocker for me is the raw velocity parsing done on the .vm
>>>>> templates. One step forward would be to implement support for any
kind
>>>>> of templates for generating
the response, using the full power of
the
>>>>> rendering engine. But
that's something for another thread.
>>>>>
>>>>>> Any other idea?
>>>>>
>>>>> Accept Edy's patches as a temporary solution, pushing for a
proper
>>>>> cleanup in the next releases.
>>>>>
>>>>> I don't know how urgent these changes are, we should decide
together
> if
>>>>> it's OK to skip these changes for 3.2 and instead work on a more
>>>>> flexible way of integrating them in 3.3.
>>>>>
>>>>
>>>> Feature-wise, the work proposed by Edy is very good. In short, it
turns
>>> XEM
>>>> into a tool that can be used to easily manage wiki-based communities,
>>> which
>>>> is a feature that I see users requesting a lot these days. People I
> talk
>>>> with keep asking me about social and communities in XWiki and I've
seen
>>>> several workaround
implementations on projects I'm involved with
> already.
>>>>
>>>> Thus I'm very much in favor of making them available in XE 3.2,
>>> especially
>>>> given that Edy spent a lot of time working on them to have them ready
> for
>>>> the release.
>>>>
>>>> I agree that his solution is far from clean, but we're still waiting
> for
>>> a
>>>> clean IX mechanism that I do not believe will be ready for 3.3. Thus
> this
>>>> means that waiting for the IX mechanism to make the Workspaces
feature
>>>> available would delay it by about
6 months. I'm not in favor of this
>>>> solution.
>>>
>>> Using jsx doesn't require any change in the platform. This means that
XE
>>> right now is compatible with the
workspaces application. That's the
> point
>>> and how extensions should be: independent of the platform (no hard
> links).
>>>
>>> So there's no issue of timeframe if Eddy is ok to use JSX.
>>>
>>> JSX is currently our clean solution for IX. There's no other way ATM.
> This
>>> is how anyone adds UI elements cleanly to an existing XE (apart from
>>> modifying templates/pages but that's not clean since an upgrade will
>>> overwrite those changes or at the very minimum you'll need to do a
> merge).
>>>
>>> ATM I'm very strongly in favor of using JSX for this kind of
integration
>>> (for extensions) till we propose a
better IX solution.
>>>
>>
>> I'm -0 tending to -1 to advertise this as the clean way of integrating
> such
>> feature. When you say this, the message I read is "you can do it if you
> want
>> but your code will be awkward". Until we have IX, I prefer we accept to
>> introduce hooks the way the "forgot username/reset password
application"
> is
>> built upon. At least the awkwardness is shared between the platform and
> the
>> feature.
>
> So you're willing for everyone in the world to submit patches to
> xwiki-platform to ask us to add static hooks for their own applications
?
Now
it's my turn to be -1 ;)
Also it's not enough to give a -1 jerome, you need to have arguments and
explain why it's a problem...
I didn't really gave -1 ; and I explained why I think it's bad. I'm not talking about external features. I
think if we were to integrate
workspaces, it would be a feature we would advertise (application
packaged
by default, mentionned in the release notes and
all - am I wrong ?)
ATM workspaces is not integrated. It's supposed to be an extension. No vote
has been sent to integrate it yet AFAIK.
Thanks
-Vincent
--
Jérôme Velociter
Winesquare
http://www.winesquare.net/
_______________________________________________
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
--
Jérôme Velociter
Winesquare
http://www.winesquare.net/
Jerome.
>
> Thanks
> -Vincent
>
>> Jerome
>>
>>
>>> Thanks
>>> -Vincent
>>>
>>>> Guillaume
>>>>
>>>>> Thanks
>>>>>> -Vincent
>>>>>>
>>>>>>>
>>>>>>> I`ve created http://jira.xwiki.org/browse/XWIKI-6991 with
some
>>> details
>>>>> about
>>>>>>> what I have done and made a pull request at
>>>>>>> https://github.com/xwiki/xwiki-platform/pull/24 since I did
not
> want
>>> to
>>>>> rush
>>>>>>> at applying the changes without running them by you guys.
>>>>>>>
>>>>>>> I`ve broken the issue down to subtasks with separate commits
to
make
>>> the
>>>>>>> review easier.
>>>>>>>
>>>>>>> There currently is a demo server for the workspaces feature
at
>>>>>>> http://wiki30-demo.xwiki.com but I will have to update it
tomorrow
>>> with
>>>>> the
>>>>>>> latest version. Not much changed, you can see the visible
changes
in
>>> the
>>>>>>> specific jira subtasks (screenshots).
>>>>>>>
>>>>>>> The goal would be for this to make it into 3.2 so that people
could
> then
>>>>> install (the soon to be released) workspaces extension and try it
out.
>>>>>
>>>>> Please take some time, if possible, to look over the proposed
changes
>>> and
>>>>> spot any problems.
>>>>>
>>>>> Thanks,
>>>>> Eduard
>>>
>
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
--
Jérôme Velociter
Winesquare
http://www.winesquare.net/
_______________________________________________
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