|
|
| Re: Some thoughts [message #25 is a reply to message #23] |
Fri, 03 September 2004 14:48   |
 Scott Rosenbaum
Messages: 425
Registered: July 2009 |
Senior Member |
|
|
Just a thought on limiting a user to design of only one table and then
limiting access to the records within that table.
I recognize where this requirement is coming from, but it seems like a more
extendable solution is to use some form of data abstraction between the
physical tables and the report design tool. Chris, would your requirements
be met if a developer created some type of Data Adapter, that would embed
all of the rules for data access and data filtering. To the user, the Data
Adapter would look just like a table.
Also, in terms of storing the report templates, if the report template is
XML, is their any reason that you could not store the XML in the database?
Scott
"Chris" <schtoo@schtoo.com> wrote in message
news:ch7nl6$m6o$1@eclipse.org...
> Hi,
>
> I'm very interested in the BIRT project. I have two things I'm thinking
> about. First, the proposal seems to be geared heavily towards J2EE. I
want
> to make sure there will still be some focus on regular ole J2SE (just
> regular client apps).
>
> Also, I'm very interested in reusing/extending the BIRT report designer
> within our applications. At my company, every application has (or needs)
> some type of custom, end-user driven reporting feature. That is, the
> ability for end-users to create their own reports. It would be great if
the
> BIRT designer could be delivered as part of our RCP applications. We
would
> need to alter/extend and primaly pare down functonality in the designer.
> The kinds of things we would need:
>
> - Ability to define and limit available datasources for a report. Most of
> our customers don't know SQL. And most of the time our reports only go
> against one main table. Our applications are mainly financial
applications
> and the reports typically show/sum/etc.. financial transactions. We would
> want to limit the datasource for the reports to be just this table. And
> we'd like to further alter and limit what is shown. Basically we would
need
> full control to what the datasource would be.
>
> - Ability to save the report templates in a database. We have 10's or
100's
> of users and if one user creates a report template, all users should be
able
> to generate that report. So we'd need to be able to extend the
persistence
> model of these templates.
>
> There's certainly more but thats I can think of at the moment.
>
> -Chris
>
> ps. Is there any idea of the timeline for this project?
>
>
|
|
|
| Re: Some thoughts [message #26 is a reply to message #25] |
Fri, 03 September 2004 15:13 |
Chris Gross
Messages: 471
Registered: July 2009 |
Senior Member |
|
|
Yes I think your Data Adapter idea would work. I'm not assuming that
something would be done to exactly match my needs, but I'm looking for an
understand that we (and others possibly) would need to limit or override the
data access stuff. So, yes, just some way in which we can plug-in and
override/extend how that works.
Regarding storing the templates, yeah I would assume we would store the XML
in the database, but I'm worried that the designer by default would just
create a file and I'd have to have some other process that would then read
that file and send it to the database. Instead I would like someway to hook
into the persistence model and redirect the loading and saving to the
database directly. This is all assuming we would deploy the report designer
as part of our RCP application.
-Chris
"Scott Rosenbaum" <scottr@innoventsolutions.com> wrote in message
news:cha010$6nk$1@eclipse.org...
> Just a thought on limiting a user to design of only one table and then
> limiting access to the records within that table.
>
> I recognize where this requirement is coming from, but it seems like a
more
> extendable solution is to use some form of data abstraction between the
> physical tables and the report design tool. Chris, would your
requirements
> be met if a developer created some type of Data Adapter, that would embed
> all of the rules for data access and data filtering. To the user, the
Data
> Adapter would look just like a table.
>
> Also, in terms of storing the report templates, if the report template is
> XML, is their any reason that you could not store the XML in the database?
>
> Scott
>
> "Chris" <schtoo@schtoo.com> wrote in message
> news:ch7nl6$m6o$1@eclipse.org...
> > Hi,
> >
> > I'm very interested in the BIRT project. I have two things I'm thinking
> > about. First, the proposal seems to be geared heavily towards J2EE. I
> want
> > to make sure there will still be some focus on regular ole J2SE (just
> > regular client apps).
> >
> > Also, I'm very interested in reusing/extending the BIRT report designer
> > within our applications. At my company, every application has (or
needs)
> > some type of custom, end-user driven reporting feature. That is, the
> > ability for end-users to create their own reports. It would be great if
> the
> > BIRT designer could be delivered as part of our RCP applications. We
> would
> > need to alter/extend and primaly pare down functonality in the designer.
> > The kinds of things we would need:
> >
> > - Ability to define and limit available datasources for a report. Most
of
> > our customers don't know SQL. And most of the time our reports only go
> > against one main table. Our applications are mainly financial
> applications
> > and the reports typically show/sum/etc.. financial transactions. We
would
> > want to limit the datasource for the reports to be just this table. And
> > we'd like to further alter and limit what is shown. Basically we would
> need
> > full control to what the datasource would be.
> >
> > - Ability to save the report templates in a database. We have 10's or
> 100's
> > of users and if one user creates a report template, all users should be
> able
> > to generate that report. So we'd need to be able to extend the
> persistence
> > model of these templates.
> >
> > There's certainly more but thats I can think of at the moment.
> >
> > -Chris
> >
> > ps. Is there any idea of the timeline for this project?
> >
> >
>
>
|
|
|
|
Powered by
FUDForum. Page generated in 0.03656 seconds
] 
Search
Help
Register
Login
Home
