Hi Jonathan, I still do not see why it is 'reasonable' to force a table name into the linkto url, and then have to write a lamba function to override it. After all, we have the URL helper which gives us all the flexibility we need. If I want the table name, I can introduce that myself as an arg or a var.
However, I appreciate that the linkto logic is quite complex. Thanks very much for your explanation and help. Best wishes -D On Nov 6, 4:48 pm, Jonathan Lundell <[email protected]> wrote: > On Nov 6, 2010, at 6:02 AM, villas wrote: > > > @Jonathan > > Rather than experiment with a new lamba work-around for 'linkto', I > > may as well avoid 'linkto' and use 'represents' which I already > > know. > > > My question was more to do with whether linkto behaves correctly and > > flexibly to produce the urls required. From your review of the code, > > it seems that linkto is not always so useful if it insists on adding a > > 'table' arg. > > It makes sense that it would do so, though, since it's reasonable to put both > the function and table name into the URL. I don't think it'd make sense to do > that differently just because they happened to have the same identifier > string. > > WRT the lambda, the linkto logic explicitly checks for a function and uses > whatever it returns. That's apparently the intended use if the default href > that it generates isn't suitable. The advantage to using linkto (over > represents) is that it's specific to this particular usage. Otherwise, yeah, > it's a coin toss. > > The complicated linkto behavior doesn't appear to be documented (lambda or > not; there are multiple cases), which makes it somewhat less useful than it > might be. > > > > > @Richard > > Yes, I know I can use represents, I said that in my original post, > > but thanks all the same for your help. > > > -D > > > On Nov 5, 9:31 pm, Jonathan Lundell <[email protected]> wrote: > >> On Nov 5, 2010, at 12:18 PM, Richard Vézina wrote: > > >>> Try this! > > >>> table.id.represent = lambda id: \ > >>> A('Edit',_href=URL(r=request,f='FUNCNAME',args=('TABLE',id))) > > >> That's going to have the same problem, since in villas's example, both > >> FUNCNAME and TABLE are 'mytable'. > > >> My earlier suggestion is to change this: > > >> SQLTABLE(mytablerows,linkto=URL()) > > >> to something like this: > > >> SQLTABLE(mytablerows, linkto=lambda rep,t,tn: URL(r=request, > >> args=[rep])) > > >>> On Fri, Nov 5, 2010 at 3:11 PM, villas <[email protected]> wrote: > >>> @Jonathan > >>> I think you are right about the /<function>/<table>/<id> convention > >>> for SQLTABLE linkto. > >>> But by using linkto=URL() I should be able specify whichever URL I > >>> want rather than have to work around an unnecessary convention? > > >>> @Richard > >>> I played around a little, but I couldn't make that work for me, but > >>> maybe I'm missing something. > > >>> On Nov 5, 6:33 pm, Jonathan Lundell <[email protected]> wrote: > >>>> On Nov 5, 2010, at 11:00 AM, villas wrote: > > >>>>> Does SQLTABLE linkto work properly? > > >>>>> If I use: > >>>>> SQLTABLE(mytablerows,linkto=URL()) > > >>>>> I get URLs like this: myapp/default/mytable/mytable/id > > >>>>> Note the duplication of "mytable". > > >>>> I wonder if this is really a "duplication". As web2py interprets a URL, > >>>> the first mytable is a function name, and the second (in this case) is a > >>>> table name, right? They happen to have the same name here. > > >>>> (That said, SQLTABLE's linkto logic is distinctly non-trivial; I'm not > >>>> at all sure what's going on in several of the cases.) > > >>>>> I have tried with URL('mytable') and URL(f='mytable'), but it's the > >>>>> same. > > >>>>> Of course I can work around the issue specifying: > >>>>> db.mytable.id.represent = lambda id: > >>>>> A('edit:',id,_href=URL(args=(id))) > > >>>>> ...which gives the URL that I expect, but that is not the question > >>>>> here... > > >>>>> --D > >
