struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Don Brown <>
Subject Re: Spring and XWork in Ti
Date Fri, 02 Sep 2005 16:45:22 GMT
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.


> <HTML>
> <body>
> <spring:Content contentPlaceholderId="cphMain" id="cphMainContent"
> runat="server">
> <wqd:RoutingMerger id="routing_merger" Runat="server"></wqd:RoutingMerger>
> <wqd:RoutingEditor id="routing_editor" Runat="server"
> OnQuit="routing_editor_Quit"
> OnSave="routing_editor_Save"></wqd:RoutingEditor>
> <wqd:FacilityEditor id="facility_editor" Runat="server"
> OnQuit="facility_editor_Quit"
> OnSave="facility_editor_Save"></wqd:FacilityEditor>
> <wqd:FacilityLister id="facility_lister" runat="server"
> OnAdd="facility_lister_Add"
> OnClick="facility_lister_Click"></wqd:FacilityLister>
> <wqd:FacilityFinder id="facility_finder" Runat="server"
> OnClick="facility_finder_Click"></wqd:FacilityFinder>
> </spring:Content>
> </body>
> </HTML>
> Running from the bottom, this particular page displays a "Facilty
> Finder". Once the user enters some search criteria, the result is
> displayed by the "Facility Lister". Here they can branch to a Facility
> Editor, to add or edit a Facility, or go on to the Routing Editor. The
> Routing Editor collects details for a "Routing Sliip", which can then
> be merged into Word document, if the user choose.
> All the business and presentation logic for each step is encapsulated
> in the individual controls. We then use the page's code-behind to
> shepard the navigation. The code-behind makes the controls visible or
> invisible as needed, reacts to the registered events, and passes
> values between controls as needed. Each control has properties to
> represent the input and output values. Since the controls are external
> to the page, we can reuse the controls in other workflows.
> Here's the handler that grabs the search criteria and passes it to the
> Facility Lister:
> 		protected void facility_finder_Click(object sender, EventArgs e)
> 		{
> 			ViewArgs v = e as ViewArgs;
> 			facility_lister.list_Criteria = v.Helper.Criteria;
> 			facility_lister.Open();
> 			facility_lister.Visible = true;
> 		}
> The nice part is that we can focus on one thing at a time. If there's
> an issue with a control, we can edit just the control. If there's an
> issue with the navigation, we can focus on that, without all the
> control code clutter.
> To run the actual business logic, each control can access the object
> catalog, which contains our command Helpers and other goodies. The
> code-behinds for the controls collect the appropriate values, invoke
> the business commands, and call an event handler when they are done.
> The icing on the cake is that we have figured out how to use the
> Spring.Web master pages. So we don't need to include any chrome on the
> workflow pages. Aside from registering the tags, all we need is what's
> above. All the headers, footers, and menu stuff is in other "Tiles.".
> -Ted.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message