[triangle-zpug] UML + AXG -- Re: Plone Jam 3/20/08
josh_johnson at unc.edu
Wed Mar 19 16:01:56 UTC 2008
I have my quams about cramming everything into the UML model (which I'd
be happy to elaborate on), but my biggest beef with AGX is it
didn't/doesn't work (at least for me). :) It's not robust enough, it's
not developed enough, it's not documented enough.. and worse, it does
stuff for it's own sake instead of what makes sense (e.g. the broken
installation code, the way it uses config.py, etc). It's getting a lot
better, but it's still not quite "right".
That's very hard for me to say. I've seen the code first hand and I
think AGX is very well written, a tremendous accomplishment, and a huge
asset to the Plone community at large. I think what Joel has done, using
it as a platform for Plone education, is very remarkable.
That being said, I'm suspicious of anything that takes away knowledge
from you. AGX does too much for you, and without much explanation. The
code it generates is based on the personal experience of "what works" by
the people who wrote it (at least that's how it looks), and it doesn't
coincide directly with any documentation I've seen. It's great when it
works, but if it doesn't, either because you want to do something that
AGX hasn't implemented, or Plone has changed in ways that AGX hasn't
kept up with, you're stuck tacking things on and working around AGX's
limitations, with the risk of having your working code whacked the next
time you regenerate. Or worse, you stop regenerating and keeping your
model up to date.
That's assuming you know how to do it on your own. Relying on a code
generator like AGX too heavily keeps you from having to understand what
you're doing... until it's too late, AGX messes up, and you're forced to
dive in (that was my problem, just exacerbated by the fact that the code
it was generating wasn't documented).
I like the direction ZopeSkel is going because it sets a good precedent.
We've got Martin Aspeli's book to explain what ZopeSkel is doing. Martin
mentioned that he actually changed Plone's code so that he could explain
it's concepts better during the writing of his book. That's huge.
ZopeSkel's core theme is: run it once, then tweak the code as needed.
Run it again to add chunks of boiler plate as needed, then tweak some
more. That's great, because as you develop for new versions of Plone, or
start using features that ZopeSkel doesn't handle (and probably
shouldn't handle, like setting up event listeners), you're free to
implement them in the way that works best for your situation, not forced
to do it a specific way for the sake of the script. It's handling the
annoying boiler plate code, even educating you on how things should be
done (assuming the paster template is well documented), but you can
Better, it forces you to understand what it's doing. Since it's based on
a solid foundation of documentation (Martin's book), it's easy to find
the resources you need to accomplish that understanding. And ultimately,
that understanding helps enable you to fix it if it breaks. In working
on my process document, I've run into that many times, and didn't have
to scratch my head trying to figure out what I did wrong or what my tool
did that wasn't kosher.
Now, I think that that philosophy can be applied to future AGX
development. I can see AGX becoming more respectful to UML, and more
flexible. I can even see it being more easily extensible, where
templates can be added easily for new stereotypes (maybe even on a
per-project basis), new plone idioms, shortcuts, etc. I can see AGX's
documentation being concise and comprehensive, so that I can rely on the
explanation of a tagged value to actually do what the docs say, and more
importantly, I can predict what code will be generated given specific
circumstances, and know _why_.
I hope that makes sense (I hate being so verbose :P),
Mark R. Biggers wrote:
> Hi folks,
> Josh Johnson writes:
> > I don't know if I'd go so far as to say that model driven development is
> > falling out of favor (least in my case), it's more like model-driven
> > _code generation_ is turning out to be a real pipe dream.
> > To put it differently: I still think I'm in love with UML, I just don't
> > want to have code babies with it.
> > Rob Lineberger wrote:
> > > I have the same dream as you, but with something that generates a
> > > working Plone 3 product.
> > >
> > > I can (and in fact, recently did) present a tutorial on 2.5-style UML >>
> > > AGX >> Plone. I'd be happy to do the same thing at a Plone Jam now that
> > > the kinks have been worked out, but with a "real" UML model. But the
> > > Plone community seems pretty set on Zope3 tech, which Josh is much more
> > > versed in.
> > >
> > > In other words, I suspect that model driven development is falling out
> > > of favor, for good reasons according to people who know what they are
> > > doing. Instead of refining that process, it might make more sense to
> > > explore the new way.
> We "discussed" this possible issue over IRC #weblion, during the
> PloSympEast. Joel Burton, in particular, thinks that there *must* be a
> story for ArgoUML + ArchGenXML going forward. There's too many folks using
> AGX right now (with their fav. UML UI) for Plone2, and will expect that they
> can go forward with their models on Plone3.
> For my part, without AGX, I don't know how I could have been "bootstrapped"
> into doing real Plone2 development! Having the unit-test stubs; some
> workable "skeleton" of archetypes-classes from the model; and having a
> product that can install or unit-test "out of the box" is a *huge win*. And
> I like the fact that the UML model-representation is reflected in the code,
> and can be (manually) "round-tripped" with the code changes.
> AGX hasn't overcome the need to stare at Plone code (e.g. unit-tests) or use
> IPython or WingIDE to "get" all the APIs, but I can't overemphasize how much
> help Argo+AGX has been. Also, I think the combo has actually attracted and
> help keep new (possibly quite experienced otherwise) developers learning
> Plone & Zope.
> Hence, my great interest in Josh's fixes for AGX, and any signs that AGX
> 1.6.x or 2.0 will be a serious lever for doing Plone3 products development.
> ("paster" is fine as far it goes; I don't have a problem with it per se.)
> My 2 cents, thank you,
> triangle-zpug mailing list
> triangle-zpug at starship.python.net
More information about the triangle-zpug