Kevin Dangoor wrote:
Yes, if you change something on your model you will need to regenerate
the template, but how does this compare to the customization and
adaptation work needed by the other solution? with the View side
appearing on my Controller side? And what about the learning curve
needed to teach yourself the right way to do the customization work
(subclassing vs plain editing of HTML).
It's not quite as simple as "regenerat[ing] the template". Many
templates may change. You can either regenerate them all and have the
designer have to redo all of the customizations or you can manually
update all of them to add the new fields.
Note that this is essentially a 3-way diff, and conflict resolution -- a
standard (though never easy) operation when doing branching.
Code generation is often thought of as a problem that requires either
(a) an initial generation, with editing but no regeneration, or (b)
continuous potential regeneration, with no editing. But if the two
sources of changes -- manual editing and model-based code generation --
are considered two branches, there's a lot of tools to make this
workable. Version control systems can often merge two changes to the
same file correctly with no manual intervention.
Unfortunately these systems are always line-based, and HTML isn't really
line-based (though if it's valid XML you could easily normalize the code
to help here). But the other issue is that when two humans are working
on a file, they generally edit rather than recreate. Which means when
the branches are synced, they both start making minimal changes to
achieve what they want. But code generation only knows how to recreate,
and so it cannot be sensitive to the synchronized changes from the human
source. Though it's not impossible that the code generation could
produce imperative commands for changing code (e.g., "add this field",
which would be implemented by determining the proper location for a
field to go, and then putting in the field, instead of whole-file
regeneration).
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
