I would greatly appreciate any knowlege about the feasibility of a potential project:

 

Is it possible to build runtime solutions for both Mac and Windows that incorporate XML imports?  (Assuming the requirements for both runtime and XML import are met in the Filemaker App.)

 

If anyone has experience with this, could you let me know if it's:

 

Not possible.

Possible but you really don't wanna go there.

Relatively straight forward.

 

 

A runtime solution cannot be entirely cross-plarform; you must generate a runtime application specifically for each platform. The solution file/s can be the same for both platforms.

 

I am not aware of any limitations on XML import in a runtime (can't remember if I ever implemented it, though).

The path to the document(s) to import may be the key here. How do you propose to make sure that happens?

I'm looking into this myself at the moment for a slightly different reason.

 

I'm trying to work out if it's possible to embed the xsl stylesheet into a container and then use it for the import.

 

The trick I guess is to figure out how to get to the style sheet that's embeded in the container field.

 

Mark

I'm trying to work out if it's possible to embed the xsl stylesheet into a container and then use it for the import.

 

Only if you export it first.

I can see how that works on PC or Mac, not sure how it would work in fm go.

Coming back to the original posters question, you should be able to have your solution, create a folder on desktop which you can then use to export embedded xml style sheets to.

I can see how that works on PC or Mac, not sure how it would work in fm go.

 

It wouldn't - since Filemaker Go cannot import XML data at all.

 

 

Coming back to the original posters question, you should be able to have your solution, create a folder on desktop which you can then use to export embedded xml style sheets to.

 

I think you are confusing OP's question with your own. The XSLT stylesheet does not have to be embedded in the solution file to begin with - it can be installed locally along with other supporting files, or served online.

The path to the document(s) to import may be the key here. How do you propose to make sure that happens?

Could be user selects the doc first, but better would be a variable that has the path and filename for the import. Ideally - another possible problem - the app gets the XML via HTTPS Post and controls where it puts the doc and what name it has. This is then the same path for the import. I don't know if avoiding this step is possible: doing the post/import/translation in one step.

I'm looking into this myself at the moment for a slightly different reason.

 

I'm trying to work out if it's possible to embed the xsl stylesheet into a container and then use it for the import.

 

The trick I guess is to figure out how to get to the style sheet that's embeded in the container field.

 

Mark

I have had that work by exporting it first and using that knowledge to specify the path to the stylesheet. To answer the other poster's solution of pre-installing it.. I was thinking of using the export method to avoid having to install something else in addition to the runtime. Kind of an automated way to install the stylesheet.

the app gets the XML via HTTPS Post and controls where it puts the doc and what name it has. This is then the same path for the import. I don't know if avoiding this step is possible: doing the post/import/translation in one step.

Yes, it is possible: use the Import Records[] script step to make the HTTP request and import the XML response directly, without saving it to a local file.

 

I was thinking of using the export method to avoid having to install something else in addition to the runtime. Kind of an automated way to install the stylesheet.

 

[shrug] If you think avoiding the installation of one file out of the multitude of files that comprise a runtime solution is worth the extra effort...

And there is also the matter of replacing the stylesheet with a newer version to consider.