| Limits of GMF [message #40298] |
Wed, 06 September 2006 02:05  |
Eclipse User |
|
|
|
Originally posted by: gorillas.paradise.net.nz
How far is GMF intended to go with the model-generate-customize-run
lifecycle? Is there a practical limit to how much customization you can
do before the model breaks and you then just have to go with the code
that you have managed to generate up to that point?
For example, I want to capture some initial model information in the
diagram new wizard. I can see the generated code for the wizard, and I
realize that I can modify it to add in some additional pages to capture
the info I want. All well and good, but every time I mark some
previously generated code as @generated NOT, I introduce a little bit of
fragility. Next time I generate the code, I may end up with conflicts
between new generated code and previously customized code that I have to
go sort out by hand.
Obviously there has to be a limit somewhere, I'm just trying to get a
feel for where GMF intends to sit. Is it essentially a bootstrapping
process, getting you say half the way there, or is it really intended
that you can model a complete application?
--
Colin Sharples
|
|
|
| Re: Limits of GMF [message #40449 is a reply to message #40298] |
Wed, 06 September 2006 04:59  |
| Eclipse User |
|
|
|
Originally posted by: khai.n.situvista.com
Yes, indeed, this is a challenge with all generative approaches that I
know of. Unless the template grammar has enough extensibility to
capture all conceivable use cases (before code generation) I don't see
this going away anytime soon.
With the current application I'm developing EMF generated 99% of the
model code and plumbing and GMF managed to generate about 90% of the
code with a perfectly usable single page editor for a fairly complex
model. Unfortunately my metamodel requires the work flow of a
multi-page editor so the remaining 10% is hand-coded with 100+ (and
counting) [@generated NOT] so far:-(
This is going to haunt me down the road because it only takes one or two
of these to be 'out of synch' to create a debugging nightmare.
What I've actually done for some of the more repetitive overrides was
edit the code generation templates themselves so that at least in the
future I would have to only keep the templates updated plus a small
number of [@generated NOT]. I would have no problem with pushing 100%
of the application definitions into the templates if the codegen engine
can support it.
The adoption of oAw http://www.eclipse.org/gmt/oaw/ by the GMF project
may provide some (more likely ALL) of the features towards this goal but
I don't know enough about it to be 'counting on it' just yet. I'm
definitely keeping my eyes on this initiative to see what fruits it may
bear. For now source control is my best friend (I've forgotten to use
NOT before regenerating the project more than once already:-P)
All in all EMF/GMF/GEF are impressively robust as they are and they have
saved countless days of development time for me already:-).
That's my 2 c's
-- Khai --
Colin Sharples wrote:
> How far is GMF intended to go with the model-generate-customize-run
> lifecycle? Is there a practical limit to how much customization you can
> do before the model breaks and you then just have to go with the code
> that you have managed to generate up to that point?
>
> For example, I want to capture some initial model information in the
> diagram new wizard. I can see the generated code for the wizard, and I
> realize that I can modify it to add in some additional pages to capture
> the info I want. All well and good, but every time I mark some
> previously generated code as @generated NOT, I introduce a little bit of
> fragility. Next time I generate the code, I may end up with conflicts
> between new generated code and previously customized code that I have to
> go sort out by hand.
>
> Obviously there has to be a limit somewhere, I'm just trying to get a
> feel for where GMF intends to sit. Is it essentially a bootstrapping
> process, getting you say half the way there, or is it really intended
> that you can model a complete application?
>
|
|
|
| Re: Limits of GMF [message #40690 is a reply to message #40298] |
Wed, 06 September 2006 07:19 |
| Eclipse User |
|
|
|
> Obviously there has to be a limit somewhere, I'm just trying to get a feel
> for where GMF intends to sit. Is it essentially a bootstrapping process,
> getting you say half the way there, or is it really intended that you can
> model a complete application?
GMF is not intended as a bootstrapping-only tool, though one could use it
that way. Nevertheless, I can't state you'll be able to model any visual
modeling application with GMF some day. Sure, some types of applications
will be 100 % generated, some will require manual coding. It's just
impossible to capture any possible use case with the models. Provided we
construct extensible tool, easily tailored to specific needs (either with
extended models, overrided templates, whatever), I'm sure GMF will slip away
"bootstrap-only" perception.
As an side note, I don't feel there's a significant difference with
"generated-and-modeified" and "fully-handcoded" approaches in the sense of
fragility and proof to errors -
> ... but every time I mark some previously generated code as @generated
> NOT, I introduce a little bit of fragility. Next time I generate the code,
> I may end up with conflicts between new generated code and previously
> customized code that I have to go sort out by hand.
There's no magic with generated code, it's just pieces you otherwise have
to write manually. With almost no application (whether generated or not) you
can be safe after some changes were introduced, and the conflict resolution
process happens regardless of the nature of the code.
Artem.
"Colin Sharples" <gorillas@paradise.net.nz> wrote in message
news:edlof2$4lb$1@utils.eclipse.org...
> How far is GMF intended to go with the model-generate-customize-run
> lifecycle? Is there a practical limit to how much customization you can do
> before the model breaks and you then just have to go with the code that
> you have managed to generate up to that point?
>
> For example, I want to capture some initial model information in the
> diagram new wizard. I can see the generated code for the wizard, and I
> realize that I can modify it to add in some additional pages to capture
> the info I want. All well and good, but every time I mark some previously
> generated code as @generated NOT, I introduce a little bit of fragility.
> Next time I generate the code, I may end up with conflicts between new
> generated code and previously customized code that I have to go sort out
> by hand.
>
> Obviously there has to be a limit somewhere, I'm just trying to get a feel
> for where GMF intends to sit. Is it essentially a bootstrapping process,
> getting you say half the way there, or is it really intended that you can
> model a complete application?
>
> --
> Colin Sharples
|
|
|
Powered by
FUDForum. Page generated in 0.40906 seconds
Home