[prev in list] [next in list] [prev in thread] [next in thread] 

List:       quanta-devel
Subject:    Re: [quanta-devel] more ideas for the parser
From:       Andras Mantia <amantia () kde ! org>
Date:       2006-01-21 9:12:41
Message-ID: 200601211112.51263.amantia () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Sorry that I'm slow. I have some problem lately, maybe with my eyes, and 
I got a headache after sitting a little in front of the computer. :-(

On Friday 20 January 2006 05:47, Jens Herden wrote:
> Hi,
>
> our new parser should be implemented as a Finite State Machine.
> 	http://en.wikipedia.org/wiki/Finite_state_machine

Might make sense.

> The configuration of the parser should be in external files, so that
> we can change the behavior of the parser at any time.

Isn't this what he have now in description.rc? Of course, the 
configuration syntax will be different, but the idea is the same.

> The input events are the text stream character by character.

OK.

> We have to think about actions that can happen on state-in and
> state-out. 
I think we should have states like:
- XML tag start
- XML tag end
- character data
- special area start
- special area end


> It is probably possible to define a set of actions and 
> hardcode them. The external configuration would refer to the internal
> coded action. Of course there are more flexible ways to implement
> this (plugins) but I fail to see where we need this yet.

The plugin idea is also something it can be used (theoretically) in the 
current parser, and makes sense in cases when a generic, configuration 
driven parser is not enough, especially for special areas.

> Some examples:
> - add the incoming character to an internal buffer
> - clear the internal buffer
> - call one of the builder functions to create the DOM tree

I don't get, what do you want to do with these? Describe in the external 
files? If yes, how did you imagine it?

> We have to think about conditions for comparing the character that
> comes in. I immediately have this in mind:
> - compare with exactly one character
> - compare with a set of characters
> - check if the character fits in a class of characters, like
> whitespaces

Makes sense.

>
> I have another one that I want to avoid whenever possible:
> - check if it match a regular expression

But you know that comparing with a set of characters of if it's in a 
class of characters is usually done with regular expressions?

> I think the next steps would to try to start to define the states and
> transitions. I want to find a graphical tool for this, but the one I
> found did not compile.
> 	http://www.kde-apps.org/content/show.php?content=17578

No wonder, they use STL... It might compile for them, but if fails for 
me as well, with that "compose2" error.

> Anyone a good idea what to use for this?

Umbrello? It has a state diagram creating module as well 
(Diagram->New->State diagram).

Andras

-- 
Quanta Plus developer - http://quanta.kdewebdev.org
K Desktop Environment - http://www.kde.org

[Attachment #5 (application/pgp-signature)]

_______________________________________________
quanta-devel mailing list
quanta-devel@kde.org
https://mail.kde.org/mailman/listinfo/quanta-devel


[prev in list] [next in list] [prev in thread] [next in thread]