On 23/07/2018 12:12, Rob Atkinson wrote:
this is where we have a little impedance mismatch - there is something
in your assumptions I am regularly missing...
I have tested this and if i do exactly what you say, the cloned copy
will be added to the open file "teamworkimporters.ui.ttlx" - then
cloning it will change that file (when i save). I really do not want
that to be the case.
Maybe your assumption is that everything is done naturally as an edit
to the source, whereas mine is that I am creating separately managed
and distributable applications that can be applied (with any necessary
modifications) to future updates of EDG. Please help me help you help
me (that seems suitably RDF-esque)
So this brings me back to the issue of import points..
What i need to do AFAICT is to open my own ui file, and import
something that imports the graph in teamworkimporters.ui.ttlx - that
may be directly or is it something higher.
(The file that did _not_ have the necessary imports was generated
using "new SWP" - because I am following a (not unreasonable IMHO)
route of testing a service - then converting it into a importer plugin)
Maybe there is another path that magically puts all the right imports
in place - either way this context is where documentation keeps
breaking down - I can understand the documentation - but its a painful
process to get to the right conditions where the suggested approach
actually works. After that its all kind of fun and the power and
elegance kicks in.
Ok, I could/should have been more specific in my response. Answering
emails is just one of the roles that I am playing, and I am doing
development work in parallel.
To our defense, you may acknowledge that it is impossible for us to
provide documentation, worked out examples and even wizards for all use
cases and extension points of our platform. There are just way too many
features. I assumed it goes without saying that you cannot edit the
system files directly and instead create your own .ui.ttlx file and then
add an import. This is equivalent to how anyone would create, say, a
customization of a Java system class - create your own file and import
what you want to subclass.
But it sounds like you are up and running, at least up to the next
stumbling block :)
Holger
On Monday, 23 July 2018 11:54:59 UTC+10, Holger Knublauch wrote:
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].
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] <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.
