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