Track access to records?

[lindm]

I am using custom web publishing and I am looking for a way to track each time a record is accessed in my database. From these statistics a top list of the most viewed records is to be created.

I was thinking of a field for each record containing the number of times it has been accessed. Creating the top list would then not be a problem.

Anyone got any hints how to solve the tracking problem?

All help appreciated.

Thanks,

Kevin

[Leb i Sol]

well I am sure that there some files in "sample files" section but here what i can think of...

assuming that this is over the web-CDML:

U can have a number field eg. "Accessed" and on a "Details_of_Record.html" page u could have an [inline] -edit or a form to update the field; also some JavaScript.

so:

------Results.html-------------

JavaScript

var counter

counter = [field: Accessed]

counter = counter+1

....

...

<form>

[hidden field with a defualt value of "counter"]

</form>

or use a text links ("click here for details") to do a submit

or use an image to cover the "submit" button and represent it as "view detials"

------------------------

and now on the action page

-----Details.html-------------

[inline] - edit / update the current RecID

and show the Details of the Record in Question

------------------------------

I hope it makes sense!

All the best!

[Leb i Sol]

Post deleted by Leb i Sol

[Unable]

"... I am looking for a way to track each time a record is accessed in my database."

Refer to your copy of the CDMLRD and specifically to the replacement tag [FMP-InlineAction]. There is a solution suggested therein. No need for me to paste it here.

[Leb i Sol]

Unable: (no offence) BUT

talking about something and not showing people is often demoralising...

--eg.--------------------------------------------------------

"You should see the car I bought!"

>OK, let me see it

"Well, I can't show it to you right now, but I assure u it is in my garage"

--------------------------------------------------------------

so this is what Unable was talking about (I think)

========================================from CDML DB======

<!-- Log page hits in another database -->

[FMP-InlineAction: -db=log.fp5, -lay=web, time="{CurrentTime}", date="{CurrentDate}",

page="This page!", browser="{ClientType}", ip="{ClientIP}", -new]

[/FMP-InlineRequest]

=================================================

which is compleatly different from what originl post was...to my understanding! anyways, what this does is "logs" page hits/visits NOT the record visits (not every page has to access the DB and pull records)

good luck to all of you!

[Unable]

No offense taken. I noticed that this is Kevin's first post. Newbies often are unaware of the CDMLRD. Because of its important role for the FMPro/web developer as a significant refernce tool for syntax and usage, I feel it is a must have item. Perhaps I am wrong. I know I'm no expert.

I would suggest that if one can develop a solution with InlineActions which will record hits in "another database", surely one can develop a solution to record hits of each record in any db file, since each record has a unique -RecID at the very least. It is possible that there is more to it than the cursory view presented by the original post and what one can infer therefrom. This could mean that there is quite possibly more to the entire solution.

Since the solution design is the responsibility of the developer, I would further suggest that I was truly pointing this fledgling to the edge of the nest. But Kevin needs to learn how to soar. Osmosis is not that useful with FMPro.

Finally, because Kevin will need the entire reference and not just a snippet for one tag if he is to succeed (unless he can get you to write his code for him), I concluded my post with, "No need for me to paste it here."

From now on perhaps I will try to be less helpful.

[LaRetta]

"From now on perhaps I will try to be less helpful."

Don't you dare!! I'm amazed at the time we all spend helping each other. We all have different styles and, because we all have lives, sometimes we only have time to offer a word of encouragement or a quick suggestion.

We give alot; we give a little. Sometimes we're right and sometimes we're wrong ... but help is help and it's all appreciated.

LaRetta

[lindm]

Hello all.

I really appreciate all the help I have received so far (?).

You could really call me a newbie. I have been in contact with filemaker earlier but only a week ago really set myself to learn more, especially web publishing. I must say it is really fun learning new things. I am pretty good at html coding which has really been helpful. My javascripting isn't the best...

I will se what I can produce from your help.

Thank you all again,

Kevin

Sweden

[lindm]

Well, I have had some success but still need some help.

I used the following inline action to input to a field called "Access", which worked:

[FMP-InlineAction: -db={CurrentDatabase}, -lay={CurrentLayout}, Access="{FMP-field:Access}+1", -recid={CurrentRecID}, -edit]

[/FMP-InlineAction]

Two problems:

1) I want the access field to update by one everytime. How do I perform an expression after Access="

Is there perhaps another way (script, calculation within FM)?

2) When I use web security the field isn't updated obviously. Is there a solution to this? Have tried setting up the fields in websecurity.fp5, but can't find a solution.

Thank you,

Kevin

[lindm]

I might have found a solution to both of my problems and would really appreciate your input.

1. I made a script called called access2 to update a field called Access which contains the number of times the detail.htm file of time each record has been accessed. Here is the code:

Insert Calculated Result [select, "Access", "Access + 1"]

On my detail.htm file I the inserted the inline action as follows:

[FMP-InlineAction: -db={CurrentDatabase}, -lay={CurrentLayout}, -Script=Access2, -RecID={CurrentRecID}, -Find]

[/FMP-InlineAction]

So far everything seems fine. A problem is that every user can fake hits to a certain record by inserting for example this in the address field of a web browser:

http://x.x.x.x:xx/FMPro?-db=database.fp5&-Format=detail.htm&-lay=1&-recid=1&Script=Access2&-Find

This demands that the user knows the name of my script access2, which easily can be viewd via the source of a record. My way to prevent this was to put the detail.htm in the protected cdml_format_files folder which seems to filter away certain parts, for example my inline action tag above. These at least seems to prevent users from finding out the name of the script...

Any comments? Flaws in my solution, other suggestions? Please.

Thank you,

Kevin

[Leb i Sol]

Hi there!

Unable:

I didn't even see that this is a new person...and I agree compleatly CDML reference is a must. but I remember when I started I didn't even know where to get it (the DBs). Filemaker.com said it is on "your CD"...and thinking that we just bought 8 licences (CDs)of the Laterst FM version (FM Pro 6) and we should have the dam* "reference" on it...well NOT the case..so I "wondered in the woods" looking for 'this' CDML thing while everyone here was just repeating the same...GET the CDML get the CDML....

and by the way ur a very helpful and post great stuff so do NOT stop helping!

Lindm:

"This demands that the user knows the name of my "

-no scripts on the web- (for various resons..look through the forum for answers but for now "just say NO to scritps" )

also from previous post: u need some JavaScript to increment the current value of a field Accessed- FM will not do this automatically. I am not that good at JavaScript but I can try..:

---"Results.html"----------------

.....

<script>

var counter

counter = [FMP-Field: Accessed]

counter += [FMP-Field: Accessed]

</script>

</head>

<body>

<form name="my_form" method="post" action="FMPro">

<input name="Accessed" type="hidden" value="counter">

....

...

....

..

</form>

===============================

All the best!

[lindm]

Well I think I got the javascript right to calculate the hit number:

<SCRIPT language="JavaScript">

var hits=[FMP-field:Access];

var hits2=hits+1

</script>

The problem is then how to get it to the Access field in my database. I am not sure what you mean with the form in your last post, but I want the variable hits2 to be automatically sent to my databse field Access. I was thinking of an inline action like this:

<script language="JavaScript">

[FMP-InlineAction: -db={CurrentDatabase}, -lay={CurrentLayout}, Access=hits2, -RecID={CurrentRecID}, -Edit]

[/FMP-InlineAction]

</script>

but can't seem to get it to work...to bad the whole idea of scripts isn't suitable when publishing on the web (

Any help, suggestions?

As always, thank you.

/Kevin

[Fenton]

I'm not no expert on this here web stuff; but I believe you got a timing problem. I think CDML executes first, then JavaScript. So you can fairly easily update the counter, but the difficulty is then setting that JavaScript variable into a FileMaker field afterwards.

I'd think that the easiest way to do it would be to have a separate field in FileMaker, Access + 1. Then just set Access to that field with an Inline on the Details page. Or include it hidden (as Leb first said) in an -Edit form that takes you to the Details page (would have to be an -Edit form though, not a -Find).

I believe it can also be done by writing the JavaScript directly in the Inline. But not by me :-)

[Leb i Sol]

...Gary would be the JavaScript expert....but I thought the opposite -> that JS runs first (if placed above FMP tags) and also can be called "onLoad" of a page which is (in this case) 1st thing being executed.

This is a great post and yet another fucntion that CDML-FM is missing!

paging Dr. Garry.....Dr. Garry...paging Dr. Garry

[Garry Claridge]

OK, I assume that one record is accessed at a time by a "-find" action.

An easy method is to use an FM Script. I don't mind using FM Scripts from the web if they are small (hence fast) and there is a very low probability of collision. (Look at using "Set Field" rather than "Insert".)

This could be achieved by calling the FM Script ("-script") in the Find URL (or Form). Or, an InlineAction could be used.

The other method is to use Javascript to increment the count and write it back to the record, or to another file which tracks access. This Javascript would look like this:

<script>

hits = [FMP-Field:access];

hits += 1;

</script>

The next challenge is to write this back to the database. The "onload=" parameter of the "<body>" tag could be used. Or, a button can be clicked when the user is finished viewing the record. Or, a META Refresh could be used. Each of these method would need to use the "-edit" action.

I think the "Finish Viewing" button would be the best method as this could return the user to the listing page. The "Listing Page" may then need an "InlineAction" to list the record titles etc.

A little bit of testing would open-up some options.

All the best.

Garry

p.s. I wish CDML could do some basic calculations

[Garry Claridge]

Be aware that all CDML is processed first by the server, then the results are sent to the Browser. Then the Javascript and HTML are processed by the Browser.

All the best.

Garry

[Unable]

For another way.

[Unable]

Leb i Sol, "...so I "wondered in the woods" looking for 'this' CDML thing while everyone here was just repeating the same...GET the CDML get the CDML..."

Golly, a search in the CDML forum for "CDML Reference Database" should have provided at least one valid link. I hate to say this, but to me the CDML forum would be a logical start point for a search of "CDML anything". Sorry you had such a hard time. Did you ask?

[Garry Claridge]

Here is a solution using the "Javascript and onload" method:

<html>

<head>

<title>Views Counter</title>

</head>

<form name="viewsfm" action="FMPro" method="POST" target="dummy">

<input type="hidden" name="-db" value="combotest.fp5">

<input type="hidden" name="-lay" value="web">

<input type="hidden" name="-format" value="blank.html">

<input type="hidden" name="-recid" value="[FMP-CurrentRecID]">

<script>

views = [FMP-Field:views] + 1;

document.write('<input type="hidden" name="views" value="' + views + '">');

</script>

<input type="hidden" name="-edit">

</form>

<body onload="Javascript:document.viewsfm.submit();">

My Record

<iframe name="dummy"></iframe></body>

</html>

I've tested it and it works fine

I have a field, in the database called "views". I also called the Javascript variable "views". (A bit confusing!)

All the best.

Garry

p.s. It is the weekend, I think I should be watching the football (Rugby League)!!!

[lindm]

Thank you Garry.

If I have password protected the edit of records via the websecurity database, this script will not work for obvious reasons. Is there a way to bypass this. I was thinking of setting the field views so that all users can edit it, but can't seem to find a way. Is it possible?

/Kevin

[Garry Claridge]

A straight-forward method is to select "Edit" for "All Users" and enter all other fields into the "Field Restriction" list with "Read Only".

This may become unworkable if you have a lot of other fields, or you need another User to edit records.

The next method would be to use a URL instead of a Form to edit the "views" field. With this you could have a User who can "Edit" records. The URL would look like this:

http://viewsuser:viewspassword@mydomain/FMPro... etc

Filemaker can do a lot more work, with their "Web Security" database, to make security much easier for Web Publishing.

All the best.

Garry

[Garry Claridge]

You could also use a Related "views.fp5" database file. "All Users" could have "Edit" access to this file, but not the main file.

A few more alternatives will keep popping-up

Garry

[Garry Claridge]

Here is a method using another file to "Track Access".

I have a related file called "views.fp5". It has three fields: { main_recid, views, views_recid }

"views_recid" is a Calculated field: Status(CurrentRecordID)

The Relationship is from the main file to the "views.fp5" file using a Calculated field in the main file "main_recid" - Status(CurrentRecordID) to "main_recid" in "views.fp5". I called the Relationship "viewsrel"

On the "web" Layout of the main file I created a Portal with one row and one field "viewsrel::views". I entered the value of 0 in this field for all existing records (this creates the related record in "views.fp5").

I created a Calculated field in the main file: "views_recid" - viewsrel::views_recid

============================================

<html>

<head>

<title>Views Counter</title>

</head>

<form name="viewsfm" action="FMPro" method="POST" target="dummy">

<input type="hidden" name="-db" value="views.fp5">

<input type="hidden" name="-lay" value="web">

<input type="hidden" name="-format" value="blank.html">

<input type="hidden" name="-recid" value="[FMP-Field:views_recid]">

<script>

views = [FMP-Field:viewsrel::views] + 1;

document.write('<input type="hidden" name="views" value="' + views + '">');

</script>

<input type="hidden" name="-edit">

</form>

<body onload="Javascript:document.viewsfm.submit();">

My Record

<iframe name="dummy"></iframe></body>

</html>

=========================================

The "Web Security" database has an entry for the main file which has "All User" as "Browse".

It has an entry for "views.fp5". "All Users" as "Edit".

This also work fine

All the best.

Garry

[Unable]

Kevin wondered, "If I have password protected the edit of records via the websecurity database, this script will not work for obvious reasons. Is there a way to bypass this. I was thinking of setting the field views so that all users can edit it, but can't seem to find a way. Is it possible?"

I believe setting "field views" might work in IWP, but in CWP to allow a field to be edited one needs only allow entry to that field through the form. An edit can then occur only to the field so designated. Unless I'm missing something.

The solution which I have posted uses two db files. The primary db file is set for Browse, the secondary file is set for Browse and Edit. The secondary file is not "seen" by the client, the -edit occurs in the "background" through an auto-loading form.

Understand, of course, that it is quite possible to use just one db file to achieve the same results.

Garry wrote, "I wish CDML could do some basic calculations". In a manner of speaking, CDML in combination with FMPro does allow that. And it does not require ScriptMaker which seems to allow for the possibility of data loss. Do not confuse possibility with probability when designing solutions in which you cannot afford data loss. Not that Kevin's stated desire is that data critical, and Garry's advice could be sufficient in his case. Incidentally, a ScriptMaker script can edit a record in a file which is set in Web Security for Browse only.

Gary recommended a script event in which one should, "Look at using "Set Field" rather than "Insert". But as Anatoli recently observed, CDML acts like "Set Field". This is why an -edit can be used to perform a calculation in FMPro, as in the example I have (after a few errors of some sort) finally posted in the Sample Files forum. You can use the link I posted above to get there.

[lindm]

Both your (Unable and Garry) solutions seem great. I seperate database seems to be a good way! I however always seem to get stuck somewhere when looking for a solution, and so far scriptmaker has proven to be an easy solution...does Filemaker Server handle scripts better? Is next version of Filemaker supposed to fix this "problem"?

I have also started to like inline scripts instead of forms, mainly because a "-Format" tag isn't needed. Problems appear however when trying to incorporate a document.write() from the javascript in the inline action.

Look at this example:

This script in the head (Garrys script above)

<script>

views = [FMP-Field:hit] + 1;

</script>

This in the body:

<SCRIPT language="JavaScript">

[FMP-InlineAction: -db=views.fp5, -lay=1, ProduktID={CurrentRecID}, hit=document.write(views), -RecID={CurrentRecID}, -Edit]

[/FMP-InlineAction]

</script>

document.write(views) is written to my database, not the number.

Someone see any faulty scripting?

/Kevin

[Unable]

"...so far scriptmaker has proven to be an easy solution...does Filemaker Server handle scripts better?"

Easy, yes. Able to lose data, Yes. Server, Unlimited, it does not matter. ScriprMaker handles one event at a time and does not queue subsequent requests received while an event is processing."

"Is next version of Filemaker supposed to fix this "problem"?"

Only if it is for database solutions. And since there is a peer-to-peer workaround to the issue, I'm not holding my breath. FileMaker's position paper tells me that they are a database solutions company, and are not really going any further with web compatablity. They make money selling licenses. Browser solutions require Unlimited, and with enough complexity they may also require Server.

"I have also started to like inline scripts instead of forms,..."

Do you mean InlineActions? If so, I see no reason one could not be used in the solution I offered in lieu of a form to perform the -edit. It should be easy enough to develop.

[lindm]

Sorry, meant inline action.

I can't as well see why it shouldn't work. I will have a go on you solution again tomorrow.

Thanks,

Kevin

[Garry Claridge]

Javascript will not work inside an InlineAction because the InlineAction is performed on the Server before the page is sent to the browser. The Javascript is performed by the Browser as the page is loading.

So, InlineActions first, then Javascript.

All the best.

Garry

[Vaughan]

"does Filemaker Server handle scripts better"

To set the record straight, FM Server *does not* handle script at all! All scripts are processed by the client (who is running FMP software).

With regard to web sharing databases, FM Server is completely optional. All scrtipts are performed by the client copy of FMP (or FMP Unlimited) that has Web Companion enabled and is acting as the web server.

BTW one solution to ther single-threaded ScriptMaker problem could be to use the Web Connector software and a RAIC -- if one web host is busy the next request will pass to another machine. At least that's my theory, haven't tried it yet.

[Unable]

"... FM Server *does not* handle script at all!" Vaughan, I sit corrected. I knew that and misspoke.

I will rephrase to, "A client copy of FMP or FMP Unlimited, it does not matter. ScriptMaker handles one event at a time and does not queue subsequent requests received while an event is processing."

Sort of like Kevin's case where the data is not critical if a hit or a dozen hits get lost since it is really a design "trick" to "impress" the client with an "on the fly popularity contest" score and list.

It's not like he's running an election in Florida.

[Leb i Sol]

Hi Unable and all!

Unfortunately I did ask...but most people just pointed out that CDML is on a a CD or on FM.com. well, FM.com tends to move arround thier D/L so it took me a while...also I was not expecting to find the file.fp5 as a "reference" ...being a newbie I was looking for some PDF or something...also there is entire CDML forum so results were "somewhat" confusing....well anyhow, I found it on some random little site and then is when the whole another world opend....which explains all for my posts and your answers!

All the best!

[Unable]

"Unable: (no offence) BUT

talking about something and not showing people is often demoralising..."

So tell me Leb i Sol, how did you like the Sample file solution?

[Leb i Sol]

hm...old post ref.

Hi Unable!

I have not really tested it but I do not doubt u were generous and I am sure I will be back for it

hopefuly the original poster is happy

thank you