Hello,

 

I have a few things for the attachments in the parsing module.

 

I registered to a free ASP.NET hosting so I should be able to show you the
first draft of the attachments shortly.

Everything is now functional I'm just refactoring a few things and
completing the unit tests.

 

Pascal

 

  _____  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of John
Davidson
Sent: February 2, 2008 9:48 AM
To: FlexWiki Users Mailing List
Subject: Re: [Flexwiki-users] 2.0 parser?

 

This email is the last in the chain of what is an import component for
FlexWiki. Moving to a Parsing Expression Grammar (PEG) from the current
Regular Expression analysis will allow a number of anomalies preventing true
XHTML from being generated to be corrected. 

Does anyone have any related code that is later than what is in the
Subversion subsystem on sourceforge (about 15 months old now). I would like
to get work going on this stuff and have some cycles now. From what I can
see the Wiki Object Model (WOM) code is about 90%. There has been a start on
the WikiText, but nothing that gets a simple wiki text file converted to
XHTML output yet. Is this still the case?

Anyone have input?

John Davidson

On Sep 26, 2006 2:52 PM, Craig Andera <[EMAIL PROTECTED]> wrote:

> I did not give much thought about it yet and open to any suggestions.
> I think what you are proposing is good.
> Another approach is to do code change in two iterations: In
> the first iteration we can try to change formatter keeping
> WikiTalk parser as-is and just change implementation of some
> functions inside of formatter.
> If it works then we can do the second iteration where we will
> implement the provider as you specified. I believe it can
> provide us more modular approach and keep system changes at
> minimum at each iteration.

OK, I like that idea. Get to the point where we can reap the majority of
benefits of the parser redesign without having to slog through yet another
massive rearchitecture.

I think I might restructure your proposal just slightly, though. It should
be pretty easy to just use the parser from within the provider chain - since
I followed your excellent advice and used an abstract base for the providers
rather than an interface, we'd probably only have to override one method.
Maybe a few small tweaks to NamespaceManager, and as long as Formatter could
be structured to use a WOM as input (perhaps in addition to a string/stream
in the first phase), we'd be in a good place.

Of course, this is all speculation - I can't think of any major roadblocks,
but there may well be some.


> WomAttribute? Since WOM model is very close to XML it may be
> a good alternative.

I think that might be a better choice.




-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php
<http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV>
&p=sourceforge&CID=DEVDEV
_______________________________________________
Flexwiki-users mailing list
Flexwiki-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flexwiki-users

 

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Flexwiki-users mailing list
Flexwiki-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flexwiki-users

Reply via email to