On 5/17/05, Sean Schofield <[EMAIL PROTECTED]> wrote: > From the javadoc and dialog-config.xml it appears that a transition > can result in either an action or a view. Actions seem to be for > performing a method call on a ViewController. In theory they can be > "chained" to one or more additional actions but ultimately they end up > in a view. Are these assumptions correct?
Yes, but there's also a "subdialog" state that can execute a complete other dialog as a black box subroutine. Action methods *can* be on a ViewController, but they do not *have* to be. I would tend to segregate pure business actions into separate classes (configured as managed beans): * Easier to write unit tests (it's all about model tier stuff, not view tier) * Managed bean configuration can do dependency injection to configure resources required by the business logic. An example of this is how the logon dialog manages its "save the profile to the database" logic, in a separate business logic class -- which is injected with an appropriate DAO. > > Also I am curious about the decision of when to use an action vs. an > action plus view. My thinking is that an action would be most > appropriate when you have logic that needs to be executed that affects > the ultimate view that you would end up at. That's a pretty good way to think about it, although there's more than one likely pattern people gravitate to. If you were to use dialog management with pure JSF (i.e. without the rest of Shale), you would likely have *two* actions in between view states -- one to finish up the previous transaction, and one to set up the next one. (This is where Struts 1.x developers keep wanting to chain actions). You can use the transition management capabilities to accomplish the branching in the navigation flow, while a setup action would typically only transition to the corresponding view. On the other hand, if you are using view controllers, the prerender() method can often take the second action (the setup one). This makes the state diagram describing your dialog simpler, and lets you (if you like) co-locate the setup, view, and processing logic related to a particular page into a single class. > So this would be simliar > to when you have a Struts Action that would decide which ActionForward > to use based on some logic. If the only logic you need is to > prepopulate a bean so it can be used by the view, then you can rely on > ViewController and just have your transition point directly to a view. > Also its possible that you would have a view that didn't require any > of the shale lifecycle stuff so you wouldn't specify a view > controller. > > Do I have that right? > Yep -- that's exactly it. > TIA, > sean > Craig > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
