OK - so this brings me back to the contract: but now having some clues about which objects the contract relates to, so a small step forward.
teamwork:EditRules is interesting - but it seems to operate on the added triples to a EDG project graph - where I kind of want to operate on the metadata - with access to the context that generated the triples. If i export to a local file in the workspace, then I suspect I'll run into a range of issues with scalability - but I'll play with that as a prototype option. What I dont see documented specifically is what the import pre-conditions are: 1) to be able to define an importer and its stack of pages, plugins, services, elements and functions 2) to clone ScriptBasedImporter what i tried was importing teamworkscripts.ttl but it doesnt seem to have transitively found all the pieces needed. (my strong suggestion is to make every recommendation to use such an element use a link to resolve to a page that explains the element, which file it is in, and what are the import paths that would transitively make it available. - a document system that did this automatically from the code - like the function lists, but operating on the higher level key UI elements - I think SWA does this for widgets - but there doesnt seem to be anything in the middle? On Sunday, 22 July 2018 13:10:35 UTC+10, Holger Knublauch wrote: > > Hi Rob, > > assuming your imported files are text-based (not binary such as Excel), I > think you would be better off with doing a stand-along > teamwork:ImportPlugin instead of being restricted by the design decisions > of the scriptBasedImporters. The SWP servlet will recognize file uploads > and assign the file contents to normal string arguments. From there you can > do whatever you like, including using the various sml:ExportToXY module > (e.g. sml:ExportToTextFile) to save the contents to a local file in the > workspace. Doing your own ImportPlugin would allow you to make arbitrary > design choices, for example to support either file uploads or URL > references. > > To modify existing importers, the closest I could think of is to define > teamwork:EditRules. These are executed at the end of each transaction and > would enable you to make further changes to the RDF. > > Holger > > > On 20/07/2018 13:44, Rob Atkinson wrote: > > > This relates to the original thread heading - as it has only been > partially covered: > > AFAICT teamwork:scriptBasedFileImport relies on an uploaded file via a > multipart form encoding > > it has a bunch of moving parts as an importer - a plugin, UI page, a > service and finally the tag that does the work - all related by code inside > prototypes. The code for this tag doesnt seem visible - does that mean > there is an import needed - or is it picking up a java function by > reflection? > > I'd like to add the option of saving the input file and referencing it. > If it has a URI location I would rather save this and make the importer > fetch it. Maybe the EDG Corpora is an appropriate intermediatary data > store for the raw data - it has load from URI importers. > > So I guess I need two pieces of info I cannot find in docs (and maybe > because these mode are not supported): > 1) how best to save a file via the Corpus importers programattically - i'd > rather not have to chain a second multi-part-form call to the service > inside my custom importer > 2) how to inject some pre- and post-processing into existing EDG importers > > (at the moment, it seems like the only option is to clone and hack each of > the moving parts and then attach this via the ProjectType? ) > > > > > > -- > You received this message because you are subscribed to the Google Groups > "TopBraid Suite Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] <javascript:>. > For more options, visit https://groups.google.com/d/optout. > > > -- You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
