On Apr 1, 2005 2:11 PM, Duong BaTien <[EMAIL PROTECTED]> wrote: > Hello Craig: > > Well, this is Friday so we can take it easy on the debate between Struts > and Jsf. This is about Struts-Shale, Jsf and Tiles. > > First, thank you for your contributions in CoR commons-chain and Shale. > I had some time to re-visit shale and have successfully implemented > shale as a servlet filter, its view controller with myfaces > JspTilesViewHandlerImpl, and DialogController. Some questions: > > 1) The logon Dialog demonstrates an implementation of DialogController > using hard-coded methods as entry points. Is there any thought of a > generic Dialog bean whose actions and processes are assembled on-demand > via CoR/IoC?
What would the method binding expression look like in this case? Today, the last component of this expression is the name of the method to be called, and you'd either have to maintain that or provide some sort of custom method binding expression evaluator that did something like creating a context and then firing off a chain. It might just be simpler to compose a Context object, and fire off the appropriate chain, yourself inside the event handling methods. With a suitable helper function, each event handling method could be a simple one liner. On a parallel note, I'm quite intrigued by the Web Flow project in Swing's sandbox, and am trying to carve out enough time to integrate it into Shale. It is much more fleshed out than DialogController, and includes nice concepts like nested subflows. > > 2) Association between view id and viewController is quite handy. I am > able to associate each view id, assembled from complex tiles fragments, > with a specialized viewController that pull part of the data from a > dialogController. All tiles fragment use Jsf <f:subview>. Now moving to > the shale <s:subview>, is it intended to replace jsf <f:subview> if more > than 1 fragments requires viewController? I have not tested this case > with myfaces tile viewHandler. I think i should wait for shale custom > ViewHandler that works with tiles. Yes, the intent is that <s:subview> would replace <f:subview> in order to provide the lifecycle event calls for every fragment's ViewController bean. If/when David gets done on extracting Tiles out of Struts, and integrating it with Shale, we'll likely want a component that does a combination of what <s:subview> and <tiles:insert> do, so the developer won't have to use both. The last time I tried (pre-1.0.9 though) the entire Shale use cases example worked correctly with MyFaces as well as with the JSF RI. In particular, there's a portion of the unit tests that verifies the event calls occur in the correct order. > > 3) If <s:subview> is intended to replace <f:subview> to work with tiles, > can it be done in such a way that each request needs to instantiate only > 2 request-scope viewControllers for 2 fragments (portlet menu and its > display fragments depending on which portlet user clicks)? I suppose you could do that by specifying two subviews in the "outer" page prepared by the portal server; but I want the ability to use subviews *inside* a single portlet as well -- hence the desire to support an arbitrary number of initialized ViewControllers per request. > > BaTien > DBGROUPS > Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
