Michael Jouravlev wrote:
I am not convinced that UI should be *that* different from domain
model.
+1.
Example: You make a html mock up an go to contract, then do ren *.html
to *.jsp for prototype.
Beased on your approved prototype your most senior desigs a domain model!
Domain Model is m
On 7/18/05, Adam Hardy <[EMAIL PROTECTED]> wrote:
> Michael Jouravlev on 18/07/05 20:52, wrote:
> > I am not convinced that UI should be *that* different from domain
> > model. Do you have examples?
>
> I'm not sure that I can conjure up something convincing (being a techie
> myself!) because you
Michael Jouravlev on 18/07/05 20:52, wrote:
On 7/18/05, Adam Hardy <[EMAIL PROTECTED]> wrote:
While the business domain is normally modelled using OO techniques, the
view or user interface should be modelled using human behaviour analysis
techniques that produce the best interface for users to
Anyone in the mood to kick the dead horse again? I decided to compare
two approaches to use/update data from Struts. I am obviously biased
towards nested VO/BO, so maybe I left something out.
[I] Property copying
This one seems to be the default and "officially endorsed" Struts practice.
1) Crea
Adam Hardy wrote:
Not all users can think like geeks!
And the (probably more important!) corollary: Most geeks can't think
like users.
Dave
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EM
Having a VO/BO with string- & strong-property getters and setters is
IMHO a short cut through the UI / business domain interface.
While the business domain is normally modelled using OO techniques, the
view or user interface should be modelled using human behaviour analysis
techniques that pro
On 7/18/05, Adam Hardy <[EMAIL PROTECTED]> wrote:
> While the business domain is normally modelled using OO techniques, the
> view or user interface should be modelled using human behaviour analysis
> techniques that produce the best interface for users to get their work
> done efficiently, reflect
7 matches
Mail list logo
