So, if these
HTML tags are *never* used anyway,
why can't we replace them
with < and > just prior to saving
an edited
article?
I just have two objections:
First, it violates the principal of least surprise;
the user doesn't get
the same thing upon a re-edit that they left during
the last edit. This
is particularly annoying for people who are putting
complicated tables
into articles (cf. [[Beryllium]] and [[Periodic
Table]]) -- if they do
one thing wrong, POOF! Half their table <tags>
suddenly turn into
<tags> and instead of fixing one tiny mistake,
they fix one tiny
mistake AND change a lot of <>s back into <>s.
Conclusion: bad for users.
Second, enforcing the limited subset HTML is just a
part of the wiki
parsing. Doing that on save is fine, but is
basically doing half the
parsing job and caching that, then doing the other
half when we display
the page. Why stop there, when we could just parse
the wiki-specific
code while we're at it and save the final result?
Conclusion: what exactly is our goal here? To save
processing time on
page load? This is most effectively done by caching
the completely
parsed version, both HTML and wiki -> HTML.
My first thought when I read this was to have two
seperate versions of the page. One for the server and
one for the editor. Basically when someone saves a
page, this creates an html page and saves a seperate
wiki page. This way all processing would be done only
when someone saves a page rather than everytime
someone loads a page?
Is there a flaw in my reasoning other than the
database doubling in size? I guess it depends on
which is more important: space or speed?
Chuck
=====
Venu al la senpaga, libera enciklopedio
esperanta reta!
http://eo.wikipedia.com/
====
Junuloj! Filadelfio, Usono 15an-17an de Februaro
http://unumondo.com/cgi-bin/wiki.pl?Filadelfia_JES
_________________________________________________________
Do You Yahoo!?
Información de Estados Unidos y América Latina, en Yahoo! Noticias.
Visítanos en
http://noticias.espanol.yahoo.com