A virtual XML document

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

A virtual XML document

nathansobo
Hi. I just picked up Scala a few days ago and it's looking awesome. I was hoping
to get some feedback on the best way to employ the existing XML tools in solving
a problem.

My plan is to link the structure of a document as defined in a DTD to the code
necessary to construct each fragment of the document. Rather than querying
against an actual document, the user would specify an Xpath against the virtual
document, which would locate and execute functions to build what they requested.
This way, I can make a hairy legacy database look like a collection of XML
documents to the outside world, but only construct those fragments of the
document that are needed. Any tips on the best approach in Scala? Thanks!

Reply | Threaded
Open this post in threaded view
|

Re: A virtual XML document

Burak Emir
Hello Nathan,

Have you looked at schema2src, Scala's data binding tools (formerly
dtd2scala)?

It is not even alpha but available in source form at
http://lamp.epfl.ch/~emir/projects/index.html
(in the scalax package)

The thing is, it is now modular enough that a user can create own
modules that read a DTD and then turn it into something else.

You just need to build the stuff in the schema2src directory and then
use the "dtd" module as a basis for your own.

This should help with the "administrative" side of the problem. To get
an XML facade that acts as a proxy to a database, you just have to
subclass scala.xml.Node. Putting altoghether, your "myproxydtd" module
would generate code which subclasses scala.xml.Node and implements
methods children, attributes, ... in a special way.

hope this helps,
Burak


Nathan Sobo wrote:

>Hi. I just picked up Scala a few days ago and it's looking awesome. I was hoping
>to get some feedback on the best way to employ the existing XML tools in solving
>a problem.
>
>My plan is to link the structure of a document as defined in a DTD to the code
>necessary to construct each fragment of the document. Rather than querying
>against an actual document, the user would specify an Xpath against the virtual
>document, which would locate and execute functions to build what they requested.
>This way, I can make a hairy legacy database look like a collection of XML
>documents to the outside world, but only construct those fragments of the
>document that are needed. Any tips on the best approach in Scala? Thanks!
>

--
Burak Emir

http://lamp.epfl.ch/~emir

Reply | Threaded
Open this post in threaded view
|

Re: A virtual XML document

nathansobo
Hey Burak, thanks for taking the time to reply. Things have evolved
a little and we're going to be using w3c schema instead of DTD, which
I think is a very good thing! I checked out dtd2schema and it looks cool,
but it seemed like for now that it only handles DTDs? Anyway, since schemas
are XML, they are pretty easy to analyze with Scala, and I was able to get
an empty boilerplate facade generated pretty quickly. Subclassing Node
worked out very well, thanks for that. I'm going to interpret annotations
to the schema as instructions about what classes need to be loaded to
provide access to different parts of the facade. Scala is awesome so far.
Thanks!



Reply | Threaded
Open this post in threaded view
|

Scala Servlets (was: A virtual XML document)

joeltt

I noticed that the Scala Servlet support is heading toward a JSP-like
solution.
I wanted to point out a technology started by NeXT which has become Apple
WebObjects. It also has open-source versions on the Java platform.

The problem with JSP is that you embed code in your HTML, JSP encourages
scripting, and discourages component re-use. Putting your html in your scala
source code is not a good solution, because (like JSP) you cannot edit
the html
with a normal editor or view it with a normal browser.

The WebObject solutions solves this problem. The HTML is left in a
separate file
that looks like (and conforms to) html except for an extra attribute in the
elements (all editors/viewers will still render properly since extra
attributes
are allowed in the html spec). So, an id is added to the elements like:

<html><body>
<span jwcid="myID">
</span>
...
</body></html>

At runtime, WebObjects finds what component myID corresponds with and replaces
the html with the custom widget html (ie. PageLink, Table, Conditional, etc.),
that has been intialized thru a separate XML file (or code).

This is a vastly more powerful component methodology that will supplant
JSP-like
scripting solutions. This is used by Tapestry, RIFE, Wicket, and will
be used in
Struts II (thru Tapestry). JSF allows componentization as well but is crippled
by its JSP heritage, but the approach is rapidly catching on for good reason.

The good thing is that you could possibly plug-in Scala into Tapestry
(Scalastry?). Tapestry does dynamically extend classes, and relies on OGNL to
do reflective look-ups on classes, but I think it should be do-able, as at one
point there was a "Groovestry" running (Groovy/Tapestry). Or, you could
rewrite
Tapestry (Java) in Scala I imagine.

I might do it, but doubt Ill find the time. Scala looks really neat as a
language, but I think is taking a step back with the technology, like Ruby did
with its JSP-like implementation. (There is a project for Ruby called Iowa to
bring Tapestry to Ruby, I've heard of versions like-technology for Python as
well)

I'd like to see Scala do well, and I think you would get an objectively
better,
more robust solution by hooking into an existing framework.

Joel


Quoting Nathan Sobo <[hidden email]>:

> Hey Burak, thanks for taking the time to reply. Things have evolved
> a little and we're going to be using w3c schema instead of DTD, which
> I think is a very good thing! I checked out dtd2schema and it looks cool,
> but it seemed like for now that it only handles DTDs? Anyway, since schemas
> are XML, they are pretty easy to analyze with Scala, and I was able to get
> an empty boilerplate facade generated pretty quickly. Subclassing Node
> worked out very well, thanks for that. I'm going to interpret annotations
> to the schema as instructions about what classes need to be loaded to
> provide access to different parts of the facade. Scala is awesome so far.
> Thanks!
>
>
>
>



Reply | Threaded
Open this post in threaded view
|

Re: Scala Servlets

Lex Spoon
Hey, Joel,

Actually, when I write web stuff using Scala, I use raw Java servlets.
When I write GUI code, I use Java Swing.  You put the rationale nicely:


> I'd like to see Scala do well, and I think you would get an
> objectively better,
> more robust solution by hooking into an existing framework.

Indeed.  It's hard enough to develop a general purpose programming
language.  Additionally developing an entire suite of libraries is not
practical.  And even if we somehow did, it would not address people's
existing legacy codebases.  IMHO, at least, it is essential to talk to
Java if you want to provide a practical language for enterprise
software.

That doesn't mean we don't do libraries, too.  But they are for
optional use.  If you want, it is possible to treat Scala as nothing
more than a more productive language to do your next component in.


Thanks for the pointers about WebObjects and Tapestry.  If anyone
gives them a try with Scala, it would be great to hear back on how it
goes!



-Lex