Purpose of startItem()?

[Seb Duggan]

Just out of interest, what exactly is the purpose of the startItem()
controller method?

Since it is always run immediately prior to the item() method, when
would you use one and not the other?

[Sean Corfield]

On Tue, Aug 17, 2010 at 9:18 AM, Seb Duggan <seb.d...@gmail.com> wrote:
> Just out of interest, what exactly is the purpose of the startItem()
> controller method?

The intended convention is either:

controller.startItem()
rc.data = service.item()
controller.endItem()

or:

controller.item() - and you call services yourself.

Given that implicit service calls are now being discouraged (and will
be disabled by default in 2.0), it may be time to revisit the
start/end convention and perhaps only execute that if implicit service
calls are not suppressed...?
--
Sean A Corfield -- (904) 302-SEAN
Railo Technologies, Inc. -- http://getrailo.com/
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

[Matt Jones]

I would like to throw in my opinion for keeping the enditem().

regardless of explicit or implicit service calls, if you used
service() to queue up services, enditem() can serve the purpose of
routing based off of the results from the service calls.

startitem() and item() could be merged, from my point of view, but i
personally like to use startitem() as the pre-service call method
whenever i do use the enditem(); and just plain item() when i do not
use enditem(). as such, my controllers end up with one of these
scenarios:

startitem() //this scenario I have some services getting queue up and
will need to react to them
enditem()

-or-

item() // this scenario my controller doesnt need to react to the
results of any service calls

-or-

enditem() // this scenario my controller is doing something with the
results of an implicit call or i guess possibly queued up by the
before()

[Sean Corfield]

On Fri, Aug 20, 2010 at 11:08 AM, Matt Jones <emj...@gmail.com> wrote:
> I would like to throw in my opinion for keeping the enditem().

Yup, after some reflection, the startItem() / item() / endItem()
convention will definitely be staying.

I wish there was a reliable way of figuring out which was active
(because it would kinda be nice to omit item() if startItem() and/or
endItem() were present) - but because of supporting onMissingMethod(),
that's not really possible (unless I enforce a convention in the
presence of onMissingMethod() I guess).