Yes currently Texo is more for the server side of web applications.
This makes it also useful in other server-oriented scenarios.
gr. Martin
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Cell: +31 (0)6 288 48 943
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@xxxxxxxxxxxxxx - mtaal@xxxxxxxxx
Web: www.springsite.com - www.elver.org
On Jul 5, 2010, at 6:49 AM, Kenn Hussey wrote:
Note that the EMFT Texo project may be of
some use/interest here, as it provides support for automatically
mapping between POJO and EMF implementations of a given domain model...
Wow, I wouldn't have even thought to look there because it is
"advertised" for Web Applications. I just started looking at MoDisco as
well and while that is advertised for legacy development there are a
number of tools that would be useful in all kinds of contexts. These
really useful bits of technology keep cropping up all over.
Imagine I'm designing a model for an inventory system
interfacing with CAD/CAM. I could define a BOM with an item that
specifies a material that needs specific dimensions. Depending on how
UOMo is designed I could a) define an attribute "dimensions" of type
say VolumeCubicMeters or b) much better of type Volume and allow
implementors to create an entry in any kind of measurement they wanted.
Regardless of how I chose to represent or edit the values I would be
confident that they could be safely and consistently translated into
any measurement context. Which is again really a tremendously useful
and reassuring thing to have *especially* if it can be done in a
relatively light-weight way.
I noted a mistake I made above and it turns out that this is a
perfect example of just how useful this approach could be and how the
representational issues are deeper than they first seem. The attribute
name is dimension, but the Measure is volume. Note that for some
applications (medical dosing, say) the distinction isn't important, but
in others (manufacturing) it obviously would be. Just as you can map /
cast an integer to a BigNum safely, but not the other way around, you
can make a dimension into a volume, but not do the inverse safely.
Having a taxonomy of specificity could be really useful for this sort
of thing. Or imagine I had a shipping application -- if I used
DimensionCubicMeters I would be able to get linear feet. Or..let's say
I have a bin packing problem, I might even be able to create a model
for an object where I could have a DimensionalyConstrainedVolume for a
composite of multiple packed objects that would be configurable in
different ways -- and these constraints need not follow a rigid
formula. You could call this the Ikea packing problem.. :) Or imagine
that measures might work together so that for example if I have a
climate model I might want to represent the notional volume of a
specified air mass but that would be dependent on a temperature and/or
heat measure...
_______________________________________________
emft-dev mailing list
emft-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/emft-dev