Eric van der Vlist wrote:
>>This is not possible at the moment. We would have to implement a new >>protocol to supports this. Another suggestion was to implement XSLT >>extension functions. Yet another one was to provide a processor >>supporting pipeline and/or PFC inclusion inclusion "tags" (ideally a >>generic "tag library" system). > > Hmmm... I am really confused here: why do you say it's not possible > when you explain later on that 99% of it is already implemented?
I thought he meant using the document() function to call a random
pipeline. What is implemented is the use of the document() function to
read inputs connected to the xslt processor with
document('oxf:input-name').> Do you mean that developing a new protocol isn't possible at the > moment?
No, that's absolutely possible! I meant there is no such protocol implemented at the moment.
>>This is exactly the reason why we decided to implement it this
>>way. The XUpdate processor also supports the same syntax, and this
>>is in fact often used with Page Flow, with document('oxf:action')
>>and document('oxf:instance'). I think your suggestion of using the
>>protocol "input:" is not bad. We went with "oxf:" at the time, but
>>it may become confusing as "oxf:instance" means a reference to an
>>input, while "oxf:/instance" means a reference to a resource.
>
> I think that it would be nice if that was easier to implement new
> protocols by providing a layer that could be overridden a little bit
> like SAX entity resolver.It is fairly easy. Look at org.orbeon.oxf.resources.URLFactory, as well as org.orbeon.oxf.resources.oxf.Handler.
> I had hoped that resource managers could be this class and it > doesn't seem to be the case since they seem to be only acting on the > "file:" (and probably "oxf:") protocols.
> As far as I understand, they belong to a layer that is after the > protocol has already been interpreted.
The idea of resource managers is very simple: they are really just a way (almost an implementation detail) to implement the "oxf:" protocol. You are free to use other protocols, like using "file:" directly, but then you don't get automatically portability between different types of storage, and you cannot easily implement a sandbox containing your resources.
The "oxf:" protocol hides underlying protocols such as "file:" and "http:", or other ways to access resources that can be stored in JARs, WARs, databases, etc. The main idea is to create a sandbox for the application files, that can be moved to different stores. For example, your application may reside on disk, in a WAR file, in a WebDAV repository, a database, etc. Practically, and this is the most common scenario, this means that you can use files on disk in development mode, and then package the resources in a WAR file for deployment at a customer.
There is BTW experimental support for a WebDAV resource manager based on the Slide client that the we tested with the Slide server. It works, but the Slide server is extremely slow. One hope was to be able to use Subversion as a server. This opens interesting doors, as you could for example have a stable branch with Subversion to which you commit the stable changes to your application, and voila, the deployed application is automatically updated.
> If that's the case, a (naive) solution might be to support > XCatalogs. Then you would be able to match a new protocol to files > locations and the resource manager could direct these files > locations to anything you like.
I don't have a particular opinion on this. It seems to be old?
> Another one (probably saner) would be to extend the scope of > resource managers so that they can intercept the read/write requests > for all the protocols. In that case, a resource manager could > implement XCatalogs. > > Or maybe a maybe a mechanism could be added so that you can just > register resource managers to protocols.
This would probably be my prefered solution, as we do have a bunch of resource managers already implemented.
-Erik
------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php _______________________________________________ orbeon-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/orbeon-user
