Best practice of coding optional prompts

Question

Post Author: maddyforums
CA Forum: WebIntelligence Reporting
I have a report that has 35 optional prompts for which I want to pass default values if the user doesnu2019t enter any values. This report was originally designed using BO 6.5 and has to be redesigned in WebI XI R2. The main concern of the data modeling team is:
To avoid hard coding of the default values for these optional prompts as this kind of coding will result in messing up the code when a report has too many prompts and might cause performance issues. During scheduling they want to run some scripts to pass the default values to the prompts but the issue is when the report is manually refreshed. They want us to find out whether we can pass the default values to the prompts without hardcoding this logic in the universe/ report for the manual refresh.
Ex:
SELECT -
FROM -
WHERE  ( dbo.BDS_BDS_TEST_TABLE.PAID_DT <= case when ltrim(rtrim(@variable('To Date (MM/DD/CCYY) (Optional)'))) is null then dateadd(ss,-1, convert(datetime,convert(varchar, datepart(mm, getdate()))'/01/'convert(char(4), datepart(yy, getdate())),101)) 
else convert(datetime, ltrim(rtrim(@variable('To Date (MM/DD/CCYY) (Optional)'))), 101) end )
One of the team members has suggested the use of separate data providers for the prompt responses (A data provider that stores all the default prompt values) and uses the data provider functions to pass the values to the prompts. Please let me know whether this kind of approach works. What is the general coding approach for designing these kind of reports with lots of prompts? Please advice.

Answer 1

Hi Ian,
There will be some guidelines in the new documentation, which is currently not yet available.
Here some very short tipps:
- Use an assistance class for each component, which should hold the current data and where you can place central methods. Placing methods in external classes is better than putting them into the component controller, because there is less overhead and more functionality (e.g. optional parameters and exceptions).
- Hold your current data in the assistance class and only put them into the context if needed (e.g. via supply functions).
- Call your business logic from the assistance class during event handling. Then you have the opportunity to do navigation or not depending on the output of the business logic.
- You could use any other class for this purpose, but the assistance class is easier, because it is instantiated by the framework and you can access it via wd_assist-> instead of wd_this->my_class-> .
- Do not create a model component, because this is just overhead and no advantage. In earlier states of the WD project, we thought, a model component would be a good idea, but we changed our minds
- Use context mapping, where it is needed, e.g. if you use the same context in different views.
- It is quite well to call the assistance class from the views.
- Be careful, if you store any references to component parts in your assistance class. Some references may change during runtime, especially those of context nodes placed in a deep hierarchy.
Hope this helps, and more tipps will follow in the documentation or weblogs.
Ciao,  Regina