Thanks Richard
(again very informative - i wish there was some way this info could get
injected into docs - IMHO its all vital to understand )
> Yes. This particular importer needs to handle imports that may take a few
> minutes, and in that case it’s better to do it asynchronously and show a
> progress indicator. Here is the source code for
> teamwork.initImportFileForm():
>
> initImportFileForm: function(progressId) {
> $('#theForm').ajaxForm({
> beforeSubmit: function() {
> swa.openProgressMonitorDialog(progressId, 'Importing
> File');
> },
> error: function(xhr, status, error) {
> swa.populateModalDialog('File import error: ' + status);
> },
> success: function(data) {
> window.location.href = data;
> }
> });
> },
>
> So it turns the HTML form into an “AJAX form” that is submitted
> asynchronously while the browser stays on the page. The called service is
> expected to return a URL upon completion (variable “data” in the success
> callback), and the browser will navigate to that URL.
>
>
aha!
so the next questions:
1) is this documented somewhere I am missing - particularly the bit about
the importer contract being a service that returns a URL, and presumably
this URL needs to make sense in the context of EDG - i.e. it either needs
to be an EDG view or a modal popup.
2) How would the URL target get access to the results of the importer on
success - either we need a complicated URL smuggling in all the details or
we need to persist in graphs, like the teamwork graph, and then access it
using some key (like in the form <input name="_progressId" type="hidden"
value="uniqueId3284"> which is set, but not documented AFIACT)
3) would it be better to hack the ajax monitor t
> For imports that finish quickly, it would be quite reasonable to ditch the
> AJAX call, and generate an HTML page with an error message or success
> message as the output of the import service. You can try removing the call
> to teamwork.initImportFileForm to better understand what happens.
>
I am not expecting this to be guaranteed, and would like to fit into EDG as
much as possible,
it strikes me the best option might be to hack the monitor to make it more
configurable - I am thinking:
1) Accept a results summary form - as RDF - and use the standard class
based configurable (ui:instanceView ?) rendering in the modal dialog
2) Provide a default class model for a result set
3) Make the URL response optional, so if the importer doesnt supply it a
default page - which should not be the same page you started with (current
behaviour - because its uninformative if not data changes for example -
blink and you miss it)
4) Make the monitor dialog pause with results, and offer options Accept
(follow provided URL) or Cancel (or Undo) or Continue (i.e if the importer
is multi-part, and the URL is the "next stage" after say a validation check
or summary
Is there a model for "undo" we should be following - lets say importer
doesnt throw an error, but has unexpected results
> So a few questions about the best way to customise this:
>
> 1) what does ui:logMessage do - where is it logged and how is that
> configured
>
>
> You mean ui:logMessage on <ui:transaction>? It only does something if the
> transaction modifies a Teamwork-managed graph (one that has a parallel .tch
> graph). In that case, when the transaction completes, a change history
> entry is written into the .tch graph, and the log message is attached to
> the entry. You can see this in action in the change history report for an
> asset collection.
>
>
<broken record> it would be nice for this vital info snippet to be
introduced in the documentation where transactions and this property are
show :-(</broken record>
> 3) how does one report status back to the user?
>
>
> It depends. If the SWP service returns HTML, the answer is obvious. If
> it’s some other kind of SWP service that is called from an HTML page via
> AJAX, then it really depends. Is the status about an error condition? Try
> <ui:throw/> with an appropriate message. Chances are that the display code
> will show the error in a popup. Is the status about a success condition?
> Then there are any number of different mechanisms, depending on what
> specifically we are talking about, and there may be none. Is the status
> about reporting progress on a long-running task? Check the section on
> “Monitoring long-running processes” in the SWP docs.
>
> See above - its about information about the transaction - that might be
generated in an intermediate stage for confirmation to proceed.
>
> I don’t know (not much of a SPARQLMotion user). I would assume no.
>
> (If you’re comfortable with writing SWP, then I would recommend against
> using the ScriptBasedFileImport, or any SPARQLMotion in fact, and writing
> the entire import service in SWP. More flexibility and better control.)
>
>
I am comfortable writing SWP myself - but I find it really useful to use
SPARQLMotion to visualise the inferencing chain needed to get a result when
communicating to my colleagues about how to get from A to B
If SWP had a better self-documenting capability of API and inferencing that
would be different - but I suspect the flexibility within SWP makes that
virtually impossible - especially when you need to create explicit
temporary graphs to handle the case where one process step has multiple
next steps for a given context - which I find i use a lot because I can
create better encapsulated inferencing steps that are a lot easier to test,
debug and re-use. (not to mention letting the dependencies work out
processing order and i would imagine future opportunites for
parallelisation..
> Richard
>
--
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.
