For importer plugins, the EDG implementation itself serves as an
example, and includes several samples, all of which are "open source" by
being written in SWP: open teamworkimporters.ui.ttlx and navigate to
teamwork:ImportPlugins then find the subclass that is closest to what
you want to implement. Then clone it from there.
Holger
On 23/07/2018 11:42, Rob Atkinson wrote:
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
<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]
<mailto:[email protected]>.
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.
