Clarity

Hello, I wonder if anyone can help me on this. I want to display a list of all cost plans for the current project in a filter field populated by the lookup query below. However, this works only when linked to a project-object attribute, but not in the filter field of the portlet. If this is not at all possible, then I would like to know if I could display to portlets on the same tab to the user and let him select the "filter" fields in the first portlet used in the second portlet below. Unfortunately the term @where:PARAM:XML:INTEGER:/data/id/@value@ does not retrieve the project-id from the url as it does with any other paramter passed there...

SELECT  @SELECT:X.id:Plan_ID@,
        @SELECT:X.object_id:Object_ID@,
 @SELECT:X.name:Plan_Name@,
 @SELECT:X.PLAN_TYPE_CODE:PLAN_TYPE_CODE@,
 @SELECT:X.IS_PLAN_OF_RECORD:IS_PLAN_OF_RECORD@

  FROM
(select fp.id id,
fp.object_id object_id,
fp.name name,
fp.plan_type_code plan_type_code,
fp.is_plan_of_record is_plan_of_record
from fin_plans fp
) X
WHERE @where:PARAM:XML:INTEGER:/data/odf_pk/@value@ = x.object_id
AND @FILTER@

rnitram:

..... this works only when linked to a project-object attribute, but not in the filter field of the portlet....

Yes, true.  You can use that PARAM/XML syntax in a NSQL query to pick up ids from the page URL but not in a lookup NSQL as far as I know.
 

.... I would like to know if I could display to portlets on the same tab to the user and let him select the "filter" fields in the first portlet used in the second portlet below....

Yes, but not quite how you have described it ; what you want is a "filter-portlet" on your page - you then can use one set of filter-fields captured in the filter-portlet to control the queries in multiple other portlets on the same page.

Thank you very much for your quick response. However, I have tried to use a filter portlet, but the filter portlet does not allow the use of queries and I am only allowed to add fields. That in turn leads to the above described problem again, i. e. the use of project id in the lookup not possible... Is there something during the filter portlet creation that must be changed in order to allow queries?

Not sure I underdstand what you mean by "the filter portlet does not allow the use of queries"?

A filter-portlet exists only to capture filter fields (which can be lookups like any other filter field).  You still have the problem that these lookups can not be sensitive to a "id" on the URL though.

--

I was only suggesting filter-portlets in response to your second question ; as far as I know there is no way that NSQL lookups can take any "page parameters" when used as filter-fields (they can use the built-in parameters like USERID though, but these do not sound useful to your use-case)
 

Thank you again for your quick reply! - I am afraid you understood it as it was meant by me... Is there a way to select the currently viewed projects via the user id? - I could use this information at least to restrict the number of entries in the filter field...

I don't think so; unless you can exploit the relationship between the logged on user and the project in some way (for example they were the project manager of the project, staffed on the project, had some identifiable instance access right on the project???)
 

Again, thank you very much for your support! I wonder if the project-id will be available for dynamic lookups in future releases, I guess this would be a valuable feature for a lot of users...

Hi Dave,

Can you provide some example syntax for the recommendation to pull values from the address?

"You can use that PARAM/XML syntax in a NSQL query to pick up ids from the page URL"

I have a subobject of Project and want to have a filter for only entries in a particular project.

Thanks,

Lowell

This is documented in the Studio Developer's Guide under "NSQL / XPATH (XML Parameter) Constuct"

As an example; 

@WHERE:PARAM:XML:INTEGER:/data/ProjectID/@value@

this will grab the ProjectID from the URL of the page you are on (assuming it contained the text "&ProjectID=123456" somewhere in the URL of course).

Some discussions elsewhere on the boards (eg RE: How to default to project instance within NSQL portlet? ) - search for "drill down" - (all this is to do with custom NSQL based portlets and custom portlet pages)

Hi Dave

this will grab the ProjectID from the URL of the page you are on (assuming it contained the text "&ProjectID=123456" somewhere in the URL of course).

Yes, true.  You can use that PARAM/XML syntax in a NSQL query to pick up ids from the page URL but not in a lookup NSQL as far as I know.

just to clarity:

You keep mentioning URL in context of XML param?

The relation between the two is that URL params get transferred into XML (check debug=1 output with custom ...&MyParam=yes&whateverElse=1111)

the @WHERE:PARAM:XML.... handles the XML, not URL

Hence you are able to access URL params as any other param in XML and you are able to access XML from NSQL Queries as well as Lookups

I do not know what xpath (if at all) parser is used in Clarity , I expect one that comes with Saxon, but still syntax construct does not

accept any collection/function handling methods , like []; ::, () (clarity ver 13)

hence you should point to single values with your xpath, like /data/header/security/@sessionId

If anybody knows how to work with collections, something like /data/Objects/Object[postition() = 1]/@code please share info

cheers!

pp

Hi - I don't really know what question you are asking me?

All I know is that using the code examples (as above), I can pickup (in a NSQL-query) values from the page URL that a portlet sits on - I can thus exploit this in order to build 'drill-down' functionality (from - for example - a summary-portlet to a detail portlet) since I can control the URL that a custom-page has using the page's linking options.

Possibly we can access other XML parms using the same syntax (is that what you are saying?) - great... any explicit examples of how we would do that or why we would want to do that (i.e. how we can exploit that to provide 'useful' functionality) would be welcome - perhaps deserving of a new "Tip" thread though rather than buried in a disucssion-thread about lookups?