There is a fundamental problem with talking about the "definition" of
words in other than a "lexical" sense. Words do not have definitions
like you find, for example, in biology but, rather, have meanings and
the meaning is, as Ludwig Wittgenstein loved to say, "the use".
People who look for and talk too much about "definitions" of terms
tend to have idiosyncratic and private senses of terms which leads to
confusion rather than to clarification, to heat rather than to light.
Words are neither swords nor shields in life and its battles, but are
a mysterious and wonderful public way to communicate within the
dimensions of our environments and understanding. Hence, there is not
a right or wrong way to talk about components, but there is the way
they are talked about and if you don't to do it that way, then no one
will understand you. I like the way Ted tackled this issue. The
issue never had anything to do with meanings, definitions or the word
"component". Thanks, Ted.
On 9/26/05, Ted Husted <[EMAIL PROTECTED]> wrote:
> 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]
>
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
