Login | Register
My pages Projects Community openCollabNet

propel
Reply to message

* = Required fields
* Subject
* Body
Attachments
Send reply to
Topic
Author (directly in email)
Please type the letters in the image above.

Original message

Author hlellelid
Full name Hans Lellelid
Date 2007-11-16 05:21:35 PST
Message Ron Rademaker wrote:
> Hi Hans,
>
> Hans Lellelid wrote:
>> Ok. It should be a little easier now that Basic & Complex objects
>> were merged into a single class. For the sake of BC, I suggest that
>> you keep the existing methods (like addSave()) but then add the
>> additional methods. So that if people are currently overriding
>> addSave() their code will still work.
> I'll do that.
>> For next version (2.0, I mean) I'd also like to move these to a more
>> modular model. I imagine a world where you register different
>> builders which declare that they add or override specific methods.
>> Any thoughts on this while you're in there would be appreciated! :)
> My first thought is to make some sort of advertisement structure in
> which a builder module / class would advertise to the generator what
> it's capable of doing. For example, a builder could advertise
> AddAccessors if, when the builder is used, it adds accessor methods to a
> class. This would result in many small classes that do one specific
> thing in the build process, making it easy to maintain and extend (you
> just extend the class responsable for the save function if you want to
> get a different save method). If multiple builder classes advertise they
> can do the same thing, the user can choose which one they want to use.
> This would be a bit like preconditions in design by contract, as an
> extended builder class would always be allowed to advertise more than
> its parent, but never less.

Yeah, that's sort of what I envisioned too. I like the term
"advertiser", though; that's exactly right.

It becomes a little less clear to me when I think about a builder
advertising that it wants to override / customize other methods. I
guess the question is what happens when several builders want to all add
custom behavior into the save method?

If we move to a model where everything has header/footer methods as you
are prorposing (perhaps more for immediate changes), that may work ok
for the common cases. I suppose there would need to be a way for
builders to handle potential conflicts too. Sounds complicated :)

Hans