Clarity

Hi guys,

I am trying to create a dynamic lookup to return all base lines from a project and i would like to use it in a portlet filter. Do you know if it is possible, it returns no data at all!

select 
@select:id:id@,
@select:name:name@
from  prj_baselines 
where project_id = @where:param:xml:integer:/data/id/@value@
and @filter@

Thanks for the help.

Check this -

RE: Custom attribute empty

NJ

And this -

Re: Technique sought for linking an NSQL parameter to a portlet or portle

NJ

Hi navzjoshi00, thanks for your aswer.

This two posts does not seem to solve the problem. The lookup does not show any data on the filter of a portlet, the portlet is on a project tab and i would like to get the project id from the url.

Think that what you are trying to do might only work if you implement the lookup as a PULL DOWN and not a BROWSE.

(reason being that the pull-down is 'on' the page with the 'id' in the URL, the browse spawns a new page that does not have a (visible) URL)

Hi Dave,

Thanks for you answer, it was a pull-down since the begining and the parameter is null always. Have you ever used a parameterized lookup in a portlet filter?

I am staring to lose my faith in this one. I guess it might just not work this way !

I've done (recently) what you are trying to do, but not on a project page, on a normal portlet-page (pulling custom parameter from the URL using the WHERE:PARAM:XML syntax) - the trick for me was the PULL-DOWN vs BROWSE distinction.

Note this is not a parameterised-lookup as such though (in that those are used on objects and the @WHERE stuff is a different syntax).

I don't see why your example would not work though

Can you check something like below ?

WHERE ( project_id = @WHERE:PARAM:USER_DEF:INTEGER:ProjectID@ OR @WHERE:PARAM:USER_DEF:INTEGER:ProjectID@ IS NULL)

Also, can you try to bounce the apps and see if the change takes affect ?

NJ

@NJ that NSQL syntax is the syntax for a proper parameter (like you'd use in a portlet) or in a parameterised lookup (where you would then associate that parameter with an attribute on the object to which you are associating the lookup), the idea here is to read the 'id' from the URL of the page and that is where that XML syntax is used (just like it can be used in a portlet's NSQL query)

--

For the record, in my recent usage of this technique, I was using the syntax ; @WHERE:PARAM:XML:INTEGER:/data/param_yymm/@value@ and that was picking up the 1410 value from my URL that looked like this;     blahblahblah/niku/nu#action:e3_m_perf_p_t&frame_id=5054049&param_yymm=1410&prj_id=5000000

( e3_m_perf_p_t being the tab id on my portlet page)

The only other thing might be that my lookup field is in a page-filter portlet rather than a normal one, but I can't think that that makes a difference.

Oh....ok

"The only other thing might be that my lookup field is in a page-filter portlet rather than a normal one, but I can't think that that makes a difference. " - might be

NJ