On Fri, 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. >
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 > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs -- Jean-Vincent Drean, XWiki. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
