1 Mar
2013
1 Mar
'13
4:05 p.m.
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 <dgl(a)softec.lu> wrote:
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).
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.
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.
On Fri, Mar 1, 2013 at 2:15 PM, Jean-Vincent Drean
<jv(a)xwiki.com> wrote:
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.
On Fri, Mar 1, 2013 at 12:34 PM, Denis Gervalle
<dgl(a)softec.lu> wrote:
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 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.
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 ?
Skin extension ? IX ?
We've discussed IX for a long time, I see UIXs as our pragmatic
implementation (some would say poor-man IXs).
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 ?
This seems to be the idea, have I missed something ?
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 :)