At 10.50 +0100 2007-03-08, [hidden email] wrote:
>I notice in the demo setup that there's two keyfields. ID that's auto incremented and keyfield that's a VARCHAR set to 255.
>From what I can gather only keyfield is used. Does ID fill any purpose?
The ID field is normally not used by Knop.
The purpose of the long keyfield is to make it a safe (or call it obscured if you prefer, it can be debated if it's actually to be considered "safe" or not) identifier also when it is exposed. If using the long keyfield, it is not necessary to also have an autoincrement, but I find it convenient to have an autoincremented keyfield available for joins and such. Maybe that's just out of habit. Knop itself doesn't need both keyfields (the keyfield and the id).
And if you like, you can specify an autoincremented numeric field as keyfield for the database ctype. The only odd thing that will happen is that when adding a new record through the database ctype, Knop will try to insert a random string into the numeric keyfield which will be ignored by MySQL.
Instead of a random string, the numeric id could be encrypted and used as exposed identifier so you wouldn't need a separate keyfield with random string. I've chosen to use a random string instead, both to minimize processing overhead but also to make it possible (easier?) to prevent the creation of duplicate records that can otherwise happen if the user reloads the page after adding a record, since it would be difficult to predict the encrypted next autoincremented value before the record is added. An option to use encrypted autoincremented id instead could be added if there's enough interest.
Btw, another common way to do duplicate prevention is to redirect the page after form submission so there is no POST data to reload, but that would cause difficulties with feedback from the operation. It also would not prevent the user from backing to the form and submitting it again, which the Knop way prevents.
Redirects after form submission is otherwise rather popular but I've never really liked it.
>And why is keyfield set to 255? It looks as it only needs 25 chars.
Just sloppy optimization from my part. It actually only needs to be something like 12-13 chars.
The lockfield however needs more length since it needs to account for both a user id (which can be a combination of values if you like), plus the lock timestamp. 25 might be enough for when using a plain integer or short string as user id.
In a Knop-based project I used the user_id, the userlevel and user category as value for the lock user, to be able to give a more informative message when someone else tries to edit the same record. That's an example of the flexibility I really like with Knop.
Johan Sölve [FSA Member, Lasso Partner]
Web Application/Lasso/FileMaker Developer
MONTANIA SOFTWARE & SOLUTIONS
http://www.montania.se mailto:[hidden email] (spam-safe email address, replace '-' with 'a')