Greeting,
I have an article with a spip marked table inside #TEXTE.
You know what I mean:
| cell1 | cell2 |
I have over 33 000 string in the table.
The #TEXTE output show nothing.
Only with #TEXTE* and #TEXTE** tags I could get the content, but it’s not formatted.
SPIP 3.0.5
What could be the reason and the solution of that?
Best regards,
Serge
Le 19/02/13 09:50, Serge Markitanenko a écrit :
I have over 33 000 string in the table.
[...]
What could be the reason and the solution of that?
reason given above the question...
33 000 string is toooooooooo much large to be treated by spip.
a solution would be to cut out the table.
Le 19/02/13 10:13, denisb a écrit :
33 000 string is toooooooooo much large to be treated by spip.
In such a case, make your table in kompozer for instance then copy/paste
in the #TEXT (if neccessary put <html> en </html> before, after your
html table but normally you don't have to.
--
Suske
I’ve tried that, I made the table in HTML way, you know etc.
The size of the table is appx. 7Mb . When I save the article with the table in the #TEXTE I see the PHP error,
memory exceed limit (64MB not enough).
I could not understand why it’s not enough 64Mb for SPIP to save the 7MB to database ,
or why could not SPIP renders the table of 33 000 strings in the SPIP’s typo shortcut format if it already stored in DB.
Best regards,
Serge
2013/2/20 Suske <suske@brubel.net>
Le 19/02/13 10:13, denisb a écrit :
33 000 string is toooooooooo much large to be treated by spip.
In such a case, make your table in kompozer for instance then copy/paste
in the #TEXT (if neccessary put en before, after your
html table but normally you don’t have to.–
Suske
spip-en@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-en
Le 20/02/13 08:29, Serge Markitanenko a écrit :
I could not understand why it's not enough 64Mb for SPIP to save the 7MB
to database ,
or why could not SPIP renders the table of 33 000 strings in the SPIP's
typo shortcut format if it already stored in DB.
SPIP has to parse all the stuff to threat the typographical signs, check
for unwanted scripts, convert models into html and so on...
I hoped that putting the table in the html way (<html><table>...</html>)
could reduce the load but it seems not.
This is a known "bug" but is it really one ? Not for the devs: in fact,
such big tables are probably not an efficient way to communicate on the
web.
--
Suske
Imho the problem is to store a structured data inside an article.
I suggest to separate it from the article. And create a template that would parse it.
Copy the table in a document attached to the article (for ex. « table_of_data.txt »). The idea is to use the table as a structured storage format (like xml in fact) - So it requires a clean html table (not generated from Word 
)
In the main template, I would include the result of a template include/parse_table_data.html like this
<BOUCLE_bigData(DOCUMENT){id_article}{titre=table_of_data}>
#INCLURE{fond=inclure/parse_table_data,id=#ID_DOCUMENT}
</BOUCLE_bigData>
It’s code is a loop other the table content with a DATA loop
| col1 | col2 | col3 |
|---|---|---|
| #VALEUR{td/0} | #VALEUR{td/1} | #VALEUR{td/2} |
Of course, another storage format is certainly better (Yaml, xml, or other)
Why would it work better ? Because of the cache
And the standard filters are applied on small datas (each #VALEUR in fact} when the cache is calculated.
If you are certain on the quality of the datas, you can make it faster with #VALEUR**
Don’t forget that the loop DATA will take some time to be parsed. That’s why I’ve choosen #INCLURE instead of : this parsing is only done when the cache is calculated - and after, the static content is inserted in the parent template cache.
it’s just an idea…
On Thu, Feb 21, 2013 at 12:15 AM, Suske <suske@brubel.net> wrote:
Le 20/02/13 08:29, Serge Markitanenko a écrit :
I could not understand why it’s not enough 64Mb for SPIP to save the 7MB
to database ,
or why could not SPIP renders the table of 33 000 strings in the SPIP’s
typo shortcut format if it already stored in DB.SPIP has to parse all the stuff to threat the typographical signs, check
for unwanted scripts, convert models into html and so on…I hoped that putting the table in the html way (…)
could reduce the load but it seems not.This is a known « bug » but is it really one ? Not for the devs: in fact,
such big tables are probably not an efficient way to communicate on the
web.–
Suske
spip-en@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-en