> > 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
> 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