>
> Thank you both for your input. Let me take a sec to try and iterate what I'm
> looking for more clearly.
>
> The only thing I'm focusing on is user interaction with the form. Greg,
> you're correct in that I'm looking for the form to lack a save button. When
> the user changes data in the form, that change is made asynchronously in the
> record in the database that the form represents. It doesn't matter how that
> change gets initiated (maybe form widgets triggering an "onblur" event,
> whatever). I don't necessarily need a persistent connection or socket or
> anything fancy like that; just a simple way to truck data from the form to
> the database, initiated by user interaction with individual form widgets.
> I'm not sure if anyone's had this requirement yet.
>
Hi Nick,
This is a relatively common need, and I think qooxdoo is well-designed
for this, in my limited experience with qooxdoo. In my app, I have a
checkbox as part of a tree item that toggles a setting on the server
through exactly what you describe:
1) listen to the "changeValue" event
2) in the event handler, contact the rpc server asynchronously with the
new value
2a) the server runs a database update and returns a result
3) with the rpc callback, check for an exception, and alert the user if
any, including timeout for network problems.
For security reasons, either use a whitelist of database tables, or
define a different callback method for each database table on the
server, i.e.
class whatever {
protected $fields = array(
'id' => true,
'something' => true,
// ...
);
// set up db object here
function saveThing($field, $value, $id)
{
if (!isset($this->fields[$field])) {
throw new Exception("Invalid field: " . $field . ", not in table
'thing'");
}
// update the database here
}
// ...
}
If you're using PHP 5.3 or newer on the server, I can send you the RPC
server I wrote that makes use of the native json extension as well as
slimmer structure for better speed and native conversion of all PHP
errors and exceptions into a qooxdoo exception format. The only thing
it doesn't do is the weird qooxdoo Date object, it expects you to
serialize it prior to transmission into a string, and to process them in
your code. This results in MUCH smaller code, and so is worth the
tradeoff in my opinion, but won't fit everyone's needs.
In your qooxdoo code, I would probably define a mixin that contains
generic code for calling the RPC server so you can re-use the logic for
any kind of form element.
There are a lot of ways to do this on the frontend (you might instead
use a table, for instance) using the standard qooxdoo stuff. I'd start
with a snippet from the demo browser that looks similar to what you want
and add the rpc portion to it.
One important note regarding the server-side. If there really is a
chance of a concurrency issue, then you'd do well to add a field to each
table that defines the record version. Thus, if Joe and Mary both grab
record version 1000, and Joe edits it, resulting in record version 1001,
and then Mary tries to edit it, you can detect this problem. Simply add
the record version to the WHERE clause of your update statement and
monitor the affected row count. Your update would look something like:
UPDATE thing SET field=value, recordversion=1001 WHERE id=123 AND
recordversion=1000;
If affected rows is 0, then you should alert the user to refresh their
work. You might also want to save who edited what in the record as
well, so you can ask something like "Joe has saved a newer version of
this record, refresh or overwrite?"
This is assuming you're using a sql database. The rules change for
nosql databases as they have this kind of concurrency check built into
the design.
Greg
------------------------------------------------------------------------------
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
