Re: Multi Valued Interface Models?
Date: Tue, 14 Feb 2006 11:03:13 +0200
Message-ID: <dss6cj$n40$1_at_nntp.aioe.org>
"dawn" <dawnwolthuis_at_gmail.com> wrote in message
news:1139881994.518885.274830_at_z14g2000cwz.googlegroups.com...
> x wrote:
> > "dawn" <dawnwolthuis_at_gmail.com> wrote in message
> > news:1139598896.676278.14030_at_g44g2000cwa.googlegroups.com...
> > You have not given the specifications for the interface in a way that
not
> > assume a particular solution.
> This was not a model of the database or any other intermediate software
> components between the UI and the DB. It is strictly a class diagram
> for the UI (an interface) itself. From a screen prototype (web page
> prototype), you can draft a UML class diagram such as this. It is NOT
> a class diagram for persisting anything, but for the interface with the
> user.
It is a class diagram (have you noticed the word class ?) for the Model
part.
It is not the UI.
> I definitely did not model an entire system, if that is what you mean.
> I prepared exactly one component of an application model -- a class
> diagram for the user interface (not for the persistence of data
> collected or presented via that interface, for example).
Your class diagram is an example of how one should not design a class.
> > > > You talk about data copying.
> >
> > > ?
> > You said "same model could be implemented in xml, for example, for data
> > exchange".
> > How is xml better at data exchange rather than at data copying (data
> > transfer) ?
> It matters not. I used XML as one example of how one might do data
> exchange. My point was that you don't have to change the model for the
> data, even if the format. The same UML works for the xml as well as
> the web page.
Too many tentatives and not one good example.
> > > > > > HTML/XML/HTTP is a poor low level complex way to describe an
> > interface.
> > > >
> > > > > I thought of it as a high level way. I wasn't intending to bring
HTTP
> > > > > into the picture, only to take an example of an arbitrary UI.
Without
> > > > > loss of generalization...
> >
> > > > If they were high level tools you would have found them easy to use.
> >
> > > So Dreamweaver and GoLive are high level tools and HTML is a low level
> > > tool? OK. I use GoLive and only bring up the source code panel and
> > > code raw xhtml. So, perhaps mid-level for the html and xml.
> >
> > Then GoLive is not good enough if you have to go to raw xhtml.
> It does a few things for me so that it is worth using, but perhaps I'm
> just old fashioned and prefer to code myself rather than have generated
> code in this case.
Do you prefer to work in assembly language instead of in a high level language ?
> > I would not call xhtml source code because it is not the source but the
> > target.
> And the source looks like...?
That is the question isn't it ?
> > You have not given the specification for the UI.
> Only a class diagram of the precise interface (user interface).
One flower does not a spring make.
> > Have you heard of Model-View-Controller UI paradigm ?
> Oh, you betcha.
>
> > RM could be used for the "Model" part for example.
> Yes! Yes! Yes! The RM could be used as the data model for the Model
> and could not be used as the data model for the View. That is my
> point.
"The view is the piece that manages the visual display of the state represented by the model. A model can have more than one view. " "The view is responsible for mapping graphics onto a device. A view typically has a one to one correspondence with a display surface and knows how to render to it. A view attaches to a model and renders its contents to the display surface"
"The controller is the piece that manages user interaction with the model."
> > I think the screen layout can also be described by RM.
> I don't. There might be extensions to SQL that ignore the RM that
Are you sure you are not making a confusion here ?
> would permit this, but if you use a SQL-92 standard, for example, you
> can see that there is no way to specify this precise UI with that
> language. You need to be able to specify a view that is not in 1NF,
> for example.
The View in Model-View-Controller has nothing to do with the View as in
"Relational View of Data" or the View in "SQL View".
> > > I would like a <foodItem> with <toppingList> on it.
> >
> > How would this exclude the RM ?
>
> that little ordered list guy at the end -- toppingList -- would not be
> how you would model this with the RM. You would have multiple
> predicates (relations), adding in an ordering attribute and a new table
> for the toppingList. So you would not model the proposition above with
> a single predicate like this using the RM.
So what if I would use multiple predicates ?
Buying a pizza is not the same as buying a pizza made according to the
client recipe.
A recipe would require multiple predicates.
> > What is atomic data by your definition ?
> I don't need it for my purposes. There is no data value that could not
> have functions defined on it that would extract a portion of it other
> than a bit. But you could define it in terms of the functions that are
> currently defined on a type. A scalar or atomic value could then be an
> element of the type/domain set where no existing operations/functions
> on that domain partition the value of the element into multiple
> disjoint values (or something like that -- I'm making it up on the fly
> when I'm sure there are better definitions existing).
The difference between atomic data and non atomic data is like the difference between the pizza and the ingredients + the recipe :-)
> > The fact that RM is badly understood and implemented is recognized by
many.
> > Codd said this many times.
> That is why I tried to dig in and actually define it, starting where
> Codd started.
In his 1990 book he stated 333 rules for a relational implementation.
> > Would you want RM to handle screen painting and mouse input ?
> No. But I'm saying that it is a limited data model. It can be used to
> model the interface between a client and a database service, but not an
> arbitrary interface between a person and software.
Right. Just the Model part.
> > I was asking if there is data that can be represented by the data model
of
> > the UI that cannot be represented by the data model of an SQL database.
> Change the word "by" to "as" and then yes.
The model of the Model part of the UI cannot be the model of an SQL
database ?
> > > Once you hide it, however, you
You skipped this.
Why ? I know SQL is bad, but you are not disputing this.
> > > are no longer using it as the model for the interface.
> >
> > Who said anything about hidding it ? Not me.
> > But if I would be willing to try
> > hard enough, maybe I could come up with a language based on the RM for
> > writing code also not just for describing data. Then the applications
would
> > become easier to maintain :-)
> I think this is something like what mountain man is suggesting by using
> stored procedures. You still cannot model the UI with the RM, however.
Why ? Received on Tue Feb 14 2006 - 10:03:13 CET