On Mar 1, 2013, at 2:52 PM, Vincent Massol <[email protected]> wrote:
> > On Mar 1, 2013, at 2:46 PM, Jean-Vincent Drean <[email protected]> wrote: > >> On Fri, Mar 1, 2013 at 2:40 PM, Jean-Vincent Drean <[email protected]> wrote: >>> On Fri, Mar 1, 2013 at 2:30 PM, Vincent Massol <[email protected]> wrote: >>>> >>>> On 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. >>>>> 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
