On Thu, Sep 22, 2011 at 3:18 PM, Vincent Massol <[email protected]> wrote:
> > On Sep 22, 2011, at 3:12 PM, Jerome Velociter wrote: > > > On Thu, Sep 22, 2011 at 12:08 PM, Vincent Massol <[email protected]> > wrote: > > > >> > >> On Sep 22, 2011, at 11:46 AM, Guillaume Lerouge wrote: > >> > >>> Hi, > >>> > >>> On Thu, Sep 22, 2011 at 1:45 AM, Sergiu Dumitriu <[email protected]> > >> 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 ?) 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 > >> [email protected] > >> http://lists.xwiki.org/mailman/listinfo/devs > >> > > > > > > > > -- > > Jérôme Velociter > > Winesquare > > http://www.winesquare.net/ > > _______________________________________________ > > devs mailing list > > [email protected] > > http://lists.xwiki.org/mailman/listinfo/devs > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > -- Jérôme Velociter Winesquare http://www.winesquare.net/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
