We want a in-house solution to have compleet control. So is it possible to make in CWP a login for the customers that we can control without mySQL ?
Can you expand a bit on this? It's not clear to me what you are after.
CWP does not automatically mean using MySQL. CWP means that you use the native PHP API, or any other web scripting language like ASP.NET, Ruby,.. (through the FMS XML API - but there are connector classes for these languages) to talk to FMS directly.
You can use MySQL or any other database as an intermediate, as the source for your web pages but then you are adding an extra step in having to push and pull data from that database to FMS. There are valid reasons for doing that (security is a big one) but it is not necessary unless you make it so.
1 of 1 people found this helpful
Performance and cost are your two driving factors.
With WebDirect you know what your cost is, both in licensing and development time; those are fairly easy to estimate given your experience with the FM platform.
Performance is a known factor and somewhat easy to test. You will need to get the necessary server hardware to support the # of concurrent sessions that you expect. How many of those 200 would be logged in at any time (worst case)?
CWP gives you less licensing cost, more flexibility and scalability but comes at a higher development cost. Either by your team getting proficient in your chosen web scripting language, or by outsourcing it.
An additional thing to consider is that your code base will be spread over two technologies: FM and your choice of web scripting platform (PHP, ASP.NET, Ruby,...) and you will have to maintain code in two places.
The main question re WeDirect is how many concurrent users you will have. We have some 600 authorized users in our system, but have never had more than 8 concurrent users at one time. And that includes 2 or 3 users logging in with FM Pro. Your users may be much more active but that would be your call.
To get 11 user licenses with WD is the first level. Maybe $1200+.
Oke, this is clear, i will go for now with the WD version, i think there will only be ± 10 concurrent connections at the time. So that would be manageable.
@wimdecorte What about in-house, that was i meaning, if we have to develop the front-end outsources we have to maintain that also, or are less flexible with changes. Also often external party's don't want to give up the code / ore let you change the code if necessary.
And is there maybe some example files available to see to have a idea how it works. We can program FM on o good level, but CWP is relative new to us.
Thxs for the advice.
Here's some useful links
If you were after some example PHP-FileMaker websites then there was a list of examples floating around somewhere but basically it's just a website pulling data from FileMaker so it can look however you want. Parts of my business website are driven straight from FileMaker.
We can program FM on o good level, but CWP is relative new to us.
Is a HUGE deciding factor! If you cannot use the function of CWP without outside help, then you may be at a disadvantage. I'm a web developer and may seem to be cutting my own throat, but I help clients with CWP and WD. Keep in mind that WD still is not exactly as client/server, so you may need to revise slightly your layouts to be the best WD experience, but it is doable!
We have ± 200 customers that can use the info for some part of the database.
Thxs for the advice.
Just one factor to point out. Webdirect isn't compatible with every browser, e.g. FireFox. If you are happy to specify the browser requirements to your clients then that is fine, whereas with CWP the compatibility of the web page is up to your developer.
FileMaker 16 introduced the Data API which is an addition to PHP and XML API (used with CWP). The Data API (JSON) is still new, but the question is will PHP and XML survive JSON ? My guess is that they will not (hints from a presentation by someone with FM Inc.).
PHP and XML have not yet been deprecated, but I wonder if for someone getting into this it's better to invest into the Data API. Questions remains though about the Data API:
- for now it's in some kind of Test period till October 2018 if I am right (I hope)
- FM Inc. haven't made its mind on how it will license the Data API
Sorry to bring more questions than answers .
The Data API, is still "CWP", if you consider the "web" for the question as asked. The API were/will not be used just for "web", as a query that can be made to FMServer to exchange data is using any application with an internet protocol that can do this kind of process.
Anyone doing web publishing knows full well that things change (daily, sometimes!) and the Data API is just another change. I don't think anyone will shout 'Mon Dieu, I'm going to quit FileMaker because of the change from "XML" to "JSON"...'
You can "JSON" with PHP, by the way! (Along with many different web applications.) ODBC/JDBC can be used with "CWP", but you don't see much on that either.
I'm sure they will warn us if things change (again!) for CWP.
You're right, Data API is CWP also. And I agree that if PHP and XML are to be removed that they will be first deprecated. That said, for someone just getting it's feet in CWP, is it better to start with PHP/XML or with JSON ? And JSON will not be We only . . .
I think consensus is to work in the web app (PHP, perhaps). The data API is for testing/trial for now.
IF you design your website well (I say correctly), then the underlying stuff will be the same. Only the query layer need change.
!) So what I say is possible.
Pick your web app first. Then use XML or the libraries of the PHP API for db connection now. Work out how it might be done with pieces that can be swapped in/out to transition if needed later.
Sent from miPhone
for someone just getting it's feet in CWP, is it better to start with PHP/XML or with JSON ? And JSON will not be We only . . .
I would recommend starting with some of the pre-built APIs, PHP, .NET, Ruby,... those offer a level of abstraction of the underlying data transfer mechanism (XML) so that you don't have to learn XML and stay within the comfort zone of the actual web scripting language. When the Data API (JSON) matures it will be easier to change to one of the new abstraction APIs that will be built on the Data API.
We are choosing now voor WD, because we get faster results. Thxs for the insight. We will continue looking to expand to CWP.