Hi devs, On 09/21/2010 06:43 PM, Anca Luca wrote: > Hi all, > > On 09/21/2010 05:55 PM, Vincent Massol wrote: >> >> On Sep 20, 2010, at 7:27 PM, Jerome Velociter wrote: >> >>> On Mon, Sep 20, 2010 at 6:50 PM, Anca Luca<[email protected]> wrote: >>> >>>> >>>> >>>> On 09/20/2010 06:16 PM, Jerome Velociter wrote: >>>>> On Mon, Sep 20, 2010 at 5:40 PM, Anca Luca<[email protected]> wrote: >>>>> >>>>>> Hi devs, >>>>>> >>>>>> actually after a discussion I had with Vincent about naming, we thought >>>>>> of the following approach, for a more general purpose: >>>>>> >>>>>> 1/ section turns into ** container ** and it gets a parameter called >>>>>> **layoutStyle** to specify the type of layout for its contents. One of >>>>>> the possible values of this param would be "columns" and it would be the >>>>>> only one implemented for the moment. >>>>>> >>>>>> 2/ the content of this container macro would be a **list of groups**, >>>>>> wiki syntax groups, like ((( ... ))). There's no point of having a macro >>>>>> that does nothing else but specify that some items should be grouped >>>>>> together. >>>>>> >>>>>> With these, the syntax of columned content would now be: >>>>>> >>>>>> {{container layoutStyle="columns"}} >>>>>> ((( some wiki content ))) >>>>>> ((( some other wiki content))) >>>>>> {{/container}} >>>>>> >>>>> >>>>> >>>>> I don't like too much "container", it's not very explicit its use is >>>>> "layouting". Do you see there are other uses? Why not "{{layout >>>>> style='columns'}}" ? >>>> >>>> For example you could use it to also provide borders, and size, >>>> eventually ending up implementing the box as a special case of container >>>> macro. >>>> >>>>> >>>>> Also, if you abandon the column macro, you abandon the possibility to its >>>>> potential parameters. >>>> >>>> This is a very good argument actually, particularly if we think about >>>> the simple case of columns that take percents of the page width, the >>>> percent should be passable as a parameter of the column macro, I don't >>>> like the idea of specially parsing the group parameters. >>>> >>>> WDYT? >>>> >>>> Also if we think about a border layout (a la Swing), we'd need a group >>>> to specify its position. >>>> >>>> In this case, a new vote would be for the name of the inner macro, which >>>> needs to have a suggestive name. Proposals: >>>> >>>> a) content >>>> b) item >>>> c) group >>>> d) widget >>>> e) part >>>> f) element >>>> g) entity >>>> >>>> >>> I like "item" >>> >>> could be containerItem, containerElement ? >>> >>> "group" is too technical IMHO. >> >> It's possible to use any kind of parameter for groups (parameters aren't >> restricted to parameters having a meaning in HTML) so I don't see this as a >> problem at all. > > After a discussion that clearified some of my concerns about the role of > (%%) parameters, I am quite convinced that it's ok to use groups params, > and we should stick to using groups. > > Since everybody agreed with groups before, except for Jerome who raised > the parameters issue, I will consider those as real +1s for this > solution, and Jerome's vote as a +0, so no -. > > The main advantage of using groups is not redefining something with the > same purpose, especially because of it being a special case (see below > Vincent's remarks about handling macros that cannot be used toplevel). > > I will prepare this solution and commit.
I committed a first version of the container macro, demonstrating the approach I plan to take, at http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-macro-container/ to be moved in the platform once I manage to write some tests. I would like a second opinion about the approach. Thanks, Anca > > Thanks, > Anca > >> >> The only thing we would need to agree and it's more general than this issue >> is how to introduce namespaces for parameters since otherwise we would have >> potential collisions. We discussed it a long time ago if I remember >> correctly but we've not really worked on it. > > I will try to see what I can do about that, for this case. > >> >> My idea would be to introduce an "html" namespace for parameters and a >> "layout" namespace for the layout/container macro. The XHTML renderer would >> copy as is any parameter in the "html" namespace. >> >> Some examples: >> >> (% html:style="...." %) >> whatever >> >> {{layout/container...}} >> (% layout:position = "south" %) >> ((( ... ))) >> {{/layout/container}} >> >> Now I don't personally really care whether we use groups or a macro but I >> find it better to reuse something that exists and that is meant for this >> purpose rather than invent a new thing. Also with a macro we'd need (if we >> want to be perfect) to find a way so that the macro isn't displayed as a top >> level macro available in the WYSIWYG but only as a macro that is made >> available when editing the content of the layout/container macro. In the >> first place we could simply not do this of course and have a check inside >> the nested macro so that it checks what macro is its parent and display an >> error if not used correctly but it's not perfect. >> >> Thanks >> -Vincent >> >>>> My +1 for c). >>>> >>>> WDYT? in general about this limitation and in particular about the name >>>> of the macro to use. >>>> >>>>> Still one could use group parameters as a replacement, >>>>> but you cannot achieve exactly the same (from the WYSIWYG interaction >>>>> perspective for example). >>>> >>>> The wysiwyg cannot handle nested macros in any case, >>> >>> >>> >>> I know, but I dare to hope they be supported at some point :) >>> >>> Jerome. >>> >>> >>> >>>> at least not for >>>> the moment and I don't think it's really that much envisaged. >>>> >>>> Thanks, >>>> Anca >>>> >>>>> >>>>> +0 anyway >>>>> >>>>> Jerome. >>>>> >>>>> >>>>>> The dashboard macro would then just delegate to a container macro with >>>>>> columns layout style. >>>>>> >>>>>> I like this approach, +1. >>>>>> >>>>>> WDYT? >>>>>> >>>>>> Once I get your votes, I will commit this in the platform. >>>>>> >>>>>> Thanks, >>>>>> Anca >>>>>> >>>>>> On 09/17/2010 03:56 PM, Anca Luca wrote: >>>>>>> Hi devs, >>>>>>> >>>>>>> wdyt about committing the section& macro columns from the contrib >>>>>>> ( >>>>>> >>>> https://svn.xwiki.org/svnroot/xwiki/contrib/projects/xwiki-macro-column/) >>>>>>> in the platform macros, along with a first, very simple implementation >>>>>>> of the dashboard macro (which for the moment only delegates to the >>>>>>> section macro)? >>>>>>> >>>>>>> This would be the first step towards the implementation of the >>>>>>> dashboard, and the plan is to be done before 2.5M2. >>>>>>> >>>>>>> Here's my +1. >>>>>>> >>>>>>> WDYT? >>>>>>> Anca >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
