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

[Pierrick Brihaye]

Hi again,

Remi Vankeisbelck a écrit:

> Hi again ! Many thanks for this quick and precise reply !

You're welcome.

> > Basically, it should : whatever you can do with Java is do-able with 
> > XSP/Cocoon or... should be.
>
> More or less, yes. At least when you talk about web applications.

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

> But actually it brings lots of complexity into a quite simple process 
> IMHO. If we look at the "code snippet" I sent in my first post (I left 
> it below), it actually is far simpler than just learning XSL :-)
>
> > // get hold of an sdx 'app'
> > SDXApp myApp = ... ;
> > // perform a search in this app...
> > SDXResult[] results = myApp.search("my request here");
> > :-)

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

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

> I guess the code should be a bit more complex, but I'm not so afraid of 
> it. I must admit I'm not an expert in writing XSL and moreover I don't 
> think it is so handy to use when the time comes for specific things...

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.

> Moreover, we want no restriction concerning the architecture, so 
> encapsulating SDX features into regular Java classes would be of great 
> benefit for us !

And for eveybody I guess :-)

> > If I'm right... we may continue this discussion :-)
>
> :-)

Let's go :-)

> > The Servlet engine provdes a Context
>
> You mean a ServletContext ?

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

> > Cocoon provides a ComponentManager.
>
> I'm not familiar with cocoon internals

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

> > When Cocoon receives an HTTP request within the SDX context for the 
> > first time, its ComponentManager, "looks-up" for an SDX Framework ; it 
> > should normally get an implementation
>
> OK, a "FrameworkImpl" instance I guess...

Correct.

> > The ComponentManager then triggers the different component life cycle 
> > events. Among them, there is a configuration step that uses 
> > configuration files that can be retrieved by the Context.
>
> This is all controlled by cocoon as far as I understood (I mean the 
> 'lifecycle events' you talk about above). All methods in "FrameworkImpl" 
> look like "callbacks" that are invoked by the cocoon servlet, aren't they ?

Basically, they are.

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

Cocoon is started by an external process (a servlet engine)
Cocoon instanciates its ComponentManager
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
Cocoon's ComponentManager configure the components
Cocoon's ComponentManager inits the components
....
Cocoon is stoppped by an external process
Cocoon's ComponentManager is disposed
Cocoon's ComponentManager disposes all "looked-up" Components

> > When the framework is ready, you can get access to it from Java. 
> > Cocoon automatically generates the code through a complex yet very  
> > powerful mechanism (namely Sitemap/SDX logicsheets).
>
>
> ??? 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...

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

> Is the RMI thing used for that in SDX (I saw there 
> was some RMI parts in the code) ?

SDX' RMI code is for quering a remote SearcIndex. It is a Lucene feature...

> > So, if you want to get rid of Cocoon, write your own app, give it a 
> > ComponentManager, and take inspiration from SDX logicsheets :-)
>
> Arf... In fact, the main purpose of my investigation is to try to save 
> time in that project, so I'm sorry but I think I won't be able to code 
> in SDX.

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.

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

> It would have been a pleasure, but I must admin my hierarchy 
> won't see it the same way :-)

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

> Thanks for the support !

One more time, you're welcome.

Cheers,

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