[TYPO3-content-rendering] Improvement of table rendering / table wizard

Franz Koch typo3 at fx-graefix.de
Thu Dec 22 10:02:15 CET 2005


I had a second thought on a possible table wizard that might fullfill 
all needs. I try to describe my idea:

########
The wizard is split into several steps.

Step 1) table creation / table import
--------------------------------
Here are two possible options:
a) A creation-wizard similar to the htmlarea wizard and co. to setup the
    cols and the rows etc. - not to much here.
b) Alternatively, a CSV-file, Excel, OOo-Doc or whatever could be
    imported to create the basic structure, which defines the table
    structure itself. After the import, step 3 is provided.

Step 2) data input, table manipulating
--------------------------------
Here it is possible to put the data into the table-cells as well as 
merge cells, add cells/rows/cols ect. like the RTE behaviour but no 
table formating at all - maybe reduced content-formating.

Step 3) table formating
--------------------------------
The table gets processed (should be possible to extract the data and the 
col/row settings (colspan etc.) and converted to an extended formating 
wizard wich seperates the content (which is now extracted) from the 
layout. This wizard shows the table and enables the styling by either 
selecting a global table-template/layout (which reflects the old 
behaviour) or allows to apply predefined classes to cols, colgroups, 
rows, cells and the table itself by allowing multiple selections for 
easier manipulation (checkboxes, via JS or whatever). This could be 
combined with a realtime-preview (ajax).

Step 4) accessibility
--------------------------------
Here some accessibility related stuff can be handled - like summary, 
defining thead, tbody or whatever else is needed. You might say that 
this step could also be combined with step 1, but if data get's imported 
you have to define thead etc. afterwards. So it has to be after step1, 
but could also be step2.
########


By providing a wizard like this, backwards compatibility should be no 
problem, as the pure data can be stored the same way it is now, the 
layout-field also is in use (step3) and the layout-configuration could 
be stored the same way as the data only in a different db-field. The 
only thing that might change is, that modifications inside the currently 
sown textarea with the table-data (you know "col1|col2|col3") must be 
disabled because no manual changes to the table-structure can be allowed 
as the formating is related to the structure (e.g. by col and rowcounts).

What do you think about this concept?

-- 
Kind regards,
Franz Koch



More information about the TYPO3-project-content-rendering mailing list