[Proposal] Provide UI extension points in the current set of templates

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

[Proposal] Provide UI extension points in the current set of templates

Jean-Vincent Drean
Hi,

in 4.x we introduced UI Extensions (UIX) and "Extension Points", it
allows applications to come and plug their bits of UI where it is
possible [1]. 5.x is a good time to provide a list of useful Extension
Points (UIXP) in our velocity templates, allowing applications to plug
themselves in, for example : the header, before the content, the
footer, etc.

To allow this I can think of 2 strategies:

== 1) Manually add UIXPs ==

Actions:

* Discuss where are the common places where applications would like to
plug (in our opinion)
* Make a lengthy list
* Vote it
* Introduce an API call (services.uix.getExtensions()) for each item in the list
* Commit it

Pros:

* We can carefully build the UI API

Cons:

* We can't think of everything
* Long process
* Overridden templates won't display the extensions

== 2) Instrument our templating mechanism with UIXPs ==

Actions:

* Modify the #template macro so that it create UIXPs before and after
the parseTemplate call. Calling #template.vm would create the
following UIXP:
** platform.template.global.before (or:
platform.template.global.above, platform.template.global.top)
** platform.template.global.after (or: platform.template.global.below,
platform.template.global.bottom)
* Commit it

Pros:

* A lot of available UIXPs
* We've worked on our template architecture for a long time, UIXP
would benefit from that
* Quick process

Cons:

* It'd make our current template architecture an API ... but since
templates can be overridden in skins, it already is one.
* A lot of API calls (but tests with YourKit shows that it doesn't
impact performance)

Note:

2) doesn't exclude 1), we'd probably still need to introduce UIXP
within templates, but we'd have way less UIX API calls with this
method.

WDYT ?

I guess it's quite obvious that my opinion is biased, I've started
playing with 2) and it's quite cool :)

[1] http://extensions.xwiki.org/xwiki/bin/view/Extension/UIExtension+Module

Thanks,
JV.
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Provide UI extension points in the current set of templates

Jean-Vincent Drean
Screenshots of 2) in action:

http://dev.xwiki.org/xwiki/bin/view/Design/UIExtensions

On Thu, Feb 28, 2013 at 12:47 PM, Jean-Vincent Drean <[hidden email]> wrote:

> Hi,
>
> in 4.x we introduced UI Extensions (UIX) and "Extension Points", it
> allows applications to come and plug their bits of UI where it is
> possible [1]. 5.x is a good time to provide a list of useful Extension
> Points (UIXP) in our velocity templates, allowing applications to plug
> themselves in, for example : the header, before the content, the
> footer, etc.
>
> To allow this I can think of 2 strategies:
>
> == 1) Manually add UIXPs ==
>
> Actions:
>
> * Discuss where are the common places where applications would like to
> plug (in our opinion)
> * Make a lengthy list
> * Vote it
> * Introduce an API call (services.uix.getExtensions()) for each item in the list
> * Commit it
>
> Pros:
>
> * We can carefully build the UI API
>
> Cons:
>
> * We can't think of everything
> * Long process
> * Overridden templates won't display the extensions
>
> == 2) Instrument our templating mechanism with UIXPs ==
>
> Actions:
>
> * Modify the #template macro so that it create UIXPs before and after
> the parseTemplate call. Calling #template.vm would create the
> following UIXP:
> ** platform.template.global.before (or:
> platform.template.global.above, platform.template.global.top)
> ** platform.template.global.after (or: platform.template.global.below,
> platform.template.global.bottom)
> * Commit it
>
> Pros:
>
> * A lot of available UIXPs
> * We've worked on our template architecture for a long time, UIXP
> would benefit from that
> * Quick process
>
> Cons:
>
> * It'd make our current template architecture an API ... but since
> templates can be overridden in skins, it already is one.
> * A lot of API calls (but tests with YourKit shows that it doesn't
> impact performance)
>
> Note:
>
> 2) doesn't exclude 1), we'd probably still need to introduce UIXP
> within templates, but we'd have way less UIX API calls with this
> method.
>
> WDYT ?
>
> I guess it's quite obvious that my opinion is biased, I've started
> playing with 2) and it's quite cool :)
>
> [1] http://extensions.xwiki.org/xwiki/bin/view/Extension/UIExtension+Module
>
> Thanks,
> JV.



--
Jean-Vincent Drean,
XWiki.
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Provide UI extension points in the current set of templates

vmassol
Administrator
In reply to this post by Jean-Vincent Drean
Hi,

On Feb 28, 2013, at 12:47 PM, Jean-Vincent Drean <[hidden email]> wrote:

> Hi,
>
> in 4.x we introduced UI Extensions (UIX) and "Extension Points", it
> allows applications to come and plug their bits of UI where it is
> possible [1]. 5.x is a good time to provide a list of useful Extension
> Points (UIXP) in our velocity templates, allowing applications to plug
> themselves in, for example : the header, before the content, the
> footer, etc.
>
> To allow this I can think of 2 strategies:
>
> == 1) Manually add UIXPs ==
>
> Actions:
>
> * Discuss where are the common places where applications would like to
> plug (in our opinion)
> * Make a lengthy list
> * Vote it
> * Introduce an API call (services.uix.getExtensions()) for each item in the list
> * Commit it
>
> Pros:
>
> * We can carefully build the UI API
>
> Cons:
>
> * We can't think of everything
> * Long process
> * Overridden templates won't display the extensions
>
> == 2) Instrument our templating mechanism with UIXPs ==
>
> Actions:
>
> * Modify the #template macro so that it create UIXPs before and after
> the parseTemplate call. Calling #template.vm would create the
> following UIXP:
> ** platform.template.global.before (or:
> platform.template.global.above, platform.template.global.top)
> ** platform.template.global.after (or: platform.template.global.below,
> platform.template.global.bottom)
> * Commit it
>
> Pros:
>
> * A lot of available UIXPs
> * We've worked on our template architecture for a long time, UIXP
> would benefit from that

I don't think this is quite true. We've been wanting to clean up our templates for a long time now. I'm not sure that considering it as our next API without careful review of each template is a good thing.

Now as you say 1) and 2) are compatible and we need to do 1) anyway.

I personally prefer 1) since a) a template isn't necessarily a feature boundary and b) any API needs to be introduced carefully since it's very very hard to change afterwards.

Also I'd like to us to get away from templates in some not too far future so this would not go in this direction.

BTW we need to start thinking about how we deprecate and remove UIX for the future… :)

Funnily, for 2) if you add "around" in addition to "before" and "after" then you're offering a new way to create skins :)

I'm not fully against 2) but I think it's an additional feature and should absolutely not replace 1) for any UIX. Now my worry is that it' generic and thus there are templates we're not sure of keeping that would get their UIX automatically. I think I prefer to manually add UIX in the templates we want, instead of being automatic.

Good topic for discussion! :)

Thanks
-Vincent

> * Quick process
>
> Cons:
>
> * It'd make our current template architecture an API ... but since
> templates can be overridden in skins, it already is one.
> * A lot of API calls (but tests with YourKit shows that it doesn't
> impact performance)
>
> Note:
>
> 2) doesn't exclude 1), we'd probably still need to introduce UIXP
> within templates, but we'd have way less UIX API calls with this
> method.
>
> WDYT ?
>
> I guess it's quite obvious that my opinion is biased, I've started
> playing with 2) and it's quite cool :)
>
> [1] http://extensions.xwiki.org/xwiki/bin/view/Extension/UIExtension+Module
>
> Thanks,
> JV.
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Provide UI extension points in the current set of templates

Jean-Vincent Drean
On Thu, Feb 28, 2013 at 1:01 PM, Vincent Massol <[hidden email]> wrote:

> Hi,
>
> On Feb 28, 2013, at 12:47 PM, Jean-Vincent Drean <[hidden email]> wrote:
>
>> Hi,
>>
>> in 4.x we introduced UI Extensions (UIX) and "Extension Points", it
>> allows applications to come and plug their bits of UI where it is
>> possible [1]. 5.x is a good time to provide a list of useful Extension
>> Points (UIXP) in our velocity templates, allowing applications to plug
>> themselves in, for example : the header, before the content, the
>> footer, etc.
>>
>> To allow this I can think of 2 strategies:
>>
>> == 1) Manually add UIXPs ==
>>
>> Actions:
>>
>> * Discuss where are the common places where applications would like to
>> plug (in our opinion)
>> * Make a lengthy list
>> * Vote it
>> * Introduce an API call (services.uix.getExtensions()) for each item in the list
>> * Commit it
>>
>> Pros:
>>
>> * We can carefully build the UI API
>>
>> Cons:
>>
>> * We can't think of everything
>> * Long process
>> * Overridden templates won't display the extensions
>>
>> == 2) Instrument our templating mechanism with UIXPs ==
>>
>> Actions:
>>
>> * Modify the #template macro so that it create UIXPs before and after
>> the parseTemplate call. Calling #template.vm would create the
>> following UIXP:
>> ** platform.template.global.before (or:
>> platform.template.global.above, platform.template.global.top)
>> ** platform.template.global.after (or: platform.template.global.below,
>> platform.template.global.bottom)
>> * Commit it
>>
>> Pros:
>>
>> * A lot of available UIXPs
>> * We've worked on our template architecture for a long time, UIXP
>> would benefit from that
>
> I don't think this is quite true. We've been wanting to clean up our templates for a long time now. I'm not sure that considering it as our next API without careful review of each template is a good thing.
>

I think we've worked on it for a long time, even if it's not perfect
it's been refined for years.
We could however implement 2) and publish a sublist of public/recommended UIXP.

> Now as you say 1) and 2) are compatible and we need to do 1) anyway.
>
> I personally prefer 1) since a) a template isn't necessarily a feature boundary and b) any API needs to be introduced carefully since it's very very hard to change afterwards.
>

Shouldn't we consider our templates as APIs already ? (re: overriding in skins).

> Also I'd like to us to get away from templates in some not too far future so this would not go in this direction.
>

Move away from templates ?

>
> BTW we need to start thinking about how we deprecate and remove UIX for the future… :)
>

For the moment UIXs are snippets of wiki syntax, hooked to an
extension point (String), they were supposed to be future-proof.

> Funnily, for 2) if you add "around" in addition to "before" and "after" then you're offering a new way to create skins :)
>
> I'm not fully against 2) but I think it's an additional feature and should absolutely not replace 1) for any UIX. Now my worry is that it' generic and thus there are templates we're not sure of keeping that would get their UIX automatically. I think I prefer to manually add UIX in the templates we want, instead of being automatic.
>
> Good topic for discussion! :)
>
> Thanks
> -Vincent
>
>> * Quick process
>>
>> Cons:
>>
>> * It'd make our current template architecture an API ... but since
>> templates can be overridden in skins, it already is one.
>> * A lot of API calls (but tests with YourKit shows that it doesn't
>> impact performance)
>>
>> Note:
>>
>> 2) doesn't exclude 1), we'd probably still need to introduce UIXP
>> within templates, but we'd have way less UIX API calls with this
>> method.
>>
>> WDYT ?
>>
>> I guess it's quite obvious that my opinion is biased, I've started
>> playing with 2) and it's quite cool :)
>>
>> [1] http://extensions.xwiki.org/xwiki/bin/view/Extension/UIExtension+Module
>>
>> Thanks,
>> JV.
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs



--
Jean-Vincent Drean,
XWiki.
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Provide UI extension points in the current set of templates

Jean-Vincent Drean
In reply to this post by vmassol
On Thu, Feb 28, 2013 at 1:01 PM, Vincent Massol <[hidden email]> wrote:

> Hi,
>
> On Feb 28, 2013, at 12:47 PM, Jean-Vincent Drean <[hidden email]> wrote:
>
>> Hi,
>>
>> in 4.x we introduced UI Extensions (UIX) and "Extension Points", it
>> allows applications to come and plug their bits of UI where it is
>> possible [1]. 5.x is a good time to provide a list of useful Extension
>> Points (UIXP) in our velocity templates, allowing applications to plug
>> themselves in, for example : the header, before the content, the
>> footer, etc.
>>
>> To allow this I can think of 2 strategies:
>>
>> == 1) Manually add UIXPs ==
>>
>> Actions:
>>
>> * Discuss where are the common places where applications would like to
>> plug (in our opinion)
>> * Make a lengthy list
>> * Vote it
>> * Introduce an API call (services.uix.getExtensions()) for each item in the list
>> * Commit it
>>
>> Pros:
>>
>> * We can carefully build the UI API
>>
>> Cons:
>>
>> * We can't think of everything
>> * Long process
>> * Overridden templates won't display the extensions
>>
>> == 2) Instrument our templating mechanism with UIXPs ==
>>
>> Actions:
>>
>> * Modify the #template macro so that it create UIXPs before and after
>> the parseTemplate call. Calling #template.vm would create the
>> following UIXP:
>> ** platform.template.global.before (or:
>> platform.template.global.above, platform.template.global.top)
>> ** platform.template.global.after (or: platform.template.global.below,
>> platform.template.global.bottom)
>> * Commit it
>>
>> Pros:
>>
>> * A lot of available UIXPs
>> * We've worked on our template architecture for a long time, UIXP
>> would benefit from that
>
> I don't think this is quite true. We've been wanting to clean up our templates for a long time now. I'm not sure that considering it as our next API without careful review of each template is a good thing.
>

There was a need to exclude non-visual templates (*vars.vm for
example), I went a bit further and worked with the following list of
excludes:

#set($uixTemplateExcludes = ['analytics.vm', 'colorThemeInit.vm',
'deprecatedVars.vm', 'editmodes.vm', 'editpanelsvars.vm',
'endpage.vm', 'frequentlyUsedDocs.vm', 'global.vm', 'htmlfooter.vm',
'htmlheader.vm', 'javascript.vm', 'layoutvars.vm',
'layoutExtraVars.vm', 'startpage.vm', 'stylesheets.vm',
'titlevars.vm', 'xwikivars.vm' ])

Here's the list of resulting UIXPs

view:

platform.template.menuview.top
platform.template.menuview.bottom
platform.template.header.top
platform.template.header.bottom
platform.template.contentmenu.top
platform.template.contentmenu.bottom
platform.template.hierarchy.top
platform.template.hierarchy.bottom
platform.template.contentview.top
platform.template.shortcuts.top
platform.template.shortcuts.bottom
platform.template.contentview.bottom
platform.template.docextra.top
platform.template.documentTags.top
platform.template.documentTags.bottom
platform.template.docextra.bottom
platform.template.endpage.top
platform.template.leftpanels.top
platform.template.leftpanels.bottom
platform.template.rightpanels.top
platform.template.rightpanels.bottom
platform.template.footer.top
platform.template.footer.bottom
platform.template.endpage.bottom
platform.template.commentsinline.top
platform.template.commentsinline.bottom

edit:

platform.template.menuview.top
platform.template.menuview.bottom
platform.template.header.top
platform.template.header.bottom
platform.template.editmenu.top
platform.template.editmenu.bottom
platform.template.hierarchy.top
platform.template.hierarchy.bottom
platform.template.editmeta.top
platform.template.editmeta.bottom
platform.template.editwiki.top
platform.template.simpleedittoolbar.top
platform.template.simpleedittoolbar.bottom
platform.template.editactions.top
platform.template.editactions.bottom
platform.template.editwiki.bottom
platform.template.editpanels.top
platform.template.editpanels.bottom
platform.template.footer.top
platform.template.footer.bottom

admin:

platform.template.menuview.top
platform.template.menuview.bottom
platform.template.header.top
platform.template.header.bottom
platform.template.leftpanels.top
platform.template.leftpanels.bottom
platform.template.rightpanels.top
platform.template.rightpanels.bottom
platform.template.footer.top
platform.template.footer.bottom

So I guess the question is, do we think we can live with those forever.
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Provide UI extension points in the current set of templates

Denis Gervalle-2
Hi,

Like Vincent, I do not really think we have thoroughly worked
our templates. IMO, templates should not be considered a good base for
implementing UI extension point blindly.

Currently templates were closely linked with our distributed skin. When we
have introduce Colibri, new templates were added, especially to support the
new content menu for example, and other were ignored, left over since no
more useful. Do you consider UI extension point to be closely linked with
our skin ? What would happen when we implement the bootstrap based skin ?

Just think about the proposal from Cathy, there is no more left panels...
but an applications panel or whatever, how do you expect to support
platform.template.leftpanels.top, platform.template.leftpanels.bottom, what
would be there meaning ?

For sure doing 1) is harder, but creating truly semantic UIXP could have
real advantage for maintenance and compatibility of code that use those
UIXP. So I would really prefer a few initial set of those semantic UIXP to
start with, than that long list of not necessarily useful  and meaningful
ones. And, at least, I would like to read more opinion to consider 2).

Thanks,


On Fri, Mar 1, 2013 at 11:51 AM, Jean-Vincent Drean <[hidden email]> wrote:

> On Thu, Feb 28, 2013 at 1:01 PM, Vincent Massol <[hidden email]>
> wrote:
> > Hi,
> >
> > On Feb 28, 2013, at 12:47 PM, Jean-Vincent Drean <[hidden email]> wrote:
> >
> >> Hi,
> >>
> >> in 4.x we introduced UI Extensions (UIX) and "Extension Points", it
> >> allows applications to come and plug their bits of UI where it is
> >> possible [1]. 5.x is a good time to provide a list of useful Extension
> >> Points (UIXP) in our velocity templates, allowing applications to plug
> >> themselves in, for example : the header, before the content, the
> >> footer, etc.
> >>
> >> To allow this I can think of 2 strategies:
> >>
> >> == 1) Manually add UIXPs ==
> >>
> >> Actions:
> >>
> >> * Discuss where are the common places where applications would like to
> >> plug (in our opinion)
> >> * Make a lengthy list
> >> * Vote it
> >> * Introduce an API call (services.uix.getExtensions()) for each item in
> the list
> >> * Commit it
> >>
> >> Pros:
> >>
> >> * We can carefully build the UI API
> >>
> >> Cons:
> >>
> >> * We can't think of everything
> >> * Long process
> >> * Overridden templates won't display the extensions
> >>
> >> == 2) Instrument our templating mechanism with UIXPs ==
> >>
> >> Actions:
> >>
> >> * Modify the #template macro so that it create UIXPs before and after
> >> the parseTemplate call. Calling #template.vm would create the
> >> following UIXP:
> >> ** platform.template.global.before (or:
> >> platform.template.global.above, platform.template.global.top)
> >> ** platform.template.global.after (or: platform.template.global.below,
> >> platform.template.global.bottom)
> >> * Commit it
> >>
> >> Pros:
> >>
> >> * A lot of available UIXPs
> >> * We've worked on our template architecture for a long time, UIXP
> >> would benefit from that
> >
> > I don't think this is quite true. We've been wanting to clean up our
> templates for a long time now. I'm not sure that considering it as our next
> API without careful review of each template is a good thing.
> >
>
> There was a need to exclude non-visual templates (*vars.vm for
> example), I went a bit further and worked with the following list of
> excludes:
>
> #set($uixTemplateExcludes = ['analytics.vm', 'colorThemeInit.vm',
> 'deprecatedVars.vm', 'editmodes.vm', 'editpanelsvars.vm',
> 'endpage.vm', 'frequentlyUsedDocs.vm', 'global.vm', 'htmlfooter.vm',
> 'htmlheader.vm', 'javascript.vm', 'layoutvars.vm',
> 'layoutExtraVars.vm', 'startpage.vm', 'stylesheets.vm',
> 'titlevars.vm', 'xwikivars.vm' ])
>
> Here's the list of resulting UIXPs
>
> view:
>
> platform.template.menuview.top
> platform.template.menuview.bottom
> platform.template.header.top
> platform.template.header.bottom
> platform.template.contentmenu.top
> platform.template.contentmenu.bottom
> platform.template.hierarchy.top
> platform.template.hierarchy.bottom
> platform.template.contentview.top
> platform.template.shortcuts.top
> platform.template.shortcuts.bottom
> platform.template.contentview.bottom
> platform.template.docextra.top
> platform.template.documentTags.top
> platform.template.documentTags.bottom
> platform.template.docextra.bottom
> platform.template.endpage.top
> platform.template.leftpanels.top
> platform.template.leftpanels.bottom
> platform.template.rightpanels.top
> platform.template.rightpanels.bottom
> platform.template.footer.top
> platform.template.footer.bottom
> platform.template.endpage.bottom
> platform.template.commentsinline.top
> platform.template.commentsinline.bottom
>
> edit:
>
> platform.template.menuview.top
> platform.template.menuview.bottom
> platform.template.header.top
> platform.template.header.bottom
> platform.template.editmenu.top
> platform.template.editmenu.bottom
> platform.template.hierarchy.top
> platform.template.hierarchy.bottom
> platform.template.editmeta.top
> platform.template.editmeta.bottom
> platform.template.editwiki.top
> platform.template.simpleedittoolbar.top
> platform.template.simpleedittoolbar.bottom
> platform.template.editactions.top
> platform.template.editactions.bottom
> platform.template.editwiki.bottom
> platform.template.editpanels.top
> platform.template.editpanels.bottom
> platform.template.footer.top
> platform.template.footer.bottom
>
> admin:
>
> platform.template.menuview.top
> platform.template.menuview.bottom
> platform.template.header.top
> platform.template.header.bottom
> platform.template.leftpanels.top
> platform.template.leftpanels.bottom
> platform.template.rightpanels.top
> platform.template.rightpanels.bottom
> platform.template.footer.top
> platform.template.footer.bottom
>
> So I guess the question is, do we think we can live with those forever.
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>



--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Provide UI extension points in the current set of templates

Jean-Vincent Drean
On Fri, Mar 1, 2013 at 12:34 PM, Denis Gervalle <[hidden email]> wrote:

> Hi,
>
> Like Vincent, I do not really think we have thoroughly worked
> our templates. IMO, templates should not be considered a good base for
> implementing UI extension point blindly.
>
> Currently templates were closely linked with our distributed skin. When we
> have introduce Colibri, new templates were added, especially to support the
> new content menu for example, and other were ignored, left over since no
> more useful. Do you consider UI extension point to be closely linked with
> our skin ? What would happen when we implement the bootstrap based skin ?
>

When I look at the list of UIXP I pasted I don't see it closely
related to a specific skin.
Some names are not perfect, but again I don't think we can afford
renaming them (because of our skin overriding mechanism).
What problem do you foresee with a bootstrap based skin ? Would it be
difficult to keep current template names ?

> Just think about the proposal from Cathy, there is no more left panels...

Does the fact that the proposal have a single panel in the left column
means that we should consider dropping the panel feature ?

> but an applications panel or whatever, how do you expect to support
> platform.template.leftpanels.top, platform.template.leftpanels.bottom, what
> would be there meaning ?
>

We could drop leftpanels.vm and rightpanels.vm and make the panel app
hook itself to platform.template.endpage.top.

> For sure doing 1) is harder, but creating truly semantic UIXP could have
> real advantage for maintenance and compatibility of code that use those
> UIXP. So I would really prefer a few initial set of those semantic UIXP to
> start with, than that long list of not necessarily useful  and meaningful
> ones. And, at least, I would like to read more opinion to consider 2).
>

1) is harder and I'm afraid it can start endless discussions :)

JV,
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Provide UI extension points in the current set of templates

vmassol
Administrator

On Mar 1, 2013, at 2:15 PM, Jean-Vincent Drean <[hidden email]> wrote:

> On Fri, Mar 1, 2013 at 12:34 PM, Denis Gervalle <[hidden email]> wrote:
>> Hi,
>>
>> Like Vincent, I do not really think we have thoroughly worked
>> our templates. IMO, templates should not be considered a good base for
>> implementing UI extension point blindly.
>>
>> Currently templates were closely linked with our distributed skin. When we
>> have introduce Colibri, new templates were added, especially to support the
>> new content menu for example, and other were ignored, left over since no
>> more useful. Do you consider UI extension point to be closely linked with
>> our skin ? What would happen when we implement the bootstrap based skin ?
>>
>
> When I look at the list of UIXP I pasted I don't see it closely
> related to a specific skin.
> Some names are not perfect, but again I don't think we can afford
> renaming them (because of our skin overriding mechanism).
> What problem do you foresee with a bootstrap based skin ? Would it be
> difficult to keep current template names ?
>
>> Just think about the proposal from Cathy, there is no more left panels...
>
> Does the fact that the proposal have a single panel in the left column
> means that we should consider dropping the panel feature ?
>
>> but an applications panel or whatever, how do you expect to support
>> platform.template.leftpanels.top, platform.template.leftpanels.bottom, what
>> would be there meaning ?
>>
>
> We could drop leftpanels.vm and rightpanels.vm and make the panel app
> hook itself to platform.template.endpage.top.
>
>> For sure doing 1) is harder, but creating truly semantic UIXP could have
>> real advantage for maintenance and compatibility of code that use those
>> UIXP. So I would really prefer a few initial set of those semantic UIXP to
>> start with, than that long list of not necessarily useful  and meaningful
>> ones. And, at least, I would like to read more opinion to consider 2).
>>
>
> 1) is harder and I'm afraid it can start endless discussions :)

That's exactly why we need 1) :)

Thanks
-Vincent


_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Provide UI extension points in the current set of templates

Jean-Vincent Drean
On Fri, Mar 1, 2013 at 2:30 PM, Vincent Massol <[hidden email]> wrote:

>
> On Mar 1, 2013, at 2:15 PM, Jean-Vincent Drean <[hidden email]> wrote:
>
>> On Fri, Mar 1, 2013 at 12:34 PM, Denis Gervalle <[hidden email]> wrote:
>>> Hi,
>>>
>>> Like Vincent, I do not really think we have thoroughly worked
>>> our templates. IMO, templates should not be considered a good base for
>>> implementing UI extension point blindly.
>>>
>>> Currently templates were closely linked with our distributed skin. When we
>>> have introduce Colibri, new templates were added, especially to support the
>>> new content menu for example, and other were ignored, left over since no
>>> more useful. Do you consider UI extension point to be closely linked with
>>> our skin ? What would happen when we implement the bootstrap based skin ?
>>>
>>
>> When I look at the list of UIXP I pasted I don't see it closely
>> related to a specific skin.
>> Some names are not perfect, but again I don't think we can afford
>> renaming them (because of our skin overriding mechanism).
>> What problem do you foresee with a bootstrap based skin ? Would it be
>> difficult to keep current template names ?
>>
>>> Just think about the proposal from Cathy, there is no more left panels...
>>
>> Does the fact that the proposal have a single panel in the left column
>> means that we should consider dropping the panel feature ?
>>
>>> but an applications panel or whatever, how do you expect to support
>>> platform.template.leftpanels.top, platform.template.leftpanels.bottom, what
>>> would be there meaning ?
>>>
>>
>> We could drop leftpanels.vm and rightpanels.vm and make the panel app
>> hook itself to platform.template.endpage.top.
>>
>>> For sure doing 1) is harder, but creating truly semantic UIXP could have
>>> real advantage for maintenance and compatibility of code that use those
>>> UIXP. So I would really prefer a few initial set of those semantic UIXP to
>>> start with, than that long list of not necessarily useful  and meaningful
>>> ones. And, at least, I would like to read more opinion to consider 2).
>>>
>>
>> 1) is harder and I'm afraid it can start endless discussions :)
>
> That's exactly why we need 1) :)
>

I meant "endless" literally.

JV.
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Provide UI extension points in the current set of templates

Jean-Vincent Drean
On Fri, Mar 1, 2013 at 2:40 PM, Jean-Vincent Drean <[hidden email]> wrote:

> On Fri, Mar 1, 2013 at 2:30 PM, Vincent Massol <[hidden email]> wrote:
>>
>> On Mar 1, 2013, at 2:15 PM, Jean-Vincent Drean <[hidden email]> wrote:
>>
>>> On Fri, Mar 1, 2013 at 12:34 PM, Denis Gervalle <[hidden email]> wrote:
>>>> Hi,
>>>>
>>>> Like Vincent, I do not really think we have thoroughly worked
>>>> our templates. IMO, templates should not be considered a good base for
>>>> implementing UI extension point blindly.
>>>>
>>>> Currently templates were closely linked with our distributed skin. When we
>>>> have introduce Colibri, new templates were added, especially to support the
>>>> new content menu for example, and other were ignored, left over since no
>>>> more useful. Do you consider UI extension point to be closely linked with
>>>> our skin ? What would happen when we implement the bootstrap based skin ?
>>>>
>>>
>>> When I look at the list of UIXP I pasted I don't see it closely
>>> related to a specific skin.
>>> Some names are not perfect, but again I don't think we can afford
>>> renaming them (because of our skin overriding mechanism).
>>> What problem do you foresee with a bootstrap based skin ? Would it be
>>> difficult to keep current template names ?
>>>
>>>> Just think about the proposal from Cathy, there is no more left panels...
>>>
>>> Does the fact that the proposal have a single panel in the left column
>>> means that we should consider dropping the panel feature ?
>>>
>>>> but an applications panel or whatever, how do you expect to support
>>>> platform.template.leftpanels.top, platform.template.leftpanels.bottom, what
>>>> would be there meaning ?
>>>>
>>>
>>> We could drop leftpanels.vm and rightpanels.vm and make the panel app
>>> hook itself to platform.template.endpage.top.
>>>
>>>> For sure doing 1) is harder, but creating truly semantic UIXP could have
>>>> real advantage for maintenance and compatibility of code that use those
>>>> UIXP. So I would really prefer a few initial set of those semantic UIXP to
>>>> start with, than that long list of not necessarily useful  and meaningful
>>>> ones. And, at least, I would like to read more opinion to consider 2).
>>>>
>>>
>>> 1) is harder and I'm afraid it can start endless discussions :)
>>
>> That's exactly why we need 1) :)
>>
>
> I meant "endless" literally.
>

To be more precise let's say someone writes an app that'd need an UIXP
at platform.template.header.bottom, if we decide to go for 1) he'll
probably take the time to push for this particular UIXP, but that's
it. At that pace the risk is to end up with let's say 10 UIXPs by the
end of 2013.

JV.
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Provide UI extension points in the current set of templates

vmassol
Administrator

On Mar 1, 2013, at 2:46 PM, Jean-Vincent Drean <[hidden email]> wrote:

> On Fri, Mar 1, 2013 at 2:40 PM, Jean-Vincent Drean <[hidden email]> wrote:
>> On Fri, Mar 1, 2013 at 2:30 PM, Vincent Massol <[hidden email]> wrote:
>>>
>>> On Mar 1, 2013, at 2:15 PM, Jean-Vincent Drean <[hidden email]> wrote:
>>>
>>>> On Fri, Mar 1, 2013 at 12:34 PM, Denis Gervalle <[hidden email]> wrote:
>>>>> Hi,
>>>>>
>>>>> Like Vincent, I do not really think we have thoroughly worked
>>>>> our templates. IMO, templates should not be considered a good base for
>>>>> implementing UI extension point blindly.
>>>>>
>>>>> Currently templates were closely linked with our distributed skin. When we
>>>>> have introduce Colibri, new templates were added, especially to support the
>>>>> new content menu for example, and other were ignored, left over since no
>>>>> more useful. Do you consider UI extension point to be closely linked with
>>>>> our skin ? What would happen when we implement the bootstrap based skin ?
>>>>>
>>>>
>>>> When I look at the list of UIXP I pasted I don't see it closely
>>>> related to a specific skin.
>>>> Some names are not perfect, but again I don't think we can afford
>>>> renaming them (because of our skin overriding mechanism).
>>>> What problem do you foresee with a bootstrap based skin ? Would it be
>>>> difficult to keep current template names ?
>>>>
>>>>> Just think about the proposal from Cathy, there is no more left panels...
>>>>
>>>> Does the fact that the proposal have a single panel in the left column
>>>> means that we should consider dropping the panel feature ?
>>>>
>>>>> but an applications panel or whatever, how do you expect to support
>>>>> platform.template.leftpanels.top, platform.template.leftpanels.bottom, what
>>>>> would be there meaning ?
>>>>>
>>>>
>>>> We could drop leftpanels.vm and rightpanels.vm and make the panel app
>>>> hook itself to platform.template.endpage.top.
>>>>
>>>>> For sure doing 1) is harder, but creating truly semantic UIXP could have
>>>>> real advantage for maintenance and compatibility of code that use those
>>>>> UIXP. So I would really prefer a few initial set of those semantic UIXP to
>>>>> start with, than that long list of not necessarily useful  and meaningful
>>>>> ones. And, at least, I would like to read more opinion to consider 2).
>>>>>
>>>>
>>>> 1) is harder and I'm afraid it can start endless discussions :)
>>>
>>> That's exactly why we need 1) :)
>>>
>>
>> I meant "endless" literally.
>>
>
> To be more precise let's say someone writes an app that'd need an UIXP
> at platform.template.header.bottom, if we decide to go for 1) he'll
> probably take the time to push for this particular UIXP, but that's
> it. At that pace the risk is to end up with let's say 10 UIXPs by the
> end of 2013.

I don't understand why you want to consider UIXP different from a Java API for example. For me it's as important and as difficult to remove/modify.

The worse that can happen is not having not enough UIXP but having too many and people starting creating extensions and having all UI-related extensions broken on e.x.o.

Since we're just starting with UIXP it's probably better to do it slowly as we learn it.

That's why I said before that we need to define a strategy for deprecating UIXP. If we have a good strategy that may help in adding new UIXP more easily.

Thanks
-Vincent

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Provide UI extension points in the current set of templates

vmassol
Administrator

On Mar 1, 2013, at 2:52 PM, Vincent Massol <[hidden email]> wrote:

>
> On Mar 1, 2013, at 2:46 PM, Jean-Vincent Drean <[hidden email]> wrote:
>
>> On Fri, Mar 1, 2013 at 2:40 PM, Jean-Vincent Drean <[hidden email]> wrote:
>>> On Fri, Mar 1, 2013 at 2:30 PM, Vincent Massol <[hidden email]> wrote:
>>>>
>>>> On Mar 1, 2013, at 2:15 PM, Jean-Vincent Drean <[hidden email]> wrote:
>>>>
>>>>> On Fri, Mar 1, 2013 at 12:34 PM, Denis Gervalle <[hidden email]> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Like Vincent, I do not really think we have thoroughly worked
>>>>>> our templates. IMO, templates should not be considered a good base for
>>>>>> implementing UI extension point blindly.
>>>>>>
>>>>>> Currently templates were closely linked with our distributed skin. When we
>>>>>> have introduce Colibri, new templates were added, especially to support the
>>>>>> new content menu for example, and other were ignored, left over since no
>>>>>> more useful. Do you consider UI extension point to be closely linked with
>>>>>> our skin ? What would happen when we implement the bootstrap based skin ?
>>>>>>
>>>>>
>>>>> When I look at the list of UIXP I pasted I don't see it closely
>>>>> related to a specific skin.
>>>>> Some names are not perfect, but again I don't think we can afford
>>>>> renaming them (because of our skin overriding mechanism).
>>>>> What problem do you foresee with a bootstrap based skin ? Would it be
>>>>> difficult to keep current template names ?
>>>>>
>>>>>> Just think about the proposal from Cathy, there is no more left panels...
>>>>>
>>>>> Does the fact that the proposal have a single panel in the left column
>>>>> means that we should consider dropping the panel feature ?
>>>>>
>>>>>> but an applications panel or whatever, how do you expect to support
>>>>>> platform.template.leftpanels.top, platform.template.leftpanels.bottom, what
>>>>>> would be there meaning ?
>>>>>>
>>>>>
>>>>> We could drop leftpanels.vm and rightpanels.vm and make the panel app
>>>>> hook itself to platform.template.endpage.top.
>>>>>
>>>>>> For sure doing 1) is harder, but creating truly semantic UIXP could have
>>>>>> real advantage for maintenance and compatibility of code that use those
>>>>>> UIXP. So I would really prefer a few initial set of those semantic UIXP to
>>>>>> start with, than that long list of not necessarily useful  and meaningful
>>>>>> ones. And, at least, I would like to read more opinion to consider 2).
>>>>>>
>>>>>
>>>>> 1) is harder and I'm afraid it can start endless discussions :)
>>>>
>>>> That's exactly why we need 1) :)
>>>>
>>>
>>> I meant "endless" literally.
>>>
>>
>> To be more precise let's say someone writes an app that'd need an UIXP
>> at platform.template.header.bottom, if we decide to go for 1) he'll
>> probably take the time to push for this particular UIXP, but that's
>> it. At that pace the risk is to end up with let's say 10 UIXPs by the
>> end of 2013.
>
> I don't understand why you want to consider UIXP different from a Java API for example. For me it's as important and as difficult to remove/modify.
>
> The worse that can happen is not having not enough UIXP but having too many and people starting creating extensions and having all UI-related extensions broken on e.x.o.
>
> Since we're just starting with UIXP it's probably better to do it slowly as we learn it.
>
> That's why I said before that we need to define a strategy for deprecating UIXP. If we have a good strategy that may help in adding new UIXP more easily.

One interesting idea would be able to create aliases and when we deprecate we wire the old UIXP id to a new UIXP id that is the closest to the old one.

Thanks
-Vincent

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Provide UI extension points in the current set of templates

Jean-Vincent Drean
In reply to this post by vmassol
On Fri, Mar 1, 2013 at 2:52 PM, Vincent Massol <[hidden email]> wrote:

>
> On Mar 1, 2013, at 2:46 PM, Jean-Vincent Drean <[hidden email]> wrote:
>
>> On Fri, Mar 1, 2013 at 2:40 PM, Jean-Vincent Drean <[hidden email]> wrote:
>>> On Fri, Mar 1, 2013 at 2:30 PM, Vincent Massol <[hidden email]> wrote:
>>>>
>>>> On Mar 1, 2013, at 2:15 PM, Jean-Vincent Drean <[hidden email]> wrote:
>>>>
>>>>> On Fri, Mar 1, 2013 at 12:34 PM, Denis Gervalle <[hidden email]> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Like Vincent, I do not really think we have thoroughly worked
>>>>>> our templates. IMO, templates should not be considered a good base for
>>>>>> implementing UI extension point blindly.
>>>>>>
>>>>>> Currently templates were closely linked with our distributed skin. When we
>>>>>> have introduce Colibri, new templates were added, especially to support the
>>>>>> new content menu for example, and other were ignored, left over since no
>>>>>> more useful. Do you consider UI extension point to be closely linked with
>>>>>> our skin ? What would happen when we implement the bootstrap based skin ?
>>>>>>
>>>>>
>>>>> When I look at the list of UIXP I pasted I don't see it closely
>>>>> related to a specific skin.
>>>>> Some names are not perfect, but again I don't think we can afford
>>>>> renaming them (because of our skin overriding mechanism).
>>>>> What problem do you foresee with a bootstrap based skin ? Would it be
>>>>> difficult to keep current template names ?
>>>>>
>>>>>> Just think about the proposal from Cathy, there is no more left panels...
>>>>>
>>>>> Does the fact that the proposal have a single panel in the left column
>>>>> means that we should consider dropping the panel feature ?
>>>>>
>>>>>> but an applications panel or whatever, how do you expect to support
>>>>>> platform.template.leftpanels.top, platform.template.leftpanels.bottom, what
>>>>>> would be there meaning ?
>>>>>>
>>>>>
>>>>> We could drop leftpanels.vm and rightpanels.vm and make the panel app
>>>>> hook itself to platform.template.endpage.top.
>>>>>
>>>>>> For sure doing 1) is harder, but creating truly semantic UIXP could have
>>>>>> real advantage for maintenance and compatibility of code that use those
>>>>>> UIXP. So I would really prefer a few initial set of those semantic UIXP to
>>>>>> start with, than that long list of not necessarily useful  and meaningful
>>>>>> ones. And, at least, I would like to read more opinion to consider 2).
>>>>>>
>>>>>
>>>>> 1) is harder and I'm afraid it can start endless discussions :)
>>>>
>>>> That's exactly why we need 1) :)
>>>>
>>>
>>> I meant "endless" literally.
>>>
>>
>> To be more precise let's say someone writes an app that'd need an UIXP
>> at platform.template.header.bottom, if we decide to go for 1) he'll
>> probably take the time to push for this particular UIXP, but that's
>> it. At that pace the risk is to end up with let's say 10 UIXPs by the
>> end of 2013.
>
> I don't understand why you want to consider UIXP different from a Java API for example. For me it's as important and as difficult to remove/modify.
>

I seriously don't understand how they wouldn't be considered API already.

> The worse that can happen is not having not enough UIXP but having too many and people starting creating extensions and having all UI-related extensions broken on e.x.o.
>

I agree, that's why I suggested having a blacklist for 2) in a
previous email, containing what we've identified as
soon-to-be-deprecated UI elements.

> Since we're just starting with UIXP it's probably better to do it slowly as we learn it.
>
> That's why I said before that we need to define a strategy for deprecating UIXP. If we have a good strategy that may help in adding new UIXP more easily.
>
> Thanks
> -Vincent
>
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs



--
Jean-Vincent Drean,
XWiki.
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Provide UI extension points in the current set of templates

Denis Gervalle-2
In reply to this post by Jean-Vincent Drean
On Fri, Mar 1, 2013 at 2:15 PM, Jean-Vincent Drean <[hidden email]> wrote:

> On Fri, Mar 1, 2013 at 12:34 PM, Denis Gervalle <[hidden email]> wrote:
> > Hi,
> >
> > Like Vincent, I do not really think we have thoroughly worked
> > our templates. IMO, templates should not be considered a good base for
> > implementing UI extension point blindly.
> >
> > Currently templates were closely linked with our distributed skin. When
> we
> > have introduce Colibri, new templates were added, especially to support
> the
> > new content menu for example, and other were ignored, left over since no
> > more useful. Do you consider UI extension point to be closely linked with
> > our skin ? What would happen when we implement the bootstrap based skin ?
> >
>
> When I look at the list of UIXP I pasted I don't see it closely
> related to a specific skin.
>

You should look closer, almost all are related to the way our current skin
is. Let takes more examples:

platform.template.menuview.*
platform.template.contentmenu.* implies we have 2 defined sets of menubars,
not less, not more

platform.template.shortcuts.* was inexistant before colibri, why wouldn't
it be remove next time ?

platform.template.*inline.* implies these * are displayed separately and
inline, by the way, you mention only comments, but there are others...

Do you really see those as semantic UIX ?


> Some names are not perfect, but again I don't think we can afford
> renaming them (because of our skin overriding mechanism).
>

This is not a matter of names, this a matter of semantic IMO.
Or, you consider UIX are linked to Skin. We will soon support Skin
extension (I hope), so we may depends on it. This way, you need a different
extension for each kind of skin (you may mutualize the source somewhat of
course). This could be a way to go.


> What problem do you foresee with a bootstrap based skin ? Would it be
> difficult to keep current template names ?
>
> > Just think about the proposal from Cathy, there is no more left panels...
>
> Does the fact that the proposal have a single panel in the left column
> means that we should consider dropping the panel feature ?
>

This seems to be the idea, have I missed something ?


>
> > but an applications panel or whatever, how do you expect to support
> > platform.template.leftpanels.top, platform.template.leftpanels.bottom,
> what
> > would be there meaning ?
> >
>
> We could drop leftpanels.vm and rightpanels.vm and make the panel app
> hook itself to platform.template.endpage.top.
>

You start thinking about the skin in terme of UIX, and you start minimizing
your templates. Very good.
This is therefore important not to create these UIXP now.


>
> > For sure doing 1) is harder, but creating truly semantic UIXP could have
> > real advantage for maintenance and compatibility of code that use those
> > UIXP. So I would really prefer a few initial set of those semantic UIXP
> to
> > start with, than that long list of not necessarily useful  and meaningful
> > ones. And, at least, I would like to read more opinion to consider 2).
> >
>
> 1) is harder and I'm afraid it can start endless discussions :)


When we add a function for an API, we now have both a deprecation strategy
and an @Unstable annotation to prevent further difficulties. This does not
prevent discussion !
We lacking deprecation for UIX and we have not sufficiently think about it.
So, until we see a nice way to go, please let's only create UIXP for what
we are sure it will be both useful and supported later.
I am sure we could find some semantic UIXP that will not really suffer
discussion like:

- UIXP to add a menu for global feature
- UIXP to add a menu for content feature
- UIXP to add a menu for edit content feature
- UIXP before/after header, footer, content
...

All these concern UI element that will not be dropped, even if we increase
our UI usage. Note that I have not suggested something like UXIP
before/after title, hierarchy,... since those could be implemented as a
UIXP themselves.

This is not endless discussion that we needs, this is more some reflexion
on how we expect to use UIX in the near future.
Starting to think about the implementation of Flamingo skin with that in
mind would probably be a good start. And to avoid lengthy discussion, start
with the obvious, just a few UIXP at a time, taking care of the potential
risk, and exposing some potential usage. I see not point to add a UIX
without at least a small idea on what it could be used for.

Thanks,



>




> JV,
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>



--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Provide UI extension points in the current set of templates

Jean-Vincent Drean
TL;DR: to me, our templates were considered as APIs (because of the
skin-overriding mechanism), that's what drived me to make the 2)
proposal. Since the consensus here seems to be that we can consider
dropping the current template architecture I agree 2) sounds bad and
we should go for 1) (and have a small set of UIXPs + some of our
current UIs moved to UIXs).

On Fri, Mar 1, 2013 at 3:20 PM, Denis Gervalle <[hidden email]> wrote:

> On Fri, Mar 1, 2013 at 2:15 PM, Jean-Vincent Drean <[hidden email]> wrote:
>
>> On Fri, Mar 1, 2013 at 12:34 PM, Denis Gervalle <[hidden email]> wrote:
>> > Hi,
>> >
>> > Like Vincent, I do not really think we have thoroughly worked
>> > our templates. IMO, templates should not be considered a good base for
>> > implementing UI extension point blindly.
>> >
>> > Currently templates were closely linked with our distributed skin. When
>> we
>> > have introduce Colibri, new templates were added, especially to support
>> the
>> > new content menu for example, and other were ignored, left over since no
>> > more useful. Do you consider UI extension point to be closely linked with
>> > our skin ? What would happen when we implement the bootstrap based skin ?
>> >
>>
>> When I look at the list of UIXP I pasted I don't see it closely
>> related to a specific skin.
>>
>
> You should look closer, almost all are related to the way our current skin
> is. Let takes more examples:
>
> platform.template.menuview.*
> platform.template.contentmenu.* implies we have 2 defined sets of menubars,
> not less, not more

Not less indeed, but it doesn't prevent adding more of them.
Now I said the names weren't perfect, indeed menuview could be named
topmenu, contentmenu looks fine to me and I think it's quite
reasonable to assume that we'll continue to need it.

>
> platform.template.shortcuts.* was inexistant before colibri, why wouldn't
> it be remove next time ?
>

I knew this one would backfire on me :)

> platform.template.*inline.* implies these * are displayed separately and
> inline, by the way, you mention only comments, but there are others...
>

I only mentioned those I logged for a simple view request, there are
indeed the 3 others.

> Do you really see those as semantic UIX ?
>
>
>> Some names are not perfect, but again I don't think we can afford
>> renaming them (because of our skin overriding mechanism).
>>
>
> This is not a matter of names, this a matter of semantic IMO.
> Or, you consider UIX are linked to Skin. We will soon support Skin
> extension (I hope), so we may depends on it. This way, you need a different
> extension for each kind of skin (you may mutualize the source somewhat of
> course). This could be a way to go.
>

Skin extension ? IX ?
We've discussed IX for a long time, I see UIXs as our pragmatic
implementation (some would say poor-man IXs).

>
>> What problem do you foresee with a bootstrap based skin ? Would it be
>> difficult to keep current template names ?
>>
>> > Just think about the proposal from Cathy, there is no more left panels...
>>
>> Does the fact that the proposal have a single panel in the left column
>> means that we should consider dropping the panel feature ?
>>
>
> This seems to be the idea, have I missed something ?
>

I haven't seen a discussion about dropping panel support but I might
have missed it (and we'd need one hell of a migration path).

>
>>
>> > but an applications panel or whatever, how do you expect to support
>> > platform.template.leftpanels.top, platform.template.leftpanels.bottom,
>> what
>> > would be there meaning ?
>> >
>>
>> We could drop leftpanels.vm and rightpanels.vm and make the panel app
>> hook itself to platform.template.endpage.top.
>>
>
> You start thinking about the skin in terme of UIX, and you start minimizing
> your templates. Very good.
> This is therefore important not to create these UIXP now.
>
>
>>
>> > For sure doing 1) is harder, but creating truly semantic UIXP could have
>> > real advantage for maintenance and compatibility of code that use those
>> > UIXP. So I would really prefer a few initial set of those semantic UIXP
>> to
>> > start with, than that long list of not necessarily useful  and meaningful
>> > ones. And, at least, I would like to read more opinion to consider 2).
>> >
>>
>> 1) is harder and I'm afraid it can start endless discussions :)
>
>
> When we add a function for an API, we now have both a deprecation strategy
> and an @Unstable annotation to prevent further difficulties. This does not
> prevent discussion !
> We lacking deprecation for UIX and we have not sufficiently think about it.
> So, until we see a nice way to go, please let's only create UIXP for what
> we are sure it will be both useful and supported later.
> I am sure we could find some semantic UIXP that will not really suffer
> discussion like:
>
> - UIXP to add a menu for global feature
> - UIXP to add a menu for content feature
> - UIXP to add a menu for edit content feature
> - UIXP before/after header, footer, content
> ...
>
> All these concern UI element that will not be dropped, even if we increase
> our UI usage. Note that I have not suggested something like UXIP
> before/after title, hierarchy,... since those could be implemented as a
> UIXP themselves.
>
> This is not endless discussion that we needs, this is more some reflexion
> on how we expect to use UIX in the near future.
> Starting to think about the implementation of Flamingo skin with that in
> mind would probably be a good start. And to avoid lengthy discussion, start
> with the obvious, just a few UIXP at a time, taking care of the potential
> risk, and exposing some potential usage. I see not point to add a UIX
> without at least a small idea on what it could be used for.
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Provide UI extension points in the current set of templates

Jérôme Velociter
In reply to this post by vmassol
Hi,

Le 28/02/13 13:01, Vincent Massol a écrit :

> Hi,
>
> On Feb 28, 2013, at 12:47 PM, Jean-Vincent Drean <[hidden email]> wrote:
>
>> Hi,
>>
>> in 4.x we introduced UI Extensions (UIX) and "Extension Points", it
>> allows applications to come and plug their bits of UI where it is
>> possible [1]. 5.x is a good time to provide a list of useful Extension
>> Points (UIXP) in our velocity templates, allowing applications to plug
>> themselves in, for example : the header, before the content, the
>> footer, etc.
>>
>> To allow this I can think of 2 strategies:
>>
>> == 1) Manually add UIXPs ==
>>
>> Actions:
>>
>> * Discuss where are the common places where applications would like to
>> plug (in our opinion)
>> * Make a lengthy list
>> * Vote it
>> * Introduce an API call (services.uix.getExtensions()) for each item in the list
>> * Commit it
>>
>> Pros:
>>
>> * We can carefully build the UI API
>>
>> Cons:
>>
>> * We can't think of everything
>> * Long process
>> * Overridden templates won't display the extensions
>>
>> == 2) Instrument our templating mechanism with UIXPs ==
>>
>> Actions:
>>
>> * Modify the #template macro so that it create UIXPs before and after
>> the parseTemplate call. Calling #template.vm would create the
>> following UIXP:
>> ** platform.template.global.before (or:
>> platform.template.global.above, platform.template.global.top)
>> ** platform.template.global.after (or: platform.template.global.below,
>> platform.template.global.bottom)
>> * Commit it
>>
>> Pros:
>>
>> * A lot of available UIXPs
>> * We've worked on our template architecture for a long time, UIXP
>> would benefit from that
> I don't think this is quite true. We've been wanting to clean up our templates for a long time now. I'm not sure that considering it as our next API without careful review of each template is a good thing.
>
> Now as you say 1) and 2) are compatible and we need to do 1) anyway.
>
> I personally prefer 1) since a) a template isn't necessarily a feature boundary and b) any API needs to be introduced carefully since it's very very hard to change afterwards.
>
> Also I'd like to us to get away from templates in some not too far future so this would not go in this direction.

Could you elaborate ?

You've made us curious :)

Jérôme

>
> BTW we need to start thinking about how we deprecate and remove UIX for the future… :)
>
> Funnily, for 2) if you add "around" in addition to "before" and "after" then you're offering a new way to create skins :)
>
> I'm not fully against 2) but I think it's an additional feature and should absolutely not replace 1) for any UIX. Now my worry is that it' generic and thus there are templates we're not sure of keeping that would get their UIX automatically. I think I prefer to manually add UIX in the templates we want, instead of being automatic.
>
> Good topic for discussion! :)
>
> Thanks
> -Vincent
>
>> * Quick process
>>
>> Cons:
>>
>> * It'd make our current template architecture an API ... but since
>> templates can be overridden in skins, it already is one.
>> * A lot of API calls (but tests with YourKit shows that it doesn't
>> impact performance)
>>
>> Note:
>>
>> 2) doesn't exclude 1), we'd probably still need to introduce UIXP
>> within templates, but we'd have way less UIX API calls with this
>> method.
>>
>> WDYT ?
>>
>> I guess it's quite obvious that my opinion is biased, I've started
>> playing with 2) and it's quite cool :)
>>
>> [1] http://extensions.xwiki.org/xwiki/bin/view/Extension/UIExtension+Module
>>
>> Thanks,
>> JV.
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs

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