28 Aug
2008
28 Aug
'08
11:14 a.m.
Hi,
Both approaches (macro & wiki syntax) have their advantages & shortcomings.
However, I don't think that's the most important issue right here. To sum
things up, I think the issue devs are having most of the time is that
they're trying to do complex stuff (layout-related or feature-related, for
the filterable / sortable table for instance).
To do so they cannot use the wiki syntax / table macro right now since it's
not powerful enough. However, they still want to use the standard XWiki
table layout (with the usual colors & borders).
So we've got 2 choices : design a wiki implementation of html tables that's
powerful enough to accomodate all the options offered by standard html or
keep simple wiki tables and make it easy for developers to mimic them using
the right class names in their html code.
Mimicking html syntax for classes in XWiki 2.0 syntax :
- Pros : Lots of options available from the syntax, can be edited from
the WYSWIYG editor
- Cons : loses the simplicity of wiki markup, harder to implement right,
new code to learn, clunky interface in the WYSIWYG editor
Making it easy to have HTML tables look like wiki tables :
- Pros : No need to learn a new syntax for developers, easier to
implement, possibly cleaner
- Cons : Need to use the {{xhtml}} macro all the time, cannot be edited
in the WYSIWYG, need to know the name of XWiki classes to use for tables
My take would be that for standard users using a wiki syntax for tables is
easier than a table macro :
Header || Header || Header
Header || item | item
Header || item | item
item | item
item | item
but that we should not try to go too far with that syntax (as Pascal pointed
out, a dev will want the full html table implementation anyway) and rather
try to provide a simple class name that would let devs use the standard
XWiki table CSS rules when they need them.
Sure, this would mean using the wiki editor to do complex table stuff... But
developers are already using it so it doesn't matter much. For standard
user, being able to create a table and choose headers / borders is probably
good enough, at least for now since we're looking for increased stability &
simplicity in the editor.
Guillaume
On Thu, Aug 28, 2008 at 10:21 AM, Pascal Voitot <pascal.voitot.dev(a)gmail.com
This syntax looks good to me, I like the very simple syntax as a
default where we can add details when needed.
--
Guillaume Lerouge
Product Manager - XWiki
Skype ID : wikibc
http://blog.xwiki.com/
wrote:
I never use the table macro because I can't design
tables in which headers
are not columns but headers are rows!
Moreover, if you need tables in which one cell has "rowspan" or
"colspan",
the macro is not usable...
With your syntax, will it be possible to do this?
[snip]
>> 4)
Tables: do we keep the table macro or do we want a wiki syntax
>> for
>> tables.
>
> Also need more input.
My take is that we should go with a macro since this allows us to
have more options like filterable/sortable/pageable/etc than a wiki
syntax.
I was wrong. I've talked to Mikhail from wikimodel and what he's done
for the wikimodel common syntax is to allow parameters for tables in
the following manner:
* Parameters at the table level:
{{tableParam=value ...}}
|| column 1 || column 2
cell 1 | cell 2
* Parameters at the column level:
|| {{columnParam=value ...}} column 1 || column 2
cell 1 | cell 2
* Parameters at the line level:
|| column 1 || column 2
{{lineParam=value ...}} | Cell 1 | Cell 2
* Parameters at the cell level:
|| column 1 || column 2
{{cellParam=value...}} cell 1 | cell 2
He says it's easy to do the same for the XWiki Parser in wikimodel.
Of course we'll need to change the parameter delimiter since {{ }} are
already used for macros for the xwiki syntax. But we could use
something like %% I guess.
So I'm now more in favor of having a wiki syntax for tables instead of
a macro.
WDYT?