[FX.php List] FMP PHP or FX.php...??
Leo R. Lundgren
leo at finalresort.org
Tue Feb 5 03:06:08 MST 2008
Chris,
Thanks for taking your time on this :)
Well, for me the reasons for running the FM PHP API instead of FX.php
are quite simple. Part is that unless I *need* to run something else,
I generally prefer to stick with the standard software shipped from
the same party, which makes FPA the choice in this case. That is, of
course, as long as it fulfills the needs I have, for example
performance. Apparently, and I don't doubt it, FX.php is a bit faster
for obvious reasons, but for me that hasn't been a showstopper yet,
and as I've expressed in other threads I'd run something else than
Filemaker if I need speed. I guess also part of my choice is that
even though my opinions of Filemaker are what they are, I yet haven't
let go of the hope that someday FPA will be better tuned and so on.
Letting go of that hope would pretty much be to tell myself to stop
using FM all the way :P
Regarding the OO it's just that I'm somewhat of a perfectionist when
it comes to my code, and so I like to keep it clean. I don't like to
handle arrays all over the place, but that's pretty much it. Until
there's a deeper technical reason for me to use FX I'll stick to the
OO-looking code :) So to answer your question, I personally don't
have a real reason to ask you to make FX more OO. You're probably
correct that doing so would impose more performance penalty than what
it would gain in ease of use, or at least I wouldn't be surprised. I
just presume OO handling in PHP is a bit heavier than array handling.
As long as people are happy using FX.php the way it is, that's just
fine in my opinion. Also, I think that most people that start using
FX haven't used any of the products before. By that I mean that the
ones who do either move to FX from FPA, and if so it's for a reason
and then they don't care about stuff like arrays instead of OO
syntax, and if they haven't used any of the products then they'll
probably be happy anyway :)
1 feb 2008 kl. 17.39 skrev Chris Hansen:
> 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
-|
More information about the FX.php_List
mailing list