Basic XML web question

[CaelC]

Hi,

I don't know much about XML, just trying to figure out whether or not I should be learning it. My question is basically this:

In order to serve FMP data as XML to allow client side sorting, searching, etc...

Do I have to use XSL Transformations server side to output HTML files for compatibility purposes?

I'm serving general data to the web ... retail application so compatibility is of paramount importance. I'd like to be at least V.4 browser compatible and up.

Also, If I do have to do it that way, why not just serve using Lasso, the load on the server isn't really reduced if I have to parse XML using XSLT on the server side is it?

Plus when you factor in DTD verifications (if needed), seems like it will take longer than just using Lasso.

I'm sure I'm missing something here but it seems like it's only good for intranet deployment where the V.5 browser can parse the XML without having to download helper apps (and even at that, I'm not totally clear if V.5 is totally compatible in both browsers).

Can anyone shed some light?

Thanks a lot!

[gdykema]

"Do I have to use XSL Transformations server side to output HTML files for compatibility purposes? "

Well, you'll need to do something on the server in order to turn the XML into HTML if you need to support any besides the latest browsers. XSLT is one way, Perl or PHP scripting is another. We're using FX.php to get FMP data into PHP and it happens to use XML, although that fact is pretty much hidden from you.

XML's not really ready for delivery to browsers yet--the browsers' fault, not XML's!

[Keith M. Davie]

"We're using FX.php to get FMP data into PHP..."

Yes, and if what I read at viking is accurate, with FMPro PHP is read only. I gather that means that using FX.php one cannot get PHP data into FMPro.

But I often misunderstand things.

[gdykema]

"Yes, and if what I read at viking is accurate, with FMPro PHP is read only. I gather that means that using FX.php one cannot get PHP data into FMPro."

Nope, data both ways. Find, FindAll, New, Edit, View, Delete, everything you can do with CDML.

[Anatoli]

RE: Nope, data both ways. Find, FindAll, New, Edit, View, Delete, everything you can do with CDML.

So why use php? It is more complicated and larger code. How the php is talking to FM? Natively or via WebCompanion.

If natively, then OK, maybe there is something in it.

If not, why bother.

I still didn't said "this cannot be done" to any of our customers.

[CaelC]

My understanding, of what I've seen of PHP, is that it is much, much more powerful than CDML. I think this is especially true in it's text pre-processing capabilities. For example, you could perform a find and have PHP pre-process the results and highlight each recurrence of the word you were searching on.

I think documentation for PHP is much, much better than CDML also. I would say that the resources out there for PHP are probably 25 to 50 times more than there are for CDML.

Also, I think it is super easy to scale your back-end from FMP to MySQL, PostGres SQL or even MS-SQL or Oracle when you use PHP middleware rather than CDML which is proprietary and only works with FMP as far as I know.

This is based on the research I have done, please correct me if I'm wrong.

Thanks!

[Garry Claridge]

CDML and PHP are very different concepts and methodologies. I don't know why you are even bothering to compare them. Why not compare the application of the methodologies in relation to various needs cases!

All the best.

Garry

[gdykema]

Yes, there's a lot more documentation for PHP than CDML, also classes/tutorials, etc.

I wouldn't say it's "super easy" to swap FMP out for a different database engine when using PHP, but you stand a lot better chance of being to reuse at least some of your PHP code vs. none of a CDML solution. If your code is very modular, you might be able to reuse almost all of it, although unfortunately none of the database-access libraries like PEAR, ADOdb or PHPLIB support FMP.