>
> I'm curious about what you consider "deletes 2nd row". Your
> statement "data was there before ... data is absent after" makes me
> think you are defining a delete as "user blanked out all fields of the
> record" -- technically that just means the user, well, nulled the field
> contents but is not considered a deletion.
>
>
Dennis, you are right.
Anyway I have already abandoned that logic.
Most interfaces that I've seen with a record deletion capability
> rely on either a column on the form with a check-box, to indicate that
> row should be deleted (this format allows multiple deletions at a time
> from a tabular/grid display), or an explicit action
> (context-menu/right-click menu) ON EACH row, with a delete "command"
> that takes effect immediately (well, maybe after a pop-up confirmation
> "Are you sure you want to delete XYZ").
>
> Hopefully the interface logic is smart enough to internally tag
> records that have had changes performed on screen, and will issue
> database updates when the screen is changed (on tabular/grid systems,
> this could be whenever the user changes to a different row, only if the
> "current" row had been modified; or it could cache all those modified
> rows and submit them as a batch when the entire page is
> exited/saved)[Reading ahead, this may be what is described in the
> master's voice]
>
I am using a hybrid of 2 systems.
Dabo's biz & db layers + web2py framework.
So I need to write the code to handle user-interaction and flag the records
accordingly.
> Message: 8
> Date: Thu, 9 Feb 2012 10:50:56 -0600
> From: Ed Leafe <[email protected]>
> On Feb 9, 2012, at 10:28 AM, Vineet Deodhar wrote:
>
> > To make my question more clear, pl. consider the vfp cursor adapter.
> > In the cursors added to data-environment, records are either updated or
> > marked for deletion or appended.
> > At the end, with just a single call, it takes care of the CRUD functions
> > automatically.
> >
> > Whether such behaviour like vfp CA is possible here?
>
> Dabo works the same with one exception: deleting a record happens
> immediately, whereas the other changes (append/update) are buffered. Those
> changes exist in the local cursor's data, and when you call save(), they
> are all written to the backend. Likewise, you can call cancel() to revert
> those changes at any time before writing them with the save() call.
>
> If you need buffered deletes, you will need to add a column to the
> cursor's data that works like the VFP delete() flag. Then, in your
> afterSave() code, find all the records with that flag set, and call
> delete() on them.
>
>
> -- Ed Leafe
>
Thanks Ed.
Your tip of adding a deletion-flag in dataset is useful.
The strategy I am planning is like this--
* I have "web2py" framework having MVC architecture.
* From the Controller, data is fetched from the DB in tuple of dicts.
* I will add a field in each dict for marking deletion (flag).
* Either pass this tuple to View as it is, or pickle it.
* In View, tuple is parsed (unpickled, if earlier pickled), values of data
are altered, flags are set, and add/edit/del are handled (with seek,
requery, setfieldval)
* On 'save' button hit, this tuple is pickled and controller function is
called for handling save/delete.
If anybody finds something silly in this, pl. point-out.
Thanks,
Vineet
--- StripMime Report -- processed MIME parts ---
multipart/alternative
text/plain (text body -- kept)
text/html
---
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
Searchable Archives: http://leafe.com/archives/search/dabo-users
This message:
http://leafe.com/archives/byMID/CAP5=7oqg17peecex-088vhozrmp6m-wg_ice-dfnan1b4kp...@mail.gmail.com
