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.