On 9/1/05, Joe Germuska <[EMAIL PROTECTED]> wrote:
> but that XML is not a very nice way to define everything that needs
> to happen, and object-level composition is also likely to be awkward
> for some of these kinds of things.
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.
<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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
