I can define custom URLs for fields in a query like this:
<column columnName="animalCount">
<datatype>integer</datatype>
<columnTitle>Animal Count</columnTitle>
<url>/query/executeQuery.view?schemaName=study&
query.queryName=demographics&
query.Id/Species/Species~eq=${species}&
query.Id/Age/AgeInYears~eq=${AgeInYears}&
query.sex~eq=${sex}&
</url>
</column>
I am finding this problem quite commonly:
In the above example, the sex field can sometimes be null. If the user follows the resulting link, they go to something like:
..../executeQuery.view?.......&query.sex~eq=
This seems to filter on sex equals empty string, not sex is blank. Hence no records are returned. Is there any way around this? I dont really know what the right fix would be. Either the code behind creating the URLs would need to translate '~eq=' into 'isblank' (which i dont know that we always want) or code behind QWP filters would need to do something similar. |
| |
| Matthew Bellew responded: |
2010-04-16 12:55 |
We seem to have a collection of related problems here. CustomURL was mostly designed to handle the simple case of generating links to detail pages or reports using key fields. Obviously, people find this useful enough that there are lot of different scenarios being tried.
Some problems I've seen are
attach javascript to a field (this is tricky, since you have to guarantee the script will work on all pages)
custom url with path substitution
custom url with conditional substitution
Then there is the problem of the difference between the Ext.Grid and the DataRegion (bigger issue)
We can tackle some of these problems from different angles.
1) add incrementally richer custom url functionality (expressions, etc).
2) expand the DataRegion object to make it easier to 'post-process' the grid to modify the url/javascript properties (very general solution, and can be page/application specific)
3) full Ext.Template like definition of the column rendering (easy to mess up the whole page through)
In this particular case you could link to an intermediate page instead of directly to executeQuery. I we need to talk about other approaches here. |
| |
| Ben Bimber responded: |
2010-04-16 13:14 |
urls are very useful.
if you go down the route of options 2 or 3, a related problem would be custom formats on cells. a simple example is something like conditional formatting: color cells red if the value is outside a pre-defined range, make bold if negative, make blue if field1 is less than field2, etc. lots of permutations are possible. i could also see a case where you have a 'status' field and you want to change formats based on the status of that record. |
| |
| Ben Bimber responded: |
2010-04-27 12:59 |
this is kind of a longshot, but I might as well ask:
Is there any value that acts as a wildcard for filtering a query from the URL? sorta like this:
query.Field~eq=*
in the above posts, I was looking for a way for field URLs to work when a value was empty. When a field that is used in the <url> param is blank, something like this ends up happening:
query.Field~eq=
Which is not the same thing as 'query.Field~isblank'. Assuming some sort of wildcard character existed, we could wrap the field of interest in a CASE expression that returned either the field value or this wildcard if that field was empty. A little awkward, but at least URLs would work. |
| |
|
|