Login | Register
My pages Projects Community openCollabNet

Discussions > dev > Propel event handler

propel
Discussion topic

Hide all messages in topic

All messages in topic

Re: [propel-dev] Propel event handler

Reply

Author hlellelid
Full name Hans Lellelid
Date 2008-05-06 09:48:07 PDT
Message Hi Ron,

Thank you! Yes, I think your implementation is correct; I read over the
ticket again and think that I did not fully understand it the first time.
This is apparently for a composite fkey, which your approach correctly
solves.

I will look over the ticket list, but I think that we should be able to
release an RC now or very soon.

Thanks again,
Hans

On Tue, 06 May 2008 17:51:25 +0200, Ron Rademaker
<r.rademaker@virt​ualbuilding.nl> wrote:
> Hi Hans,
>
> I just commited a fix for 606. At least it works for the unit test you
> added and those I added earlier today.
>
> Ron
>
> Hans Lellelid wrote:
>> Is that true ... ? Maybe; I thought we'd have to have them be separate
>> joins, but I haven't looked at this recently. I was assuming that we'd
>> need to introduce some aliasing to avoid collision in the generated
>> doSelectJoin*() method.
>>
>> Hans
>>
>> On Tue, 06 May 2008 15:47:08 +0200, Ron Rademaker
>> <r.rademaker@virt​ualbuilding.nl> wrote:
>>
>>> I just looked at that ticket. If I understand the problem correctly
>>> extending the addJoin API so it also accepts arrays for the first two
>>> arguments would solve it.
>>> Like:$criteria->​addJoin(LoggedOfferI​PPeer::MEMBER_ID,
>>> LoggedOfferPeer::MEMBER, Criteria::LEFT_JOIN);
>>>
>>> $criteria->addJo​in(LoggedOfferIPPeer​::OFFER_ID,
> LoggedOfferPeer::OFFERID,
>>> Criteria::LEFT_JOIN);
>>>
>>>
>>>
>>>
>>> Hans Lellelid wrote:
>>>
>>>> The one ticket I would really like to fix before RC is
>>>> http://propel.phpdb.​org/trac/ticket/606
>>>>
>>>> If you have a few spare minutes and want to look at that, I'd
> appreciate
>>>> it! -- Otherwise, that's first on my list to fix and I should be able
> to
>>>> finally get some non-housework done this weekend :)
>>>>
>>>> Hans
>>>>
>>>>
>>> --------------------​--------------------​--------------------​---------
>>> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
>>> For additional commands, e-mail: dev-help at propel dot tigris dot org
>>>
>>
>>
>> --------------------​--------------------​--------------------​---------
>> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
>> For additional commands, e-mail: dev-help at propel dot tigris dot org
>>
>>
>>
>
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> For additional commands, e-mail: dev-help at propel dot tigris dot org

Re: [propel-dev] Propel event handler

Reply

Author Ron Rademaker <r dot rademaker at virtualbuilding dot nl>
Full name Ron Rademaker <r dot rademaker at virtualbuilding dot nl>
Date 2008-05-06 08:51:25 PDT
Message Hi Hans,

I just commited a fix for 606. At least it works for the unit test you
added and those I added earlier today.

Ron

Hans Lellelid wrote:
> Is that true ... ? Maybe; I thought we'd have to have them be separate
> joins, but I haven't looked at this recently. I was assuming that we'd
> need to introduce some aliasing to avoid collision in the generated
> doSelectJoin*() method.
>
> Hans
>
> On Tue, 06 May 2008 15:47:08 +0200, Ron Rademaker
> <r.rademaker@virt​ualbuilding.nl> wrote:
>
>> I just looked at that ticket. If I understand the problem correctly
>> extending the addJoin API so it also accepts arrays for the first two
>> arguments would solve it.
>> Like:$criteria->​addJoin(LoggedOfferI​PPeer::MEMBER_ID,
>> LoggedOfferPeer::MEMBER, Criteria::LEFT_JOIN);
>>
>> $criteria->addJo​in(LoggedOfferIPPeer​::OFFER_ID, LoggedOfferPeer::OFFERID,
>> Criteria::LEFT_JOIN);
>>
>>
>>
>>
>> Hans Lellelid wrote:
>>
>>> The one ticket I would really like to fix before RC is
>>> http://propel.phpdb.​org/trac/ticket/606
>>>
>>> If you have a few spare minutes and want to look at that, I'd appreciate
>>> it! -- Otherwise, that's first on my list to fix and I should be able to
>>> finally get some non-housework done this weekend :)
>>>
>>> Hans
>>>
>>>
>> --------------------​--------------------​--------------------​---------
>> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
>> For additional commands, e-mail: dev-help at propel dot tigris dot org
>>
>
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> For additional commands, e-mail: dev-help at propel dot tigris dot org
>
>
>

Re: [propel-dev] Propel event handler

Reply

Author hlellelid
Full name Hans Lellelid
Date 2008-05-06 06:49:51 PDT
Message Is that true ... ? Maybe; I thought we'd have to have them be separate
joins, but I haven't looked at this recently. I was assuming that we'd
need to introduce some aliasing to avoid collision in the generated
doSelectJoin*() method.

Hans

On Tue, 06 May 2008 15:47:08 +0200, Ron Rademaker
<r.rademaker@virt​ualbuilding.nl> wrote:
> I just looked at that ticket. If I understand the problem correctly
> extending the addJoin API so it also accepts arrays for the first two
> arguments would solve it.
> Like:$criteria->​addJoin(LoggedOfferI​PPeer::MEMBER_ID,
> LoggedOfferPeer::MEMBER, Criteria::LEFT_JOIN);
>
> $criteria->addJo​in(LoggedOfferIPPeer​::OFFER_ID, LoggedOfferPeer::OFFERID,
> Criteria::LEFT_JOIN);
>
>
>
>
> Hans Lellelid wrote:
>> The one ticket I would really like to fix before RC is
>> http://propel.phpdb.​org/trac/ticket/606
>>
>> If you have a few spare minutes and want to look at that, I'd appreciate
>> it! -- Otherwise, that's first on my list to fix and I should be able to
>> finally get some non-housework done this weekend :)
>>
>> Hans
>>
>
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> For additional commands, e-mail: dev-help at propel dot tigris dot org

Re: [propel-dev] Propel event handler

Reply

Author Ron Rademaker <r dot rademaker at virtualbuilding dot nl>
Full name Ron Rademaker <r dot rademaker at virtualbuilding dot nl>
Date 2008-05-06 06:47:08 PDT
Message I just looked at that ticket. If I understand the problem correctly
extending the addJoin API so it also accepts arrays for the first two
arguments would solve it.
Like:$criteria->​addJoin(LoggedOfferI​PPeer::MEMBER_ID,
LoggedOfferPeer::MEMBER, Criteria::LEFT_JOIN);

$criteria->addJo​in(LoggedOfferIPPeer​::OFFER_ID, LoggedOfferPeer::OFFERID, Criteria::LEFT_JOIN);




Hans Lellelid wrote:
> The one ticket I would really like to fix before RC is
> http://propel.phpdb.​org/trac/ticket/606
>
> If you have a few spare minutes and want to look at that, I'd appreciate
> it! -- Otherwise, that's first on my list to fix and I should be able to
> finally get some non-housework done this weekend :)
>
> Hans
>

Re: [propel-dev] Propel event handler

Reply

Author hlellelid
Full name Hans Lellelid
Date 2008-05-06 06:39:12 PDT
Message The one ticket I would really like to fix before RC is
http://propel.phpdb.​org/trac/ticket/606

If you have a few spare minutes and want to look at that, I'd appreciate
it! -- Otherwise, that's first on my list to fix and I should be able to
finally get some non-housework done this weekend :)

Hans

On Tue, 06 May 2008 09:15:41 +0200, Ron Rademaker
<r.rademaker@virt​ualbuilding.nl> wrote:
> Hi Hans,
>
> I totally agree on getting 1.3 out. What tickets are currently blocking
> a RC?
> I'm going to do some more testing on the event stuff today and if
> everything goes well, I'll check it into trunk.
>
> Ron
>
> Hans Lellelid wrote:
>> Hi Ron,
>>
>> If you'd like to merge in 1.3 changes to trunk, you could commit it
> there.
>> I don't *think* there's anything in trunk that's not in 1.3, so you
> could
>> also delete trunk and copy 1.3. I'd rather not add new features to 1.3
> for
>> now, because releasing that version is highest on my priority list (as
> soon
>> as I've finished "moving in" to my new house).
>>
>> Hans
>>
>>
>
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> For additional commands, e-mail: dev-help at propel dot tigris dot org

Re: [propel-dev] Propel event handler

Reply

Author Ron Rademaker <r dot rademaker at virtualbuilding dot nl>
Full name Ron Rademaker <r dot rademaker at virtualbuilding dot nl>
Date 2008-05-06 00:15:41 PDT
Message Hi Hans,

I totally agree on getting 1.3 out. What tickets are currently blocking
a RC?
I'm going to do some more testing on the event stuff today and if
everything goes well, I'll check it into trunk.

Ron

Hans Lellelid wrote:
> Hi Ron,
>
> If you'd like to merge in 1.3 changes to trunk, you could commit it there.
> I don't *think* there's anything in trunk that's not in 1.3, so you could
> also delete trunk and copy 1.3. I'd rather not add new features to 1.3 for
> now, because releasing that version is highest on my priority list (as soon
> as I've finished "moving in" to my new house).
>
> Hans
>
>

Re: [propel-dev] Propel event handler

Reply

Author hlellelid
Full name Hans Lellelid
Date 2008-05-05 09:53:00 PDT
Message Hi Ron,

If you'd like to merge in 1.3 changes to trunk, you could commit it there.
I don't *think* there's anything in trunk that's not in 1.3, so you could
also delete trunk and copy 1.3. I'd rather not add new features to 1.3 for
now, because releasing that version is highest on my priority list (as soon
as I've finished "moving in" to my new house).

Hans

On Mon, 05 May 2008 16:16:33 +0200, Ron Rademaker
<r.rademaker@virt​ualbuilding.nl> wrote:
> Hi all,
>
> I picked up on the mail below again (which I've send to the list last
> November) last week and today. I actually got the first handler (which
> creates backups when changing db records) working in a very limited
> test. I don't think it would be a good idea to commit this to 1.3
> because I expect this first version to still be quite buggy (and getting
> 1.3 into RC would be nice) . However, from the looks of it trunk is
> pretty old right now (and the event handler thing requires the commit I
> did this morning) and nobody probably uses trunk so it wouldn't get
> tested anyway. Where should I commit this stuff?
>
> Ron
>
> Ron Rademaker wrote:
>> Hi all,
>>
>> Last week I told you about my idea to create a backup function in
>> propel based on sql triggers. I've been working on this a bit this
>> week only to find out sql triggers and procedures have some very
>> annoying properties. This would result in having to redefine all
>> triggers whenever you change your schema, and often no errors if you
>> forget to do this (and I *know* I would something forget it and I
>> would be *very* surprised if the other developers here wouldn't). I
>> don't think this is a good idea so I've come up with a different, much
>> more flexible, database independent solution. The only drawback I see
>> is that performance would be better if the backup functionality was
>> implemented in sql.
>>
>> The basic idea is that you can add event to tables and columns (and
>> databases, though I haven't though of a useful example for that yet).
>> An example schema (I think the first event is obvious, I'll explain
>> the second later) could be:
>>
>> <table name='foo'>
>> <column name='id' primaryKey='true' type='INTEGER'
>> autoIncrement='true'/>
>> <column name='date' type='TIMESTAMP'/>
>> <column name='bar' type='VARCHAR'/>
>> <event occasion='onChange'> <!-- this is now defined on the table,
>> but could also be defined on the bar column -->
>> <handler name='setcolumn'>
>> <parameter name='column' value='date'/>
>> <parameter name='value' type='phpfunction'>
>> <function name='date'>
>> <parameter value='"now"'/>
>> </function>
>> </parameter>
>> </handler>
>> </event>
>> <event occasion='onCreate'>
>> <handler name='saver' function='registerSave'/>
>> </event>
>> <event occasion='onSave'>
>> <handler name='saver' function='triggerSave'/>
>> </event>
>> </table>
>> <table name='bar'>
>> <column name='id' primaryKey='true' type='INTEGER'
>> autoIncrement='true'/>
>> <column name='bar' type='VARCHAR'/>
>> <event occasion='onCreate'>
>> <handler name='saver' function='registerSave'/>
>> </event>
>> <event occasion='onSave'>
>> <handler name='saver' function='triggerSave'/>
>> </event>
>> </table>
>>
>> Both table foo and bar have the saver handler for the onCreate and
>> onSave event. I intent to implement the event / handler structure
>> using the observer pattern, Propel objects being Observables and event
>> handlers being Observers. The saver handler (observer) would be an
>> example where the onCreate event registers the propel object with the
>> handler and the onSave triggers save on all registered objects. This
>> way you can save multiple objects with a single save() call,
>> potentially this means you could tweak things so that you would add or
>> update many objects in a single sql query.
>> I know many of the things this will make possible are already possible
>> by overriding functions in the propel classes. I do believe however,
>> that this mechanism would prove to be very flexible and easier to
>> maintain than implementations in propel classes (I still have a whole
>> lot of classes where I need to change save(PDO $con = nul) to
>> save(PropelPDO $con = null)).
>> I'll be starting to build this shortly, anyone having suggestions,
>> improvements, seeing upfront bottlenecks, just let me know and if I
>> think it makes sense I'll try to do something useful with it ;)
>>
>> Ron
>>
>> --------------------​--------------------​--------------------​---------
>> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
>> For additional commands, e-mail: dev-help at propel dot tigris dot org
>>
>>
>
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> For additional commands, e-mail: dev-help at propel dot tigris dot org

Re: [propel-dev] Propel event handler

Reply

Author Ron Rademaker <r dot rademaker at virtualbuilding dot nl>
Full name Ron Rademaker <r dot rademaker at virtualbuilding dot nl>
Date 2008-05-05 07:16:33 PDT
Message Hi all,

I picked up on the mail below again (which I've send to the list last
November) last week and today. I actually got the first handler (which
creates backups when changing db records) working in a very limited
test. I don't think it would be a good idea to commit this to 1.3
because I expect this first version to still be quite buggy (and getting
1.3 into RC would be nice) . However, from the looks of it trunk is
pretty old right now (and the event handler thing requires the commit I
did this morning) and nobody probably uses trunk so it wouldn't get
tested anyway. Where should I commit this stuff?

Ron

Ron Rademaker wrote:
> Hi all,
>
> Last week I told you about my idea to create a backup function in
> propel based on sql triggers. I've been working on this a bit this
> week only to find out sql triggers and procedures have some very
> annoying properties. This would result in having to redefine all
> triggers whenever you change your schema, and often no errors if you
> forget to do this (and I *know* I would something forget it and I
> would be *very* surprised if the other developers here wouldn't). I
> don't think this is a good idea so I've come up with a different, much
> more flexible, database independent solution. The only drawback I see
> is that performance would be better if the backup functionality was
> implemented in sql.
>
> The basic idea is that you can add event to tables and columns (and
> databases, though I haven't though of a useful example for that yet).
> An example schema (I think the first event is obvious, I'll explain
> the second later) could be:
>
> <table name='foo'>
> <column name='id' primaryKey='true' type='INTEGER'
> autoIncrement='true'/>
> <column name='date' type='TIMESTAMP'/>
> <column name='bar' type='VARCHAR'/>
> <event occasion='onChange'> <!-- this is now defined on the table,
> but could also be defined on the bar column -->
> <handler name='setcolumn'>
> <parameter name='column' value='date'/>
> <parameter name='value' type='phpfunction'>
> <function name='date'>
> <parameter value='"now"'/>
> </function>
> </parameter>
> </handler>
> </event>
> <event occasion='onCreate'>
> <handler name='saver' function='registerSave'/>
> </event>
> <event occasion='onSave'>
> <handler name='saver' function='triggerSave'/>
> </event>
> </table>
> <table name='bar'>
> <column name='id' primaryKey='true' type='INTEGER'
> autoIncrement='true'/>
> <column name='bar' type='VARCHAR'/>
> <event occasion='onCreate'>
> <handler name='saver' function='registerSave'/>
> </event>
> <event occasion='onSave'>
> <handler name='saver' function='triggerSave'/>
> </event>
> </table>
>
> Both table foo and bar have the saver handler for the onCreate and
> onSave event. I intent to implement the event / handler structure
> using the observer pattern, Propel objects being Observables and event
> handlers being Observers. The saver handler (observer) would be an
> example where the onCreate event registers the propel object with the
> handler and the onSave triggers save on all registered objects. This
> way you can save multiple objects with a single save() call,
> potentially this means you could tweak things so that you would add or
> update many objects in a single sql query.
> I know many of the things this will make possible are already possible
> by overriding functions in the propel classes. I do believe however,
> that this mechanism would prove to be very flexible and easier to
> maintain than implementations in propel classes (I still have a whole
> lot of classes where I need to change save(PDO $con = nul) to
> save(PropelPDO $con = null)).
> I'll be starting to build this shortly, anyone having suggestions,
> improvements, seeing upfront bottlenecks, just let me know and if I
> think it makes sense I'll try to do something useful with it ;)
>
> Ron
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> For additional commands, e-mail: dev-help at propel dot tigris dot org
>
>

Re: [propel-dev] Propel event handler

Reply

Author =?ISO-8859-1?Q?David_Z=FClke?= <dz at bitxtender dot com>
Full name =?ISO-8859-1?Q?David_Z=FClke?= <dz at bitxtender dot com>
Date 2007-11-16 07:22:12 PST
Message Another thing we could consider is an approach similar to phpAspect's
where source is transformed using XSLT via the parse tree... that
would, actually, be the nicest solution, if it can be done in a simple
fashion and without (any|too many) external dependencies.

David



Am 16.11.2007 um 15:44 schrieb Hans Lellelid:

> David Zülke wrote:
>> How bout something wicked such as having method bodies in an array,
>> with
>> each line having a unique ID ;) That would be hax0r.
>>
>> But seriously - yes, we need something like that. The more modular it
>> is, the better. But as you pointed out, it could be a bitch to
>> design -
>> maybe we need alien technology from outer space to do that. Not quite
>> sure... :>
>>
>>
>> David
>>
>>
>>
>> Am 16.11.2007 um 14:58 schrieb Ron Rademaker:
>>
>>> Hans Lellelid wrote:
>>>> 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?
>>>>
>>> I guess we could reevaluate the way classes are generated
>>> completely.
>>> Instead of passing along some string by reference and appending code
>>> in a function we could model the classes that are being generated
>>> and
>>> let the builders fill the model. Finally, some toString function on
>>> the model class creates the actual code. That way you don't have to
>>> create an entire function in one sweep but you can add, remove and
>>> change stuff later. Obviously, the model is gonna be a challenge to
>>> design :)
>>>
>
> Yeah, that's a possibility. I looked into that a bit when considering
> the initial design. In the end, I opted for the current system,
> because
> I think it's a lot easier for people (including myself) to understand.
> I worry about completely abstracted code generation being really
> difficult to get in there and change :)
>
> Maybe the initial pass continues to use a template-based approach
> and we
> look at revamping this based on usage / needs.
>
> Hans
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> For additional commands, e-mail: dev-help at propel dot tigris dot org
>
>

Re: [propel-dev] Propel event handler

Reply

Author hlellelid
Full name Hans Lellelid
Date 2007-11-16 06:44:57 PST
Message David Zülke wrote:
> How bout something wicked such as having method bodies in an array, with
> each line having a unique ID ;) That would be hax0r.
>
> But seriously - yes, we need something like that. The more modular it
> is, the better. But as you pointed out, it could be a bitch to design -
> maybe we need alien technology from outer space to do that. Not quite
> sure... :>
>
>
> David
>
>
>
> Am 16.11.2007 um 14:58 schrieb Ron Rademaker:
>
>> Hans Lellelid wrote:
>>> 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?
>>>
>> I guess we could reevaluate the way classes are generated completely.
>> Instead of passing along some string by reference and appending code
>> in a function we could model the classes that are being generated and
>> let the builders fill the model. Finally, some toString function on
>> the model class creates the actual code. That way you don't have to
>> create an entire function in one sweep but you can add, remove and
>> change stuff later. Obviously, the model is gonna be a challenge to
>> design :)
>>

Yeah, that's a possibility. I looked into that a bit when considering
the initial design. In the end, I opted for the current system, because
I think it's a lot easier for people (including myself) to understand.
I worry about completely abstracted code generation being really
difficult to get in there and change :)

Maybe the initial pass continues to use a template-based approach and we
look at revamping this based on usage / needs.

Hans

Re: [propel-dev] Propel event handler

Reply

Author =?ISO-8859-1?Q?David_Z=FClke?= <dz at bitxtender dot com>
Full name =?ISO-8859-1?Q?David_Z=FClke?= <dz at bitxtender dot com>
Date 2007-11-16 06:36:22 PST
Message How bout something wicked such as having method bodies in an array,
with each line having a unique ID ;) That would be hax0r.

But seriously - yes, we need something like that. The more modular it
is, the better. But as you pointed out, it could be a bitch to design
- maybe we need alien technology from outer space to do that. Not
quite sure... :>


David



Am 16.11.2007 um 14:58 schrieb Ron Rademaker:

> Hans Lellelid wrote:
>> 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?
>>
> I guess we could reevaluate the way classes are generated
> completely. Instead of passing along some string by reference and
> appending code in a function we could model the classes that are
> being generated and let the builders fill the model. Finally, some
> toString function on the model class creates the actual code. That
> way you don't have to create an entire function in one sweep but you
> can add, remove and change stuff later. Obviously, the model is
> gonna be a challenge to design :)
>
> Ron
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> For additional commands, e-mail: dev-help at propel dot tigris dot org
>
>

Re: [propel-dev] Propel event handler

Reply

Author Ron Rademaker <r dot rademaker at virtualbuilding dot nl>
Full name Ron Rademaker <r dot rademaker at virtualbuilding dot nl>
Date 2007-11-16 05:58:30 PST
Message Hans Lellelid wrote:
> 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?
>
I guess we could reevaluate the way classes are generated completely.
Instead of passing along some string by reference and appending code in
a function we could model the classes that are being generated and let
the builders fill the model. Finally, some toString function on the
model class creates the actual code. That way you don't have to create
an entire function in one sweep but you can add, remove and change stuff
later. Obviously, the model is gonna be a challenge to design :)

Ron

Re: [propel-dev] Propel event handler

Reply

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

Re: [propel-dev] Propel event handler

Reply

Author Ron Rademaker <r dot rademaker at virtualbuilding dot nl>
Full name Ron Rademaker <r dot rademaker at virtualbuilding dot nl>
Date 2007-11-16 04:15:58 PST
Message 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.

Ron

Re: [propel-dev] Propel event handler

Reply

Author hlellelid
Full name Hans Lellelid
Date 2007-11-16 04:02:10 PST
Message Hi Ron,

> I'll check out the symfony code, though I know they're still at propel
> 1.2 and despite many user request can't seem to even get a beta or
> unstable version with 1.3 running (afaik) so I'm not hoping for much.
> You're right, it's very much AOP. I just know a whole lot more web
> developers familiar with the concept of events (from javascript) than
> AOP, so I choose to name it events. I'll definitely make an option to
> completely disable the code.

Ok, yeah, this sounds great. Fabien mentioned that he didn't think the
Symfony-based system was optimal (or when we discussed this, he said
"Don't do it the way we did"), but it seems like it would be good to
look at, since I think it has the same goal.

> Currently, I except that I'll start with completely refactoring the om
> builder classes so that a function no longer add a complete function to
> the om class, but instead multiple functions will do this (I'll check
> out symfony first though and maybe they used a solution that I can
> borrow). First function will open the function, second will add the body
> and a third will close the function.

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.

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! :)

> Are the test units for the om
> classes complete? Does performing the test just involve building the
> bookstore project and running the tests?

Yeah, that's all they do. The GeneratedObjectTest and GeneratedPeerTest
  just perform tests on the generated objects. It's not optimal --
since obviously there are different objects that can be generated. In
the end, the tests need to be linked up to a build process. I'm
considering having different suites for different build options (and
some core tests for the basics).

Hans

Re: [propel-dev] Propel event handler

Reply

Author Bert-Jan <info at bert-jan dot com>
Full name Bert-Jan <info at bert-jan dot com>
Date 2007-11-16 02:34:57 PST
Message > Hi Hans,
>
> Hans Lellelid wrote:
>>
>> Yeah, I think this is what Symfony is doing w/ Propel. I believe they
>> have extended the builder classes to wrap the various methods to fire
>> pre/post events. They call this "mixins" (I guess it's a bit AOP
>> like). You may wish to start from their implementation. I'm open to
>> us including a version of this directly in Propel too (maybe ability
>> to enable/disable the code would be nice too). I think it's a useful
>> idea.
>>
>> Hans
>>
>> --------------------​--------------------​--------------------​---------
>> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
>> For additional commands, e-mail: dev-help at propel dot tigris dot org
>>
>>
>
> I'll check out the symfony code, though I know they're still at propel
> 1.2 and despite many user request can't seem to even get a beta or
> unstable version with 1.3 running (afaik) so I'm not hoping for much.
> You're right, it's very much AOP. I just know a whole lot more web
> developers familiar with the concept of events (from javascript) than
> AOP, so I choose to name it events. I'll definitely make an option to
> completely disable the code.
> Currently, I except that I'll start with completely refactoring the om
> builder classes so that a function no longer add a complete function to
> the om class, but instead multiple functions will do this (I'll check
> out symfony first though and maybe they used a solution that I can
> borrow). First function will open the function, second will add the body
> and a third will close the function. Are the test units for the om
> classes complete? Does performing the test just involve building the
> bookstore project and running the tests?
>
> Ron
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> For additional commands, e-mail: dev-help at propel dot tigris dot org
>
>

There is a 1.3 beta plugin for symfony at
http://trac.symfony-​project.com/wiki/sfP​ropel13Plugin and I have it
running perfectly for the project I'm building. The only things missing
are query logging and support for the 'encoding' parameter in
databases.yml. The author of the plugin told me he'll look into the
encoding parameter (simply running 'set names $encoding' is sufficient)
but the query logging issue is the main problem that's keeping 1.3 in
beta.

Re: [propel-dev] Propel event handler

Reply

Author Ron Rademaker <r dot rademaker at virtualbuilding dot nl>
Full name Ron Rademaker <r dot rademaker at virtualbuilding dot nl>
Date 2007-11-16 00:28:50 PST
Message Hi Hans,

Hans Lellelid wrote:
>
> Yeah, I think this is what Symfony is doing w/ Propel. I believe they
> have extended the builder classes to wrap the various methods to fire
> pre/post events. They call this "mixins" (I guess it's a bit AOP
> like). You may wish to start from their implementation. I'm open to
> us including a version of this directly in Propel too (maybe ability
> to enable/disable the code would be nice too). I think it's a useful
> idea.
>
> Hans
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> For additional commands, e-mail: dev-help at propel dot tigris dot org
>
>

I'll check out the symfony code, though I know they're still at propel
1.2 and despite many user request can't seem to even get a beta or
unstable version with 1.3 running (afaik) so I'm not hoping for much.
You're right, it's very much AOP. I just know a whole lot more web
developers familiar with the concept of events (from javascript) than
AOP, so I choose to name it events. I'll definitely make an option to
completely disable the code.
Currently, I except that I'll start with completely refactoring the om
builder classes so that a function no longer add a complete function to
the om class, but instead multiple functions will do this (I'll check
out symfony first though and maybe they used a solution that I can
borrow). First function will open the function, second will add the body
and a third will close the function. Are the test units for the om
classes complete? Does performing the test just involve building the
bookstore project and running the tests?

Ron

Re: [propel-dev] Propel event handler

Reply

Author hlellelid
Full name Hans Lellelid
Date 2007-11-15 15:28:03 PST
Message Hi Ron,

<snip>
> Both table foo and bar have the saver handler for the onCreate and
> onSave event. I intent to implement the event / handler structure using
> the observer pattern, Propel objects being Observables and event
> handlers being Observers. The saver handler (observer) would be an
> example where the onCreate event registers the propel object with the
> handler and the onSave triggers save on all registered objects. This way
> you can save multiple objects with a single save() call, potentially
> this means you could tweak things so that you would add or update many
> objects in a single sql query.
> I know many of the things this will make possible are already possible
> by overriding functions in the propel classes. I do believe however,
> that this mechanism would prove to be very flexible and easier to
> maintain than implementations in propel classes (I still have a whole
> lot of classes where I need to change save(PDO $con = nul) to
> save(PropelPDO $con = null)).
> I'll be starting to build this shortly, anyone having suggestions,
> improvements, seeing upfront bottlenecks, just let me know and if I
> think it makes sense I'll try to do something useful with it ;)
>

Yeah, I think this is what Symfony is doing w/ Propel. I believe they
have extended the builder classes to wrap the various methods to fire
pre/post events. They call this "mixins" (I guess it's a bit AOP like).
  You may wish to start from their implementation. I'm open to us
including a version of this directly in Propel too (maybe ability to
enable/disable the code would be nice too). I think it's a useful idea.

Hans

Propel event handler

Reply

Author Ron Rademaker <r dot rademaker at virtualbuilding dot nl>
Full name Ron Rademaker <r dot rademaker at virtualbuilding dot nl>
Date 2007-11-15 02:45:32 PST
Message Hi all,

Last week I told you about my idea to create a backup function in propel
based on sql triggers. I've been working on this a bit this week only to
find out sql triggers and procedures have some very annoying properties.
This would result in having to redefine all triggers whenever you change
your schema, and often no errors if you forget to do this (and I *know*
I would something forget it and I would be *very* surprised if the other
developers here wouldn't). I don't think this is a good idea so I've
come up with a different, much more flexible, database independent
solution. The only drawback I see is that performance would be better if
the backup functionality was implemented in sql.

The basic idea is that you can add event to tables and columns (and
databases, though I haven't though of a useful example for that yet). An
example schema (I think the first event is obvious, I'll explain the
second later) could be:

<table name='foo'>
    <column name='id' primaryKey='true' type='INTEGER'
autoIncrement='true'/>
    <column name='date' type='TIMESTAMP'/>
    <column name='bar' type='VARCHAR'/>
    <event occasion='onChange'> <!-- this is now defined on the table,
but could also be defined on the bar column -->
       <handler name='setcolumn'>
          <parameter name='column' value='date'/>
          <parameter name='value' type='phpfunction'>
             <function name='date'>
                 <parameter value='"now"'/>
             </function>
          </parameter>
       </handler>
    </event>
    <event occasion='onCreate'>
       <handler name='saver' function='registerSave'/>
    </event>
    <event occasion='onSave'>
       <handler name='saver' function='triggerSave'/>
    </event>
</table>
<table name='bar'>
    <column name='id' primaryKey='true' type='INTEGER'
autoIncrement='true'/>
    <column name='bar' type='VARCHAR'/>
    <event occasion='onCreate'>
       <handler name='saver' function='registerSave'/>
    </event>
    <event occasion='onSave'>
       <handler name='saver' function='triggerSave'/>
    </event>
</table>

Both table foo and bar have the saver handler for the onCreate and
onSave event. I intent to implement the event / handler structure using
the observer pattern, Propel objects being Observables and event
handlers being Observers. The saver handler (observer) would be an
example where the onCreate event registers the propel object with the
handler and the onSave triggers save on all registered objects. This way
you can save multiple objects with a single save() call, potentially
this means you could tweak things so that you would add or update many
objects in a single sql query.
I know many of the things this will make possible are already possible
by overriding functions in the propel classes. I do believe however,
that this mechanism would prove to be very flexible and easier to
maintain than implementations in propel classes (I still have a whole
lot of classes where I need to change save(PDO $con = nul) to
save(PropelPDO $con = null)).
I'll be starting to build this shortly, anyone having suggestions,
improvements, seeing upfront bottlenecks, just let me know and if I
think it makes sense I'll try to do something useful with it ;)

Ron
Messages per page: