On 6/29/06, Andrew Phillips <[EMAIL PROTECTED]> wrote:
On 6/29/06, Kai Sterker <[EMAIL PROTECTED]> wrote: > > I'm wondering ... any editor should be able to write data files that > are directly usable by the engine. Basically, there are/will be two > formats that are equivalent. A binary format and a ASCII format (which > needs a few tweaks and a functional parser yet). That's good to know.
Basically, each class that requires it has a put_state and get_state method that will serialize its current state. Everything is collected in memory first and can finally be passed to a writer (or transfered over the network, should the need arise). So it would save a little work if the editors actually used the classes of the engine. (It's a little different with dlgedit, as dialogues aren't data files but python scripts.)
At this point, the 'output' consists of some labels in a pane at the bottom of the screen. Their captions change as the data changes. I'm not ready to worry about file formats or even file handling. But yes, once we decide on a file format, we can teach the editors to read it. I merely proposed XML because it lends itself to structured data, (including key/value pairs, I think) can be checked for data integrity via DTD, and logically compliments my original Perl/CGI/HTML idea.
Makes me think about replacing the sad ASCII file format with XML, as I haven't invested a lot of time anyway. Since libxml is already a dependency required for config files, it wouldn't be too difficult. Actually, I like that idea. Should I come up with a format definition? Kai _______________________________________________ Adonthell-devel mailing list Adonthell-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/adonthell-devel