Dear friends,

 

Every time I'm so surprised how little data and examples there are online on filemaker server side xml requests / query's. Specially in combination with XSL.

 

My case: 

1. Customers come and ask me... please send results as xml and it should look like "this".

2. The results should be a result of a query they do on my server (so I supply a sort of webservice)

3. I can get them to send parameters, even do some pre scripts, get the results, but their browser wil show them the ugly FILEMAKER GRAMMER Result set.

 

I need to be able to change the way the results look in a simple and easy manner. And the result should be passed back as a result of a http request.

 

Any advice on the best practice here when we consider 2 things:

 

1. I'm not an XML/XSLT crack.. nor want I to be one;

2. My service provider won't let me place PHP in the server root. Which rules out 360 webservice I quess.

 

My idee was to generate the result XML myself by looping through records and putting the result (parsed with some xml tags) back into one global field. After looping through all the fields this one field is published on the result layout of my the original query... This makes me very flexible because I symply translate the original xml to a header, middel and footer area that I later concatenate to one field.

 

Unfortunately now it will show up WITHIN the ugly fmresultset.

 

Should I and how apply xsl here?

 

If you know the best solution, let me know.

 

Thanks

jeroen

 

1. I'm not an XML/XSLT crack.. nor want I to be one;

 

The tool to transform XML from one grammar to another is XSLT. I would be extremely wary of trying to do this using anything else. Same thing about attempting to write your own XML "by hand".

The tool to transform XML from one grammar to another is XSLT. 

 

Unless you happen to be proficient with any OS-level scripting tool that has built-in XML parsing / writing support, in that case you can use that and be sure that the XML comes out ok.  FMS's script sequence schedules work good in that respect.

Agreed with Comment that writing your own "by hand" is a bad idea.

Dear friends,

 

Every time I'm so surprised how little data and examples there are online on filemaker server side xml requests / query's. Specially in combination with XSL.

 

 

That's largely because XSLT skills or XML parsing/writing skills have not much to do with FileMaker, it's its own skill set that has its own forums.

 

FM provides us with XML in a number of well defined grammars.  How you consume that XML is largely outside of FM's realm.

Unless you happen to be proficient with any OS-level scripting tool that has built-in XML parsing / writing support

 

XML parsing is not XML transformation. There is built-in OS support for both parsing and XSLT on both platforms, I believe - but the language to use it is XPath for the former and XSLT for the latter. I am not sure what tool you have in mind for writing XML.

I

 

XML parsing is not XML transformation. There is built-in OS support for both parsing and XSLT on both platforms, I believe - but the language to use it is XPath for the former and XSLT for the latter. I am not sure what tool you have in mind for writing XML.

 

Parsing & writing can be used to transform one XML grammar into another.  These days most modern scripting language have native support for reading/walking through/ targeting nodes within XML and for writing XML compliant documents.  You can XPath to find nodes or sometimes they're just serialized and you loop through, taking the bits and pieces you're interested in.

 

Powershell on Windows and Ruby/Python on Mac will do, heck even AppleScript has XML libraries that you can use.

 

A powershell example to set an XML object would look like:

$doc = New-Object System.Xml.XmlDocument

you can then load it from a file and walk through it

or write to it, it has CreateElement and SetAttribute methods and so on

 

And these things are very very fast.

While I still do the occasional XSLT, I find that writing code in a scripting language is easier to troubleshoot.

Parsing & writing can be used to transform one XML grammar into another.

 

 

Perhaps, but I don't think this can be compared to the power and flexibility of XSLT.  And the troubleshooting tools of an XSLT processor are indispensable, IMHO. I don't know how you can "be sure that the XML comes out ok" without that. There are so many ways to screw this up...

Perhaps, but I don't think this can be compared to the power and flexibility of XSLT.  And the troubleshooting tools of an XSLT processor are indispensable, IMHO. I don't know how you can "be sure that the XML comes out ok" without that. There are so many ways to screw this up...

 

I think you are underestimating the other tools.  In my experience they are just as fast and produce something that is more easy to understand and read to coders that have no XSLT experience.

 

The validity of the XML is enforced by using the explicit XML methods that those languages offer.

 

I'm not saying that people should abandon XSLT, just pointing out alternatives that are just as robust and that may be easier to grasp.

I think you are underestimating the other tools.

 

I don't think so. It's just that XSLT is a programming language dedicated entirely to processing XML. Sure you can perform a simple task or two using other tools, but ... and this brings me to your other point, which IMHO is more salient:

 

 

something that is more easy to understand and read to coders that have no XSLT experience.

 

Well, that depends on your starting point, doesn't it? I mean if you already know PowerShell or Python, then it's easier to use them and understand the code*. If you're starting from zero, then I'd say XSLT has the advantage here too: you can learn the basics in a few hours by doing a tutorial. Of course, there is much more to learn beyond the basics but to tell the truth, you rarely need much more when dealing with database output.

 

 

In any case, all this seems to be off-topic to the OP. That is unless you can suggest a way of submitting a query to FMS and getting a customized XML in response. AFAIK, if using FMS 12 or above, they cannot do this using XSLT either. I wondered about this before:

http://fmforums.com/forum/topic/91642-state-of-fms-and-xmlxslt/?p=421418

and I don't think this has been answered.

 

 

 

---

(*) Upon re-read, I see that your original point was:

 

Unless you happen to be proficient with any OS-level scripting tool that has built-in XML parsing / writing support,

 

so we're not that far apart.

 

In any case, all this seems to be off-topic to the OP. That is unless you can suggest a way of submitting a query to FMS and getting a customized XML in response. AFAIK, if using FMS 12 or above, they cannot do this using XSLT either. I wondered about this before:

http://fmforums.com/forum/topic/91642-state-of-fms-and-xmlxslt/?p=421418

and I don't think this has been answered.

 

 

I have not read that thread, but check out the source code for fmDotNet (www.fmdotnet.org), or for pyMaker or Rfm for that matter.  You'll see how they are able to natively (and very efficiently) receive and "parse" FMS's XML grammar and turn it into something else.  While they transform that FMS XML into native objects suitable for the language on hand, it can just as easily be adapted to outputting another grammar of XML instead of say a .NET data set or a Ruby array.

 

Not trying to convince you of anything, I think this is a good conversation.  More options for folks to consider...

check out the source code for fmDotNet

 

LOL, Wim - you could just as easily point me to a text in Chinese...

 

 

Anyway, I understand that this (getting a customized XML in response to a query) is currently impossible without using some middleware. My impression is that the most straightforward path would be PHP - simply because it's natively supported by FMI. I am curious what kind of installation OP has that prevents him from using that.

LOL, Wim - you could just as easily point me to a text in Chinese...

 

 

Anyway, I understand that this (getting a customized XML in response to a query) is currently impossible without using some middleware. My impression is that the most straightforward path would be PHP - simply because it's natively supported by FMI. I am curious what kind of installation OP has that prevents him from using that.

 

Wow Wim and Comment,

 

I tried to follow this discussion   but I only understood the last part .... there seems to be no solution??

So do I understand correctly:

 

1. When we do an FMPro export the regular way (menu or script) we can add a XSL to format the FMgrammer output;

2. But based on a http query to a server we are not able to create (scripted or not) output that's able to be formatted through xsl?

3. And there is no way I can present the content of 1 field as a result of a http request, just as is.. with no grammer around it?

 

I do understand that i could hand my customer the original fmgrammer xml but their demand is that I format the result :-(

 

Any other solutions here? I seems so simple? But maybe that's why it's difficult 

 

thanks up to now!

Jeroen

Besides Comment, You helped me before.. the import part with XML en xsl is done and working ;-) but now I'm hanging with my export.