|
| Re: Interactive Viewer in 2.0 [message #66156 is a reply to message #65863] |
Tue, 09 August 2005 11:44  |
Eclipse User |
|
|
|
This rocks! I'm so pleased that you are taking a path towards interactive
html reports. It really is an impressive list of enhancements. I hope you
can pull it off.
What would be the timeline for delivering this?
If it was up to me, i was focus on the HTML implementation of the viewer.
Then you can save the extra effort of building a fatclient renderer (SWT,
Swing, ...). The HTML viewer could still be embedded in a fat app using a
SWT browser wrapper or the JDIC browser component (maybe also requiring a
lightweight embedded http server).
https://jdic.dev.java.net/#demos
Having a single viewer would also remove the inconsistencies that you will
inevitably have between the multiple implementations (which is already a big
enough battle having to fight with multiple browser versions).
And the HTML viewer can also be deployed as a standard webapp, viewed by a
standard browser - which for many will be only way reports will be deployed.
Use AJAX and skip the fat client component. I think the time saved would be
much better served realizing the new report functions you propose.
For me it would be important that this could be integrated into an existing
web app, where the report may occupy a piece of real-estate on a page (eg.
located in the content area of a page that contains an application header,
navbar, footer, portlets, ...).
I would guess that enabling this kind of integration would be challenging,
especially if the report is interactive (having to isolate the AJAX, DOM
rewriting, etc. to a region of a single page).
Making the integration as flexible as possible is very important. For
example, a widget to navigate/search pages, needs to be easily customized,
overridden, styled. How parameters requested and passed to the report needs
to be open. It may be nice to provide defaults out of the box, but i may
want to create my own input widgets, or use the app context, to get the
parameter values, rather than use the viewer's parameter input widgets.
To help me correctly customize my input widgets i would like to have the
possibility to associate additional design-time metadata to a parameter.
eg. I may have a parameter that is a date type, but the date must be
constrained to the last invoiced month for a customer. I would like to add
metadata to this parameter such as; <input><month
last-valid="11-2004"/></input>. My webapp runtime can then interpret this
metadata to show/validate the correct input form.
** Please make the component model framework agnostic! I have my own webapp
framework and i can not be forced to use Struts, JSF, OpenLaszlo, or any
other framework. If you wish to provide wrappers to make the viewer easier
to integrate into popular frameworks, then that would be great, but please
make the core integration API only require the Servlet API.
Another item on my wishlist is enhancing the PDF rendering to support more
styling (maybe using something other than FOP?).
In general i would also like the possibility to have a particular renderer
(in this case PDF) to use a different sheet/properties, than for an HTML
rendering.
eg. in HTML i may want have a table column widths unspecified (allowing the
browsers to use a preferred width), but for PDF i may want to have an
exactly specified column width (so looks correct when printed).
I think you have already announce you intention to do this, but i would like
to say that shared/library style sheets is needed.
To simplify style sheets it would be nice to support setting multiple styles
for a single element as HTML/css allows.
http://www.pixelsurge.com/experiment/multiplestyles.htm
Support for Excel export would be a huge bonus, but i think the CVS "Data
Extraction" should hopefully cover this need.
Thank you!!!
"Jun Zhai" <jzhai@actuate.com> wrote in message
news:a92c09bf81318a0069760f9eb06a2883$1@www.eclipse.org...
> A draft interactive viewer feature spec is available at:
>
>
http://www.eclipse.org/birt/release20specs/BPS5%20-%20Intera ctive%20Viewer.pdf.
>
> We are looking forward to your inputs.
>
> Thanks.
>
> Jun Zhai
>
|
|
|
Powered by
FUDForum. Page generated in 0.02959 seconds
Home