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.
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
