Re: [sdx-users] [newbie] Programmatic use of SDX...

[Remi Vankeisbelck]

Pierrick Brihaye wrote:

> For sure. It would make sense to have invoke Cocoon with "non-http" 
> protocols. Well, that's another matter.

Yep...

> Unfortunately, it is more complicated than this. You definitely need a 
> complete "SDX object hierarchy" because a Framework gives access to 
> applicationS that give access to repositorieS (notice the plurals). 
> Isolating would be a backward step for SDX IMHO...

Yep, I saw that framework / apps / repositories architecture, and I like 
that !

> Futhermore, SDX offers a nice (IMHO) abstraction between document 
> content and document indexation.

Fully agreed. That's why we're evaluating it :-)

> Well... from my point of view, it is quite a surprising statement from 
> someone who wants to evaluate a System for Documents in XML :-) Apart 
> for archiving purposes, XML is of *no* use in itself : it just claims 
> to be transformed.

Once again, fully agreed ! But actually we *do have* lots of XML we 
already know how to manipulate and present to the user... The main 
features which are of interest for us in SDX are "indexing and searching 
into virtually any XML documents" :-)

> And for eveybody I guess :-)

You told it ! :-)

> Yes. Roughly, it gives you access to the server's filesystem, i.e. 
> where config files reside.

OK, I saw that also in the code (framework init)...

> That's understandable. However, Cocoon is just one illustration of the 
> best pratices in COP (Component Oriented Programming)... and COP 
> definitely needs a ComponentManager.

OK.

> More precisely, the are through Cocoon's... ComponentManager. Here is 
> what Cocoon does : wherever you see Coccon, replace by 
> MyYetToBeDevelopedApp :

OK, so, please correct me if I'm wrong, but to get SDX features 
available from a simple Java program (I mean not using HTTP but real API 
calls) one should simply develop a so called "ComponentManager" 
(Avalon-compliant I guess), expose desired methods (I mean business 
methods to index, search, etc.) through a given interface, and trigger 
specific (Avalon again) events when these methods are invoked to get the 
job done and send back a result to the user ?

> Cocoon is started by an external process (a servlet engine)
> Cocoon instanciates its ComponentManager

OK, I guess I might provide my "CustomComponentManager" there... I'll 
have a look at Avalon I think :-)

> Cocoon read its configuration which defines components (see SDX' 
> cocoon.xconf file : SDX components are at the very beginning)
> Cocoon's ComponentManager lookups for the required components
> [CUT]

> Cocoon's ComponentManager disposes all "looked-up" Components

OK... Assuming I can write my own ComponentManager, I guess this is not 
so complex finally...
Please tell me more about invocation :-)

> > ??? You mean cocoon generates Java sources ? Gee ! 
>
> Of course : exactly like JSP.

> Test SDX and have a look in the "work" directory of your servlet 
> engine. Notice however that these Java files are not intended to be 
> human-readable...

Arf. I must admit I can't see the "mapping" between the XSP/L and the 
corresponding Java source :-/
I guess that, just like for JSPs, generated sources are compiled and 
instanciated by cocoon, which in turn invokes them ( using the 
'generate()' method I guess),  and "applies a stylesheet on the 
generated document" (sorry for my poor XSL vocabulary :-/)

> > How can I access that "framework", "application"s and "document"s 
> > from a regular Java source ?
>
> See above : just look at the generated java files...

Yes, I've noticed access to the applications, etc... I can't figure out 
how this all works and what it exactly does ( :-) ), but I should be 
able to go through :-)
Still, one other question. In fact, the XSP/XSL seems to be used only 
for the presentation layer according to what you tell me.
If I'm right, an SDX request is handled in the following way (I assume 
that everything's been loaded and initialized OK) :
1/ Cocoon receives an HTTP request for the SDX context, with an XSP URL 
in it (the 'document' to be presented to the end user)
2/ SDX locates appropriate XSPGenerator instance, and invokes 'generate' 
on it : specific SDX tags are handled and then the "framework" is 
accessed programmatically
3/ Cocoon applies the XSL tranform and send back the response to the 
client browser

Is this correct ?

If yes, shall I get rid of cocoon ? I'm asking this because I think I've 
read somewhere in the docs that SDX was internally using XSL for 
indexing, extracting terms, etc...

> Well... SDX is free software but you don't like, for reasons that are 
> obscure to me, its HTTP-based implementation and its powerful 
> XSP-based API that permit to build an application with a few tens of 
> lines.

I have absolutely no problems with the XSP thing I swear it :-)))
Frankly speaking, I found SDX very clever and trying it clearly 
illustrates your point of view ! I think I've noticed the power of the 
framework when talking about quickly building web applications. But as I 
told you, the HTTP thing should *not* be mandatory IMHO. This is not the 
purpose of this talk, but I think it's an interesting one, and as you 
seem to react quite well... let's go :-)
IMHO the business logic should be encapsulated somewhere you can reuse 
it the most. In my mind, a "service" is obtained from a program using OO 
mechanisms. And it definitly is in SDX (applications, repositories, 
etc.). Then, on the "client" side (the one who requests for the service 
: me :-) ) when you've got the "API", nothing enforces you to use a 
given technology (in our case, HTTP transports and XSP/L) whether you 
need it or not.
In my opinion, the HTTP / XSP/L thing is nothing but a presentation 
layer on top of a generic indexing and search engine. But nothing should 
enforce me to use the first while I only need the second...
Do you get my point ?
I can continue to try miserably to explain if you want :-)))

> So... I'm afraid you'll have to pay the price, won't you ? :-)

Looks like, yes... But frankly speaking, this looks very interesting and 
I'd be really happy to investigate it more !

> Tell your hierachy that nothing is really free on this planet :-)

Gee ! I think they already know that :-)))

Many thanks

Cheers

Remi