[Anonymous]

Hi Pete,

  I'd sugest you to use sessions to pass data between WPs and pages.

The session is "invisible", it does the work silently, it doesn't show up in URLs, so no need to reconstruct URL after the users drilled down and they want to go back.

Please let me know how that goes. If you see that there is no way to accomplish your goal using sessions then we can look into the URL options. What do you think?

[Anonymous]

I don't believe that mechanism (while helpful) will allow the form actions of submit and cancel to "go to source" correctly. I'd have to construct the original page from the session variables (these view/edit pages are used from a number of drill pages) and I dont now how I would invoke the return to the constructed link from the qListForm pages.

[Anonymous]

Using sessions you don't have to "reconstruct" the page. Just go bak to it and everything will be rememberd. All the session vars you used to get to the page will be there when you get back to the page (unless you reset them).

QWP session feature is easy to use and helps users to avoid the http params problems. 

If you decide to give them a try I'd suggest the followig best practices.

– avoid by all means the session duplicate names

– use meaningful names for your session variable (ie. qListView Customers session name CustomersViewSession,

for Edit Customer CustomerEditSession)

– you can reset one session variable if you consider it necessary

– keep a clear scope of your session

– please note that the session that you set on a QWP (ie qListView Customers) would hold all the data shown on the form (ie for Customers list would hold the Customer Name, Address, Phone, email etc)

– check the documentation, it provides samples and explains the session mecanism in great details

[Anonymous]

I think it's unfortunate that the qListView doesn't provide a fully formed Source parameter by default. Using Sessions will be a considerable rework of my existing site and I am unsure whether it will really fix the problem. I will give it a go.

[Anonymous]

Hi Pete,

It's worth it to give it a try. If that works well and you decide to go the "session way" then you'll find that the application is much cleaner.

[Anonymous]

I have looked into the session mechanism and I can't see how to populate the session variables from a chart drill from many different chart pages into the same drill page. I could set up hidden qSelectors on the drill page to take the values of the passed parameters but when using qSelectors on the same page I have often found them to be out of step with the page they are on (i.e. they don't filter the other WPs on the page until the page is refreshed) when they are used as part of the CAML filter, so I am unconvinced they can be used in the setup I have.

[Anonymous]

Hi Pete,

  On the qSelector web part enab;le the option Refresh age when selection changed and that would to the sessio/page refresh.

Please let me know how that goes.

[Anonymous]

I don't appear to have that option on the qSelector webpart. what version of QWP is that on? I think we are using 5.0

the problem with using session variables on a drill is that the drill is not particular to the qListview part, the parameters are part of the previous page(s) and when I try to use qConnector as filters on the same web page, either the session variable is a step behind the selection, or (if I try to use connections) I get "No provider Schema" errors.

so far, moving to session variables within my application has had mixed results. when working from the top drill, where people might filter before drilling into an edit page, it's all fine. When I have come from a page to the current page, my drill is in the form of http parameters not captured by session variables at present (unless I put a load of hidden qSelectors on the drill page) so to go to an edit page from the drill page means I can't use the drill mechanism of charts, since they don't populate session variables, and populating qSelectors from http parameters isn't workable as part of the drill up/down.

[Anonymous]

QWP ver. 5.0 doesn't have that option.

I know that all version from 5.3 to 5.6 have that option.

I'd suggest you to upgrade to a newer version, it would be easier for you since QWP have improved a lot since 5.0 and also easier for us to support/answer your questions better. What do you think?

Thanks,

[Anonymous]

That suggestion is several steps above my pay grade, unfortunately.

It also doesn't really address the issue of the session solution not really applying to chart drills.

[Anonymous]

I have a page into which people have drilled , which therefore has parameters in the URL which specify the page fully. This page has qListView WPs on it, which have custom actions to view or edit data, and I would like people to return to the drill they were looking at when they click Cancel or Submit on the view or edit page.

I can specify  the HTTP Parameter as URL and call it Source but it doesn’t include the original parameters used to fully specify the drill page and if I add those parameters to the page it will assume that they are parameters for the view/edit page and not the source page.

How do I create a drill-specific Source parameter for use with the GoToURL parameter?

[Anonymous]

Try a newer version to see if thechart and session issue is fixed. QWP offer 30 days trial licenses out of the box (it gets applied during the installation). It would take you a couple of hours to installa nd recreate your env.

[Author]

Posts