callback vs inline methods
Hi,
I am having trouble understanding the differences between callback and inline methods. For example when dealing with filters, the destroy();
method is always container callback method, but the doFilter();
can be both. Now there might be other examples outside the J2EE framework, I am not sure.
Is this up to the container to decide which method is callback or inline, or does the developer can specify that? - Not sure if this is a valid question
I would be grateful if someone could share an explanation together with a straightforward example (from J2SE or J2EE or anywhere else)
Thank you in advance
[652 byte] By [
DeChristoa] at [2007-11-27 10:36:19]
Callback vs. inline isn't that formally specified. Even callbacks are called "inline", just not inline by your code.
A callback method is simply a method that some other piece calls on your object when some task is done or some event occurs.
jverda at 2007-7-28 18:40:33 >
> Callback vs. inline isn't that formally specified.
> Even callbacks are called "inline", just not inline
> by your code.
>
> A callback method is simply a method that some other
> piece calls on your object when some task is done or
> some event occurs.
Thanks jverd. So a method is "callback" when a third party calls it on my object? (could be the container then) Is it possible perhaps to be a bit more specific? Thanks again.
> > Callback vs. inline isn't that formally specified.
> > Even callbacks are called "inline", just not
> inline
> > by your code.
> >
> > A callback method is simply a method that some
> other
> > piece calls on your object when some task is done
> or
> > some event occurs.
>
> Thanks jverd. So a method is "callback" when a third
> party calls it on my object? (could be the container
> then) Is it possible perhaps to be a bit more
> specific? Thanks again.
Not necessarily third party. It could be some other piece of your code, or some part of the core API. It's just not typically called directly by the module that its part of, or by clients of that module.
As an example, all the event handling methods in ActionListeners are callbacks. You create the class and impelement the method, but you don't directly call it. You hand the class to Swing, and it calls your listeners' methods when something happens.
jverda at 2007-7-28 18:40:33 >
I see. So basically a callback is invoked indirectly when something acting as a trigger for it goes off, right?. (For example when the container instantiates a Filter) When the developer creates/overrides a method that is called in such a way then it is "callback"...
And I would assume the "inline" method always gets invoked at runtime because it is meant to be called right then and not wait for a trigger of some sort... that is my best explanation so far.
Thanks for the help jverd.
> I see. So basically a callback is invoked indirectly
> when something acting as a trigger for it goes off,
> right?.
I guess that's a reasonable explanation.
> When the developer creates/overrides a
> method that is called in such a way then it is
> "callback"...
Yup.
> And I would assume the "inline" method always gets
> invoked at runtime
Well, *any* method can only be invoked at runtime. But by "always gets invoked at runtime," if you mean it's guaranteed to be invoked, no, it's not. It might be inside an if condition that's never met, for instance.
> it is meant to be called
> right then and not wait for a trigger of some sort...
More or less, yes.
jverda at 2007-7-28 18:40:33 >
> Thanks for the help jverd.
You're quite welcome.
I'd be interested to say what others here have to say. There are several others who can usually state these things much more concisely and accurately than I.
jverda at 2007-7-28 18:40:33 >
