You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Tore Halset <ha...@pvv.ntnu.no> on 2008/02/07 11:23:40 UTC

newbie callback questions

Hello.

I just tried callbacks for the first time. I wanted to update a  
modified field every time a data object was changed. In the modeler I  
added a method called "onPreUpdate" of type pre-update for the entity.  
Then I added the following method in the data object.

	protected void onPreUpdate() {
		setModified(new Date());
	}

It seem to work very well. Is this the correct way to do it?

In my simple case it would have been even nicer if the _MyEntity.java  
included something like "protected abstract void onPreUpdate();"  
generated from the model. Default MyEntity.java should include an emty  
stub for that method.

Would that be a reasonable feature request? I am asking before  
registering as I am such a callback newbie.

In modeler, the difference between callbacks and listeners are a bit  
confusing. Anyone having some ideas to how this interface could be  
clearer/simpler?

Regards,
  - Tore.

Re: newbie callback questions

Posted by Andrus Adamchik <an...@objectstyle.org>.
Yeah, probably a good idea to add abstract callbacks to the cgen  
templates.


> Unfortunately there is no simple way to achieve the reverse:  
> disabling them in the model and forgetting to remove the code from  
> the application

I think there is, but the burden will be on the user to set it up  
properly. What I mean is @Override annotation in the subclass (which  
Eclipse generates automatically). If the super abstract method is  
removed, @Override will cause a compilation error in subclass.

Andrus




On Feb 7, 2008, at 3:10 PM, Aristedes Maniatis wrote:

>
> On 07/02/2008, at 9:23 PM, Tore Halset wrote:
>
>> In my simple case it would have been even nicer if the  
>> _MyEntity.java included something like "protected abstract void  
>> onPreUpdate();" generated from the model. Default MyEntity.java  
>> should include an emty stub for that method.
>>
>> Would that be a reasonable feature request? I am asking before  
>> registering as I am such a callback newbie.
>
> I think that is a nice idea. That would force the user to implement  
> those methods and not forget that they were switched on in the  
> model. Unfortunately there is no simple way to achieve the reverse:  
> disabling them in the model and forgetting to remove the code from  
> the application: unless we used a @Callback annotation to mark the  
> appropriate methods. Something like:
>
> @Documented
> @Inherited
> @Retention(RetentionPolicy.RUNTIME)
> public @interface CallBack { }
>
>
> I'm not 100% sure that would work out, but I thought I'd throw it in  
> there with your idea. I'm not sure how you'd then use this to give  
> some warning at compile time or runtime if the callback was not  
> enabled in the model.
>
> Ari
>
>
> -------------------------->
> ish
> http://www.ish.com.au
> Level 1, 30 Wilson Street Newtown 2042 Australia
> phone +61 2 9550 5001   fax +61 2 9550 4001
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A
>
>
>


Re: newbie callback questions

Posted by Aristedes Maniatis <ar...@ish.com.au>.
On 07/02/2008, at 9:23 PM, Tore Halset wrote:

> In my simple case it would have been even nicer if the  
> _MyEntity.java included something like "protected abstract void  
> onPreUpdate();" generated from the model. Default MyEntity.java  
> should include an emty stub for that method.
>
> Would that be a reasonable feature request? I am asking before  
> registering as I am such a callback newbie.

I think that is a nice idea. That would force the user to implement  
those methods and not forget that they were switched on in the model.  
Unfortunately there is no simple way to achieve the reverse: disabling  
them in the model and forgetting to remove the code from the  
application: unless we used a @Callback annotation to mark the  
appropriate methods. Something like:

@Documented
@Inherited
@Retention(RetentionPolicy.RUNTIME)
public @interface CallBack { }


I'm not 100% sure that would work out, but I thought I'd throw it in  
there with your idea. I'm not sure how you'd then use this to give  
some warning at compile time or runtime if the callback was not  
enabled in the model.

Ari


-------------------------->
ish
http://www.ish.com.au
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001   fax +61 2 9550 4001
GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A