[RomaFramework-dev] R: Plugin-based development in ROMA?

[Luca G. <luc...@as...>]

Hi Ted,
I'm very glad to listen to proposals about other modules/aspects!

Since last releases of Roma you can inject hook inside the Roma =
controller.
You can register your own
org.romaframework.core.flow.UserObjectEventListener implementation to =
catch
Roma events. To register it:

// REGISTER MYSELF AS EVENT LISTENER FROM OBJECTCONTEXT
Controller.getInstance().registerListener(UserObjectEventListener.class,
myListener);

But what you need it's quite different: to define "virtual" class.
Namely...Class without a ".class" but definited at run-time. Current =
release
doesn't support this feature completely. Roma creates a SchemaClass =
instance
for any Class definition. SchemaClass inherits SchemaClassDefinition.
SchemaClassDefinition is unjoined with .class. So I should change some =
part
of ROMA where uses SchemaClass to use the base abstract
SchemaClassDefinition rather.

SchemaClassDefinition is what you need. You can build instances at =
run-time
and register their in the SchemaManager to be viewed by all Roma modules =
and
aspects.

I need to refactor a little bit classes to support full "virtual" class
definition. It seems to me an important feature to release before 1.0!

Do I have understand correctly your needs?

bye,
Luca Garulli
Blogging on: http://zion-city.blogspot.com
http://www.AssetData.it
http://www.RomaFramework.org - The new way to build applications
http://www.OrienTechnologies.com - Light ODBMS, All in one JDO solution

-----Messaggio originale-----
Da: rom...@li...
[mailto:rom...@li...] Per =
conto
di ted stockwell
Inviato: marted=EC 12 settembre 2006 14.17
A: Rom...@li...
Oggetto: [RomaFramework-dev] Plugin-based development in ROMA?

Hi All,

I have been working on my own ROMA/Naked Objects/EMF - like =
metadata-based
framework for a while.  I looked at ROMA a while back and didn't get it.
But ROMA has come a long way since then and I want to evaluate it again =
to
see if it meets my own requirements.
So far I like a lot of what I see in ROMA, especially like the way that =
ROMA
binds aspects to annotations and ROMA's concept of modules.

Anyway, the one requirement that I have, that I am not sure that ROMA =
can
handle, is that I want to develop a plugin-based product.  I actually =
want
to build an Eclipse RCP application (I am willing to build an RCP view
module for ROMA, that's not a problem).
However, I want my application to be extendable by third party plugins =
in
the way that the Eclipse IDE is extendable by plugins.  For instance, it
should be possible for a third party plugin to dynamically extend the =
menu
system of my ROMA-based application when the plugin is loaded into the
application.

Let me make the question more specific and refer you to the wiki article =
on
how to create a menu in ROMA, at
http://romaframework.xwiki.com/xwiki/bin/view/Doc/Create+menus.
It is not clear to me if it would be possible to develop a menu in ROMA =
that
could be extended by a dynamically loaded plugin from a third party.
The ROMA documentation states that ROMA creates a menu from a POJO, and =
by
default the pojo's fields and actions are treated as menu items.

Question....  Would it be possible to extend this example to dynamically
create a menu from an flat text file with menu labels.
That is, given a flat text file with the following three lines in it...
        menu1
        menu2
        menu3
...could I dynamically create a menu in ROMA with the three menu items;
menu1, menu2, & menu3?

If that can be done in ROMA then I know that I could hook ROMA up to the
Eclipse plugin-based extension mechanism.


Best Regards, and Congratulations on your recent release.  You've done a =

lot of good work on ROMA!
Ted Stockwell

PS:  I suspect that the answer to my question might involve the xml=20
descriptors (maybe I could generate a descriptor dynamically at run =
time?)=20
But I haven't been able to understand the exact relationship between=20
descriptors, pojos and annotations yet.
The ROMA docs could use just a snippet of documentation regarding=20
descriptors.