Re: [cowiki-dev] The new coWiki parser

On 9/22/05, Paul Hanchett <[email protected]> wrote:
>  Archie and Team--
>
>  I've been meaning to ask a question...  If we back out the parser for no=
w,
> what features and bug fixes do we loose?  The "Black Magic" that seems to=
 be
> contained in the parser frankly makes me very nervous and tells me that i=
t
> is serious trouble.  Perhaps a strategic retreat and some planning sessio=
ns
> are what's required instead...

A good description of what issues are affected by rolling back the
parser is available here: http://www.cowiki.org/11.html#A6  along with
a version of cowiki with the parser rolled back.

Also, as a point of note, we're not dealing with "black magic" but
"bad magic"... we should be nothing, if not consistent when referring
to ill defined areas of doubt and uncertainty.  In my opinion, the bad
magic bug has been fixed in CVS HEAD since late July of this year.  It
seems not to deal with the parser (did I miss a cvs committ or thread
on this?), but rather the DAO classes.


On a more developer side-note:
As far as the two things that you seem most concerned with (WYSIWYG
editing and embeded image management), I don't think they are the main
issue quite yet.  However, I have been focusing in two directions for
WYSIWYG.  One started out seeming simple... integrate the LGPL
licensed fckEditor into cowiki.  The entire markup language is defined
in xml files and it should work.  The problem is that the xml file
names element names and the converter classes do the work of
bracketing and attributing that name into a tag.  Changing this
behavior became much more work than I had time for, but it still seems
possible with more study.   The second method is not WYSIWYG, but
rather a preview  function utilizing AJAX.  Basically, there would be
an add-on script added in the htdocs directory that would take the raw
coWiki text, run it through the various parsers and then return the
resulting html code into a new layer (which curiously enough,
corresponds with the textarea).  The main issue here is the fact that
the final parser that generates the html output accepts a node id as
input, and pulls that information from the database.  The fix to that
is adding some code to the parser class that accepts text as an
argument and bypasses the database pulling entirely before returning
the html output.  I think I can implement the AJAX preview solution
easily enough, but the WYSIWYG editor is a much bigger task.