Re: [Actionframework-users] using invoke

[Craig L. <cr...@be...>]

On Fri, 2002-08-09 at 14:50, Petr Toman wrote:
> The reason why <template>'s <output-variable>s are placed before
> <invoke> is that you can nest another set of <output-variables>s inside
> <invoke> (and override values or whatever):
>=20
> <template name=3D"/displayObject.vm">
>      <invoke component=3D"session"
>              method=3D"storeSession(Context context, Object $typeID)">
>        <output-variable name=3D"objectList" component=3D"objectManager"
>                         value=3D"getDefaultList($typeID)"/>
>      <invoke>
>     </template>
>=20
> In addition, <invoke> behaves almost exactly as <action> and may also
> retrieve values from request (or set them by <input-variable>). Does
> this satisfy your requirements?

it does technically satisfy what i wanted, yes.  however, it doesn't
'sit' right with me.  the output-variable and the invoke elements are
not related in any way, shape or form, so it didn't make sense to me to
nest it like that.  if the output-variable depended on something the
invoke set up, then i guess it does.  now, i understand that technically
its not relevant, the stuff done by output-variable in the above case
would still be available to the template when it finally runs, but it
just seems to me that it is a more semantically correct to be able to
put the invoke by itself before the output-variable, if the two are not
related or dependent on each other.  too picky?

for my money, i think its cleaner to simply have no order requirement
for invoke/output-variable elements.


now, on to a bit of a possible bug.  i've actually gone ahead and done
some test coding to allow invoke elements before and after the
output-variable elements in a template (and processed in that order),
and part of what i was doing i initially tried to use input-variable
elements to set some variables from the request, but it seemed to me
that they were never actually executed.  i saw this:

when a _template_ has a 'subaction' (invoke for eg), the ActionServlet
calls the static Action.handleTemplate() method, which simply calls the
invoke() method directly on the subaction, which does no input-variable
processing at all (afaict).  when a normal action is processed, via the
Action.reinvoke() method (which is, in turn, called by Action.invoke()
), it use the Action.invokeSubAction() method, which clearly does handle
the input variables.

everything seems to allow the input-variable element inside an invoke
element, the tutorial even uses it.  but my basic testing didn't work,
and if i look closely at the tutorial, although i suspect there was a
loophole in the tutorial example (the on-return and the input-variable
both named the variable 'result').

i'm not convinced that i didn't have something else wrong that was
causing problems, but i did notice this while going through the code and
would appreciate some one explaining where i'm wrong, or not.  once i
get my other testing doen, i'm going to explore this more closely also
and maybe i'll notice what i'm missing.

cheers,

--=20

     CraigL->Thx();
     Be Developer ID: 5852