WebAppConstruction

MeatballWiki | RecentChanges | Random Page | Indices | Categories

I created this topic to see if there were others interested in discussing techniques for constructing dynamic web applications, particular techniques that challenge common assumptions in the established ones like Perl, JSP, Velocity and so forth.

To get the ball rolling, see "The Problem: Misusing Dynamic Binding when Static Binding would do" in the left margin of http://virtualschool.edu/wap and flame away. --BradCox

I am interested in following this discussion. From your article in Dr Dobbs May 2001, I quickly agreed with the part about configuration files. In Struts, to map requests to action/controller objects, you use an xml configuration file. In JWAP, this is done in the code which I like. --JohnYeung

What is your reaction to using the MLS preprocessor to convert long strings to java strings at compile time? The usual comment I get is that this violates the separation of presentation from code, a reaction that I've never understood. After all, JWAP does separate them... just to separate methods (statically bound) instead of to separate (dynamically bound) files.

My reaction is that MLS makes life easier, since the capability exists in other languages, e.g perl and ruby.

MLS based on what it does itself cannot violate seperation of presentation from code. Its the programmers/web-designers who do that :-) See http://www.rubygarden.com/ruby?DisputeBetweenHTML_PersonAndCoder

Brad, have you seen this article: http://www.paulgraham.com/lib/paulgraham/bbnexcerpts.txt ? These folks are also turning against the prevaling model of web app programming.

Thanks for that pointer. BBN's Lisp-based approach is very similar to the Perl-based approach I used for distance education (http://virtualschool.edu/98c). Basic idea there was that web pages are Strings (arrays of them actually) like Lisp's everything is an S expression attitude. If web apps are viewed as string processors it is hard to beat Lisp or Perl.
The approach described at http://virtualschool.edu/wap is quite different in that it explicitly breaks with the string processing paradigm. Rather, JWAP views web apps as state machines, composed of state and transition OBJECTS that just happen to emit strings of html to web browsers when the transitions fire.
Its a figure-ground reversal. Sure strings are getting processed in both approaches. But in JWAP its hidden, not the very paradigm for application design. Although I would have defended my Perl-based approach then as vigorously as BBN defends Lisp, I eventually realized that this String-oriented approach is why web applications seemed so much harder than uni-CPU programming. Thinking of them primarily as state machines than just happen to emit html text made things much simpler in the end. And the cost of running make to see changes was not a major cost, in comparison of the benefits of having errors reported at compile time.

I am new to wiki, saw this link under HtmlIsAssembler, and had to jump in. I am surprised that this link is so cold ( dormant for 6 months ). I have spent about 2 years doing various ASP/VB/JavaScript/HTML "things" - mostly making VB-like apps "happen" on an HTML page.

In order to minimize the overhead of IIS/ASP/VBScript, I put as much of the host-side code as possible into Activex libraries. The client-side processing is done in JavaScript. My resulting architecture makes the HTML + JavaScript page into a sort of object which is "conceived" (in the biological sense) in a Factory class but comes to life on/in a browser.

Once "instantiated" in the browser environment, it does the usual JavaScript editing things when the user "sends", then, of course, relays "input" as a collection of strings. The creation and interpretation processes are all carefully wrapped in objects at the server end.

Now an application can be written with relatively little thought about HTML or JavaScript because all of the creation and execution is encapsulated and handled by libraries of objects with "nice" interfaces.

During the process of building this system, I OFTEN thought of HTML as a kind of assembly language -- but then what does that make JavaScript? In a sense, a page is a lot like a classical COBOL program in which the HTML is the "data division" and the JavaScript is the "procedure division".

In a sense my software is a "compiler" producing HTML, with a "macro capability" which produces JavaScript. In another sense, it is just an especially complex Facade.

Having worked in many kinds of software for over 30 years, I find web pages fascinating just because they incorporate so many ways of doing things. -- AlMeyers

I am interested in web development tools making full use of dhtml and scripting languages. Paul_2061@yahoo.com

WebAppConstruction

Discussion