Leon,
in my opinion, even if the widgets have not been designed to be used as
a reporting tool, they are an excellent tool for simple reports.
About BI: I do agree with you that we should not even try to achieve
these using the widgets, in fact, in my opinion the highly normalized
OFBiz data model is also not well suited for this kind of data
analysis... sooner or later we should consider to implement (or
integrate) a data warehousing tool to export data (in an external
denormalized system) and then create reports (complex ones such as cubes
etc...) on it.
However I don't think that the applicability of OFBIZ-364 is limited to
the reports...
Jacopo
David E Jones wrote:
Leon,
That's interesting. I wasn't thinking of reporting at all for this
discussion and my comments on it, just a more custom screen/form.
-David
On Oct 18, 2006, at 6:49 PM, Leon Torres wrote:
Hi David et al,
For what it's worth, I've been developing some pretty sophisticated
reports and stretching the view entity and form widget system to their
limits, sometimes breaking them and having to create improvements such
as this issue and the complex-alias one. :-)
It's been a lot of fun so far but I fear it's getting me nowhere. I
just realized even with all the recent improvements to reporting
capability, there is simply no way we can adequately address the needs
of Business Intelligence reporting with just the entity and form system.
We can certainly continue making incremental improvements until we get
something useful for reporting, but I think it will end up being a
poor approximation to a full featured BI tool.
Until we find a good way to plug a BI framework into OFBiz, it might
be better if we have some stopgap system such as the ability to write
SQL queries that get transformed into EntityEngine calls, otherwise we
are trying to shove a square peg (the entity + form system) into a
round hole (BI reporting).
Just my 2 cents.
- Leon
David E Jones wrote:
On Oct 18, 2006, at 7:30 AM, Jacopo Cappellato (JIRA) wrote:
[
http://issues.apache.org/jira/browse/OFBIZ-364?page=comments#action_12443180
]
Jacopo Cappellato commented on OFBIZ-364:
-----------------------------------------
Leon Wrote:
It's working without issues for me, although I don't know if
putting a magical parameter in the context
is the right way to invoke this ability. Maybe a form widget
attribute would be better?
This is a good question... and I'd love to get a comment from David
Jones about it since I'm not totally sure about the best way of
doing this.
That is a good point. An attribute on the form definition element
would be better, and can be a constant or parameterized as needed
(even if it would almost always be parameterized...). Something like
the current name would be great, though we can probably leave out the
"Form" since that is redundant, so we'd just have "override-list-size".
Of course, if the intent is just to get a partial list from the
database and display it with the form widget there are ways of doing
that without all of this manual stuff... I haven't looked at this
specific scenario enough to know if all the manual stuff is really
required, but in general it's nice to keep the code as simple as
possible and let it take care of the pagination and getting partial
results from the database using the built in stuff.
Whatever the case is, this additional flexibility of being able to
put the list together manually does sound like a nice feature (I
guess I just haven't run into a need for it yet).
-David
