. . . and I see where Ville got his nodes and edges db representation:
XML files are trees, and that's one way to store them. I'm going to
need to figure how to plug in something where other approaches to
doing sax and xml in databases presuppose a specific db
representation. A dbxml in which I code the db writes myself.
Seth
What would be easier than making Leo load from scratch from a DB would
be making scripts which, with a regular Leo file already loaded, at the
user's prompting, import / export from / to a DB. That would let you
get to proof of concept demo faster without dealing with the extra
details involved in loading an outline completely from the DB, where
you have to untangle the outline creation and data loading components.
Cheers -Terry
> --
> You received this message because you are subscribed to the Google Groups "leo-editor" group.
> To post to this group, send email to leo-e...@googlegroups.com.
> To unsubscribe from this group, send email to leo-editor+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
>
> What procedures would you adapt? I'm assured of supporting all Leo's
> current functionality if I adapt the file load and save procedures.
I'd just look at Ville's schema and write a script to export / import
to it, from scratch. So no support for @<file> nodes. Whether that's
useful depends on what you're trying to do. I think you want to get
Leo's storage into a DB back end so you can demonstrate cool things
that will be possible when that's done. Without knowing what those
things are, I don't know if this export / import script shortcut would
be sufficient or not. I'm sure it would be a lot easier than teaching
Leo to create, initialize, and load an outline from a DB.
OTOH (a) maybe that's needed for what you want to do, and (b) perhaps
it won't be so bad if you can avoid @<file> complications.
Cheers -Terry