Semantics of external keyword

20 views
Skip to first unread message

Paulo Abrantes

unread,
Mar 1, 2010, 9:42:17 AM3/1/10
to Fénix Framework
Hello,

This is a message that concerns everyone that is using the keyword
external in their DML files.

Even thought the DML introduced the keyword external a long time ago,
we've only started using
it a couple of months ago, and after having to deal with some problems
I think the current semantics
aren't what we really want.

Currently the external keyword defines an external entity in the
domain model that has to handle all
it's persistent and transactional behaviors by itself, the jvstm
doesn't do anything at all to those entities.

During my work regarding fenix framework plugins, I found the need to
reference in a domain
model file from one plugin entities that are defined in other plugin
and for that I used the external
keyword.
The problem here is that at run time both DML files would be passed to
the framework bootstrap and
we'll get an error for a double definition of a given entity (as a
domain entity and as an external entity
because of external keyword).

After discussing this issue with João Cachopo we agreed that we had
the wrong semantics for
the external keyword, since we were only using the correct semantics
for it in one case (regarding
the AbstractDomainObject in the fenix framework DML file) and that we
could simply make the
framework know this "special" object. All the other cases of external
keyword should behave
with a semantic similar to "import".

Right now I have a local version of fenix framework which implements
that semantic for external
keyword.
This means:

* It allows multiple DMLs to define the same external entity
* In during the bootstrap some of the external entities are not
defined as domain entities by other DML files an
exception will be thrown and the DomainModel won't be created.

After saying all this I have two questions for the ones who are using
the external keyword:

1. How are you using the external keyword?
2. Will these changes break your code?

Thank you,

Paulo Abrantes

Régis Jean-Gilles

unread,
Mar 1, 2010, 11:08:18 AM3/1/10
to Fénix Framework
I encountered the same problem : I initially expected the "external"
keyword to function much like "extern" in C/C++.
In other words, I thought I could define an external entity, and later
on define it. As you point out, this doesn't work like that.
So we ended up writing all the "external" declarations in a separate
DML file, and take care NOT to include it at runtime (instead, we
provide the DMLs defining the actual class definitions).
This is not as cumbersome as it might seem in our specific case,
because we actually aren't writing raw DMLs anymore : we have a thin
layer on top of that, from which DMLs are generated. So it's all
automatic.
However in the general case the current semantics of "external" are
indeed quite a limitation.
Your new version will be welcome.

I guess this answers point (1).
As for point (2): this shouldn't break our code.

Paulo Abrantes

unread,
Mar 1, 2010, 1:05:00 PM3/1/10
to Fénix Framework
Hello Régis,

Thank you for your quick feedback.

On Mar 1, 4:08 pm, Régis Jean-Gilles <regis...@gmail.com> wrote:

....

> So we ended up writing all the "external"  declarations in a separate
> DML file, and take care NOT to include it at runtime (instead, we
> provide the DMLs defining the actual class definitions).

It's the same fix I was doing before implementing the modification :-)

> This is not as cumbersome as it might seem in our specific case,
> because we actually aren't writing raw DMLs anymore : we have a thin
> layer on top of that, from which DMLs are generated. So it's all
> automatic.

If I may ask, what kind of thin layer? Graphical one? Just curious.

> However in the general case the current semantics of "external" are
> indeed quite a limitation.
> Your new version will be welcome.
> I guess this answers point (1).
> As for point (2): this shouldn't break our code.

Ok, great!
After this new version, there is no longer the need to NOT include the
external
entities DML file, although there won't be any problem either if you
keep leaving
it out.

Paulo

Régis Jean-Gilles

unread,
Mar 2, 2010, 4:47:21 AM3/2/10
to Fénix Framework
> If I may ask, what kind of thin layer? Graphical one? Just curious.

We are actually parsing input DMLs and generating target DMLs (and
supporting code) from them.
This is bascially just a preprocessor tailored to our very specific
needs.

Paulo Abrantes

unread,
Mar 2, 2010, 10:01:01 AM3/2/10
to Fénix Framework

Got it, it's the way your extending the DML.

I've already committed the modification we've been speaking, so since
revision 46346 the external keyword expresses the new behavior.

João Pereira

unread,
Mar 15, 2010, 7:29:36 PM3/15/10
to fenix-f...@googlegroups.com
In the scope of my master thesis project, I did the same workaround as
Régis when working with external entities within the fenix-framework.

The new changes will also not break my code, however the new plugin
architecture is highly desirable :)

João Pereira

> --
> You received this message because you are subscribed to the Google Groups "Fénix Framework" group.
> To post to this group, send email to fenix-f...@googlegroups.com.
> To unsubscribe from this group, send email to fenix-framewo...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/fenix-framework?hl=en.
>
>

Reply all
Reply to author
Forward
0 new messages