On 4/6/10 1:04 PM, Ricardo Aráoz wrote:
> Paul McNett wrote:
>> On 4/2/10 3:19 PM, Ricardo Aráoz wrote:
>>
>>> Ed Leafe wrote:
>>>
>>>> On Apr 2, 2010, at 3:53 PM, Ricardo Aráoz wrote:
>>>>
>>>>
>>>>
>>>>> Hi, in the PyCon Tutorial in the section "Creating the Many:Many
>>>>> Relationship between Recipes and Categories" when adding the
>>>>> CklCategories control to the PagEditRecipes the code reads :
>>>>>
>>>>> 79 mainSizer.insert(0, gs, 1, "expand", border=20,
>>>>> borderSides=("top", "bottom", "left"))
>>>>>
>>>>> I think it should read :
>>>>>
>>>>> 79 mainSizer.insert(0, gs, "expand", 1, border=20,
>>>>> borderSides=("top", "bottom", "left"))
>>>>>
>>>>> Because checking the API, layout comes before proportion.
>>>>>
>>>>>
>>>> You are correct, but that's one of the little magic things that we do
>>>> under the hood. Layout is a string, while proportion is an integer, so if
>>>> the method receives them reversed, it will figure out what you really
>>>> meant. ;-)
>>>>
>>>>
>>>>
>>> Ok, thanks.
>>>
>>> New question (it is one of those days ;cP). At the end of this section,
>>> after adding the methods to save changes in CategoriesForRecipe(), it is
>>> stated
>>> """
>>>
>>> I also chose to save() the new record in line 50. Dabo's delete()
>>> already commits immediately to the backend, so we may as well make
>>> save() immediate in this context, too. It wouldn't make sense to the
>>> user that unchecking a category saves the change immediately, while
>>> checking a category requires an explicit save().
>>>
>>> """
>>> This is correct, it is what the code does, but I think it is
>>> inconsistent with the rest of the form. You see, the user can change
>>> many recipes at will but nothing will be saved (in recipes) till he
>>> clicks the save button, but on the other hand whatever he does linking a
>>> category to a recipe gets automatically saved. The result is that if the
>>> user performs a series of changes to the recipes (including adding or
>>> deleting links to categories) and then chooses not to save, the changes
>>> will not be completely undone as the linking to categories can not be
>>> undone.
>>>
>>
>> I know, it is inconsistent. But I didn't know what to do given the
>> inconsistency
>> between new() and delete() in Dabo (the latter implicitly commits, while the
>> former
>> doesn't). I guess I could have managed the category linking in my own
>> structure
>> instead of keeping them in the bizobj, and then created code to run on
>> save() to get
>> the category information linked up.
>>
>> Paul
>>
>
> What about enclosing everything between saves in a transaction, and
> having a cancel changes button which would roll it back? And it would
> make a good teaching on how to control transactions from within Dabo.
> I'd love to see how it is done. Can't take up too much coding to do it.
I don't think a transaction should be held open for a potentially long time. As
far
as enclosing things in explicit transactions, it is as simple as:
biz.beginTransaction()
...
biz.commitTransaction()
--or--
biz.rollbackTransaction()
Paul
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
Searchable Archives: http://leafe.com/archives/search/dabo-users
This message: http://leafe.com/archives/byMID/[email protected]
