Matt Good wrote: > Ilias Lazaridis wrote: > > Matt Good wrote: > > > The parameter could be called "cols" which I think would be more clear. > > > > The model talks about "fields", thus possibly this term should be > > prefered for consistency reasons (the user does not see the term "cols" > > within the code). > > Well, the model's part of the code too, so they wouldn't see "fields" > either. I went ahead and wrote a patch tthat should fix the issues I > mentioned before which uses "columns". I figured this would be > meaningful to end-users since it corresponds to the columns in the > displayed table of results. However, I'd be fine with "fields" if > there's consensus from the other developers for that.
The TracQuery user documentation mentions only "field/fields": http://trac.edgewall.org/wiki/TracQuery Thus the term "fields" should be prefered. > > one thing is a given: the parameter describes a collection of "sets". > > > > Thus, if "col" should be use, the parameter would be "colsets". > > Well, I don't think it should just be limited just to the column lists > defined in trac.ini. This patch provides a "columns" parameter which > can contain a list of column names, or aliases defined in trac.ini: > > http://en.pastebin.ca/246140 > > This also allows aliases to be defined in terms of each other such as: > basic = id,description > expanded = basic,reporter,owner This looks very interesting, but I personally prefere to add functionality incrementally in small steps, taking some (dev)user-feedback in account (at this point I got only feedback ffrom one user). > > > Maybe the trac.ini section > > > could be renamed to "query-field-aliases" or "query-col-aliases", but > > > I'm open to suggestions there. > > > > Query is not specific enouth (other queries will become possible, e.g. > > MilestoneQuery). > > I was thinking there was already a [query] section, so I was going to > be consistent with that, but I checked again and realized that's not > yet defined. The patch I provided uses [ticket-query-column-aliases]. > That is a bit long though, so suggestions for shorter names would be > fine. I still suggest "ticket-query-fieldsets" or "ticket-query-display-fieldsets" > > I apoligize, the provided diff contains a change against a previous > > version of mine and is missleading. the default behaviour is not > > overridden: > > Well, I noticed that it wasn't diffed against a vanilla Trac, but > that's not what I was referring to. See: > http://dev.lazaridis.com/base/browser/infra/trac-dev/trac/ticket/query.py?rev=88#L111 I was not sure about the intention of the code, that's was the reason for this comment: http://dev.lazaridis.com/base/browser/infra/trac-dev/trac/ticket/query.py?rev=88#L123 > In line 111 and 112 Trac defines the initial list of "cols", which you > override in lines 118 and 121. Compare the columns when querying your > site with a "Keywords" filter: > http://dev.lazaridis.com/base/query?status=new&status=assigned&status=reopened&keywords=%7Ea&order=priority > A tiny bug, I've re-created the original behaviour for the keyword, cc, reporter fields: http://dev.lazaridis.com/base/changeset/110 > To the same query on the Trac site: > http://trac.edgewall.org/query?status=new&status=assigned&status=reopened&keywords=%7Ea&order=priority > > The Trac site lists the "Keywords" column in the results while yours > doesn't. The patch I provided above also fixes this. Your patch differes from my development direction. I would prefere to see small steps, thus developers can follow the development and users can review the functionality, too. Additionally, a newcomer can work on code-clarity - something that the existent developers cannot do. But after one month on this topic, I would like to see that something goes into the trunk (thus I get my 'fulfilled-happiness' that an open-source project should give to it's contributors) - so if you go ahead and commit your patch, it would be fine for me. . -- http://dev.lazaridis.com/base/wiki/PlanTicketQueryMacro --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" 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/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
