I have shared my thoughts on these forums and have elected no response from
the community.
Recently other software projects have taken my focus away from web2py,
however I will be diving back into web2py projects
in a week or two, when I do this is one of the first tasks I will be working
on.
I w
Thadeus,
Please consider some blog posts toward an immediate goal of
redesign suggestions. As a new entrant into web2py, it
would be handy for me (and others) to understand where the
edge cases lay.
In the early days of Django, I wrote a lot of forms code
(pre-newforms) and I understand it's a
As fare as I can tell the problems arise from SQLFORM. Nothing
prevents us from creating an alternative (as opposed to a replacement)
to SQLFORM.
There is a reason you have to call SQLFORM explicitly (or call crud
which calls SQLFORM) and it is not implicit. The reason that one may
not want to use
I'm not sure there is a good solution with the current design.
At the moment, I am compiling a document with problem with the current form
system. Along with the document I am also including topics that come up in
the google groups and specific issues that continue to arise where the
solution does
On Jan 13, 2:25 pm, Thadeus Burgess wrote:
> *the inherit problem of always keeping backwards compatibility*
backward compatibility aside. How would you do it?
--
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To post to this group, send email
Good point. Please check trunk and I will post 1.74.7
On Jan 13, 2:25 pm, Thadeus Burgess wrote:
> *the inherit problem of always keeping backwards compatibility*
>
> However, aside from this, there is a bug with the new "choose a value" that
> is unacceptable.
>
> http://static.thadeusb.com/choo
*the inherit problem of always keeping backwards compatibility*
However, aside from this, there is a bug with the new "choose a value" that
is unacceptable.
http://static.thadeusb.com/choosevaluebug.png
-Thadeus
On Wed, Jan 13, 2010 at 9:32 AM, mdipierro wrote:
> On Jan 13, 8:02 am, Alexan
On Jan 13, 8:02 am, Alexandre Andrade
wrote:
> I always remember web2py needs to be more easier to internacionalize.
>
> as example, delete_label in forms always have to be set to be able to
> localize.
>
> All strings 'under the hood' need to be T('string').
Yes but technically, how would you do
I always remember web2py needs to be more easier to internacionalize.
as example, delete_label in forms always have to be set to be able to
localize.
All strings 'under the hood' need to be T('string').
2010/1/13 mdipierro
> There is no way to make everybody happy.
>
> Ok to make zero='' not t
There is no way to make everybody happy.
Ok to make zero='' not to go back to zero=None.
On Jan 12, 11:44 pm, Iceberg wrote:
> I also notice this change.
>
> I suggest to change its default value back to None, so that old apps
> behave in the same way.
>
> Or at least, let the default value be
On 13 ene, 05:44, Iceberg wrote:
> I also notice this change.
>
> I suggest to change its default value back to None, so that old apps
> behave in the same way.
+1
--
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To post to this group, send em
I also notice this change.
I suggest to change its default value back to None, so that old apps
behave in the same way.
Or at least, let the default value be empty string '', rather than an
English phrase "choose a value". The latter causes a developer have to
customize it again and again when de
IS_IN_DB(...,zero=None)
On Jan 12, 9:51 am, Jose wrote:
> How to remove the words "choose a value" of the dropbox?
> I want to work as before where it showed the first reading in the
> table.
>
> Jose
--
You received this message because you are subscribed to the Google Groups
"web2py-users" gr
13 matches
Mail list logo
