Lambda the Ultimate

inactiveTopic Object-oriented markup
started 5/1/2002; 2:43:56 PM - last post 5/5/2002; 2:35:12 PM
Michael St. Hippolyte - Object-oriented markup  blueArrow
5/1/2002; 2:43:56 PM (reads: 967, responses: 6)
I'm curious if a language approach I've been researching has any precedents.

As an object-oriented-oriented programmer with a small but growing number of web sites to maintain, I have often found myself facing a messy HTML job that would have been a lot easier if HTML had inheritance and other OO features. For example, instead of cutting and pasting snippets of HTML from file to file, I could put them into classes and then just instance them when I needed them. I could take everything that shows up on every page and put it into a base page, which I could then subclass for the detail pages. I could segregate the browser-specific code into pluggable modules. The list goes on.

A few months ago I started thinking about what precisely an object-oriented markup language might look like. Once I shed a sufficient number of preconceptions, some rather simple ideas emerged, and before long I had a grammar. After a little programming and playing I've concluded that the concept is feasible, and maybe even useful, and for more than just simplifying HTML coding. The markup-with-embedded-scripting paradigm that dominates dynamic content languages and frameworks (JSP, ASP, PHP, ColdFusion, Velocity, WebMacro etc.) is not without drawbacks, and for some things at least object-oriented markup may be a better approach.

Surely this is not a new idea. I'm unaware of any concrete examples, however, other than my own fledgling language. If there are any, I suspect they are known to the participants in this forum.

I should emphasize that I am not talking about a declarative format for an object-oriented language, e.g. XML serialization of Java objects. I am talking about a declarative language which itself follows OO principles.

My own language is rather haphazardly described at -- I would be enormously grateful for any questions, suggestions or criticisms anyone may have to offer.

andrew cooke - Re: Object-oriented markup  blueArrow
5/3/2002; 8:55:20 AM (reads: 1006, responses: 0)
Why didn't Sun do this? When they went from Servlets (which do what you want, but aren't declarative) to JSP (which is declarative), they didn't rpovide (as far as I know - am I wrong?) any way for for one JSP page to extend another. What stopped them?

Michael St. Hippolyte - Re: Object-oriented markup  blueArrow
5/3/2002; 10:43:34 AM (reads: 1010, responses: 0)
Big companies seldom innovate any more than they have to. JSP was Sun's answer to ASP, and being able to use Java as the embedded scripting language was as much innovation as they needed. It wasn't until after JSP was out for a while and a number of big sites were actually built in JSP that the ugly reality became clear: jsp files are harder to maintain than either html or java! You need two distinct skill sets, HTML and Java, which usually means two people, and even small changes can require a lot of coordination and project management. Bugs pop up more easily (a small change in the HTML can throw a monky wrench in the Java and vice versa) and are harder to track down. Many HTML and Java tools are useless for working on JSP pages.

Now that these drawbacks are evident, Sun really should do something. But I don't think they will, because "nobody else" (MS, IBM, etc.) is either. They're all mesmerized by web services and see the old fashioned human web as a low-end commodity business not worth investing in.

So it's left to independent efforts like Velocity and Tapestry (and Bento, if I can get it off the ground) to further the art of web development.

Brent Fulgham - Re: Object-oriented markup  blueArrow
5/3/2002; 1:19:57 PM (reads: 998, responses: 0)
This looks pretty cool -- I'd love to see the prototype.

Only question, why did you choose to make your "Hello, World" program look like this?

" Not Found (404) Original request: /hello.html

Not found request: /hello.html "

I'm more used to just seeing "Hello, World".... ;-)

Michael St. Hippolyte - Re: Object-oriented markup  blueArrow
5/3/2002; 1:32:45 PM (reads: 999, responses: 0)
Maybe you're right, I should stick to tradition. Try it again :)

Keith Devens - Re: Object-oriented markup  blueArrow
5/3/2002; 8:12:18 PM (reads: 967, responses: 1)
Mason ( works exactly the way you describe, from what I remember. Might be worth checking out. Warning: it's Perl.

Michael St. Hippolyte - Re: Object-oriented markup  blueArrow
5/5/2002; 2:35:12 PM (reads: 924, responses: 0)
Thanks for the link.

Mason shares the same goals as Bento, but there are some notable differences in the two approaches. The most obvious is that it isn't actually object-oriented in the most accepted sense as I understand the term. It has some OO-like features, but does not really have a concept of a classes and subclasses. It has a hierarchy of autohandlers instead of a class hierarchy. For me this is a significant difference, because I'm an OO programmer and my development techniques and habits of thinking depend on deep OO.

More subtle, but just as significant, Mason doesn't quite break with the embedded script model. You still write procedural language code (in perl in this case) which is embedded in html. Mason does take some big steps, but it doesn't take the conceptual leap to the next paradigm. For example, Mason implements components and containment, i.e. constructing pages out of separately defined chunks, a very powerful capability resulting in much greater developer productivity. But you have to write a fair bit of perl code to get this advantage. The idea of object-oriented markup is to achieve the same capability by declarative rather than procedural programming. The end result may be the same but the way you get there is different.

I don't think that declarative programming is intrinsically better than procedural programming (it would be silly if I did, being a procedural programmer myself), but it may have some advantages in the case of defining web pages because of the nature of the web.