Re: [Qexo-general] XqlServlet

[Ivelin Ivanov]

----- Original Message -----
From: "Per Bothner" <address@hidden>
To: "Ivelin Ivanov" <address@hidden>
Cc: <address@hidden>
Sent: Tuesday, January 14, 2003 1:30 AM
Subject: Re: [Qexo-general] XqlServlet


...
> I assume you're aware that a Qexo program can be compiled directly
> to a servlet,

Yes, I certainly am. This is the hardest thing to do.
BTW, do you plan to share code or ideas with Xalan XLSTC?

> so I'm a little unclear exactly how what you're
> attempting is different from what exists.  The automation aspects?

Yeap. Ease of prototyping and development is crucial.
Can you imagine people having to manually compile a JSP every time they make
a change to it?

>
> > It will eventually detect changes in .xql source files, compile them,
load
> > and execute.
>
> This stuff *is* missing - i.e. the integation/infrastructure hooks.

If you expect people to actually try to write non-trivial webapps with QEXO,
then an XqlServlet is definitely a step in the right direction.
That's what I would like to help with.

>
> > I have done some research and this what I found so far:
> >
> > 1) You can run an arbitrary file with:
> > Shell.runFile(initFile.getPath())
> >
> > 2) If you extend a KawaServlet you implement apply(CallContext), where
the
> > CallContext is a ServletCallContext.
> >
> > What I cannot figure out easily yet is how do I pass the CallContext to
the
> > Shell, so that the XQL files has access to the request and response
> > variables.
>
> I think that's the wrong approach.  It is better to just compile the
> XQuery program directly to a servlet.

Well, I agree with you.
Ultimately this is where I would like to get, however I want to take it one
step at a time.

>
> However, you could create a ServletCallContext, and then set it
> with CallContext.setInstance.  Then when Shell calls
> CallContext.getInstance it shoudl get that ServletCallContext,
> bcause CallContexts are associated with threads.

I think I understand. Noticed that you're making extensive use of
ThreadLocal
for Environments as well.
Will give it a shot.

>
> > BTW, I am using 1.6.98. I know it is not the latest.
>
> Yes, please use the CVS version.  (I'm trying to get 1.7
> released, but my day job will delay things.)
>
> > from your example. It appears that $request/requestURI, $request/method
and
> > $request/pathInfo are not resolved to what is expected.
>
> This is kind-of a kludge and I'm not 100% sure I want to keep
> supporting this syntax.  request-uri(), request-method(), and
> request-path-info() are cleaner and more efficient.  They are
> documented in the Kawa manual.

Actually I think it is a "nice" kludge.
I would suggest offloading the work to something like JXPath.
If you are not familiar with it, look at
http://jakarta.apache.org/commons/jxpath/users-guide.html
See the "Servlet Context" section.
We use JXPath extensively for various Cocoon components.
It provides XML authors an intuitive bridge to the Java layer.
This is just one example component:
http://xml.apache.org/cocoon/howto/xmlform-wizard/howto-xmlform-wizard.html



Cheers,


Ivelin



> --
> --Per Bothner
> address@hidden   http://www.bothner.com/per/
>