Ted Husted wrote:
>On Wed, 15 Dec 2004 17:22:15 +0000, Pilgrim, Peter wrote:
>
>
>> I was thinking in truth, only providing access to the ``catalog''
>> and ``command'' not necessarily changing the execution model. But
>> if that is the case, could a Struts ``Action'' as it appears in
>> 1.2.6 actually be a commons chain `Command' type? If it is, then,
>> it opens the doors for the ``chaining action'' conundrum all again.
>>
>>
>>
>
>It's my own feeling that there should be a clean break between the presentation layer
(Struts) that collects and display values, and the business logic layer (e.g. Chain) that
should do everything else.
>
>I started a new project this week based on Context, Command, and (as of five minutes ago)
Spring. The paradigm is that the presentation layer collects whatever values are needed and
puts them into a Context. A controller component executes the associated Command (or Chain)
and returns the outcome in the Context. Both the Context and Command are extended so that
they can handle all the business processing: Input and Output Validation, Execution, Error
and Exception Handling, and Message Resolution.
>
>For input, the Context has convenience properties for Locale, User, Role, and for output,
there are properties for Output, Errors, Messages, and Fault (Exception). I expect there to
be more, but I'm only adding what I need when I need it.
>
>When the Context returns, it can be examined by the presentation layer, which can then
display the output, messages, or errors.
>
>
>
This is great Ted. What it means is that each individual backend
software component catalog can determine finer grain of authorization
and the amount of supplied information. The web layer will take care of
the first pass and assemble the supplied fragments. Please let all the
mortals know when it is available.
Thanks
BaTien
DBGROUPS
>It's all in C# now, since I'm working in .NET, but I'd like to port it back to Java 1.5
and maybe PHP 5.
>
>-Ted.
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>For additional commands, e-mail: dev-help@struts.apache.org
>
>
>.
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
|