[
Lists Home |
Date Index |
Thread Index
]
* M. David Peterson <m.david.x2x2x@gmail.com> [2005-04-21 12:03]:
> Hey, this is pretty cool. In my opinion and in answer to your
> hierarchical question the time to use a generalogical structure as
> part of your XML-based language is if you plan to use these
> relationsips as a way of enforcing an implied set of logical
> processing rules. For example, if there is no child element "doThis"
> then obviously this method is not available for that portion of your
> code base... quick and dirty error checking. You can also make nested
> structure that will step through to each child element until it
> evaluates to true (based on whatever you are testing for. e.g. using
> the value of the data and the name() or local-name() of the element
> to determine the name of a sequence that should then be invoked to
> properly the child elements of the parents name value being tested.
Okay, I'm falling behind on the lingo, as I usally do in this
mailing list. I'm looking at creating a simple document thus:
Let's use a custom scheme specific part to remove any implied
hieracrchy. Let's say I filled out a form like so:
First Name: Alan
Last Name: Gutierrez
Farvorite OS:
Linux [x] OS X [z] Palm OS [ ] Windows 98 [ ] OS/360 [x] Other[ ]
Comments: I <strong>love</strong> your software.
In Relay I can fetch this document:
<request>
<server-name>engrm.com</server-name>
<server-port>80</server-port>
<content-type>application/x-www-form-url-encoded</content-type>
<content-uri>request:content</content-type>
</request>
Using:
request:properties
Then I can create a varsity generated relay that looks like this:
<relay>
<stream>
<uri>request:content</uri>
</stream>
<form-decode/>
<saxon>
<url>xslt/post-to-sql.xslt</url>
</saxon>
<sql>
<connent-uri>jdbc:mysql:foo</connect-uri>
</sql>
</relay>
(The SQL bit is totally, naive, yes. I've put more work into XML
to relational mapping than the example above.)
In any case, the form-decode element creates a document that
looks like this:
<form>
<field>
<name>first-name</name>
<value>Alan</value>
<uri>request:field:first-name:1</uri>
</field>
<field>
<name>last-name</name>
<value>Gutierrez</value>
<uri>request:field:last-name:1</uri>
</field>
<field>
<name>favorite-os</name>
<value>Linux</value>
<uri>request:field:favorite-os:1</uri>
</field>
<field>
<name>favorite-os</name>
<value>OS X</value>
<uri>request:field:favorite-os:2</uri>
</field>
<field>
<name>favorite-os</name>
<value>OS/360</value>
<uri>request:field:favorite-os:3</uri>
</field>
<field>
<name>comments</name>
<value>I <strong>love</strong> your software.</value>
<uri>request:field:comments:1</uri>
</field>
</form>
If there was a file upload field, I'd use a different parser,
but the output would be very similar.
<form>
<field>
<name>nickname</name>
<value>Alan</value>
<uri>request:field:nickname:1</uri>
</field>
<field>
<name>photo</name>
<content-type>image/jpg</content-type>
<content-length>123456</content-length>
<uri>file:///tmp/upload-213131.jpg</uri>
</field>
</form>
Note how the photo URI is swapped out with a file URL. My
chioces might seem more reasonable.
Taking the first example, I could create a pipeline like so:
<relay>
<stream>
<uri>request:field:comments:1</uri>
</stream>
<html-tidy/>
<saxon>
<uri>xslt/strip-user-comment-html.xslt</uri>
</saxon>
</relay>
I'm thinking hard about URI design because I'd probably pull
that pipeline into a query using an include:
<xsl:value-of
select="document('varisty:/internal/user-comments.xml')/xhtml:html"/>
That would fire the parse and clean comments pipeline. The
heirarchy comes back into play, since a Varisty URI is supposed
to be interchangable with a file or http URI.
> An example of each of the XML trees for something like this might look
> like:
>
> Data being processed:
>
> <foo>
> <bar>
> <element>data</element>
> <element>data</element>
> </bar>
> </foo>
>
> Data its being compared against:
>
> <foo true-sequence="seq1">
> <bar true-sequence="seq2"/>
> </foo>
>
> Sequence definition file:
>
> <sequence id="seq1">
> <do_this/>
> <then_this/>
> <if_this>
> <do_this/>
> </if_this>
> </sequence>
>
> Using this type of dynamic application construction can be really
> powerful and as long as you seperate the XML definition files out into
> seperate files, allowing only elements and data that are there serving
> the same purpose (e.g. to invoke a processing sequence) then I think
> you will find this a simple way to maintain decent code readability as
> well as the ability to use the structure viewing tools contained
> within the tools we use an extremely powerful way to view whats taking
> place in your code without having to scan a 2000 line file up and down
> looking for this sequence or that sequence, etc...
>
> I really like your chosen style. I would be interested in seeing how
> this continues to develop for my own learning so please keep us up to
> date, or if you would prefer, just those of us who want to watch by
> creating an Atom feed that we can subscribe to.
>
> Cheers :)
>
Again, trying to keep up with the nomeclature, but I think you
are thinking a head of me.
Relay/Varisty to a bang up job of creating a new XML document
from sundry sources. It's simply because all the data flows into
one document.
Handling a form submission is difficult, becasue you need to
branch the pipeline, different output if the submission is not
valid.
Furthermore, it is a realy pain to deal with a form submission
that goes to multiple destinations, say an LDAP DB, an RDB, an
XMLDB, a web service, an e-mail notification, etc.
I'm thinking about a new set of problems, including
multiplexing and transactions on the inbound, while I already
feel confident in my strategies for caching, dependencies, and
aggregation on the outbound.
If you are talking about abstracting business logic, then I'm
not doing that quite yet. I'm simply generating pipelines using
XSLT, so much of the application logic is in (oh, my) XSLT 2.0.
However, if you can express your business logic ultimately as
XML pipelines, and initially create a document that can be
transformed into those pipelines, then Relay/Varsity is probably
the output format. Relay/Varsity does not include any logic,
merely a caching engine. Logic is supposed to be external, and
Relay/Varsity are supposed to snap to it, parse an XML pipeline
specification, and execute it a quickly as possible.
I hope this helps. It's all open source, as I noted before. If
you're interested let me know. The RSS feed is below.
Cheers.
--
Alan Gutierrez - alan@engrm.com
- http://engrm.com/blogometer/index.html
- http://engrm.com/blogometer/rss.2.0.xml
|
