[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-24 12:57:15
Message-ID: 200601241457.15950.amantia () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Hi  Jens,

 I'm trying to imagine what data structures would be the best, but I 
think I understand what you want.

> state. There are actions that will happen when the parser enters the
> state and others when the parser leaves a state. I am not sure yet if
> we really need both. There can be also more than one action that
> needs to be done at one time. E.g. emitting the tag name to the
> builder and clearing the tagname buffer.

I think we don't need the "exit action" from the state.

> Please have a look at kdevquanta/quantacore/parsers/comparator.cpp/.h
> This is my first attempt to hardcode the possible compare functions
> but make them configurable from a file. In the file you just write an
> id and when the parser reads the file it will translate the id into a
> pointer for the correct function. This function will get used to
> compare the incoming character and do something according to the
> result.

What I don't understand is how you find the id when you read the 
document?


> Looking into you file I think we are on the right track. Of course
> some things are missing, like namespace support.

I completely forgot about that.

> But I think we 
> should continue to write a diagram for our parsers. We could improve
> it even more if we clearly describe the in- and out-actions for each
> state.

So I will put it into the svn, so we can modify it.

> There is a problem with our special areas. The start of a special
> area can be in different states of the XML parser.

I'm not sure about this, but you may be right. Oh yes, you are right, a 
special area can start inside a tag as well. Yes, this will be trickier 
to implement.

> For a correct 
> result we need a kind of state-stack to remember where we want to
> return when the special area has ended. Actually I believe we have to
> make a solution that is on top of the XML parser and that takes over
> whenever a special area has started and returns to the XML parser in
> the state where it took over.

Yes, makes sense.

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]