[FX.php List] FMP PHP or FX.php...??

Sun Feb 3 15:21:20 MST 2008

Well, while you are first at it Chris, asking for contributions, I
would like to add that any technology would be nice to have in the
distribution using index.php and detail.php as template, lajax,
jquery, smarty and so on.

G. G. Thorsen

2008/2/1, Chris Hansen <chris at iviking.org>:
> Leo (& List - especially the second paragraph on),
>
> To what extent do you want FX.php to be object oriented?  Right now FX
> uses two objects: a monolithic connection object (which can even be
> used to return query metadata), and an error object.  The only thing
> you _have_ to get as an array is the returned records, and in recent
> releases, that array usually need only be two levels deep.  I was
> thinking yesterday about the sense of splitting the individual
> connection types into separate objects, but I believe that FileMaker
> has gone way over the top in how object oriented their API is.  Why?
> Persistence and verbosity.  Of course there are many places where it
> makes sense to go heavy on the OO side (and Java, for one, is all
> about OO), but when I work with the FileMaker API for PHP, the objects
> I'm creating feel to me like they're not designed for a non-persistent
> environment like the Web.  I feel like FAP is designed the way that I
> would build a desktop application.
>
> All that said, I'm willing to be convinced.  I was a fervent lasso
> supporter until 2001 when Chris Adams (who worked with me on FX.php
> 1.0) showed me that what I'd been told about PHP being much more
> difficult than Lasso was bunk.  I'm willing to be convinced, but I
> need to know what bits you think need to be more object-oriented, and
> why.  And be specific =)  Also, keep in mind that objects can add
> overhead, and I believe that's a big part of the reason why FAP is so
> much slower than FX.php.  Finally, remember that FX is open-source:
> Gjermund nagged me mercilessly, and sent a plethora of code bits and
> examples of how it was done elsewhere until I got UTF-8 support
> working; when Steve Lane wanted OO error handling, he sent me a
> suitably updated version of FX.php which required relatively few
> tweaks to turn it into a releasable version; Masayuki Nii created a
> version of FX which added character encoding support; and on and on
> (see CHANGES.txt for the full list of who has done what...)
>
> So, here's what you can do if you want something in FX.php, in no
> particular order:
>
> 1) Tell me you want it, and why it should be part of FX.php;
>
> 2) Send me and example of something that has what you want (ideally,
> actual code, even if it requires significant modification);
>
> 3) Add the code to FX.php, and send me the updated version;
>
> 4) Create a tool that can be used with FX.php, and submit it as an
> addition to a future release.
>
> As a final thought, in a release of FX.php in the near future, I will
> be moving to the PHP5 object model (and making some internals of the
> code protected, etc.)  At that point I'll add some getter and setter
> methods, and the last version supporting PHP4 will be frozen but
> available for those who need it.  At first, I'll only lock people out
> of the methods and attributes that they shouldn't be touching anyway
> (I've seen some ..er.. interesting code at times =), and the new
> methods will be mostly added features, but a couple years down the
> line, new versions of FX.php will require that attributes be set via
> function.  (Leo, if that's all you're after, then yes, we're heading
> that way.)
>
> Best,
>
> --Chris
>
> On Feb 1, 2008, at 12:56 AM, Leo R. Lundgren wrote:
>
> > Chris,
> >
> > Any chance of FX.php becoming OO anytime soon? Would be nice.
> >
> > // Leo
> >
> > 31 jan 2008 kl. 19.03 skrev Chris Hansen:
> >
> >> Greetings List!
> >>
> >> This inquiry intrigued me.  During the beta days of the The
> >> FileMaker API for PHP (F.A.P.), FX.php seemed a bit faster; and
> >> since I have a little test box in my basement with both FX.php and
> >> F.A.P. installed on it, and F.A.P is no longer beta, I thought I'd
> >> throw equivalent tests at it, and see what popped out.  The results
> >> REALLY surprised me:
> >>
> >>     * F.A.P.: 14.6196269989
> >>     * FX.php: 1.72123408318
> >>     * F.A.P.: 14.7427921295
> >>     * FX.php: 1.68022203445
> >>     * F.A.P.: 15.8884699345
> >>     * FX.php: 2.96020698547
> >>     * F.A.P.: 14.6040740013
> >>     * FX.php: 1.64016890526
> >>     * F.A.P.: 15.450097084
> >>     * FX.php: 1.72534799576
> >>
> >> Average F.A.P. Time: 15.0610120296
> >> Average FX.php Time: 1.94543600082
> >>
> >> In short, FX.php is almost 8x faster!  I performed this test by
> >> simulating load using repeated queries via each API repeatedly.
> >> Also, although the server in question is running the latest version
> >> of FileMaker Server Advanced 9, it only has a developer license
> >> installed, so I had to keep repetitions very low, but I would
> >> expect results to scale similarly as server load and available
> >> connections were increased.  Also, the test box is a Mac Mini, so
> >> you could handle a lot more lot with faster hardware.  I've
> >> attached my test code.
> >>
> >> --Chris Hansen
> >>   FileMaker 8 Certified Developer
> >>   FileMaker 7 Certified Developer
> >>   Creator of FX.php
> >>   "The best way from FileMaker to the Web."
> >>   www.iViking.org
> >>
> >> On Jan 31, 2008, at 6:27 AM, Leo R. Lundgren wrote:
> >>
> >>> Hi,
> >>>
> >>> I cannot shed very much light upon whether FM PHP API is more
> >>> integrated to the server than FX.php, but I doubt it. AFAIK, both
> >>> of them communicated with the server using XML and parses it on
> >>> their side. The PHP stuff you see on the server and in its
> >>> permissions are most likely just administrative stuff FM put in
> >>> there to integrate the PHP part with the server as a whole a bit
> >>> more.
> >>>
> >>> I decided to go with the FM API, mainly because it's object
> >>> oriented whereas FX.php uses arrays. I just like to keep it clean
> >>> and similar to the rest of my code. I have no doubt that FX.php
> >>> works just as well though.
> >>>
> >>> BTW, it would be interesting to see some performance comparisons
> >>> between the two? Nomatter which one you choose, having FM as a DB
> >>> backend will never be fast, but perhaps there's some difference in
> >>> speed between the two anyway? Perhaps they parse XML differently
> >>> or something.
> >>>
> >>> // Leo
> >>>
> >>> 31 jan 2008 kl. 14.20 skrev Steve Winter:
> >>>
> >>>> Greetings all…
> >>>>
> >>>>
> >>>>
> >>>> In search of the holy grail, web app speed, I'm looking for;
> >>>>
> >>>> a.       gut feelings
> >>>>
> >>>> b.      opinions
> >>>>
> >>>> c.       evidence
> >>>>
> >>>> and am interested in all three on which is faster, the native FMP
> >>>> PHP interface or using FX.php…?
> >>>>
> >>>>
> >>>>
> >>>> I was under the impression that 'native' FMP PHP is simply an
> >>>> alternative to FX.php in that it still uses the xml interface…
> >>>> that said I've also noticed that in FMS 9 there is actually a PHP
> >>>> interface listed, which makes me wonder if in fact it has hooks
> >>>> directly into the server….??
> >>>>
> >>>>
> >>>>
> >>>> As I said, any information greatly received…
> >>>>
> >>>>
> >>>>
> >>>> Cheers
> >>>>
> >>>> Steve
> >>>>
> >>
> >> <speed_comparison.php>
> >> _______________________________________________
> >> FX.php_List mailing list
> >> FX.php_List at mail.iviking.org
> >> http://www.iviking.org/mailman/listinfo/fx.php_list
> >
> >
> > -|
> >
> > _______________________________________________
> > FX.php_List mailing list
> > FX.php_List at mail.iviking.org
> > http://www.iviking.org/mailman/listinfo/fx.php_list
>
> _______________________________________________
> FX.php_List mailing list
> FX.php_List at mail.iviking.org
> http://www.iviking.org/mailman/listinfo/fx.php_list
>