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 <[email protected]> wrote: > On Fri, Mar 1, 2013 at 2:15 PM, Jean-Vincent Drean <[email protected]> wrote: > >> On Fri, Mar 1, 2013 at 12:34 PM, Denis Gervalle <[email protected]> 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
