21 Sep
2011
21 Sep
'11
6:43 p.m.
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`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
21 Sep
21 Sep
9:41 p.m.
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)
Any other idea?
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
22 Sep
22 Sep
1:45 a.m.
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:
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.
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) 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.
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
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
11:46 a.m.
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:
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
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.
Guillaume
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 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.
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
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
12:08 p.m.
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:
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.
Thanks
-Vincent
On 09/21/2011 03:41 PM, Vincent Massol wrote:
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
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. 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 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.
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
>
3:12 p.m.
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:
XEM
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.
Jerome
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.
Feature-wise, the work proposed by Edy is very good. In short, it turns 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.
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.
Thanks
-Vincent
--
Jérôme Velociter
Winesquare
http://www.winesquare.net/
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
3:18 p.m.
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:
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...
Thanks
-Vincent
On Sep 22, 2011, at 11:46 AM, Guillaume Lerouge wrote:
XEM
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. 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 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.
Jerome
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 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
3:25 p.m.
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:
such
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.
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 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...
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
>
>> 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
3:40 p.m.
On Sep 22, 2011, at 3:25 PM, Jerome Velociter wrote:
On Thu, Sep 22, 2011 at 3:18 PM, Vincent Massol
<vincent(a)massol.net> wrote:
Could you explain again because I don't remember it and I don't see it your
previous email?
On Sep 22, 2011, at 3:12 PM, Jerome Velociter wrote:
such
I didn't really gave -1 ; and I explained why I think it's bad. 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 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'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
Jerome.
Thanks
-Vincent
_______________________________________________
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 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
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
4:09 p.m.
On Sep 22, 2011, at 3:52 PM, Jerome Velociter 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)
In addition to what I've mentioned above, the problem jerome is that with this
reasoning we'll never progress and we'll keep increasing our technical debt. Look
at how many years have passed already on this and the progress we've made… Answer:
none. Why: because it's simpler to just add a hack than to bit the bullet… ;)
Thanks
-Vincent
On Thu, Sep 22, 2011 at 3:40 PM, Vincent Massol
<vincent(a)massol.net> wrote:
We have a lot of pages using JSX and I don't feel it's dirty.
That said what I don't find clean is that it means that extension are using
non-defined extension points and since those are not explicit extension points we can
break them at any time. So for me what we need to do with IX is defined explicit extension
points (equivalent of APIs in Java code for ex).
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. 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. 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.
I think it's ok that extensions appear after the main page is loaded, as they become
available. I don't see a big issue with this.
Especially if some of those extensions do perform AJAX
requests, like
the annotations extension is doing right now.
What is this AJAX request doing for the annotation extension?
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.
All I'm saying is that right now JSX is the best IX implementation we have. I'm
not saying we shouldn't do better (we should!).
Hardcoding something is not an IX… it's just increasing our hacks and augmenting our
technical debt + it doesn't offer any solution for anyone not being a committer to
extend the XWiki platform for his own extension and I don't think it's a good idea
to consider extension writers second class citizens if they're not committers…
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.
Jerome.
>
> Thanks
> -Vincent
>
>> 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
4:28 p.m.
On Thu, Sep 22, 2011 at 4:09 PM, Vincent Massol <vincent(a)massol.net> wrote:
Getting annotatations for the current page.
Then the solution is to invest in IX : making extension writter hack the UI
with javascript IS also making them second class citizens.
think
For me, and I repeat I speak only for bundled extensions (so apparently NOT
talking about workspaces here, but in a generic manner for bundled
extensions), building XE with extension that inject their content in JS is
also increasing technical debt. Maybe not the debt of XWiki Platform, but
the debt of XE.
Jerome
On Sep 22, 2011, at 3:52 PM, Jerome Velociter wrote:
added
elements
Well you didn't write the annotations extension (me neither, but I know what
it looks like). I guess you have to trust me on this :
On Thu, Sep 22, 2011 at 3:40 PM, Vincent Massol
<vincent(a)massol.net>
wrote:
On Sep 22, 2011, at 3:25 PM, Jerome Velociter wrote:
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 >>>>> 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.
>
> 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 from JavaScript might keep the platform code
clean, it makes the
extension
code dirty.
We have a lot of pages using JSX and I don't feel it's dirty.
That said what I don't find clean is that it means that extension are using
non-defined extension points and since those are not explicit extension
points we can break them at any time. So for me what we need to do with IX
is defined explicit extension points (equivalent of APIs in Java code for
ex).
As I said, if you have a lot of hooks on dom loaded event that are doing
complex stuff, like manipulating the DOM, AJAX response handlers, etc. it
will feel clumsy. You will perform actions on the page and the browser will
not respond immediatly as it will have a whole stack of DOM manipulation,
event handlers etc. to perform before.
I repeat myself : this is not something you can feel now because only the
annotations are doing that, but make it a lot of extensions like the
annotations I'm pretty sure it will be a different story.
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.
I think it's ok that extensions appear after the main page is loaded, as
they become available. I don't see a big issue with this.
Especially if
some of those extensions do perform AJAX requests, like
the annotations extension is doing right now.
What is this AJAX request doing for the annotation extension?
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.
All I'm saying is that right now JSX is the best IX implementation we have.
I'm not saying we shouldn't do better (we should!).
Hardcoding something is not an IX… it's just increasing our hacks and
augmenting our technical debt + it doesn't offer any solution for anyone not
being a committer to extend the XWiki platform for his own extension and I
don't think it's a good idea to consider extension writers second class
citizens if they're not committers…
>> 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.
OK, I didn't understand it like this, sorry about that. Indeed I don't 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)
In addition to what I've mentioned above, the problem jerome is that with
this reasoning we'll never progress and we'll keep increasing our technical
debt. Look at how many years have passed already on this and the progress
we've made… Answer: none. Why: because it's simpler to just add a hack than
to bit the bullet… ;)
Thanks
-Vincent
--
Jérôme Velociter
Winesquare
http://www.winesquare.net/
Jerome.
>
> Thanks
> -Vincent
>
>> 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
4849
days inactive
4850
days old
11 comments
5 participants
participants (5)
-
Eduard Moraru -
Guillaume Lerouge -
Jerome Velociter -
Sergiu Dumitriu -
Vincent Massol