Again, a web designer might be interested in
Google's Web Authoring Statistics for best practices.
There are far too many articles about the GWT, but here is Dion Hinchcliffe's analysis of GWT's service abstraction.
30.7.06
19.7.06
always good to remember some best practices in web development.
Ralf Laemmel and Erik Meijer take a head-on jump into xml object mismatch. More (or less) data binding.
I still haven't gotten to look microformats and wonder if I need to.
This Scala XML documentation needs some updating.
Ralf Laemmel and Erik Meijer take a head-on jump into xml object mismatch. More (or less) data binding.
I still haven't gotten to look microformats and wonder if I need to.
This Scala XML documentation needs some updating.
14.7.06
different takes on data binding
Some time ago, Kathleen Dollard showed how to generate classes from an XML Schema using XSLT. I dislike both schema and XSLT, but I would understand why someone would need to use both technologies and have respect for everybody that plunges in that hell. However all those technologies together might serve to describe the problem rather than the solution
Pull parsing examples, also a while ago, is often demonstrated as a fast way to do data binding. We can find Chris Fry's writeup on XML pull parsing. It seems
Pull parsing will be available in JDK6
This pull parsing stuff ultimately looks better than all other APIs, because all the other ones can be implemented on top of this one.
13.6.06
typed scripting? typescript
Types are good, but a language aiming to resemble JavaScript should leave type annotations optional wherever possible. Palsberg and Schwartzbach have something to say about type inference for object oriented programs.
What would types be good for? There's all those "message-not-understood" (and so on), but there is also fancier stuff like Session types for channels, or regexp-like types for semistructured data.
JavaScript is object based, but not class based. Abadi and Cardelli's "A Theory of Objects" is the standard reference on object calculi. "Type inference for JavaScript" introduces a calculus for modeling JavaScript.
Castagna provides an account on overloading in the publication that came out of his thesis, titled
"Object-Oriented Programming: A Unified Foundation". The thing with overloading is that it might give a more precise type to pattern matching statements, an idea that haunts me since ages.
8.6.06
JavaScript2
Brendan Eich's XTech 2006 keynote JavaScript 2 and the Future of the Web mentions some deltas to the language. This is warmly welcomed on LtU, who add a new JavaScript department.
One of the typing experts sitting int the committee, Cormac Flanagan, has worked on SAGE: Practical Hybrid type checking for Expressive Types and Specifications[pdf]
Not to be confounded with ECMAScript 4, the next version of JavaScript 1, designed by committee ECMA TC39TG1. They get proposals from Mozilla guys, and recently published their Wiki, which also is half-heartedly discussed on LtU.
29.5.06
why those books? discussions with friends
Edward Angel. OpenGL(tm): a Primer. ISBN 0-201-74186-5 A fascination with NeuroScience and displaying 3d graphics, ideally in a web browser. Unfortunately, we are missing a Canvas3D that supports this stuff. For the moment, there are Java bindings, and lwjgl looks like the way to go.
David Flanagan. JavaScript: The Definitive Guide, Fourth Edition. ISBN 0-596-00048-0 Actually I don't remember why that book is here, I get all the info I want from the net.
John C. Mitchell. Foundations for Programming Languages. ISBN 0-262-13321-0The style and notation of this book are of a beauty that makes me want to read it over and over again. Although I don't really have spare cycles to do more foundational stuff, the proofs are spelled out in a very clear, yet concise manner and it is inspiring.
Benjamin Pierce, ed. Advanced Topics in Types and Programming Languages. ISBN 0-262-16228-8 Here, I started with the chapter of typed assembly language, also with an implementation actually. Wouldn't it be useful to have a low-level VM for iron that interprets typed assembly code? and have an x86 backend at some point.
When chatting with my chap about my final project, I was surprised how rational I could tell him the objectives and problems that I am facing, things I have been trying to find out for a long time. And there I am just communicating it as if I had known it all the time. My reluctance to use *the language*, the advantages of using HTML for user interfaces, the insights into GWT and the architectural sketch and constraints of the system.
When receiving another chap's email I'm surprised at his argument for dynamic typing having become more differentiated, preferring LISP over Python. And it somehow makes sense, because uniform containers (like sequences and hashtables) seems to be what most of my obsession with iron is about as well. His CLOS speak is beyond me but I recall from the book that I forgot to mention that setting up some object system in those languages is not very difficult.
Abelson and Sussman. Structure and Interpretation of Computer Programs. ISBN 0-262-51087-1 Never made it to those later chapters, where writing a scheme compiler is given as an exercise. Opening this book again is due to my interest in doing dynamic typing via tags. However it just clashes with the idea of doing static checking for regular expression types. What gives? There should be some program analysis and type inference.
Benjamin Pierce. Types and Programming Languages. ISBN 0-262-16209-1 There's something about recursive types that makes me return to this book. It stems from my obsession of regular expression types for sequences. The iron language is supposed to have sequences as primitives, and do some type-checking for an xsd-extension based object-class system. Also, the type inference idea mentioned above can be nourished from this book.
David Flanagan. JavaScript: The Definitive Guide, Fourth Edition. ISBN 0-596-00048-0 Actually I don't remember why that book is here, I get all the info I want from the net.
John C. Mitchell. Foundations for Programming Languages. ISBN 0-262-13321-0The style and notation of this book are of a beauty that makes me want to read it over and over again. Although I don't really have spare cycles to do more foundational stuff, the proofs are spelled out in a very clear, yet concise manner and it is inspiring.
Benjamin Pierce, ed. Advanced Topics in Types and Programming Languages. ISBN 0-262-16228-8 Here, I started with the chapter of typed assembly language, also with an implementation actually. Wouldn't it be useful to have a low-level VM for iron that interprets typed assembly code? and have an x86 backend at some point.
When chatting with my chap about my final project, I was surprised how rational I could tell him the objectives and problems that I am facing, things I have been trying to find out for a long time. And there I am just communicating it as if I had known it all the time. My reluctance to use *the language*, the advantages of using HTML for user interfaces, the insights into GWT and the architectural sketch and constraints of the system.
When receiving another chap's email I'm surprised at his argument for dynamic typing having become more differentiated, preferring LISP over Python. And it somehow makes sense, because uniform containers (like sequences and hashtables) seems to be what most of my obsession with iron is about as well. His CLOS speak is beyond me but I recall from the book that I forgot to mention that setting up some object system in those languages is not very difficult.
Abelson and Sussman. Structure and Interpretation of Computer Programs. ISBN 0-262-51087-1 Never made it to those later chapters, where writing a scheme compiler is given as an exercise. Opening this book again is due to my interest in doing dynamic typing via tags. However it just clashes with the idea of doing static checking for regular expression types. What gives? There should be some program analysis and type inference.
Benjamin Pierce. Types and Programming Languages. ISBN 0-262-16209-1 There's something about recursive types that makes me return to this book. It stems from my obsession of regular expression types for sequences. The iron language is supposed to have sequences as primitives, and do some type-checking for an xsd-extension based object-class system. Also, the type inference idea mentioned above can be nourished from this book.
24.5.06
22.5.06
forging hypertext templates
The good old hypertext. What have they done to you, pal? Just look at you. JSPed all over. And all those taglibs hanging down your front.
No, no, some other I may have done this to you myself a long time ago, but not again.
Joel is right, so facade elements with attributes and ognl and tapestry style it shall be.
editable, viewable, maybe even validatable and bindable. No use to go over the top with WebObjects.
<%@ taglib uri="/WEB-INF/tld/struts-bean.tld" prefix="bean" %>
<%@ taglib uri="/WEB-INF/tld/struts-html.tld" prefix="html" %>
<%@ taglib uri="/WEB-INF/tld/struts-logic.tld" prefix="logic" %>
<!--Logon_Block_Start-->
<html:form action="/loginlogout/login" focus="username">
<TABLE WIDTH="<bean:message key="block.size.x"/>"
...
No, no, some other I may have done this to you myself a long time ago, but not again.
Joel is right, so facade elements with attributes and ognl and tapestry style it shall be.
editable, viewable, maybe even validatable and bindable. No use to go over the top with WebObjects.
19.5.06
so you want to get web programming right, eh?
Programming should be done in a decent language. That language should be the same on client and server (and I won't tell you why).
All web scripting somehow started with JavaScript. You could embed it on your server side if you really want to.
One can target JavaScript (and also targets ActionScript) with the haXe language. It also has a server component, going through an Apache plugin.
The Links language promises to compile from a single source database updates and Javascript bits in your page.
OTOH, one can get a nice language, XML capabilities and leverage the whole Java shebang using the Scala language. However, the whole backend-multiplexing thing is missing as of yet.
All web scripting somehow started with JavaScript. You could embed it on your server side if you really want to.
One can target JavaScript (and also targets ActionScript) with the haXe language. It also has a server component, going through an Apache plugin.
The Links language promises to compile from a single source database updates and Javascript bits in your page.
OTOH, one can get a nice language, XML capabilities and leverage the whole Java shebang using the Scala language. However, the whole backend-multiplexing thing is missing as of yet.
18.5.06
so you want to start a blog, eh?
No meta-discussion, no navel-gazing, no propaganda. No technical details.
Once again scanning the web for frameworks, I got lost in Apache MyFaces and Tapestry and of course Google Web Toolkit the new kid on the block.
Over lunch, a discussion on JavaScript turns onto the XML lane and I realize that is another something that is missing in that language, just like actors.
Once again scanning the web for frameworks, I got lost in Apache MyFaces and Tapestry and of course Google Web Toolkit the new kid on the block.
Over lunch, a discussion on JavaScript turns onto the XML lane and I realize that is another something that is missing in that language, just like actors.
Subscribe to:
Posts (Atom)