Re: Scaffold API proposal 0.2

Hi John,

On Sat, 2004-01-24 at 13: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)

Looks good.

> /Documents/Document would return a list of all Document objects

How do you tell the difference between getting all Document objects and
getting the "Document" child of "Documents"?

> /Documents/Document[1] would return the first document "hello.c"
> /Documents/Document[last()] would return the last document "world.h"

Hmm... functions can get complicated.

> /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.

Given that the issue above is resolved, I like the idea.  One thing
though: this would be implemented only as sugar wrappers around the
ValueContainer interface.  I really don't want to force all objects
implementing the interface to provide this kind of functionality.  I.e.
I want to keep the get_value() virtual function simple.

Also, I don't think we can keep an xml tree in memory, because some of
the ValueContainer providers will be virtual.  For example, I don't want
to keep a copy of the list of project targets to put under
/Project/Targets.  Instead, in /Project I want to install an object
implementing a ValueContainer interface which can proxy children
accesses.  And what's the point in replicating information which can be
easily obtained using Gnome Build API? (ok, maybe this wasn't a good
example, since /Project/Targets should be a flat list, not a tree
hierarchy, but you get the point ;-)

Regards,
Gustavo