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

[Remi Vankeisbelck]

Pierrick Brihaye wrote:

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

:-)
Actually, most of the XML docs we have are... HTML :-))))

> 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 

I'm into it... Looks very, very interesting ! A mate told me to look at 
that project 3 years ago, and I never had time ! Looks definitly great !

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

Let's go !

> 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 

Looks even simpler :-)
But I'll have to read more to understand why it now handles "Objects" 
instead of "Component"s... At first sight, loosing typing can be seen as 
a drawback, but I'm pretty comfident wityh Apache guys' design abilities :-)

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

Could you please use this occasion to provide a "standalone" 
implementation ?
lol :-)

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

I think I get it. Great !
My only "problem" is that implementations of Avalon interfaces are 
provided by cocoon... Looks like it's not gonna be so easy to get rid of 
it !
Moreover, even context-things are strongly relying on the Web App 
context, which is what I'd like to avoid...
Nevertheless, I feel better now that I understand everything a bit more !

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

Yep. This shouldn't be a problem (compared to the replacement of cocoon 
by "MyYetToBeDevelopedApp" :-) )...

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

Definitly !

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

Understood.

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

Anyway, in my simple "do a search using methods" example, I guess I 
don't even need to put my hands there...
Actually, I think my only "problem" now would be to provide a 
ServletContext to a "standalone" app :-)

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

Yes I noticed that. That's quite explicit !

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

Yes that's what I meant, sorry. I put user interactions into the 
presentation tier... In my mind, logic was related to "business logic" 
(in SDX it would be into the Framework, Applications, Repos, Lucene, 
etc. classes).
I think we talk about the same thing actually.

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

Gee ! That's really awesome !

> > If yes, shall I get rid of cocoon ? 
>
> This looks like it is *your* wish :-)

Actually, I wouldn't have no problems with cocoon if XSLT was not an 
HTTP only thing :-)

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

Yep ! And since I'm the client in the scenario, I should be able to get 
hold of a "SDX app" component and invoke methods on it :-)

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

Strange...

> Lucky man ! No so obvious here :-)

lol :-)

Well, it's been a real pleasure to have this talk ! You really explained 
everything very well, that's far beyond most of the support I could find 
even for commercial products ! I think I can now investigate the rest of 
SDX by myself and stop bothering you with my philosophical 
considerations :-)

So, all I have to say is *many thanks* ! You saved me a looooot of time !

Cheers

Remi