Home » Archived » BIRT » Does BIRT 2.2 support "named" parameters of data sets?
| | | | |
| Re: Does BIRT 2.2 support "named" parameters of data sets? [message #360531 is a reply to message #360520] |
Wed, 06 February 2008 16:36   |
 Maged Elaasar
Messages: 529
Registered: July 2009 |
Senior Member |
|
|
Ok I see what you are talking about now. However, there is an assumption in
this implementation that you can implement IQuery.getParameterMetaData()
based on the queryText only. This means that the queryText has to include
the information about the parameters. This is not true in my case as the
user would use BIRT parameter page (and not my custom ODA page) to specify
the parameters metadata, i.e. that metadata is not encoded in the query
string, but is available in the DataSetDesign. This also makes returning the
ParameterDefinition from my page awekward since it does not have any thing
to do with parameters, as I said parameters are defined in a BIRT-provided
page.
I am quoting from the BIRT documentation
( http://www.eclipse.org/birt/phoenix/ref/rom/elements/OdaData Set.html)
"Many data sets allow parameters, which can be of input and/or output modes.
For some, the user must define the parameters as part of the data set
definition. For other data sets, the driver itself can provide the set of
parameter definitions from the information available in a data set query. In
the latter case, parameter definitions are derived data and are not stored
in the parameter definition."
Ok so according to this, there is 2 ways of defining parameters : 1) in the
data set definition 2) from the data set query. The implementation you are
suggesting follows approach number (2) where my implementation follows
approach numbe (1). The question still is: how do I set the position param
to -1 in ParameterDefinition if the param metadata is not encoded in the
query string of my data set, but rather defined by BIRT parameters page?
Also am I right that in using approach (1), there is no way to implement
IQuery.getParameterMetaData() ?
I really appreciate your help
Maged
|
|
| | |
| Re: Does BIRT 2.2 support "named" parameters of data sets? [message #360573 is a reply to message #360535] |
Fri, 08 February 2008 22:01 |
Linda Chan
Messages: 845
Registered: July 2009 |
Senior Member |
|
|
Your use case should be workable, though it might not have been fully tested
;-).
The parameter metadata defined by BIRT Parameters page does get passed to a
custom ODA data set page. The DataSetDesign argument passed to the
CustomDataSetWizardPage.updateParameterDesign method contains those metadata
in the ParameterDefinition instance(s). Try implement the
updateParameterDesign method to modify the existing ParameterDefinition
instance(s), instead of replacing them with runtime parameter metadata.
Note that the parameter name defined on the BIRT Parameters page is for the
BIRT level, and is separate from a "native" parameter name defined by an ODA
designer/driver. Thus the ParameterDefinition of a BIRT-defined parameter
has an empty native name and an automatically assigned position in its
DataElementAttributes. So your CustomDataSetWizardPage will need to assign
the parameter's native name and set its position to 0 (btw, -1 is actually
not a valid value).
Separately, a query's parameters information do not need to be embedded in a
query text for an ODA runtime driver to implement
IQuery.getParameterMetaData(). The oda.IQuery interface has other methods
that can also pass in needed information before a query returns its
parameter metadata, e.g. setAppContext, setProperty.
The assumption you saw from the generated implementation in
CustomDataSetWizardPage.updateParameterDesign method was just an example for
a simple use case. A custom ODA implementation should modify the
implementation based on the capabilities of its own ODA data source.
Linda
"Maged Elaasar" <melaasar@ca.ibm.com> wrote in message
news:focons$he2$1@build.eclipse.org...
> Asking the question in another way: If the parameter metadata is defined
> by BIRT parameter page and not by a custom ODA page, which means the
> parameters are NOT encoded in the query string, how then to implement
> IQuery.getParameterMetaData() which takes the query string only? and
> subsequently where should the ParameterDefinition be created? It makes
> sense to me to be created in BIRT's parameter page's savePage method, but
> in this case how to make it set the position to -1 as it is not allowed in
> that page GUI?
>
|
|
|
| Re: Does BIRT 2.2 support "named" parameters of data sets? [message #360593 is a reply to message #360573] |
Tue, 12 February 2008 03:10 |
Maged Elaasar
Messages: 529
Registered: July 2009 |
Senior Member |
|
|
Thanks very much Linda. I tried things the way you suggested and here are my
observations:
- I think it is not logical or robust to expect a CustomDataSetPage to
handle changing dataset ParameterDefinitions (native name, position, etc.)
when it is not responsible for defining them in my usecase. It really should
be the job of the dataset Parameter Page to allow for that (i.e. expose full
editing of parameter metadata including the position and native name). Also,
when there are more than one CustomDataSetPage in the dataset like in my
case, it is not obvioius which one of them should take care of those
PrameterDefinition changes. Also, you suggest putting these changes in the
collectDataSetDesign method of the page, which is meant to save the info
from that page's own GUI (not from the GUI of other pages like Parameter
page) to the dataset design.
- I still tried you suggestion, by picking one of my custom pages and
letting it have the following code in its collectDataSetDesign method. One
problem I ran into is how to get the name supplied by the user in the
metadata info in the Parameter Page, since this is the one I should be using
as it is the only name the user has specified for that parameter.
Unfortunately that name, as you said, is not set in the ParameterDefinition
and there is no way to get it!! The second problem here is instead of
getting the parameters changed in the Parameter Page as implied by the code,
I keep getting "new" parameters created in the Parameter Page with the new
info (changed name and position). The worst part is, I keep getting more and
more parameters every time I dismiss the wizard and bring it back up and go
to the parameter page. I also tried deleting the parameters from the
ParameterPage, but I noticed that the following code still finds them in the
design.getParameters() (i.e they went out of synch). I think there is big
problems with this piece of functionality in BIRT.
DataSetParameters parameters = design.getParameters();
if (parameters != null) {
for(Object object : parameters.getParameterDefinitions()) {
ParameterDefinition pd = (ParameterDefinition) object;
DataElementAttributes attributes = pd.getAttributes();
attributes.setPosition(0);
attributes.setName("test"); //where do I get the native name from?
}
design.setParameters(null);
design.setParameters(parameters);
}
In light of this, do you still think what I am trying to do is doable (i.e.
I am just missing one piece of the puzzle) or that usecase is not supported?
In which case, what is the proper way I should be supporting named
parameters? For example do I have to create a custom Parameter Page and
discard the birt one (is this even doable) ?
I really appreciate your help with this.
Maged
|
|
| |
| Re: Does BIRT 2.2 support "named" parameters of data sets? [message #360610 is a reply to message #360593] |
Tue, 12 February 2008 21:46 |
Linda Chan
Messages: 845
Registered: July 2009 |
Senior Member |
|
|
Maged,
>> do you still think what I am trying to do is doable (i.e.
> I am just missing one piece of the puzzle) or that usecase is not
> supported? In which case, what is the proper way I should be supporting
> named parameters? For example do I have to create a custom Parameter Page
> and discard the birt one (is this even doable) ?
Umm, like I said, this use case hasn't really been tested. What I
previously suggested was what I had hoped to be a workaround. Apparently,
the matching of the updated ODA ParameterDefinitions with the BIRT parameter
definition has a problem since both the identifiers, i.e. native name and
position, got changed from what BIRT had known.
Your use case is indeed not intended to be a supported one. Normally a
custom ODA designer is expected to provide all its own custom page(s) to
collect whatever design info that are needed and used by its ODA runtime
driver to retrieve data. So for your case, the supported solution is to
provide a custom page that collects user-defined parameter definitions; and
users would use this, instead of the BIRT Parameters page, to enter the
parameter definition. And the custom page should then include those
parameter metadata in the oda.design.DataSetDesign. When BIRT consumes the
oda DataSetDesign, it would then map the ODA parameter definition to the
BIRT-level data set parameters, and will automatically show up in the BIRT
parameters page.
From our architecture perspective, only an ODA provider should be the one to
assign/update the "native" metadata. The name that got assigned in the BIRT
Parameters page should be kept at the BIRT level only. Keep in mind that
the ODA framework is a separate component in DTP, and can be consumed by
other consumer applications. BIRT is straightly an ODA consumer, and is
thus loosely coupled with an ODA provider component.
Note that the BIRT Parameters page provides the UI to map a BIRT data set
parameter to a BIRT report parameter. So you might want to keep that page
for those capabilities. If you really want to hide it, you can specify that
by setting the dataSetUI.supportsInParameters to "false"
in your org.eclipse.datatools.connectivity.oda.design.ui.dataSource
extension in your UI plugin.xml file.
Linda
|
|
|
Goto Forum:
Current Time: Mon May 06 12:41:34 GMT 2024
Powered by FUDForum. Page generated in 0.03913 seconds |
] 
Search
Help
Register
Login
Home
