testers needed
mdipierro
In particular now you can do
IS_IN_SET(...,sorted=True)
IS_IN_DB(...,sorted=True)
IS_EMPTY_OR(IS_IN_SET(...,sorted=True))
IS_EMPTY_OR(IS_IN_DB(...,sorted=True))
If your app uses a lot of dropdowns please check nothing is broken by
this change and let us know.
we also have
IS_DATE_IN_RANGE(minimum,maximum,error_message)
IS_DATETIME_IN_RANGE(minimum,maximum,error_message)
please check them out.
Massimo
Miguel Lopes
Has soon as I clean somethings I'll upgrade my development version and check!
Miguel
--
You received this message because you are subscribed to the Google Groups "web2py-users" group.
To post to this group, send email to web...@googlegroups.com.
To unsubscribe from this group, send email to web2py+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Jeff Bauer
> I have rewritten some of the code that deals with dropdowns, in trunk.
> In particular now you can do
>
> IS_IN_SET(...,sorted=True)
> IS_IN_DB(...,sorted=True)
> IS_EMPTY_OR(IS_IN_SET(...,sorted=True))
> IS_EMPTY_OR(IS_IN_DB(...,sorted=True))
>
> If your app uses a lot of dropdowns please check nothing is broken by
> this change and let us know.
IS_IN_SET works, except problems reported earlier
with SQLFORM.widgets.checkboxes.widget. (I haven't
gotten around to looking into it like I said I would.)
IS_IN_DB works, except I can't still use it to enforce
a one-to-one relation:
db.diag.soc.requires = IS_IN_DB(db, 'soc.id',
_and=IS_NOT_IN_DB(db, 'diag.soc'))
> we also have
>
> IS_DATE_IN_RANGE(minimum,maximum,error_message)
> IS_DATETIME_IN_RANGE(minimum,maximum,error_message)
>
> please check them out.
I have a use for IS_DATE_IN_RANGE and will try it out
tomorrow.
Jeff Bauer
Rubicon, Inc.
mdipierro
On Jan 17, 7:06 pm, Jeff Bauer <jba...@rubic.com> wrote:
> On 01/17/2010 03:27 PM, mdipierro wrote:
>
> > I have rewritten some of the code that deals with dropdowns, in trunk.
> > In particular now you can do
>
> > IS_IN_SET(...,sorted=True)
> > IS_IN_DB(...,sorted=True)
> > IS_EMPTY_OR(IS_IN_SET(...,sorted=True))
> > IS_EMPTY_OR(IS_IN_DB(...,sorted=True))
>
> > If your app uses a lot of dropdowns please check nothing is broken by
> > this change and let us know.
>
> IS_IN_SET works, except problems reported earlier
> with SQLFORM.widgets.checkboxes.widget. (I haven't
> gotten around to looking into it like I said I would.)
Should be fixed. Arent' they?
mdipierro
You need to set IS_IN_SET(...,zero=None)
If not, web2py gives you a radio option that means "none of the
above". It shows as blank because suggested blank looks better when
using a dropbox instead of radio widgets.
On Jan 18, 9:48 am, Thadeus Burgess <thade...@thadeusb.com> wrote:
> Radio buttons are not working correctly.
>
> IS_IN_SET()
>
> and
>
> IS_IN_DB()
>
> are effected.
>
> They are placing a blank option at the top.
>
> -Thadeus
>
> is_in_set not fixed.png
> 20KViewDownload
>
> checkboxes ok.png
> 13KViewDownload
Thadeus Burgess
It breaks backwards compatibility on my company application.
-Thadeus
mdipierro
works. Anyway, you are right, I just thought of a way around that ONLY
restore the default behavior in radiowidgets when the string is empty.
In trunk now. Please check if this is acceptable to you.
On Jan 18, 9:59 am, Thadeus Burgess <thade...@thadeusb.com> wrote:
> Sorry this is unacceptable.
>
> It breaks backwards compatibility on my company application.
>
> -Thadeus
>
Thadeus Burgess
I like the functionality for the dropdowns, but here is the situation.
I am running a production app on earlier code. I would like to update
to the latest version of web2py to receive some security patches that
have happened since this version. I can't update web2py without making
changes to my base code if I want my app to still look the same.
Are we re-defining the term "backwards compatibility" then ?
The reason I care so much about this is the fact there are a couple
other cases where minor edits like this have not been accepted for the
same reason. Edits to basic html display were denied because of
"backwards compatibility". If this were django or python 3.0, I'd shut
up and change my forms.
-Thadeus
mdipierro
does not necessarily constitute breaking of backward compatibility.
Anyway, in this case I agree with you. I think this can be fixed and
made it work as it did before for radio buttons.
Perhaps you can help me debug this. In sqlhtml RadioWidget, why is
this code
opts = [TR(INPUT(_type='radio', _name=field.name,
requires=attr.get('requires',None),
hideerror=True, _value=k,
value=value), v) for (k, v) in options if str
(v)]
still displaying the empty option? The str(v) should prevent it.
Massimo
On Jan 18, 10:17 am, Thadeus Burgess <thade...@thadeusb.com> wrote:
> They are still displaying the same way.
>
> I like the functionality for the dropdowns, but here is the situation.
> I am running a production app on earlier code. I would like to update
> to the latest version of web2py to receive some security patches that
> have happened since this version. I can't update web2py without making
> changes to my base code if I want my app to still look the same.
>
> Are we re-defining the term "backwards compatibility" then ?
>
> The reason I care so much about this is the fact there are a couple
> other cases where minor edits like this have not been accepted for the
> same reason. Edits to basic html display were denied because of
> "backwards compatibility". If this were django or python 3.0, I'd shut
> up and change my forms.
>
> -Thadeus
>
Thadeus Burgess
-Thadeus
Thadeus Burgess
This had to do with another issue, the fact that I am using a custom
options that displays as a OL instead of a table.
So since there is now a space in the options array, I am looping
through this and appending it. If I patch my widget adding if str(v)
then it has the expected result.
It only requires changing one line of code, so I won't bother any
further with the issue.
Thank you.
We need a clinical definition of what "web2py" backwards compatibility
is, and this should be noted on the website.
So I have this software that I am using that has an interface to alter
my data, I use this interface to calculate my data and expect an
output result from the program.
To me, backwards compatibility means that my interface to this
software will always have the same API (call commands), and always
outputs the exact expected output result across backwards compatible
versions.
In web2py, the output is html. I expect this output to be the same
across version upgrades, in my definition of backwards compatibility
it is required the output stay the same for old features.
If changes to the html rendering are not part of your "backwards
compatibility" then my argument is made null, and I will be accepting
of these kinds of changes and edit my apps accordingly if I wish to
upgrade, as long as your clinical definition is noted on the
web2py.com site.
Of course, any changes that happen like this will need a "web2py
version to version" log to help with these upgrades. Since this new
feature is undocumented, I would have no clue as to why this is
happening without an upgrade guide.
In this way, there will be no grey area.
-Thadeus
mdipierro
I need to clarify this to myself as well. I will try.
First of all for me backward compatibility applies to documented APIs
(as documented in the book). It also applies to APIs that are in
stable assuming they have been talked about in the mailing list and
assuming people have tested them.
It does not apply to code in trunk. It does not apply when an
exception was explicitly claimed (I can think of one example only: I
stated many times the current SQLCustomType may go away in the new
DAL, this was always a hack to solve a few people specific problems).
In this case we slightly changed the output of:
IS_IN_SET(('a','b','b')).options()
and we added a
IS_NULL_OR(IS_IN_SET(...)).options()
that did not exist before.
They are used internally by the widgets. The final output of the
widgets did not change (except in the case it was buggy) because we
moved some logic from outside to inside the function. The options
method is not documented in the book and it is not documented in the
epydoc. It does not have a docstring . That is because it is a
function for internal use. It should have had a docstring anyway.
Anyway, it may happen again that in order to fix a bug or streamline
the workflow we may have to make a minor adjustment like the one
above, particularly when the new DAL is out. This does not mean that
backward priority is no longer a priority (it is). In this case I did
not expect it would affect anybody. If it turns out an internal change
affects people you notify me and we decide together the best course of
action.
Massimo
> On Mon, Jan 18, 2010 at 12:47 PM, Thadeus Burgess <thade...@thadeusb.com> wrote:
> > I will, give me until after lunch.
>
> > -Thadeus
>
pihentagy
Someone changed my initial patch, that's not a problem, but 4 lines
misses the s - string specifier at the end of the strings.
error_message = "enter date on or before %(max)s"
error_message = "enter date on or after %(min)s"
error_message = "enter date and time on or before %(max)s"
error_message = "enter date and time on or after %(min)s"
> I have a use forIS_DATE_IN_RANGEand will try it out
mdipierro
patch. I may have done an error in applying it. Can you send me a
patch to fix the corrent version?
KONTRA, Gergely
ps: is not there an easier way to suggest changes to the codes, than
creating a new project on googlecode, and commit changes to that
branch, and after the patch is accepted, delete the branch, and then
for the next typo again, and again...
Is not that possible, that everyone can commit to hg, but Massimo will
decide what can go into, and what not?
diff -r 8b923e09a8d1 gluon/validators.py
--- a/gluon/validators.py Thu Mar 11 14:00:32 2010 -0600
+++ b/gluon/validators.py Sat Mar 13 16:32:14 2010 +0100
@@ -2040,9 +2040,9 @@
self.maximum = maximum
if error_message is None:
if minimum is None:
- error_message = "enter date on or before %(max)"
+ error_message = "enter date on or before %(max)s"
elif maximum is None:
- error_message = "enter date on or after %(min)"
+ error_message = "enter date on or after %(min)s"
else:
error_message = "enter date in range %(min)s %(max)s"
d = dict(min=minimum, max=maximum)
@@ -2072,9 +2072,9 @@
self.maximum = maximum
if error_message is None:
if minimum is None:
- error_message = "enter date and time on or before %(max)"
+ error_message = "enter date and time on or before %(max)s"
elif maximum is None:
- error_message = "enter date and time on or after %(min)"
+ error_message = "enter date and time on or after %(min)s"
else:
error_message = "enter date and time in range %(min)s %(max)s"
d = dict(min = minimum, max = maximum)
+-[ Gergely Kontra <pihe...@gmail.com> ]------------------+
| |
| Mobile:(+36 20)356 9656 |
| |
+- "Olyan lángész vagyok, hogy poroltóval kellene járnom!" -+
mdipierro
> +-[ Gergely Kontra <pihent...@gmail.com> ]------------------+
> | |
> | Mobile:(+36 20)356 9656 |
> | |
> +- "Olyan lángész vagyok, hogy poroltóval kellene járnom!" -+
>