Hi
never thought that discussing solutions and voicing opinions would be
called 'disservice': I always thought that this is the point in having
mailing lists.
But you setting me straight I humbly apologize for having voiced my
clearly not counting opinion on this list.
Werner
Greg Beaver wrote:
>> 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
------------------------------------------------------------------------------
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
