| EMF and things [message #12] |
Thu, 26 August 2004 10:39  |
 Micheal Norman
Messages: 2
Registered: July 2009 |
Junior Member |
|
|
The subtext here is we'd like to use this stuff in Hyades (now known as
TPTP). This isn't official TPTP feedback we haven't had time to formulate
it, but I thought I'd put something out on the newsgroup before the
various councils next week.
One thing I'd like to see represented in this project is a relationship
with EMF, which is Eclipse's existing way of dealing with the object/data
interface. The way I see this working is that the intermediate format
between the charting and reporting layers is EMF. THis means that any
tool that operates with EMF models can leverage the charting widgets, and
we get interop between BI and other tools (and avoid other tools using
divergent widgetry). It also makes sense for you to allow some of the
charting widgetry to update the models, we already need this in Hyades.
Varieties of widgetry make sense here including SVG-based stuff.
Then there's the question of the XML format for the reporting template.
The UML base of EMF is probably preferable because it caries more
semantics so let's imagine we define this template in EMF, which instantly
has the advantage that the charting widgetry is re-used in the reporting
template editors.
So, what do we mean here by reporting template. Conceptually it seems
remarkably close to the test model we use in Hyades. There are structural
elements defining the when and where, and behavioural elements defining
the actual process. In Hyades we have publilshed a behavioural model in
EMF which maps onto UML and so in principle a generic UML code generator
can suffice as an execution engine. In the absence of such a beast (and
the fact we need to tidy up our external interface definitions) we have
some restritions on the behaviour & interfaces which allow us to provide
specific execution engines and, crucially we provide a "cat flap" which
allows you to branch out to your favourite proprietary (or even open
source) behavioural model. Then we provide an interface whereby the
associated propritary engine can be invoked. What this means is that
third-party tools can be invoked in a standard way inside the framework
and, assuming they write to the EMF models (typically through an adaptor),
the UI widgetry will work with them. This will allow more flexible
adoption by players with existing tool investment.
In terms of what all of this does to your project. It broadens the scope
of useage models significantly - it becomes the data visualization
project. It means your project structure needs reshaping (I can't quite
work it out but I think you have an engine project and a UI project) and
you fold in GEF into the UI project.
Preparing for flames...
Mike Norman
Hyades test project lead
|
|
|
| Re: EMF and things [message #21 is a reply to message #12] |
Tue, 31 August 2004 18:07  |
Wenfeng Li
Messages: 25
Registered: July 2009 |
Junior Member |
|
|
Mike,
It will be great if TPTP can use BIRT components for its reporting and
charting needs.
Yes, we are considering EMF as the modeling framework for the charting
project.
As for the reporting template, I suspect we will start with defining XML
schema for report designs. We would like to make the XML file format concise
and easy to read by the people who write reports and design tools that write
reports. An XMI based design file format probably is too verbose for a human
being to read. I think we can look into using EMF to generate the Java
classes.
We will study the proposed behavioral model in Hyades to see if we can use
it for report generation.
Regards,
Wenfeng
Actuate Corporation,
Email: wli@actuate.com
"Mike Norman" <mgn@scapatech.com> wrote in message
news:cgkel1$46l$1@eclipse.org...
> The subtext here is we'd like to use this stuff in Hyades (now known as
> TPTP). This isn't official TPTP feedback we haven't had time to formulate
> it, but I thought I'd put something out on the newsgroup before the
> various councils next week.
>
> One thing I'd like to see represented in this project is a relationship
> with EMF, which is Eclipse's existing way of dealing with the object/data
> interface. The way I see this working is that the intermediate format
> between the charting and reporting layers is EMF. THis means that any
> tool that operates with EMF models can leverage the charting widgets, and
> we get interop between BI and other tools (and avoid other tools using
> divergent widgetry). It also makes sense for you to allow some of the
> charting widgetry to update the models, we already need this in Hyades.
> Varieties of widgetry make sense here including SVG-based stuff.
>
> Then there's the question of the XML format for the reporting template.
> The UML base of EMF is probably preferable because it caries more
> semantics so let's imagine we define this template in EMF, which instantly
> has the advantage that the charting widgetry is re-used in the reporting
> template editors.
>
> So, what do we mean here by reporting template. Conceptually it seems
> remarkably close to the test model we use in Hyades. There are structural
> elements defining the when and where, and behavioural elements defining
> the actual process. In Hyades we have publilshed a behavioural model in
> EMF which maps onto UML and so in principle a generic UML code generator
> can suffice as an execution engine. In the absence of such a beast (and
> the fact we need to tidy up our external interface definitions) we have
> some restritions on the behaviour & interfaces which allow us to provide
> specific execution engines and, crucially we provide a "cat flap" which
> allows you to branch out to your favourite proprietary (or even open
> source) behavioural model. Then we provide an interface whereby the
> associated propritary engine can be invoked. What this means is that
> third-party tools can be invoked in a standard way inside the framework
> and, assuming they write to the EMF models (typically through an adaptor),
> the UI widgetry will work with them. This will allow more flexible
> adoption by players with existing tool investment.
>
> In terms of what all of this does to your project. It broadens the scope
> of useage models significantly - it becomes the data visualization
> project. It means your project structure needs reshaping (I can't quite
> work it out but I think you have an engine project and a UI project) and
> you fold in GEF into the UI project.
>
> Preparing for flames...
>
> Mike Norman
> Hyades test project lead
>
|
|
|
| Re: EMF and things [message #49 is a reply to message #12] |
Wed, 22 September 2004 00:40 |
Eclipse User |
|
|
|
Originally posted by: red1.red1.org
"Mike Norman" <mgn@scapatech.com> wrote in message
news:cgkel1$46l$1@eclipse.org...
>
> Preparing for flames...
>
> Mike Norman
> Hyades test project lead
>
Nay, on the contrary, it has been very layman-friendly (from my
false-learned perspective). Reusability and plugin-peer-awareness is in
conformity with Eclipse value proposition and vast EcoSystem.
Way to go, (just that your affinity to flames and hat place,...where u say u
hail from?)
:)
redhuan d. oon
tutorial writer
Compiere-MFGSCM
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.05684 seconds
] 
Search
Help
Register
Login
Home
