Project Have Hope

[geoffrey hendrey]

Hi All,

Beeing down with a bad cold the last few days, ironically this has given me some time to work with Jen from Dartmouth Design on using the REST features to build some features for Project Have Hope. She has graciously offered to share the preliminary results. So far we've used nextdb for creating profiles of children to sponsor. The entire page, including the paging links, profile data, and paypal buttons, is created by applying an XSLT transformation to the table served up by nextdb. The result is sourced in an iframe and loaded into a Joomla module. This appears to be a very nice way to integrate nextdb content with Joomla. I'm also very stoked to see NextDB used on such a worthy project.

http://projecthavehope.org/sandbox/index.php?option=com_content&view=article&id=105&Itemid=99

You can read about the XSLT approach here:

http://www.nextdb.net/wiki/en/REST#XSLT_(reformatting_your_data%27s_presentation)

This is the XSLT that is being used by Project Have Hope. http://nextdb.net/nextdb/rest/dd/phh/config_files/row/1/xslt.xslt

I've just learned XSLT so I think there are many things that can be done smarter, and there is also a bit of cruft template in the XSLT that is never used (for example the 'append-pad' template is never used) and needs to be cleaned up. But that aside, it's an amazingly small amount of XSLT considering this XSLT is the *only* code required to bring together this dynamic page.

Cheers,
geoff

--
http://nextdb.net - RESTful Relational Database
http://www.nextdb.net/wiki/en/REST

[ibec]

Nice marriage between great cause and technology!

But..., have you ever tried to support the lifecycle of an XSLT? When
you want to change things overtime - after not having touched it for
let's say a few months - it's a pain. Plus, I still don't like the
direct relationship and exposure between a table and its output.

What about adding an extra "projection" or "view" abstraction layer
that you maintain via the admin panel. Here you define the table or
query for your projection, including an HTML template for generating
an (unordered) list or table and the brackets for the applicable
fields, like "My name is {firstname} {lastname}. {bio}". Furthermore,
the projection gets an alias name that completely hides your
credentials, like a bit.ly shortlink. And its the projection level
where you define your access and security settings; these don't belong
on a database or table level since they can be different for different
purposes.

Clear? Ivo

[ibec]

Oh no, don't call it projection or view; call it "layer" as in the
augmented reality apps. It's an abstraction of how you want to look at
the world, in this case a data store. For the data entry and meta data
I want layers as well, but more on that later...

-Ivo

[geoffrey hendrey]

Hi Ivo,

I'll probably also support the templates like you describe, in which ${column-name} would be used as substitution variables. I think that will be easier than XSLT for basic page templates.

But one of the cool things about XSLT is that using the "text" output mode you can use it to generate JSON or any other structure. A plain substitution-variable system won't have constructs like for-each so it wouldn't be able to easily do those sorts of things. That said, I *do* want to do the simplified template you suggest.

I think I can support both ordinal-style (ala select="ht:td[11]") as well as named-column-style (als select="ht:td@COLUMN_NAME");

I'm going to defend the direct relationship and exposure between the table and output, but just a little bit. We've already got a lot of really fancy javascript stuff, and it can't be understood by folks who are not decent JavaScript programmers. So I thought, without removing any of the JS capability, how could I build something that an HTML front-end designer could understand. The HTML output is the HTML web designer's "native language", so I thought I'd build on that.

thanks for the great suggestions,
-geoff

[ibec]

Yeah, there's an audience for every approach! I'm feeling fine now
with the "service" requests in an SSJS environment.

But with the REST approach you could probably add an <ul><li>..</ul>
output alternative instead of a <table>. This leaves much more
flexibility to reformat via CSS. And an individual list-item could
look like this:

<li>
<p class="firstname">{firstname}</p>
<p class="lastname">{lastname}</p>
..
</li>

As such, you can control to show, hide, position, combine the fields
that you like.

-Ivo

[Harry Roberts]

I much prefer Zope style TAL over XSLT or the other types of
templating I've seen on this list (and the wikipage on google groups).
I'm using PHPTAL at the moment ( http://phptal.org/ ), though there
are implementations in other languages, notably one in Javascript:
http://bazaar.launchpad.net/~bkc/atali/trunk/annotate/head%3A/jstal/jstal.js

e.g.

<li>
<p class="firstname" tal:content="column/firstname">First Name Here</
p>
<p class="lastname">${column/lastname}</p>
</li>
<li tal:repeat="email fk/emails">${email/address}</li>

[geoffrey hendrey]

Hi guys,

About 5 months back I actually implemented and posted docs for a client-side templating engine that worked more like what you show (it was implemented in JS). Please download the simpleTemplate.zip file from here

http://groups.google.com/group/nextdb-user/files

unzip it and open the html file. You will see a working example. The HTML is shown below. As you can see, span tags are used in the source to tell the JS template engine how to put values into the HTML.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 TRANSITIONAL//EN">
<html>
    <head>

        <script src="gallery.js"></script>
        <script src="http://nextdb.net/api.js"></script>

        <script src="jquery-1.3.2.min.js"></script>
        <title></title>

    </head>

    <body onLoad="new Template().loadQuery('geoff', 'simpleReviews', 'all');">

        <div id="nextdb_example_gallery_item">
            <h1><span nextdb-col="title">Startrek was awesome!</span></h1>

            <h2>By</h2><span nextdb-col="author">xxx</span>

            <h2><span nextdb-col="numstars"></span> stars</h2>

            <p >

                <span nextdb-col="body">

                    In speaking of Star Trek, JJ Abrams’ origin story prequel designed to sex up the venerable brand and relaunch it as an again-viable film franchise...
                </span>

            </p>
            <span nextdb-back="true"><a href="#">back</a></span>

            <span nextdb-next="true"><a href="#">next</a></span>

        </div>
    </body>

</html>


However, the issue I have with the technique above, is quite honestly that maintining the JavaScript template engine was a nightmare (take a look at the JS in the zipfile).

The XSLT is totally non-intrusive into the HTML and I really like that a lot. Couple that with the fact that the transformation can be done on the server using open source XSLT
engine written in Java, and I've got the system that I can easily maintain. I'd like to move forward with XSLT, since you can use it to generate custom formats.It's pretty easy to serve out <li> style output

like Ivo wants. It's also easy to generate JSON. This really frees me up for other tasks, while giving you the flexibility youn need. Let me know what you think.

-geoff

[ibec]

No, no; don't move on with a JS templating engine, they're already out
there (like PURE).

Just have the REST approach serve table and list output, so one can
format the end-result by only adding some CSS.

-Ivo

[geoffrey hendrey]

Do you see any problem with writing a css class into the things in the <li>? I've done widget integrations with Blogger.com, and it's a pretty crowded css "namespace". I did in fact encounter CSS clashes. Maybe if I called the CSS class something like "xdb_<columnname>" that would avoid clashes. I don't think CSS supports any genuine namespacing concept.

The <li> option will also make it easy to use the nextdb REST output from JQuery applications. It's only a few lines to write an XSLT to do the <li> thing, so I'll probably internally just use XSLT to support this, or just publish a public XSLT that you can apply to your REST tables to get <li> output.

-geoff

[ibec]

Clashes can always occur, but when you're in control of the entire
page or use an iframe then there's no problem. And you can at least
make the NextDB CSS definitions very specific, so they override and
don't conflict with very generic definitions.

How about adding a CSS prefix or namespace name as a parameter to the
REST request? The UL could have this name and the LI's would only need
a column name class:

<ul class="{namespace}">
<li class="{column-name}">{column-value}</li>
..
</ul>

And the CSS looks like this:
.{namespace} -> for the UL
.{namespace} .{column-name} -> for the LI's

With this approach, you also avoid clashes when having multiple NextDB
payloads on one page as well, since they all have their own namespace.

-Ivo