Lists Home |
Date Index |
On Monday, October 21, 2002, at 11:36 AM, m batsis wrote:
> email@example.com wrote:
>> No, none of these are enough (well, maybe java, only the current
>> implementations aren't up to it). These only specify *appearances*
>> not behavior. We want to get behavior into the UI layer. No more
>> elaborate syntax is going to solve this problem.
> Java certainly does include behavior although seperation of conserns
> is another subject. You may be interested in UIML  on that.
I did mention Java might be an exception - but the implementations have
been really lacking in performance. Honestly, when was the last time
you saw a really useful (cr)applet? Plus, Java is a good example of
how not to do an OO language.
I looked at UIML and it looks like a bad joke to me. I can't remember
when I've seen something less readable and more complicated that did so
little. So much noise for so little signal.
Your later comment about hammers is particularly applicable. ML's are
really poor mechanisms for describing behavior. They're sort of poor
mechanisms for describing relationships (they impose a sort of
directional view via the element nesting that is artificial - is artist
inside of CD or is CD inside of artist - depends). They're not bad for
describing elements in streams. Sadly, the "well formedness"
requirements in XML makes them not particularly good for general
"markup" as well. Markup (think red pen) is more free form than that.
> But XUL and company is by far the most well designed framework I have
> some experience with. XBL  contains the behavior and provides
> almost unlimited extensibility in a flexible approach.
You ought to spend some time doing WebObjects development. Because
XBL also looks like a mishmash of Java and XML and is overly verbose
and unreadable. I'm not too impressed.
> > The problem as I see it is that
>> XML is a retrograde development in computer science and application
> Hammers are the best in what they do. Similarly, XML offers new
> possibilities in exchanging and using datastructures, provides for
> interoperability and many more. But this surely belongs to other
Are we talking about application delivery over the web or not? Because
you have to question the underlying assumptions and examine the
evolutionary path that lead us to this location. Failing to consider
that is to blindly accept that things are correct because thats the way
>> In the early software days the emphasis was on behavior (C, Fortran,
>> Pascal, procedures, functions) and data was secondary. Presently the
>> emphasis appears to be data formats (and serial ones at that).
> I enjoy clever data formats that allow reusable behavior code.
I do too. Sadly, we've stripped the behavior off of the data now. Its
still inanimate - whether its xml or result sets, the data is still
passive. I don't see this as progress.
>> Somewhere in between was a balanced approach that bound behavior with
>> data into entities we called "objects". It is my opinion that
>> browsers need to move from glorified page layout engines with ugly
>> scripting languages towards full blown distributed object engines
>> that happen to have rich page layout capabilities.
> The problem is this sounds generic enough for one to say it's alrady
> done ;-)
Examples? I don't see one. If I did, I'd use it for developing the
latest web based house of cards my client wants.