Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [modeling-pmc] Re: [emft-dev] Proposal for Texo Component

Hi Yves,
As I see it there are two ways of handling the ui-question (not necessarily contradictionary): 1- enrich the domain model with ui-annotations and create specific templates for specific views (like list views etc.) which use the ui-annotations. By choosing a specific template (==workflow) the user can choose what type of view to create. 2- specify the ui you want to generate, in a separate document (based on a ui-model). In this case the user specifies how his/her view by for example creating an instance of a list-view as defined in the ui-model. Based on the defined view the user can then generate an implementation (e.g. jsf page) using a specific template (==workflow).

The 1. approach is fairly light-weight but has its limitations because it offers less control when generating views/artifacts. The second approach allows more control but is more heavy as it means that a user needs to specify the ui in a model, e.g. create an instance of a list-view, select the columns etc. Afaics both approaches have their value. The Texo proposal starts with 1 and then when the pmf has achieved results and is ready to be used will integrate to additionaly support scenario 2. In this way users of Texo can choose which approach has the best value for them. The approach which has the most users will be the one which is maintained/developed best..

As far as I can see there is not so much double work. By far most work will be in creating and maintaining templates and the templates for case 1 and 2 are very similar.

So this is why I think that the two projects can start separately, for scenario 1 there is no direct relation to or dependency on pmf.

I hope I have clarified things a bit.

gr. Martin

Yves YANG wrote:
I get confused. If Texo can work without PMF, Texo has to implement most of
the concepts proposed and realized in PMF. As I said PMF is abstract and
high level infrastructure, it seems to me Texo as a specific implementation
for JSF. Some other projects can use PMF as well to provide other solutions
such as RCP on SWT. And furthermore, PMF, without a specific generator,
cannot be used directly by users. So PMF+Texo should be a complete solution
for JSF for Web application. I cannot understand why you need force Texo's
users to use PMF.

So for now I would say that the two projects start separately and work
together when some results have been achieved.

So we probably waste our energy on both sides to implement the same
-----Original Message-----
From: Martin Taal [mailto:mtaal@xxxxxxxxx] Sent: Wednesday, April 16, 2008 4:45 PM
To: Yves YANG
Cc: 'EMFT Developer Mailing List'; 'PMC members mailing list'
Subject: Re: [modeling-pmc] Re: [emft-dev] Proposal for Texo Component

Hi Yves,
I think Texo can integrate with pmf but it should also work without pmf. As I don't want to force users of Texo to also use pmf. So for me pmf is an additional component. As you say, the same applies the other way around pmf can be used as the basis for generators for other target platforms as well. So for now I would say that the two projects start separately and work together when some results have been achieved.

gr. Martin

Yves YANG wrote:
Hi Martin,

Does it mean that Texo could be an extension of PMF for JSF? If so, whould
we setup PMF project first in order that both team works closely?
-----Original Message-----
From: Martin Taal [mailto:mtaal@xxxxxxxxx] Sent: Wednesday, April 16, 2008 4:11 PM
To: Yves YANG
Cc: 'EMFT Developer Mailing List'; 'PMC members mailing list'
Subject: Re: [modeling-pmc] Re: [emft-dev] Proposal for Texo Component

Hi Yves,
I think this is more a terminology thing, with Ui-model I mean what you are refering to so definition of master/detail, selection dialog, page flows etc. and not the technical ui implementation. So afaics we mean the same thing.

gr. Martin

Yves YANG wrote:
I don't know which the presentation modeling framework you are talking
about. I have prepared a project named as PMF (presentation modeling
framework). But it is NOT an UI-model like XUL, XAML. It is an abstract
modeling framework that implements the presentation patterns like data
binding, page flows, Master/Detail etc. Each technology like JSF, SWT,
then can implement its generator. Please find the draft in the attached

Best regards
-----Original Message-----
From: emft-dev-bounces@xxxxxxxxxxx [mailto:emft-dev-bounces@xxxxxxxxxxx]
Behalf Of Martin Taal
Sent: Wednesday, April 16, 2008 3:54 PM
To: PMC members mailing list
Cc: EMFT Developer Mailing List
Subject: Re: [modeling-pmc] Re: [emft-dev] Proposal for Texo Component

Hi Christian,
Depends on how you look at it. On the one hand the artifacts generated are editable using wtp (for example jsp editor, dali project). On the other hand the Texo project does not need to make use of any component currently present in wtp while it uses (and tightly integrates with) emf, mwe, jmerge, teneo and xpand. Also the ideas for a ui-model (the presentation modeling framework) will be used by Texo. In addition it is the idea to make it possible to extend the solution with custom templates/workflows. So as there is a definite and large modeling side to it I would say that it belongs to modeling.

gr. Martin

Christian Damus wrote:

Can one also make an argument for locating this component in the Web
Platform project?  It seems to me that Texo is more of a model-driven
application development tool (and WTP is all about developing web apps)
than it is a framework for building modeling tools or even a big-M



Christian W. Damus
Component Lead, Eclipse OCL and EMF MQ/MT/VF
IBM Rational Software

  From:       Ed Merks/Toronto/IBM@IBMCA
  To:         PMC members mailing list <modeling-pmc@xxxxxxxxxxx>
  Cc:         modeling-pmc-bounces@xxxxxxxxxxx, EMFT Developer Mailing
List <emft-dev@xxxxxxxxxxx>, PMC members mailing list
  Date:       04/16/2008 09:04 AM
  Subject:    Re: [modeling-pmc] Re: [emft-dev] Proposal for Texo

Once-only code generators really do suck, so you have to wonder at their
preponderance given how relatively trivial it was to build Java merge
support. The original design and implementation of JMerge took roughly a
week of effort, as a I recall.  EMP is definitely a great basis for
building DSLs with the added benefit that they all have a common
meta model to ensure that we don't end up with just a Tower of Babel.
addition, we aren't suffering from the misguided belief that XML syntax
the be-all-and-end-all of human readable notations.

In our quest toward a grand vision, I think it's best to start small and
build the little pieces bottom rather than carve out a grand high level
space top down.  We also have to consider our project's charter and be
sensitive to the concerns that the scope of the modeling project could
creep out to consume all other projects.   Many DSLs would most
live in other projects and we'd be best off to ensure that things evolve
that direction when it makes the most sense.  So for the time being, I'd
rather avoid creating more direct child projects under the modeling
project.  Having a small number of projects to group the large number of
components seems appropriate...

Ed Merks/Toronto/IBM@IBMCA
mailto: merks@xxxxxxxxxx
905-413-3265  (t/l 313)

             Sven Efftinge
             Sent by:                  EMFT Developer Mailing List
             modeling-pmc-boun         <emft-dev@xxxxxxxxxxx>, PMC
             ces@xxxxxxxxxxx           mailing list

             04/16/2008 07:12
                                       [modeling-pmc] Re: [emft-dev]
                                       Proposal for Texo Component
             Please respond to
                PMC members
               mailing list

Hi all,

this sounds very cool. We all know that there are many general
frameworks (web, RCP, SOA, etc,) out there which would profit from
Some of them (Ruby on Rails, Grails, SEAM just to name a few) already
use code generation a lot.
Unfortunately they use wizard-style passive code generation, where you
generate once and further change the generated code manually.
So most of the time generators are just used to get users up and
running as fast as possible.
Also they come up with concise languages to descibe domain models
(internal DSLs).
Those languages are not statically typed, have to fit into the host's
syntax and have no tool support at all (EMP can do better).
IMHO there should be some more projects like Texo, which show how EMP
can be used.

As EMFT is for EMF technology I find that those projects don't fit
well there. We should create a new Project for such domain-specific
applications of EMP.
What do you think?


btw: +1

On Apr 16, 2008, at 12:34 , Ed Merks wrote:
Extended EMF Community,

Martin Taal, the lead for the Teneo component, recently announced his
intent to work on the Texo component which will focus on exploiting
modeling technology for building web applications.

I request the community's approval to create this new component as
part of
the EMFT subproject with Martin Taal as the component lead.  Please
with +1 or -1 on this thread.  Obviously I recommend you give a +1,
Martin's outstanding track record with Teneo and his exemplary
support for
it.  All EMF and EMFT committers are eligible to vote, so please
take a
moment to do so.

Ed Merks/Toronto/IBM@IBMCA
mailto: merks@xxxxxxxxxx
905-413-3265  (t/l 313)

emft-dev mailing list
Sven Efftinge

Phone: +49 431 5606335
Fax     :  +49 431 5606339
Mobile: +49 175 5274726

mail: sven.efftinge@xxxxxxxxx

itemis AG
Schauenburgerstra├če 116
24118 Kiel

Rechtlicher Hinweis:
Amtsgericht Dortmund, HRB 20621
Vorstand: Wolfgang Neuhaus, Jens Wagener, Dr. Georg Pietrek
Aufsichtsrat: Dr. Burkhard Igel(Vors.), Stephan Grollmann, Michael

modeling-pmc mailing list

emft-dev mailing list

modeling-pmc mailing list


With Regards, Martin Taal

Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@xxxxxxxxxxxxxx - mtaal@xxxxxxxxx
Web: -

Back to the top