Re: Scaffold API proposal 0.2

Maybe for the /Session subtree the actual value database could be kept
as an XML tree.  That would be nice and convenient.

As I said in the other mail, I don't think this is possible for all
cases though.

Regards,
Gustavo


On Sat, 2004-01-24 at 13:14, John (J5) Palmieri wrote:
> Oh and one more advantage of having an internal XML representation of
> the Paths: Your session code is written for you.  The XML representation
> reflects the internal state and can be saved out and then relaoded with
> zero extra processing.
> 
> --
> J5
> 
> On Sat, 2004-01-24 at 11:03, John (J5) Palmieri wrote:
> > Hey Gustavo,
> > 
> > I would just like to say great work.  I'm still looking over it all and
> > digesting it.  Once we have solid interfaces I would be glad to code
> > some of them.  
> > 
> > I would like to consider using the at least a subset of the XPath API
> > for the ValueContainer stuff.  Why?  because it is very simple and well
> > defined.  Basicly if we had a tree:
> > 
> > /Documents
> > 	/Document name = "hello.c" mimetype="text/x-c"
> > 	/Document name = "hello.h" mimetype="text/x-c-header"
> > 	/Document name = "world.c" mimetype="text/x-c"
> > 	/Document name = "world.h" mimetype="text/x-c-header"
> > 
> > /Documents/*  would return a list of all children of Documents (In this
> > case a list of all Document objects)
> > /Documents/Document would return a list of all Document objects
> > /Documents/Document[1] would return the first document "hello.c"
> > /Documents/Document[last()] would return the last document "world.h"
> > /Documents/Document[@name] would return all Document objects with a name
> > /Documents/Document[@name="hello.h"] would return the hello.h Document
> > 
> > This would give us the ability in the future to integrate into open
> > standards more redily.  It also takes the pressure off defining an API
> > as we can now consentrate on defining what subset we would use.  I can
> > remeber using a program written in VB.  The one cool asspect of it was
> > that the main interface was written in HTML and used XPath or some MS
> > knockoff, to trigger events within the ActiveX controls.  So a link that
> > was clicked would have /app/main/action[10] as its target.  Inorder to
> > customize the interface for my company all I had to do was figure out
> > what action path did what and write a link.  Scaffold might not use this
> > but some other app using scaffold technology might.  
> > 
> > XPath is already integrated into libxml2 so we could somehow use that
> > (keep an XML rep of our paths in memory which should never get more than
> > a couple of hundred nodes if even), rip their code, or implement our own
> > mini-XPath API.
> > 
> > Just a thought.
> > 
> > --
> > J5
> > 
> > On Thu, 2004-01-22 at 19:16, Gustavo Giráldez wrote:
> > > Hi guys,
> > > 
> > > Here's a new version of my API proposal for Scaffold with changes due to
> > > the feedback I got from you.  Attached is the html version.  You can get
> > > the Docbook file from
> > > http://webs.uolsinectis.com.ar/gustavog1/scaffold/.
> > > 
> > > There are still a bunch of missing/incorrect parts.  Most notably, the
> > > ideas from John's last mail[1]: the layout switch, highlighting and the
> > > markers interface.  Those are particularly hard and I haven't had much
> > > time to think about them.
> > > 
> > > I think I'll start throwing out some code, so I'd like to get the basic
> > > interfaces first (ValueContainer, EventBus, ShellUI and UIActionTarget).
> > > 
> > > Also, I want to have a document describing the expected implementation
> > > and behavior of the fundamental plugins (namely project manager,
> > > document manager and session).  I'll write a draft document in the next
> > > few days (unless somebody else wants to do it ;-)
> > > 
> > > Comments, ideas, flames? :-)  All feedback appreciated.
> > > 
> > > Regards,
> > > Gustavo
> > > 
> > > 
> > > [1] http://mail.gnome.org/archives/gnome-devtools/2004-January/msg00031.html
> > > 
> > > 
> > 
> > _______________________________________________
> > gnome-devtools mailing list
> > [email protected]
> > http://mail.gnome.org/mailman/listinfo/gnome-devtools
> 
>