> IMHO, wether a code generator will be usefull or not
depends on its
> ability to perform reverse-engineering of generated
code, whatever it
> does.
Do you mean the ability to update existing code? In that
case,
'reverse-engineering' would be one strategy or maintaining
some metadata
either in separate files or comments would be another. I've
been playing
around with both.
> Two of the main interests of CG are development speed
and runtime
> performances improvments. If the latter is (almost)
always reached
> (compared to on-the-fly analysis and interpretation),
the first really
> depends on the way it handles code customizations.
Well, generated code isn't necessarily faster than
inheritance-based
extension. In fact, unless you're using introspection (which
I think you
might be talking about) there should be very little
difference in the
two. I personally don't like configuration-based content
generation
(whether or not it's done through code generation) because-
even if it's
not too bad to begin with- as new requirements come up, the
config files
tend to grow and grow and eventually it seems like it would
just be
easier to write the page yourself than figure out what
you're supposed
to put in a config file and where. One direction I wouldn't
want to go
in is that of the symfony admin generator. A single
generator requiring
a config file cheat sheet isn't the kind of extensibility
I'd like to
see in ZF.
> If you're talking about model-driver generator, it's a
must that the
> model could be updated by parsing the edited code. To
achieve that,
> it's
> obvious that a higly descriptive format has to be used
to describe the
> model, as XML (my turn to wonder if i said that...)
That's starting to sound a lot like Propel. We're thinking
about
generating code for models in the initial release, but this
is more than
we plan to take on. But I take your point of being to update
the model.
This is something that we're keeping in mind, and it may be
a good place
to make use of inflection.
> Anyhow, one thing remains, in most projects built on
top of a
> framework,
> a part of the code stills the same, regardless of the
purpose of the
> projects.
>
> I strongly believe that a xml-model-driven approach
would open the
door
> to highly efficient processes for development and
tests, by allowing
> connections to other tools and enabling them to share
the whole
> informations attached to the models.
OK, we could apply that to more than models, however (maybe
you are
talking about something other than the M in MVC?). This
sounds like one
approach to the metadata-driven strategy I mentioned
before.
Interesting- and maybe a good application of XML. I guess
the XML
question ultimately comes down to what metadata we'd want to
store.
,Wil
|