On 9/22/05, Michael Oliver <[EMAIL PROTECTED]> wrote:
> If you are going to compose an application
> from components, then the components are more closely aligned with the
> business objects they encapsulate. A "Customer" component then may be
> composed into any number of Applications from Accounts Payable to CRM. Such
> a "Component" would have its own UI for CRUD operations, and a Web Services
> Interface for data and method access, and it would likely have its own data
> persistence or utilize framework or container managed persistence.
In our application, now that we are collecting coherent segments of
ASPX code into controls, that's what exactly what is happening. The
architecture is chain-based and service-orientated. We aren't using
business objects per se, but there are a number of business entities
present in the model (database schema).
The command and query files for Chain and iBATIS are grouped by
business entity. The iBATIS datamaps acts like a "code-behind" for the
Commands. For every coherent set of command, we end up with a
companion datamap configuration.
The ASPX page flows tend to follow entity lines as well, which became
even more apparent when we started "normalizing" the UI into controls.
Now we have a components like a FacilityFinder, FacilityLister,
FacilityViewer, and FacilityEdtior, each of which is encapsulated as a
tag (or component) with it's own markup and code-behind.
The neat part is that its easy to reuse these components when use
cases cross entity lines. If we need to list or edit facilities as
part of a larger case, we can plop the appropriate tag on the page,
turning it on and off as needed. The ASPX page then starts to act like
a controller. Instead of presenting content, it manages a set of
components from its own code-behind. Right now, most of our pages look
like this:
<%@ Page language="c#" Codebehind="Events.aspx.cs"
AutoEventWireup="false" Inherits="WQD.Web.Forms.Events" %>
<%@ Register TagPrefix="spring" Namespace="Spring.Web.UI.Controls"
Assembly="Spring.Web" %>
<%@ Register TagPrefix="wqd" TagName="Lister"
Src="../Controls/StepLister.ascx" %>
<%@ Register TagPrefix="wqd" TagName="Finder"
Src="../Controls/StepFinder.ascx" %>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" >
<HTML>
<body>
<spring:Content contentPlaceholderId="cphMain" id="cphMainContent"
runat="server">
<wqd:Lister id="lister" runat="server"></wqd:Lister>
<wqd:Finder id="finder" Runat="server"></wqd:Finder>
</spring:Content>
</body>
(The content tags are part of the Spring templating system, which is
not unlike Tiles.)
This page presents a finder control and a lister control. The finder
control collects search criteria. The code-behind hands the critieria
it collects to the lister using a method like this:
protected void finder_Click(object sender, EventArgs e)
{
AppArgs a = e as AppArgs;
lister.Open(a.Criteria); // A Criteria is a Map
lister.Visible = true;
Template_Load(App.msg_EVENTS_HEADING,
App.msg_EVENTS_LIST_PROMPT);
}
After browsing the list, the client might select an item
protected void lister_Click(object sender, EventArgs e)
{
AppArgs a = e as AppArgs;
Key = a.facility_issue_key;
SetResult(App.RESULT_STEP_LIST);
}
SetResult is a Spring.Web base method. It fires a redirect or forward
to another page. We coded the result so that the Key property is
included. The reference is kept in a configuration file.
This ResultSet elements tells Spring.Web to redirect to the
Search.aspx page and append the query string "op=Issues&q=${Key}",
where Key is a property on the calling page. (Obviously, the value of
Key replaces the variable notation.)
<object id="StepList" type="Spring.Web.Support.Result, Spring.Web">
<property name="TargetPage"><value>Search.aspx</value></property>
<property name="Mode"><value>Redirect</value></property>
<property name="Parameters">
<dictionary>
<entry
key="op"><value>Issues</value></entry>
<entry
key="q"><value>${Key}</value></entry>
</dictionary>
</property>
</object>
Of course, if you're careful, it's not hard to write these "lister"
and "finder" controls so that they can be plunked down on some other
page. Which is exactly what we do. Instead of bouncing around from
page to page, we use pages to represent Use Cases and incorporate
whatever controls are needed by the case.
While this code is ASPX, JSF uses the same paradigm, and I expect the
architectural elements apply.
-- HTH, Ted.
http://www.husted.com/poe/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
