On 9/2/05, Don Brown <[EMAIL PROTECTED]> wrote: > Ted Husted wrote: > > Well, in the spirit of discussion ... > > > > An important consideration is where to put the composition. We haven't > > figured out how to use the Spring.Web wizards yet, so for our .NET > > apps we've been decomposing the "pages" or "dialogs" into User > > Controls. The actual ASPX page then becomes a list of controls that > > the workflow might use. > > That's a very interesting approach, so in effect, your page behind becomes > your > "Controller" containing multiple page actions. I wonder how/if that would > translate to JSF. Reminds me of the folks that are doing pure client-side, > one > url apps, using javascript to handle page navigation.
Yes. I expect that the approach would port, given the similarities between the platforms. Many other .NET applications do the same sort of thing, but typically use a "placeholder" control in the page to swap other controls in and out. Swapping seems to work well enough, but code-behind logic can get hoary, especiallly when people try to use one page to serve the entire application. The placeholder approach also makes the application harder to "discover" for someone just wandering through the code. Under the container page approach, you can look at the page and see what User Controls are involved. It's also very easy to pass values, since the components are all live. We just have to be careful to not let the list components save large lists, which encumbers the page state. When we do need to jump between pages, Spring.WEB has a very nice "ActionForward" like component. * http://opensource2.atlassian.com/confluence/spring/display/NET/Result+mapping For the business logic, we inject a "ViewHellper" into the page that encapsulates the Context and Command into a single facade. Typical calls look like public void Open() { if (IsPostBack) return; IViewHelper helper = ExecuteBind(App.ROUTING_FIND); if (!helper.IsNominal()) Page_Error = helper; } Line 2 executes the command named "routing_find", and then binds the result values to the UI controls. Line 3 asks the helper if all went well, and if not, hands the helper to the Page_Error property. This "property" actually fires an event handler, which passes the helper to to the containing page, which displays the message. Any manner of error could be displayed here, including system errors coming back from the database. ---- private void find_Click(object sender, EventArgs e) { if (Click == null) return; IViewHelper helper = Read(App.ROUTING_FIND); if (helper.IsNominal()) Click(this, new ViewArgs(helper)); } Here, line 2 reads values input by the user. If all goes well, line 3 throws a Click event to be caught by the containing page. ---- protected IViewHelper save_Changes() { IViewHelper helper = ReadExecute(App.FACILITY_SAVE); if (helper.IsNominal()) Page_Reset(); else Page_Error = helper; return helper; } Line 1 reads values input by the user, and then executes the "facility_save" command. Depending on whether everything worked, the second statement either resets the UI controls, or displays any messages. The helper is returned to the caller, in case further processing is needed. ---- In case anyone is interested, I posted a copy of our internal User Control RFC here: * http://husted.wush.net/docs/display/NEO/RFC+-+User+Controls -Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
