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

[Remi Vankeisbelck]

Pierrick Brihaye wrote:

> Hi,

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

> Notice that is is a Cocoon feature : SDX *is* a Cocoon application.

Yes I've noticed that.

> 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.
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");
> :-)


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... I 
always found problems in using XSL and so I'd prefer not use it (this is 
only a personnal view I won't discuss here, but I just want to clearly 
describe our requirements for an "XML-enabled indexing and search 
engine")...

Moreover, we want no restriction concerning the architecture, so 
encapsulating SDX features into regular Java classes would be of great 
benefit for us ! You may agree on the fact that XSL is not so handy when 
you deal with Swing apps, and starting a local web container to run a 
local swing app is quite a hack IMHO :-)

Last but not least, indexing and searching is one feature amongst others 
which are already encapsulated into Java classes. That's why putting one 
"part" of the app into a Web container, using another technology (XSL).

In brief, we'd prefer an "integrated" solution than to deploy cocoon 
etc. for each type of "configuration". Of course, we *could* do that, 
but this is not so handy and it's never a good thing to have pieces of 
your apps running different technologies and issueing HTTP requests 
instead of invoking real methods...

> Let your app build a request, then let your app send it to SDX, then 
> let SDX do the hard-work, then let your app process the response.

That's exactly what I'd like to do... through a regular method 
invocation ;-)

> That could be a problem indeed : SDX is designed for HTTP transport. 
> Well... localhost may do the trick but I guess that this is not what 
> you want ?

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

:-)

> I agree... So here is a rough outline of the architecture :
>
> The Servlet engine provdes a Context

You mean a ServletContext ? Looks like an Avalon Context...

> Cocoon provides a ComponentManager.

I'm not familiar with cocoon internals (done a few XSL transforms years 
ago using it, that's all), and nor with Avalon :-/
I'm sorry but I think I miss the point here...

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

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

> 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 ! I think I'm lost :-)
How can I access that "framework", "application"s and "document"s from a 
regular Java source ? Is the RMI thing used for that in SDX (I saw there 
was some RMI parts in the code) ?

> 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. It would have been a pleasure, but I must admin my hierarchy 
won't see it the same way :-)

Thanks for the support !

Cheers

Remi