I agree this needs to be clarified.
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 Jan 18, 3:31 pm, Thadeus Burgess <[email protected]> wrote:
> using str(v) does work.
>
> 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
>
> On Mon, Jan 18, 2010 at 12:47 PM, Thadeus Burgess <[email protected]>
> wrote:
> > I will, give me until after lunch.
>
> > -Thadeus
>
> > On Mon, Jan 18, 2010 at 10:28 AM, mdipierro <[email protected]> wrote:
> >> I think we are in a gray area. I think that changing how things look
> >> 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 <[email protected]> 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
>
> >>> On Mon, Jan 18, 2010 at 10:05 AM, mdipierro <[email protected]>
> >>> wrote:
> >>> > Technically it does not "break" backward compatibility. Your app still
> >>> > 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 <[email protected]> wrote:
> >>> >> Sorry this is unacceptable.
>
> >>> >> It breaks backwards compatibility on my company application.
>
> >>> >> -Thadeus
>
> >>> >> On Mon, Jan 18, 2010 at 9:56 AM, mdipierro <[email protected]>
> >>> >> wrote:
> >>> >> > py gives you a radio option that means "none of the
> >>> >> > above". It shows as blank because suggested blank looks better when
> >>> >> > using a dropbox in
>
> >>> > --
> >>> > You received this message because you are subscribed to the Google
> >>> > Groups "web2py-users" group.
> >>> > To post to this group, send email to [email protected].
> >>> > To unsubscribe from this group, send email to
> >>> > [email protected].
> >>> > For more options, visit this group
> >>> > athttp://groups.google.com/group/web2py?hl=en.
>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "web2py-users" group.
> >> To post to this group, send email to [email protected].
> >> To unsubscribe from this group, send email to
> >> [email protected].
> >> For more options, visit this group
> >> athttp://groups.google.com/group/web2py?hl=en.
>
>
--
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en.
