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

[Pierrick Brihaye]

Hi,

Remi Vankeisbelck a écrit :

> Once again, fully agreed ! But actually we *do have* lots of XML we 
> already know how to manipulate and present to the user... 

Without using XSLT as far as I have understood... wow :-)

> > 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),

Easier than this : develop a "root" class and embed a ComponentManager 
in it.

If you look at : 
http://avalon.apache.org/framework/api/org/apache/avalon/framework/component/ComponentManager.html

... you will see that you "just" need 3 methods. Well... it may be 
slightly more complicated than that :-) See below for more info.

Notice that the link describes a deprecated architecture, SDX' one 
though... Current design is described there : 
http://avalon.apache.org/framework/api/org/apache/avalon/framework/service/ServiceManager.html

... some (more) work for SDX developers I'm afraid :-)

> 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 ?

Not exactly. You "just" need to "look-up" an SDX Framework component. 
Then, you have to manage its lifecycle, see :

http://jakarta-k.sourceforge.net/avalon/framework/reference-the-lifecycle.html

When your SDX Framework implementation is initialized (phase #6 in the 
"complete" lifecycle description), you can expect a fully working SDX 
Framework.

Using it, you should have a full access to SDX functionnalities. It's 
*your* job to write *your* your bindings but it should be fairly easy 
(kind of Accessors writing).

> OK, I guess I might provide my "CustomComponentManager" there...

A standard (default in Avalon's terminology) should do the trick.

> I'll 
> have a look at Avalon I think :-)

Good readings there :-)

> Please tell me more about invocation :-)

Use SDX methods : they should definitely work once your framework is set-up.

> > 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 :-/

Have a look at the logicsheets and, if possible, at Cocoon's ones, 
especially the XSP devoted one.

> 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),

Correct.

> and "applies a stylesheet on the 
> generated document" (sorry for my poor XSL vocabulary :-/)

Yes : basically, the Java code is the result of several XSLT 
transformations of a root logicsheet. XSLT generally generates text and 
Java code is... text.

> 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 :-)

Certainly. The root point is the SDX Framework Implementation. From 
there you can access applications and then excecute some queries, 
upload/dowload some documents from repositories...

> Still, one other question. In fact, the XSP/XSL seems to be used only 
> for the presentation layer according to what you tell me.

No : it's really where resides the application *logic*, i.e. where 
interactions with the user are defined.

> 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)

Nope. More complicated (and thus more powerful). A good start point is 
the "API-URL" (see the docs). You have a *full* access to the server 
through an HTTP request... within security restrictions set-up by the 
app's developper of course :-)

> 2/ SDX locates appropriate XSPGenerator instance, and invokes 'generate' 
> on it : specific SDX tags are handled and then the "framework" is 
> accessed programmatically

That's it.

> 3/ Cocoon applies the XSL tranform and send back the response to the 
> client browser

This is called "serialization" by Cocoon. A request *should* get a 
response (even a 404 ;-). Although this is suitable, this step is not 
mandatory : for example, a *big* upload shouldn't receive a response 
IMHO because the connection *should* be closed before the upload succeeds.

> If yes, shall I get rid of cocoon ? 

This looks like it is *your* wish :-)

> 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...

XSL is the preferred way but you have a full programmatic access. If it 
weren't the case, your patchs would be *most* welcome :-)

> 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.

Better than this : COP :-)

> 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.

Historical reasons : Cocoon 1.x (an thus SDX 1.x) was completely based 
on HTTP.


> 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 ?

Absolutely and... I *fully* agree.

> > Tell your hierachy that nothing is really free on this planet :-)
>
> Gee ! I think they already know that :-)))

Lucky man ! No so obvious here :-)

Cheers,

--
Pierrick Brihaye, informaticien
Service régional de l'Inventaire
DRAC Bretagne
mailto:address@hidden
+33 (0)2 99 29 67 78