But shouldn't it be the same for the grid and for the record of the grid?
The difference confuses me - having to specify the table should be
consistent when I use the grid for all the transactions of the
grid, including view/edit etc..

In other words, having to specify the table is perfectly fine - but it
should be consistent and I should as well specify the table for the
view/edit action of the grid record. Different structures for the gird and
fo the record of the grid seems inconsistent to me.It took me time to
figure this out - now that I know how this works, I simply have the
try/except to solve it - this makes practical sense, as it solves the
problem, but it makes no logical sense. Do you know what I mean? Anybody
who encounters such a situation will presumably be messed up and have to
spend time figuring out what's going on.

On Wed, Oct 7, 2020 at 10:22 PM Jim Steil <ato.st...@gmail.com> wrote:

> I think that is a result of having a left join specified.  With the left
> join you now have to specify which table the field is in as well.
>
> Or, am I missing something?
>
> -Jim
>
> On Wed, Oct 7, 2020 at 9:13 PM Eliezer (Vlad) Tseytkin <
> westgate6...@gmail.com> wrote:
>
>> Jim,
>>
>> Thank you for the suggestions.
>>
>> I do specify field_id (it wasn't there in the simplified code, but the
>> complete code does have it).
>>
>> When I use a function, instead of the lambda, I indeed can have a
>> solution, but at the same time it emphasizes that something is wrong:
>>
>> The links are now presented as such:
>>
>>     links = [dict(header='View', body=GetCartsGridLink)]
>>
>>
>> And the GetCarrsGridLink function as follows:
>>
>> def GetCartsGridLink(row):
>>>
>>>     id = None
>>>
>>>     try:
>>>       id = row.cart.id # this works for the grid itself
>>>     except:
>>>       id = row.id # this works for the view/edit of a record of the grid
>>>
>>>     result = A(id,
>>>                _href=URL('manage', 'view_cart', args=id,
>>> user_signature=True),
>>>                _target='blank')
>>>
>>>     return result
>>
>>
>> It does solve the problem, because try/except takes care of it, setting
>> up the id based on the context.
>>
>> I feel there is something wrong with the very necessity of having to use
>> try/except here. Why would it use different structures in the grid itself
>> vs. view/edit a row of the grid???
>>
>> The problem has been solved, but the mystery remains. I am still missing
>> something about it...
>>
>> On Wed, Oct 7, 2020 at 4:48 PM Jim S <ato.st...@gmail.com> wrote:
>>
>>> I have a couple of ideas, but none are tested
>>>
>>> First, can you try adding the field_id parameter to your SQLFORM.grid()
>>> call?  I believe that tells this grid which is your 'primary' table.
>>>
>>> Secondly (this is the way I typically handle it) - instead of coding
>>> everything in a lambda, call a function to build your buttons and just pass
>>> it the id of the row.  Then, in your function you can retrieve the entire
>>> row and get all the data you need even if it isn't included in the grid
>>> fields.
>>>
>>> Not sure that completely addresses your concern, but if you run through
>>> those ideas it might help you onto a solution.
>>>
>>> -Jim
>>>
>>>
>>> On Wednesday, October 7, 2020 at 1:44:41 PM UTC-5, Vlad wrote:
>>>>
>>>> Seems to me this is an inconsistency in the way how grid operates
>>>> (which breaks it, as I show below, but, of course, most probably I am just
>>>> missing something.)
>>>>
>>>> The following code crashes:
>>>>
>>>>     query = db.cart
>>>>     fields = [db.cart.id]
>>>>     links = [dict(header='View', body=lambda row: str(*row.cart.id
>>>> <http://row.cart.id>*))]
>>>>     grid = SQLFORM.grid(query, editable=True, details=True,
>>>> links=links, fields=fields)
>>>>
>>>> This is because row.cart is undefined in the links. Instead, the links
>>>> should be made as such:
>>>>
>>>>     links = [dict(header='View', body=lambda row: str(*row.id
>>>> <http://row.id>*))]
>>>>
>>>> Now this works.
>>>>
>>>> However, when I add more fields in the code, like this:
>>>>
>>>>     fields = [db.cart.id, db.cart.description, db.cart_ownership.boss,
>>>> db.cart_ownership.status, db.cart.count]
>>>>
>>>> Now in the links I can't use "row.id". It must be "row.cart.id"
>>>>
>>>> This by itself would be fine, I could just use *row.id <http://row.id>*
>>>> or *row.card.id <http://row.card.id>* accordingly, depending on the
>>>> fields used (though I would like to control this structure), but I am
>>>> having the following problem further on:
>>>>
>>>> The grid described by the code
>>>>
>>>>     query = db.cart
>>>>     fields = [db.cart.id, db.cart.description, db.cart_ownership.boss,
>>>> db.cart_ownership.status, db.cart.count]
>>>>     links = [dict(header='View', body=lambda row: str(row.cart.id))]
>>>>     grid = SQLFORM.grid(query, editable=True, details=True,
>>>> links=links, fields=fields)
>>>>
>>>> crashes when I try to view or edit a row of the grid. This is because
>>>> the links takes  row.cart.id in the grid itself, but expects row.id in
>>>> edit- or view- actions (i.e. when editing or viewing a row). When viewing
>>>> or editing a row, row.cart is undefined in the links, so row.cart.id
>>>> crashes it (when "view" or "edit" buttons are clicked), while in the grid
>>>> itself row.cart.id works just fine (and row.id would not work).
>>>>
>>>> What am I missing here? How do I control how this field should be
>>>> expected in the links in the grid vs. in the view/edit a row of the grid?
>>>>
>>>> Here is still simplified but more complete code, in case I missed
>>>> something important in a "shortcut" code above:
>>>>
>>>>     query = db.cart
>>>>     fields = [db.cart.id, db.cart.description, db.cart_ownership.boss,
>>>> db.cart_ownership.status, db.cart.count]
>>>>     links = [dict(header='View', body=lambda row: str(row.cart.id))]
>>>>     grid = SQLFORM.grid(query,
>>>>                         editable=True,
>>>>                         details=True,
>>>>                         links=links,
>>>>                         fields=fields,
>>>>                         left = [db.cart_ownership.on(db.cart.id
>>>> ==db.cart_ownership.cart)],
>>>>                         field_id=db.cart.id,
>>>>                         )
>>>>
>>>> --
>>> Resources:
>>> - http://web2py.com
>>> - http://web2py.com/book (Documentation)
>>> - http://github.com/web2py/web2py (Source code)
>>> - https://code.google.com/p/web2py/issues/list (Report Issues)
>>> ---
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "web2py-users" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/web2py/UGhYBMwmXec/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> web2py+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/web2py/257aa85d-41f2-4b2e-a59a-bd1980c83efco%40googlegroups.com
>>> <https://groups.google.com/d/msgid/web2py/257aa85d-41f2-4b2e-a59a-bd1980c83efco%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>> --
>> Resources:
>> - http://web2py.com
>> - http://web2py.com/book (Documentation)
>> - http://github.com/web2py/web2py (Source code)
>> - https://code.google.com/p/web2py/issues/list (Report Issues)
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "web2py-users" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/web2py/UGhYBMwmXec/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> web2py+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/web2py/CABZ%2BKCCVY37AMAFQ6FxgpJvX3X%3Dbr9gFBU68c74HpUJw3pEa%2BQ%40mail.gmail.com
>> <https://groups.google.com/d/msgid/web2py/CABZ%2BKCCVY37AMAFQ6FxgpJvX3X%3Dbr9gFBU68c74HpUJw3pEa%2BQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
> --
> Resources:
> - http://web2py.com
> - http://web2py.com/book (Documentation)
> - http://github.com/web2py/web2py (Source code)
> - https://code.google.com/p/web2py/issues/list (Report Issues)
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "web2py-users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/web2py/UGhYBMwmXec/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> web2py+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/web2py/CAERBpoBS7skdN8q%3DzYwfA01WK-TKEHXkvq0iX%3Df4ghMRVbPzyw%40mail.gmail.com
> <https://groups.google.com/d/msgid/web2py/CAERBpoBS7skdN8q%3DzYwfA01WK-TKEHXkvq0iX%3Df4ghMRVbPzyw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

-- 
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
--- 
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to web2py+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/web2py/CABZ%2BKCDDLn4LQRq83HhU6tsd9myU%3Du2Ksaf1cLu1ujKAVyjGhw%40mail.gmail.com.

Reply via email to