That seems to be a good idea... I would love to see this in the next
release.
On Apr 8, 9:41 pm, Thadeus Burgess wrote:
> Ive sent emails on the list twice, and one email to you personally
> about this. I have not implemented it since it never received any
> feedback.
>
> There will be a 'pre' an
Ive sent emails on the list twice, and one email to you personally
about this. I have not implemented it since it never received any
feedback.
There will be a 'pre' and 'post' of 'select', 'insert', 'update',
'delete', separated by an underscore.
The dal will maintain a list of functions for each
On Apr 8, 10:50 am, Thadeus Burgess wrote:
> I have proposed a signal/slot system for the new DAL.
when? I may have missed or forgotten about this. I would be in favor
of this but I would like to see a complete naming scheme and
understand how do you handle the case when two functions are regiter
I have proposed a signal/slot system for the new DAL.
Simply, The DAL provides an interface to "register" functions for
common operations, such as select/insert/update/delete.
You will simply
db.register('pre_delete', myFunc)
db.register('post_delete', myFunc)
The only difference is when myFunc
Except from being less verbose, how is this different from calling
somefunc under form.accepts?
form=SQLFORM(...) # create, update or delete
if form.accepts(...):
somefunc(...)
On Apr 8, 5:34 am, Ishbir wrote:
> The way that you are doing it in crud, do the same way in DAL. The
> only differe
The way that you are doing it in crud, do the same way in DAL. The
only difference that create_onaccept function will be called if
db.table.insert() is called whether directly or indirectly (via a crud
form for e.g.) and the same applies for update and delete.
In db.py, it could be something like-
Right now the DAL does not provide it because the goal is to keep it
as close as possible to SQL layer. Nevertheless you have a good point
and I would like to see a few proposals for possible API extension.
On Apr 7, 5:33 am, Ishbir wrote:
> What you mentioned is only for crud forms. Isn't there
What you mentioned is only for crud forms. Isn't there anything like a
database wide on add/remove/update function definition? If no, don't
you think it would be good to implement it? For e.g. say I have tags
and tag count. I want to increment tag count on each post update/
addition/removal. That w
This can only be done if insert and delete is done via crud.
crud.settings.create_onaccept = f
crud.settings.update_onaccept = f
crud.settings.delete_onaccept = f
where f is any function that takes the submitted form.
On Apr 6, 5:34 am, Ishbir wrote:
> Thanks for your help, although I had to tw
Thanks for your help, although I had to tweak the code to get it
working. It finally works! Thank you.
And by the way, do you know any way by which behaviours can be
defined? For e.g. if a record is added, then do something, if record
is deleted then do something. Can stuff like that be implemente
Thinking of ditching MANY-MANY altogether, I have come up with this
approach which uses multiple=True-
http://web2py.pastebin.com/813ZELF5
However, the problem is that whenever I do something like
snippet.tags, it just gives me a string list with the IDs. How do I
make it give me a list of the ta
11 matches
Mail list logo
