... But if we want to keep it longer term we need a better reason.
A recent post has reminded me about a really cool crud feature:
crud.settings.many table-wide callbacks and other options
What would be the replacements for SQLFORM?, I don't think that SQLFORM
supports this kind of
El sábado, 22 de diciembre de 2012 19:30:17 UTC-3, Alan Etkin escribió:
I like crud very much (it's almost tallking english to the server)
crud.read crud.update, ... it's like a web2py classic. For me, sounds like
your preferred pizza delivery is not selling pepperoni anymore
I guess I
LOL. I understand. For now this will stay. But if we want to keep it longer
term we need a better reason.
One posibility would be to rewrite crud keeping the current API (which you
like) on top the new DALForm object from web3py (which is faster than form
handling in web2py).
Massimo
On
I am finishing up the book 5th edition. I was to remove every mention of
the crud API. Almost all of the functionality has been moved into
SQLFORM(...).process(). The latter is in fact better. The crud code has not
been updated in long time and should be deprecated.
The code will stay and we
On 22 Dec 2012, at 11:44 AM, Massimo Di Pierro massimo.dipie...@gmail.com
wrote:
I am finishing up the book 5th edition. I was to remove every mention of the
crud API. Almost all of the functionality has been moved into
SQLFORM(...).process(). The latter is in fact better. The crud code has
I am going over the book with grep. The problems are these: 1) crud checks
permission, SQLFORM does not. 2) crud is used in welcome 3) in chapter 13
we say plugins can rely on crud.
So on a second thought we cannot easily remove it form the book. I will
remove some examples to avoid using
I like crud very much (it's almost tallking english to the server)
crud.read crud.update, ... it's like a web2py classic. For me, sounds like
your preferred pizza delivery is not selling pepperoni anymore
El sábado, 22 de diciembre de 2012 16:57:34 UTC-3, Massimo Di Pierro
escribió:
I am
7 matches
Mail list logo