[FX.php List] What to tell a customer that wants to use FM IWP vs PHP/FX

Blair Duncan Blair.Duncan at bbdo.ca
Mon Oct 6 12:48:00 MDT 2008


Agreed,
I would not think of using IWP on anything that was exposed to the untrained
user such as a website accessible by the rest of the world. For that PHP
would be a much better solution. But, for the typical internal business
solutions such as those used for dockets, inventory, contacts, scheduling,
shipping labels etc it works quite well. One of the deciding factors for us
was the never ending cost of having to maintain 50-100 FMPro licenses in a
multi-OS environments Even with upgrade pricing it gets costly. Also, via IP
connection for many things we find IWP much faster than a FMPro client (as
would PHP), since all of the processing is done locally and only the results
are transferred vs data being transferred back and forth to the individual
FMPro clients to process.





On 10/3/08 5:36 PM, "Bob Patin" <bob at patin.com> wrote:

> While I do agree with Blair that IWP works well in some situations,
> there are others where it's clearly not up to the task.
>
> For example, I worked on an IWP database that's used in a huge factory
> near Nashville, where 100-200 employees use an IWP database for their
> in-house training. The company is very pleased with how it works on
> their network; however, this isn't going out over the Internet.
>
> We host quite a few IWP solutions here, and have some that have been
> hosted here ever since FileMaker 7 was released. I don't know how high
> their traffic is exactly, but the clients are apparently happy with
> their performance.
>
> Having said that, here are a couple of things that I've encountered
> when working with clients' IWP solutions:
>
> 1. Secure transactions - there are ways around the limitations with
> IWP, but essentially it's a huge pain to try to do merchant
> transactions with an IWP solution over the Internet. For example, one
> client tried to do this, and his customers kept trying to use the
> browser's BACK button, which caused huge headaches for him. Eventually
> he contacted me and I rewrote his solution in PHP.
>
> 2. Alerts - I like to use Javascript FORM validation, and that's not
> available in IWP. You can write the validation in the layouts, but
> can't use popup alerts. I know, you can fake it with layouts that show
> alerts (I've used this on IWP solutions), but for me it's a huge pain.
>
> 3. Speed - Get any more than a dozen or so hitting an IWP site and
> things can quickly bog down.
>
> 4. Eating up user slots - FileMaker Server only allows for 125
> concurrent users. In a hosted environment such as Longterm Solutions,
> where our clients are hosted on shared servers with other databases,
> each IWP user is counted as a concurrent user. If that user walks away
> from his computer without logging out, he's still taking up one of the
> user slots. So if a server has 70 databases on it, and there are 20-25
> clients sitting on a server, as there often is here, and then an IWP
> site has another 50 or more connected, you have 75 concurrent users on
> the server at one time. On the other hand, with a PHP solution, users
> aren't concurrent users at all; the site engages in transactions with
> the server, but it's not constant.
>
> So consider a site where there are a lot of users who might be
> "sitting" on the site for a length of time; adding 100 users could max
> out the server, making it unavailable to all of the other clients
> whose databases are hosted on the same machine.
>
> 5. Email, etc. - Trying to do things like email, PDFs, etc. with IWP,
> in my opinion, is much more difficult. In PHP it's a simple matter to
> deal with PDFs, send out multiple emails after a cart transaction or
> registration; before someone tells me that all of this is doable in
> IWP, I do know that--but it's easier, in my opinion, to get these done
> in PHP, without using scripts or plugins.
>
> 6. Scripts - So far, in the 4-5 years I've been doing PHP sites, I've
> never had to use a script. We've had discussions on here about the
> speed difference between scripting a function or writing it in PHP,
> but I still prefer to have everything happening in PHP, leaving the
> server to take care of other things, deal with other users, etc.
>
> I have a fairly large IWP site that's going to be live very soon, and
> I'm interested to see how their use affects other databases on the
> same server. They've been testing for quite a while, but once more
> users are hitting the database I'll be watching to see how it affects
> bandwidth, etc.
>
> Bottom line: I think IWP is fine for in-house, but I don't recommend
> it to any of my clients for Internet use. Others may of course
> disagree with me, but that's my professional opinion.
>
> Best regards,
>
> Bob Patin
> Longterm Solutions
> bob at longtermsolutions.com
> 615-333-6858
> http://www.longtermsolutions.com
> iChat: bobpatin
> AIM: longterm1954
> FileMaker 9 Certified Developer
> Member of FileMaker Business Alliance and FileMaker TechNet
> --------------------------
> FileMaker hosting and consulting for all versions of FileMaker
> PHP EUR Full email services EUR Free DNS hosting EUR Colocation EUR Consulting
>
>
>
> On Oct 3, 2008, at 2:11 PM, Blair Duncan wrote:
>
>> I've never understood the bad wrap that IWP gets. Usually this is
>> due to
>> users expecting all of the feature that work fine in the FMPro
>> Client to
>> work in IWP as well. When they don't, it can be painful to re-
>> engineer to
>> accommodate IWP and most tend to give up on it.
>>
>> We have been using IWP for several years and generally like it a
>> lot. IWP
>> provides a consistent interface that enables users to do a lot of data
>> entry, perform finds and run reports, trigger automated emails etc.
>>
>> We use a combination of all three: IWP, FMPro Client and FX.php
>> driven by
>> FMSA. From within IWP, anything that requires the client such as
>> building
>> pdfs, emails etc, we have in the corner a FMPro client running as
>> slave to
>> process the request from the web and return the data to the IWP
>> client. With
>> the addition of FX.php we have additional arsenal under our belt
>> that has
>> enabled us to eliminate most of the shortfalls of IWP.
>>
>>
>> On 10/3/08 2:04 PM, "John Funk" <criticalsolution at comcast.net> wrote:
>>
>>> I have a Customer with a very large, 500+ layout, 50 Table,
>>> convoluted,
>>> complex and mostly self made database. He "discovered" Instant Web
>>> Publishing and now he wants to integrate some IWP pages into his
>>> solution.
>>> (This is like a kid in a candy store) I have been trying to sell
>>> him on the
>>> idea of using traditional html pages with PHP (FX) instead. I have
>>> many
>>> reasons why I do not want to go with IWP, but mostly because this
>>> customer
>>> is non technical and thinks he can just make his layouts and they
>>> will work
>>> just like that.
>>> There are already small parts of the solution that DO use PHP/FX.
>>> In the big
>>> picture I am working on him to let me rewrite the entire FM solution.
>>>
>>> I am looking for bullet points that tell the reasons NOT to use IWP
>>> vs
>>> html/php/fx. If there are good reasons to go with IWP, list them
>>> also.
>>>
>>> Any feedback is greatly appreciated.
>>>
>>> John Funk
>>> Critical Solution
>>>
>>>
>>> _______________________________________________
>>> FX.php_List mailing list
>>> FX.php_List at mail.iviking.org
>>> http://www.iviking.org/mailman/listinfo/fx.php_list
>>>
>>
>>
>> Please consider the environment before printing this e-mail.
>>
>> This message and any attachments contain information, which may be
>> confidential or privileged. If you are not the intended recipient,
>> please refrain from any disclosure, copying, distribution or use of
>> this information. Please be aware that such actions are prohibited.
>> If you have received this transmission in error, kindly notify us by
>> e-mail to helpdesk at bbdo.com. We appreciate your cooperation.
>>
>> _______________________________________________
>> 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
>


Please consider the environment before printing this e-mail.

This message and any attachments contain information, which may be confidential or privileged. If you are not the intended recipient, please refrain from any disclosure, copying, distribution or use of this information. Please be aware that such actions are prohibited. If you have received this transmission in error, kindly notify us by e-mail to helpdesk at bbdo.com. We appreciate your cooperation.



More information about the FX.php_List mailing list