Server Advanced CWP options

[iMarcW]

I'm also weighing my options in moving my company's databases and our elaborate online registration system from FMP 6 to 8, and it makes me nervous that there seem to be few developers using FM's XML/XSLT-based CWP. It's also frustrating that there's no way to get my hands on a trial version of the Server Advanced software to try it out.

Do you think there's anything poorly implemented or unreliable with the XML/XSLT approach, or is it just that Lasso and PHP-based solutions have a less steep learning curve? I am not familiar with PHP, so I am tempted to go with Lasso, but software and hosting costs might be more, and I should probably learn PHP anyway.

What do others think?

[iMarcW]

Also, I was wondering about plug-ins. Pre-7, the server and Unlimited were separate, so you ran plug-ins on the Unlimited client if you wanted to use them with your online solutions. (In our case, we use SMTPit to send confirmation e-mails from a script when a registration is completed.)

I know you don't have to run the server and the Web components on the same machine with Server Advanced, but is there any way to install plug-ins and use them with Custom Web Publishing?

[Zero Tolerence]

I use Lasso, couldn't be happier. FX.php is just as good(Although lasso has some very nice features that aren't availiable in FX.php). But Lasso was in my companies Budget from the get go, its expensive and a lot of people don't have that extra money to spring for it. Lasso has built in features for Email, so does PHP, either of these would work for your needs.

You cannot directly use Plug-Ins with CWP.

[iMarcW]

I think I will probably wind up using PointInSpace hosting which provides Lasso capabilities in its service. Instead of shelling out for Lasso server and FMSA, all I have to buy (besides the monthly hosting fee, but that buys reliability and peace of mind too) is Lasso Developer, which is $99 and serves to 2 IPs for development and testing. (Why doesn't FM have something like that for Server Advanced?)

I looked through the documentation for Lasso and found the E-mail tags, which is great. It can make PDFs from scratch or overlay text onto an existing PDF. It works with both Unlimited 6 and FMSA, so I can start using it before I upgrade. I can build on my existing CDML code instead of having to learn something completely different. I think that's the way I'm going to go.

[John May - Point In Space]

Also note we offer Lasso Developer for $79 when purchased in conjunction with any new FileMaker or MySQL hosting account.

- John

[Martin Brändle]

The learning curve for XML/XSLT is not so steep as one thinks.

CWP with XML/XSLT offers web sessions, cookies, e-mailing, string parsing, and it is extensible with server-side JavaScript or Java if one needs that.

Have a look at the FMS8A CWP Guide provided by FMI: http://www.filemaker.com/support/product/documentation.html

There is also a XSLT Site Assistant coming with FMS8A for the first steps.

You have to learn about 5-10 XSLT tags, about 2-5 XSLT functions, and the concept of XPath to achieve what you want.

xsl:stylesheet

xsl:output

xsl:variable

xsl:template

xsl:for-each (for loops)

xsl:value-of (most important to access field and variable data)

xsl:attribute

XSLT functions, used normally within xsl:value-of

concat() (concatenation of strings)

document() (loading additional documents)

[Martin Brändle]

BTW: As an FSA member, you get access to a developer version of FMS8A (allowing 3 concurrent users).

[iMarcW]

I'm sure XML/XSLT is perfectly capable, but what matters more to me is whether there's an active community of users that will be there when I need help. It seems like if there were any place that would be host to such a community, it's here, and I don't see much evidence that many people are using XML/XSLT with FileMaker at an advanced level. Of course, I could be wrong about that--all I'm saying is that if they're out there, I haven't seen them.

As far as FSA goes, I might consider joining once to get the FMPSA developer license, but as an in-house developer on a tight budget, it's a little too much for me.

[iMarcW]

Just found this on Brian Dunning's Web site: granted, he's selling a Lasso class, but...

(snip)

Why not use XML/XSLT with FileMaker?

FileMaker, Inc. recommends that you use XSLT with FileMaker's XML stream as the recommended solution for Custom Web Publishing. If you've tried it, chances are you gave up very quickly. Don't worry, it's not you: it's the technology.

XSLT is not a programming language, nor was it ever intended by its creators to be a logical solution to the problem of creating dynamic web sites. It's much better suited to the transformation of FileMaker data into other text-based document formats, like RTF, EPS, and Microsoft Office documents - which is a very different task than Custom Web Publishing.

Just Google for "limitations of XSLT" to find plenty of reasons why you should probably not bother spending much time trying to shoehorn useful web application functionality out of XSLT.

(snip)

Also:

http://www.briandunning.com/lasso-training/not-php.php

[Martin Brändle]

Yes, this was a long discussion that was also held in the FSA forum, and many of your points are correct. It always depends on several factors how one decides, but even one could think mixing XML/XSLT and PHP as well (and I would do for our web applications if I saw I reason that a certain feature can not be achieved with XML/XSLT)

Just some advantages/disadvantages that come to my mind:

PHP:

+ a lot of functions and libraries, still growing

+ especially well suited if one needs interaction with other applications (e.g. getting data from an e-commerce application, controlling devices, upload of files, etc.), functions are available

+ programming language, therefore easy to understand for people which have programming experience

+ object-oriented, objects can be any data structure (also suited for handling binary data)

- problems with security (look how often patches are posted)

- simplicity, overview of functions

- because the language is a scripting language, code is orthogonal to HTML and XML

- code is sometimes lengthy (compare how many lines you have to write with FX.php to send a query to a database with XSLT)

+ very large developer base

+ very large end-user base

+ a lot of publications

XML/XSLT (in its FileMaker implementation)

- functional language (concepts similar to LISP and other AI languages), therefore people with programming experience must first learn to think in a new scheme (e.g. different behaviour of variables or loops)

+- XPath concept may be difficult to understand, but is very elegant and powerful

+ W3C standard

+ extensible, can be easily mixed with Java, JavaScript

+ very secure

+ fmxslt extension functions

+ code is similar to HTML, builds up on XML and integrates well

+ code is small and efficient

+ XML data is handled inherently and flawlessly (selection and transformation)

+ generation of XML, HTML, text data is inherent and flawless

- objects are always XML result trees, therefore especially suited for handling text and number data

- not well suited for interaction with other applications or data sources that don't send well-formed XML data

- small developer base

- small user base

- small number of publications

There are more minuses with XSLT, as you see (that's also because I'm more critic to something I know well). The lack of a large knowledge base is certainly a drawback, but there are some people around like Russell Kohn, Beverly Voth and me that support XSLT. I have decided for XML and XSLT because in our field (natural and life sciences, information sciences) these languages are gaining momentum and getting increasingly important. In these fields there are cases which can not be solved with relational databases, and native XML databases and XSLT come to their full strength. If you are more e-commerce oriented, I would go in your case rather with Lasso or PHP.

XSLT is not a programming language, nor was it ever intended by its creators to be a logical solution to the problem of creating dynamic web sites. It's much better suited to the transformation of FileMaker data into other text-based document formats, like RTF, EPS, and Microsoft Office documents - which is a very different task than Custom Web Publishing.

His argument can be used in the same way against PHP and Lasso's CDML. PHP and Lasso are also only a part of a dynamic website like XSLT is, they can not stand for themselves; all the three require input from the database. The second statement is nonsense, because XSLT can transform XML into any format and is not restricted to the examples he mentions, and it does it especially well to create XHTML for the end-user application. In this sense, XSLT is much more generic than PHP or Lasso which require this additional function and that additional library to do the same transformations. The best proof against his argument are FMSA's excellent capability to do CWP with XML/XSLT and the XML/XSLT websites that exist and were presented by Russell Kohn at the last DevCon.

Edited January 15, 2006 by Guest
Minor corrections of grammar.

[iMarcW]

Although PHP might make more sense for a lot of people, I'm convinced Lasso is the right way for me to go, for two reasons.

First, I already have a fully realized set of CDML-based Web solutions that work just fine (but still have to be upgraded to 8 for the sake of the desktops), and using Lasso will virtually ensure that they continue to work just fine, because converting is a matter of syntax, not a completely different language.

Secondly, having been hemmed in all these years by the limited Lasso subset that is CDML, I'll now have lots of exciting new options that I can explore at my leisure. Basically, I can spend my time making our Web databases do more, rather than learning how to make them do what they already do, only in another language.

I don't fault FileMaker for taking the course they did. Clearly, the XML stream allows CWP to be implemented with FMP in at least three different ways (XSLT/PHP/Lasso). They knew that Lasso was still out there for those who wanted to use it, and those who move to Lasso from CDML will have new appreciation for all it can do, not to mention the resources available from its fervent user base. I make no justification for FMSA's hefty price tag, of course -- that's why I'm moving to a host.

I appreciate all the input.

[Martin Brändle]

Secondly, having been hemmed in all these years by the limited Lasso subset that is CDML, I'll now have lots of exciting new options that I can explore at my leisure. Basically, I can spend my time making our Web databases do more, rather than learning how to make them do what they already do, only in another language.

Yup, true. Our websites were a major overhaul when we went to XML/XSLT, and offer now much more functionality than with FM6's CDML. If that were not possible, we had moved to Lasso as well.

[John May - Point In Space]

XML/XSLT is essentially a data markup methodology. Lasso and PHP are certainly, however, complete programming languages. You can do a LOT more with Lasso and PHP separate from pulling and transforming data from FileMaker. That alone is reason enough to ditch XML/XSLT and go for Lasso or PHP.

I personally prefer Lasso. I'd say if you already know PHP, use FX.php - otherwise I feel Lasso's learning curve is less steep that PHP from a blank slate.

- John

[Martin Brändle]

XML/XSLT is essentially a data markup methodology.

Yes and no. Have a look into Michael Kay's XSLT book and you'll see why, there are some nice computational examples. I agree on that with PHP or Lasso you can do more, especially if it comes to interaction with other applications (see my post above), and personally I would stick to a combination of XLST and PHP if can not solve a problem with XSLT alone. We sticked to XSLT first because it comes right out of the (FMSA) box and you are not dependent on third-party products (PHP and associated libraries, or Lasso) that in case of bugs or security problems you have to update as well.

An important point for me also is that XSLT is a W3C standard and PHP has a widely installed and supporting base. With CDML one is on a dead end as soon as the single enterprise responsible for it will stop.