Skip to Content.
Sympa Menu

pcplantdb - Re: [pcplantdb] data and presentation

pcplantdb@lists.ibiblio.org

Subject: pcplantdb

List archive

Chronological Thread  
  • From: Chad Knepp <pyg@galatea.org>
  • To: john@eco-living.net, Permaculture Plant Database <pcplantdb@lists.ibiblio.org>
  • Cc:
  • Subject: Re: [pcplantdb] data and presentation
  • Date: Tue, 22 Mar 2005 07:40:36 -0600

John Schinnerer writes:
> Aloha,
>
> Bear said,
>
> > I'm looking to be able to recognize individual HTML elements via the
> > class to provide the most flexibility in formating and layout....
>
> > I get what you're worried about....is there another route you would take?
>
> Yeah, I thought we'd discussed this quite a bit and agreed to have a
> clean API for the DB engine that kept data and presentation separated.
>
> Maybe Chad's already done that and he's returning to you stuff that's
> already from his 'client' side of things...I just haven't heard that out
> loud, if true.
>
> So, I'm checking my assumptions - what it looks like from your posts
> here is that the DB engine is returning data combined with HTML markup.
>
> Chad, have you got a DB engine/client model with XML data transport
> between them already implemented?
> Or are you just munging your DB engine output with HTML markup?

Yeah, what Bear and I are referring to is the client side of eden
although I haven't specifically made a separation in the code base.
The seperation internally is pretty clear in my head. It actually has
three layers because I like the option of the data engine emitting raw
data (or data with internal XML markup). The engine consists of
Session.py, Search.py, Auth.py, and Vocabulary.py, then is the XML
markup (Kfml.py) layer, then the actual clients Text.py, Html.py. The
stuff Bear is referring to would end up in Html.py.

Currently there is no mechanism for raw data transfer from the data
engine, but as I said earlier, I'm really excited about xml-rpc/soap
which basically lets you write the client in a compatible language and
access the data engine methods as if they were an imported module.
The xml transport layer is transparent. Very elegant and you can
write all kinds of clients.

> > Or do you mean if Chad does this he should be sure it's part of a middle
> > layer between the data end, and HTML output....Can what I'm asking for
> > be done via XLST, using it as the middle layer from data->XML->HTML?
>
> Yeah, afaik we decided that XML would be our data transport markup, and
> that the DB engine would provide a 'clean' API for clients to use in
> communicating with it (making queries, getting responses, adding
> comments, etc. etc.).

Theoretically yes. If I knew what I know now when I started, I would
have suggested that we completely scrap doing XML ourselves and use
xml-rpc for all non broswer based clients and write a very specific
HTML client for browser based access. Currently my guess is over 99%
of access will be browser based so it makes sense to optimize for it.

> So, please let me know what's actually going on in the bowels of the
> code regarding this.

If you look through and understand the code, I actually do have some
elements muddled. This is because the server/client separation was
not as high of a design parameter early on (two years ago). The far
off implementation of xml-rpc (not this iteration) will require an
enforcement of this distinction and at that point I plan on having a
nice code cleaning party. In the meantime I'm trying not to further
muddle things but at the same time, I don't think investing the time
to reorganize things is the best use of resources. I'm open to
differing opinions here...

> thanks,
> John S.
>
>
> --
>
> John Schinnerer - MA, Whole Systems Design
> ------------------------------------------
> - Eco-Living -
> Whole Systems Design Services
> People - Place - Learning - Integration
> john@eco-living.net
> http://eco-living.net
> _______________________________________________
> pcplantdb mailing list
> pcplantdb@lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/pcplantdb




Archive powered by MHonArc 2.6.24.

Top of Page