Forum OpenACS Development: Re: xoWiki and images
What I ended up doing on SG site is to pass in source_package_id as a xinha_option in richtext-procs.tcl and use that in OacsFs.js so that its propagated up to the point of file-selector.tcl in xowiki. That in turn would allow to query for a parameter, say FSPackageID specific to each package as we have the source_package_id on where xinha is being called.
In file-selector.tcl, That has priority over all fs instances assuming none was passed. We are also able to add in more package parameters like in most of SG clients's cases, UseLRNFs or UseFOLIOFs if .lrn or dotfolio is installed respectively.
It's generic enough for Solution Grove's roster of clients but I don't know if it will be generic enough for everyone else. Just posting here so that one would know where to get the code if one needs the same functionality.
Deds, could SG share this code? We have a similar scenario here: people would like to use OacsFS xinha plugin in the dotlrn forums and access shared community folder from wyswyg editor.
Thank you for share. I followed up instructions you pointed and everything works well.
I think SG approach in this topic was very good providing several options to use xinha OacsFs plugin. We choose add XinhaFileStoragePackageID to forum package so we could now set the community/class file-storage package intance for store files/images and referring them inside forums. Great! A very attractive way to replace attachments package in forums.
I do admit it's not pretty at this point but we just needed something real quick that deviates from the default implementation. It just attempts to do more on the resolver but the code is backwards compatible with current implementation such that everything can still be passed by URL and folder ids are still supported. The package ids are not required to be specified as parameter but just an option that I check precedence-wise.
We also have several clients who use .lrn and .folio and we needed to support both with a single patch that's why the resolver looks complex. The only actual hard code on the resolver in the strict sense is the check on a mounted /xowiki which is already being mounted on install.
If you have implementations that achieve similar functionality lying around feel free to commit and we're sure to pull it.