Losing functionality in script when called by CDML

[lance667]

I have created a script in FMP that searches for records that contain a number less than 8. The search works perfectly when I run it in FMP, but when I call it using CDML in a webpage, it shows me all of the records (not checking for < 8).

Here is the script that I created in FMP using scriptmaker:

Enter Find Mode [ ]

Insert Text [select, "age", "<8"]

Perform Find [ ]

Here is the CDML code that I used in my webpage to call the script which is called "numcal"

href="FMPro?-token=118&-db=subjects.fp5&-format=subjecttable.htm&-Script=numcal&-Find

I cant figure out what Im doing wrong

Thanks

[Anatoli]

Do not use scripts for this.

Scripts cannot return something -- result -- back to the browser

Do the find from web directly.

Actually, in my 20 web solutions there are not scripts at all. I don't need them.

[lance667]

I must use scripts. My client has created hundreds of them to maintain her database. I'm creating a web site to serve her data, and she will maintain all of her scripts on an as needed basis

[Keith M. Davie]

If you must use ScriptMaker, you would be well advised to inform yourself about the single-threaded nature of ScriptMaker and how to serve ScriptMaker scripts safely over the www. Please feel free to visit my web site which uses FMPro 4.0.v3 on the backend and which runs ScriptMaker scripts safely and successfully.

[Anatoli]

RE: I must use scripts.

That is just ridiculous claim. Web site cannot work based on result from scripts.

Again -- scripts cannot return something -- result -- back to the browser.

Anyway

[lance667]

I actually HAVE been using scripts to return data to the browser for several months now. They have been simple "find" scripts that contain 4 lines. When I call them with my CDML tag, they work fine. The only problem that I have found so far is when Im trying to perform a numeric search that searches for > or <.

I did hear at one time that instant web publishing cannot support scripts that have over a certain amount of commands. Perhaps that is what you are referring to?

[The Bridge]

Some ideas:

You don't specify a -Lay in your CDML link (in your example);

The age field is not on the layout specified in your actual CDML link, if any;

You can find records where age<8 with this:

href="FMPro?-token=118&-db=subjects.fp5&-Lay=LayoutName&-format=subjecttable.htm&-Op=lt&Age=8&-Find

As Anatoli says, no script required.

[Keith M. Davie]

While I agree that a script is entire unnecessary for the -find task in question, I must disagree with Anatoli when he writes, "Again -- scripts cannot return something -- result -- back to the browser."

Anatoli, if you have not visited my site, perhaps you should. You will find that the two scripts which are run by the client do return results from the running of those scripts back to the browser, including a result when the script event fails to perform because of a near-simultaneous request.

Lance, re: "When I call them with my CDML tag, they work fine.". How rigorously have you tested your scripts? Have you submitted six or more near-simultaneous requests on your scripts through a browser as can occur in the multi-user environment of a browser solution? If you have not, I would recommend strongly to you that you make the effort to perform such rigorous tests. ScriptMaker handles just one event at a time and does not queue subsequent near-simultaneous requests to perform events when an event is performing. You are inviting trouble running scripts which are not structured to resolve this single-threaded issue. In and of itself, cdml does not recognize an event failure as an error which would generate your -error.htm.

[Anatoli]

RE: Anatoli, if you have not visited my site, perhaps you should. You will find that the two scripts which are run by the client do return results from the running of those scripts back to the browser, including a result when the script event fails to perform because of a near-simultaneous request.

Are you saying, that Script can send something back to the browser without -Find, -Edit, -View action requests?

Are you saying, that one can specify just the name of the script, the Find criteria are stored in the script and browser will get that result?

[Keith M. Davie]

"Are you saying, that Script can send something back to the browser without -Find, -Edit, -View action requests?"

If you will refer to the cdml reference database, you will see: "Other tags that are required -DB, any action tag". Therefore, in order to invoke a ScriptMaker script such that it will return data to a browser page, an action tag is required.

"Are you saying, that one can specify just the name of the script, the Find criteria are stored in the script and browser will get that result?"

I have find criteria in my scripts. The scripts I allow clients to run are invoked through an action tag (not -find). If the find is valid, the script will continue to its completion. If the find is not valid, I have structured things to return an error, or to advise the client that they must resubmit (should a ScriptMaker event be in the process of running when the request is made). These scripts operate as they are structured to operate.

The only problems which I have observed are when someone fails to follow the instructions. (1) They try to register a password which begins with a number. I have structured this so that they pretty much must completely reenter the site (though I could have done that differently I considered my audience and I designed it intentionally in this manner). (2) The client registers and fails to make note of their username or password and subsequently enters one of those incorrectly. Since I do not bother anyone who registers with any email, I did not provide for emailing the client the correct data should they fail to follow instructions. I could have designed in that which would have allowed for this client malfeasance. That was not my purpose on my site.

The purpose of the site is to demonstrate to FileMaker developers the successful running of ScriptMaker in a browser solution. One can confirm the success of this by making multiple submissions requesting either or both of the ScriptMaker scripts. How to do that (rigorously test) is explained at the site.

[Anatoli]

RE: Therefore, in order to invoke a ScriptMaker script such that it will return data to a browser page, an action tag is required.

So when I do the action, I do not need the script. I programmed start to finish many application for web driven by FM engine completely without scripts.

Why use them? I still don't need them.

What if the engine will be another database without the scripts? I can probably port the solution quite fast. To reprogram FM scripts to something else can be anything from easy to impossible or cheap or not financially viable.

[Keith M. Davie]

Allow me to elucidate a bit more. I am running FMPro 4.0.v3. I do not have the luxury of the -inlineaction tag and I have the option of only one token, not up to ten. Additionally, in FMPro 4.0, while one can set a field to be "unique", that characteristic is true only for peer-to-peer type solutions. Over the web that is not true.

I am not too fond of the stylish pop-up window provided by FileMaker Web Security, and, at registration I want each client to have a unique password of their own creation, kinda like a real web site. So I allow All Users and I created my own user/password schema.

Now since I am using Pro4.0, I could not set the password field as "unique". (Well, I could have, but it would have been to no avail,) In a Pro4.0 browser soluiton Sue Doe could create a record with the password "password". Subsequently Sam Roe could have created a record with data unique to Sam Roe, and yet Pro4.0 would have allowed Sam Roe to create that record through a browser solution had he chosen the password "password". And If Jon Woe then chose to use "password", he too would have been able to create a record. And the same for Sally Doe.

In order to use Pro4.0 successfully in the design constraint of allowing All Users in Web Security, it was convenient that a ScriptMaker script be used to confirm the uniqueness of the password and not allow the creation of a permanent record unless the password was unique.

In addition, as a security measure, the client creates a record into which the data is entered, and when the password passes muster, the ScriptMaker script continues such that all "privileged data" is removed to a file not set for Web Sharing, some non-privileged data is placed in a db which is set for Web Sharing (for future use and easy access to publishable data) and as a final step the original record created by the client is deleted, and finally the client is advised through the browser of a successful transaction. I know of no other method using cdml and FileMaker of removing data from db's which allow Web Sharing. But my knowledge is limited. I have never seen anyone else address this issue of successfully removing data from db's which allow for Web Sharing. Though one can move data through a portal, a record exists in a Web Sharing db which contains that portal. Though one can move data through an -inlineaction tag (Pro5+), that tag operates on cdml which means the db must be set for Web Sharing.

And in my soluiton if the password is already taken, the ScriptMaker script is structured such that the client is properly advised that the transaction was not successful and is advised to create another password, which is also tested by a ScriptMaker script, and so forth until the client finds a usable password.

And in my soluiton if a ScriptMaker script event was being processed at the time the client submitted their request, the client is advised that they must resubmit. But I structured it that way. Without that structure the client would have been advised of a successful transaction even though the event had not even been queued, much less that it failed to run.

Running a protected ScriptMaker script successfully in a browser solution can produce results which look deceptively simple to the client, but which in reality are quite complex in their design and their interface with the browser. This is elegance of design.

Also at my site, a client, once registered, can at any time come back to the site and "Run A Different Script" (regain entry through password/username verification by ScriptMaker, and performed with an additional ScriptMaker task of incrementing a number). The client just needs to remember their username and password. If they do, the script will cause the generation of a new number and the client will be so informed. In this instance, since the password has been removed from a Web Sharing database, it can be confirmed only through the use of a ScriptMaker script. My demonstration, though limited, is presented as an example upon which broader solutions can be based.

ScriptMaker, like other FileMaker tools, is a powerful design tool when used wisely, in both peer-to-peer and browser soluitons. Data-handling solutions are a matter of design and design choices. I chose to use as many tools as are available to aid me in designing effective data-handling soluitons. Others may choose to ignore certain tools which are readily available. That is what choice is about.

[Anatoli]

You overlooked many things.

First design -- why unique passwords? That will be not welcomed at all in discussion forum that I did e.g. for Procter and Gamble.

Demand for unique passwords = not elegant solution.

Even in your example

"Sue Doe could create a record with the password "password". Subsequently Sam Roe could have created a record with data unique to Sam Roe, and yet Pro4.0 would have allowed Sam Roe to create that record through a browser solution had he chosen the password "password". And If Jon Woe then chose to use "password", he too would have been able to create a record. And the same for Sally Doe."

if you combine all names and passwords the result is practically unique. That could create potential problem only if there is somebody with the same names and password. Then you can introduce some numbering scheme into concept.

Also moving data in and out is slowing down the FM. That will be noticeable when 50-100 users are working in the same moment.

RE: additional ScriptMaker task of incrementing a number

That IS bad design. Why to do it through script is beyond my comprehension. Simple calc field in FM or JavaScript and Field in the browser will do the job faster.

I still don't see any usefulness for scripts in web solution. You are so focused on scripts, that you overlooked many straightforward ways working without scripts, in fact I will say you are obsessed with scripts. That is fine with me. I get paid for results and not for theories.

[Keith M. Davie]

>You overlooked many things.

You are presumptuous to make that claim.

>First design -- why unique passwords? ...

>Demand for unique passwords = not elegant solution.

Yeah. Right. Take eBay for example. The password is not unique, the username is. I did not overlook this, I made a design choice. That you don't agree with it is ok with me.

>Even in your example...

>if you combine all names and passwords the result is practically unique.... potential problem >...numbering scheme into concept.

I considered that "practically unique" was not "unique". I considered adding a numbering scheme into the concept. I considered generating a unique password or random characters. Then I made my design decision. That you don't agree with it is ok with me.

>Also moving data in and out is slowing down the FM....

I created a demonstration for FileMaker developers. The way I created the ScriptMaker scripts was intentionally cumbersome to allow interested developers a better opportunity to cause a near-simultaneous request so they could see that the solution informed them correctly if a ScriptMaker event failed to be performed. As it is, the Mac I am serving this on handles the ScriptMaker events much faster than the Mac on which they were developed. Rewritten for effeciency they would run in less than 10 milliseconds. You have no understanding of what has been accomplished and how my solution does not slow down anything except by intent.

>RE: additional ScriptMaker task of incrementing a number

>That IS bad design. Why to do it through script is beyond my comprehension. ...

It was intentionally bad design. And you have not even mentioned the copying and pasting data into 26 fields. Now that is REALLY BAD design. Anatoli, what my site does is presents a demonstration of a workaround to the single-thread nature of ScriptMaker. It was done for the FileMaker community, not the general public. And it was structured intentionally with cumbersome scripts to afford a better opportunity for the interested developer to cause a near-simultaneous request while an event was being processed. Thus, what you see as bad design was intentional design to achieve a particular purpose.

>I still don't see any usefulness for scripts in web solution. ...

You also failed to see the design usefulness of writing an intentionally cumbersome script. You make your design choices based on your knowledge and abilities and I make mine. ScriptMaker is a useful tool which comes with the application. I have determined how to use it successfully in browser solutions. And I see reasons for using it on occasion, NOT IN EVERY SOLUTION. That you "don't see" (or is it "won't see"?) is OK with me.

Talk about obsessions... Every time anyone asks about using the ScriptMaker tool in a browser solution, you say it cannot be done. Similarly, as noted above, you also said, "You overlooked many things." And as I have just pointed out, I did not overlook any of those things which you claim. I have considered all of that and more. Please visit my site. You will see that your advice and observations are in error. Successful browser solutions can be and are being done with ScriptMaker doing data-handling and the client being properly informed.

Put simply, ScriptMaker is a valid and useful tool in solution design.

[Keith M. Davie]

Oh, Anatoli, one other thing. I just ran one of those cumbersome scripts through NN 7.0. Making the submission, processing the script and returning the results took a very long 0.411 seconds.

Loading the page to write this message to 2.309 seconds.

You do the math.

[Anatoli]

In another words -- you created something to show to developers it can be done. Fine.

I did the scripts tests years ago. Then I found that it will not work reliably or will work slowly on web and I found much better ways to do all web programming without scripts. It is fast, robust, no reports like "your script doesn't run, submit that again" stuff. It always runs fast. Even with 100 users connected.

I still cannot see anything wrong with that. Use your scripts. That is fine with me. Just don't try to sell that concept to me, that's all.

I am earning my living in real world with real applications. If you want to sell your ideas and be rich, that is also fine with me.

[Keith M. Davie]

>I did the scripts tests years ago. Then I found that it will not work reliably or will work >slowly on web

Yes, I remember you mentioning in a thread that you tried to develop a workaround and were unable to do so. And without that workaround ScriptMaker is unreliable, I agree. As I mentioned, submitting an action with one of my scripts, running it and returning a results page to the browser in NN 7 took less than one-half a second. I don't consider that working slowly, especially in relation to the 2 plus seconds it took for the Forum to return my request for a "Reply" page. Sure, running a looping script will cause it to run slowly, but I have often advised against using looping scripts on the web. That is why I say that scripts must be created intelligently for browser solutions.

>That is fine with me. Just don't try to sell that concept to me, that's all.

Oh Anatoli, I'm not trying to sell it to you. I know better. I was responding to your mis-statements of fact to lance667, "Scripts cannot return something -- result -- back to the browser" and "Web site cannot work based on result from scripts."

>I am earning my living in real world with real applications.

>no reports like "your script doesn't run, submit that again" stuff.

Well the real world in which I live has web sites such as Del Mar Racecourse's online searchable pedigree database. I have no connection with this web site other than I research thoroughbred pedigrees. This site allows a client to search the database, create new records and edit existing records. On occasion at this site it is not unheard of to get a message to resubmit the request. I don't know what db platform is running in the background, but I am reasonably certain that it is not FileMaker. As a client I have never been bothered by getting a message to resubmit my request.

As to the way I handled the resubmit in my solution, again it was a design choice. I could have used a meta redirect to resubmit. But for the audience I was trying to reach, what I am demonstrating, and based on my own real world experience, I chose to create client resubmits.

Not all of us are concerned with having 100 clients per minute. You should feel wonderful to have such successes with your web sites (6000 clients per hour). Your clients must be very happy with so much business.

It is good to have design choices and options. It is good to be able to use all the tools provided by FMI in designing solutions.

[Anatoli]

RE: I was responding to your mis-statements of fact to lance667, "Scripts cannot return something -- result -- back to the browser" and "Web site cannot work based on result from scripts."

Pardon me Keith -- bull****.

Without action scripts cannot return something back to the browser so my statements are not mis-statements at all. It is you (alone) just going in circles around scripts.

And web site really cannot work based on result from scripts.

Web site is driven 100% with FM actions. Without them there is no web at all.

If you are clumsy designer you must use scripts with actions. Elegant design doesn't need the slow scripts just the actions.

So stop twisting my words.

[Keith M. Davie]

>Pardon me Keith -- bull****.

Anatoli, I really appreciate the level of intellectual heights that expresses.

>Without action scripts cannot return something back to the browser so my >statements are not mis-statements at all.

I am not twisting your words. I've answered your every mis-statement, even to dealing with the real world. For the -script tag to cause an event to run, two other tags are necessary, -db and an action tag according to the cdml reference. For that to return data to the browser, a -format tag will also be necessary.

Ummmmm. And how do you get data from a FM db to be returned through cdml without an action tag? Not portals for a record containing the portal must be called with an action tag. Not inlineaction tag for that too must contain an action tag. How do you do it Anatoli?

Scripts will cause a "slowdown" when not intelligently constructed. Done correctly, there is no slowdown and nothing inelegant about ScriptMaker in a browser solution.

ScriptMaker is just a tool available to all FM developers for solution design. I learned how to use it. Others can as well.

[rdhaden]

I love the ongoing Anatoli-Keith grudge matches. It's almost as entertaining as Jerry Springer.

Anatoli, Keith will not let go of the script thing.

Keith, Anatoli will not use scripts.

Seems like a simple solution to me. But hey, keep getting worked up over each other. It makes for a fun read.

[Anatoli]

You are absolutely right. I will not use them. I need performance. Script is sloooow. Halve second equals 4-5 full transactions like -find and sorts.

Keith will twist his own words like Web can be script driven and in next he admits we need the actions. When actions why scripts?

And I am having fun also, when I imagine the total collapse of my blazing actions being replaced by slow scripts with lotsa workarounds

[Keith M. Davie]

The time which I mentioned 0.4...seconds, included loading the results page. The script ran in less time than the 0.4... total. Anatoli's "slow" is quite illusional. Asking for a re-submit exists in the real world beyond my solution. It does not happen very often. It depends on traffic at that moment. And if the client wants to be at such a site, they will be there whether they encounter a "please resubmit" or not. And even that message can be designed away so the resubmit is automatically handled.

Anatoli's aim's are different than mine in some designs, but the overall goal is similar, data-handling and accurately providing information to the client.

FileMaker is a wonderful application because it provides different tools to accomplish the same goals. And that often means more than one way to do the same thing. Choice is good.