Home » Eclipse Projects » DTP » Custom ODA data source, want different behavior during preview vs. actual usage?
| Custom ODA data source, want different behavior during preview vs. actual usage? [message #33130] |
Fri, 20 July 2007 23:08  |
Eclipse User |
|
|
|
Originally posted by: allevato.vt.edu
I posted this message in the BIRT newsgroup, but perhaps it's more
appropriate here, so I'm hoping to increase my chances of getting a
response.
Summary:
Need a custom ODA plug-in to act differently in the BIRT designer than
it does when integrated on the server. Also need a way to pass
server-specific information to the plug-in when it's integrated, some
time shortly after the server initializes the BIRT platform.
Longer version:
I'm writing an ODA data source plug-in to encapsulate a custom data
source on our server -- it's a WebObjects application, so in a
nutshell, we'll pass in an array of objects (the rows) to BIRT, and the
columns that the user defines will be keypaths to access values from
these objects.
The catch is that to support previewing in the BIRT designer, the way
the objects are accessed must be vastly different than it is when
running under BIRT integrated on the server. The integrated instance
can just access the objects directly by making WebObjects fetch calls,
but from the designer, we'll likely just implement a simple HTTP
request handler on the server that sends back sample records for
previewing purposes. Furthermore, the plug-in when used at design-time
would require properties that aren't needed on the server, like the URL
to the server that should be used for previewing, as well as a
username/password for authentication. So I need some way of specifying
"design-time only" data source parameters that aren't saved in the
report template, which will eventually be uploaded to the server.
What is the best way to handle this? Should we maintain two different
plug-ins with the same IDs -- one to distribute for designing purposes
and one to run on the server? Or is there a way to get the same
plug-in to change its behavior depending on whether it's in design mode
or on the server?
And regardless of which approach I use, I'll need to be able to pass
information into the ODA plug-in from the server once the BIRT platform
is initialized -- such as which editing context to use to pull objects
from at report generation time. Is this as easy as adding the plug-in
JAR to the build path of the server and then calling
MyODAPlugin.getDefault() and other such methods once the platform is
initialized? Or are there other issues that arise from trying to
communicate from the server to the plug-in? Ideally, I think I would
like to do the following:
* Custom ODA plug-in contains a proxy interface that it calls to get
objects/data from the server
* A class on the server implements this interface and passes a
reference to this object into the ODA plug-in
* The plug-in calls these methods in the implementations of
IConnection, IQuery, IResultSet, etc., so that all access back to the
server occurs through this proxy and the ODA plug-in itself does not
need any WebObjects library dependencies
If I use this approach, then I could also implement an alternate
version of the interface for design-time, which would use the HTTP
method instead of the direct access method to obtain the data, as long
as I can detect whether I'm being used in the designer or on the
server. Is this likely to work?
Thanks!
- Tony Allevato
|
|
|
| Re: Custom ODA data source, want different behavior during preview vs. actual usage? [message #33736 is a reply to message #33130] |
Fri, 27 July 2007 22:02  |
Linda Chan
Messages: 845
Registered: July 2009 |
Senior Member |
|
|
You should be able to use the same ODA plugin to handle the difference in
behavior.
Your WebObjects application would fetch the data objects and pass them to
your ODA driver in an application context object via the BIRT Engine API.
The BIRT Engine would in turn pass such user-defined application context
object thru to your ODA driver via the setAppContext method (in the oda
IDriver, IConnection and IQuery interfaces).
Your ODA implementation can then adjust its behavior based on the
availability or content of the application context object.
See the spec on the "Pass-through of External Context Objects to ODA Data
Providers". It was on the BIRT BPS site, but I couldn't find the link
right now. I'm attaching a copy of the spec in this post.
Linda
"Tony Allevato" <allevato@vt.edu> wrote in message
news:f7rf9c$9lq$1@build.eclipse.org...
>I posted this message in the BIRT newsgroup, but perhaps it's more
> appropriate here, so I'm hoping to increase my chances of getting a
> response.
>
> Summary:
> Need a custom ODA plug-in to act differently in the BIRT designer than
> it does when integrated on the server. Also need a way to pass
> server-specific information to the plug-in when it's integrated, some
> time shortly after the server initializes the BIRT platform.
>
> Longer version:
> I'm writing an ODA data source plug-in to encapsulate a custom data
> source on our server -- it's a WebObjects application, so in a
> nutshell, we'll pass in an array of objects (the rows) to BIRT, and the
> columns that the user defines will be keypaths to access values from
> these objects.
>
> The catch is that to support previewing in the BIRT designer, the way
> the objects are accessed must be vastly different than it is when
> running under BIRT integrated on the server. The integrated instance
> can just access the objects directly by making WebObjects fetch calls,
> but from the designer, we'll likely just implement a simple HTTP
> request handler on the server that sends back sample records for
> previewing purposes. Furthermore, the plug-in when used at design-time
> would require properties that aren't needed on the server, like the URL
> to the server that should be used for previewing, as well as a
> username/password for authentication. So I need some way of specifying
> "design-time only" data source parameters that aren't saved in the
> report template, which will eventually be uploaded to the server.
>
> What is the best way to handle this? Should we maintain two different
> plug-ins with the same IDs -- one to distribute for designing purposes
> and one to run on the server? Or is there a way to get the same
> plug-in to change its behavior depending on whether it's in design mode
> or on the server?
>
> And regardless of which approach I use, I'll need to be able to pass
> information into the ODA plug-in from the server once the BIRT platform
> is initialized -- such as which editing context to use to pull objects
> from at report generation time. Is this as easy as adding the plug-in
> JAR to the build path of the server and then calling
> MyODAPlugin.getDefault() and other such methods once the platform is
> initialized? Or are there other issues that arise from trying to
> communicate from the server to the plug-in? Ideally, I think I would
> like to do the following:
>
> * Custom ODA plug-in contains a proxy interface that it calls to get
> objects/data from the server
> * A class on the server implements this interface and passes a
> reference to this object into the ODA plug-in
> * The plug-in calls these methods in the implementations of
> IConnection, IQuery, IResultSet, etc., so that all access back to the
> server occurs through this proxy and the ODA plug-in itself does not
> need any WebObjects library dependencies
>
> If I use this approach, then I could also implement an alternate
> version of the interface for design-time, which would use the HTTP
> method instead of the direct access method to obtain the data, as long
> as I can detect whether I'm being used in the designer or on the
> server. Is this likely to work?
>
> Thanks!
>
> - Tony Allevato
>
>
|
|
| |
| Re: Custom ODA data source, want different behavior during preview vs. actual usage? [message #586929 is a reply to message #33130] |
Fri, 27 July 2007 22:02 |
Linda Chan
Messages: 845
Registered: July 2009 |
Senior Member |
|
|
You should be able to use the same ODA plugin to handle the difference in
behavior.
Your WebObjects application would fetch the data objects and pass them to
your ODA driver in an application context object via the BIRT Engine API.
The BIRT Engine would in turn pass such user-defined application context
object thru to your ODA driver via the setAppContext method (in the oda
IDriver, IConnection and IQuery interfaces).
Your ODA implementation can then adjust its behavior based on the
availability or content of the application context object.
See the spec on the "Pass-through of External Context Objects to ODA Data
Providers". It was on the BIRT BPS site, but I couldn't find the link
right now. I'm attaching a copy of the spec in this post.
Linda
"Tony Allevato" <allevato@vt.edu> wrote in message
news:f7rf9c$9lq$1@build.eclipse.org...
>I posted this message in the BIRT newsgroup, but perhaps it's more
> appropriate here, so I'm hoping to increase my chances of getting a
> response.
>
> Summary:
> Need a custom ODA plug-in to act differently in the BIRT designer than
> it does when integrated on the server. Also need a way to pass
> server-specific information to the plug-in when it's integrated, some
> time shortly after the server initializes the BIRT platform.
>
> Longer version:
> I'm writing an ODA data source plug-in to encapsulate a custom data
> source on our server -- it's a WebObjects application, so in a
> nutshell, we'll pass in an array of objects (the rows) to BIRT, and the
> columns that the user defines will be keypaths to access values from
> these objects.
>
> The catch is that to support previewing in the BIRT designer, the way
> the objects are accessed must be vastly different than it is when
> running under BIRT integrated on the server. The integrated instance
> can just access the objects directly by making WebObjects fetch calls,
> but from the designer, we'll likely just implement a simple HTTP
> request handler on the server that sends back sample records for
> previewing purposes. Furthermore, the plug-in when used at design-time
> would require properties that aren't needed on the server, like the URL
> to the server that should be used for previewing, as well as a
> username/password for authentication. So I need some way of specifying
> "design-time only" data source parameters that aren't saved in the
> report template, which will eventually be uploaded to the server.
>
> What is the best way to handle this? Should we maintain two different
> plug-ins with the same IDs -- one to distribute for designing purposes
> and one to run on the server? Or is there a way to get the same
> plug-in to change its behavior depending on whether it's in design mode
> or on the server?
>
> And regardless of which approach I use, I'll need to be able to pass
> information into the ODA plug-in from the server once the BIRT platform
> is initialized -- such as which editing context to use to pull objects
> from at report generation time. Is this as easy as adding the plug-in
> JAR to the build path of the server and then calling
> MyODAPlugin.getDefault() and other such methods once the platform is
> initialized? Or are there other issues that arise from trying to
> communicate from the server to the plug-in? Ideally, I think I would
> like to do the following:
>
> * Custom ODA plug-in contains a proxy interface that it calls to get
> objects/data from the server
> * A class on the server implements this interface and passes a
> reference to this object into the ODA plug-in
> * The plug-in calls these methods in the implementations of
> IConnection, IQuery, IResultSet, etc., so that all access back to the
> server occurs through this proxy and the ODA plug-in itself does not
> need any WebObjects library dependencies
>
> If I use this approach, then I could also implement an alternate
> version of the interface for design-time, which would use the HTTP
> method instead of the direct access method to obtain the data, as long
> as I can detect whether I'm being used in the designer or on the
> server. Is this likely to work?
>
> Thanks!
>
> - Tony Allevato
>
>
|
|
| |
Goto Forum:
Current Time: Wed Apr 24 19:25:21 GMT 2024
Powered by FUDForum. Page generated in 1.13712 seconds |
] 
Search
Help
Register
Login
Home
