Erik Hatcher wrote:

Yes, it should be. Do you have the form name listed on that action? Let's see your action mappings for the prepare and edit actions.
      <action path="/admin/role/EditFormPrepare"

type="net.covalent.spider.ui.action.portlet.admin.role.EditFormPrepareAction">
      </action>

      <action path="/admin/role/Edit"

type="net.covalent.spider.ui.action.portlet.admin.role.EditAction"
              name="EditRoleForm"
              scope="request"
              input="/Home.do?id=104">
        <forward name="cancel" path="/Home.do?id=103" redirect="true"/>
        <forward name="reset" path="/Home.do?id=104"/>
        <forward name="failure" path="/Home.do?id=104"/>
        <forward name="success" path="/Home.do?id=103"/>
      </action>

The form bean itself is null... hmmm??? strange - only if you've not specified it on the action mapping is my guess.
aha! looking at this mapping clears up at least part of the mystery...

the input path is "/Home.do?id=104". HomeAction actually forwards to a jsp with a bunch of tiles in it. Edit.jsp is one of those tiles, and its controlling action is EditFormPrepareAction.

this means that when EditForm fails validation, i have this forward chain:

EditForm --> HomeAction ---> Home.jsp ---> (tiles controller mechanism invokes EditFormPrepareAction) ---> Edit.jsp.

all of these forwards execute in the context of the same RequestProcessor tho, right? so presumably the EditForm instance gets passed all the way down the forward chain through the tiles controller invocation mechanism to EditFormPrepareAction?

is this an instance of "evil action chaining"? if so, what actually is the evil?

Oh, there are always around things! :) Putting things in request or session scope work, depending on whether you are doing a redirect. Or the evil action chaining keeping things available for you in a later action. And I'm sure some other tricks too.
yeah, there's no "cleaner" way that i can think of. my team is especially wary of using the session scope for managing page flow, so rewriting the forward path in the action is the least offensive hack :)




--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to