Archive for the ‘ajax’ Category

Local Web Apps

Wednesday, April 27th, 2011

I think I’ve finally settled on the architecture that makes the most sense for data collection types of applications for the iPhone. I just do them in HTML and use the webkit control everywhere.

Of course I need access to sqlite and so I’ve found I can add new subclasses of NSURLProtocol to provide handlers to access different parts the local machine’s resources.

The first and most useful one I did works with urls of the format sqlite://database/table?a=&b=&c= where a,b, and c are field names. If this is used with a form that has its method set to POST, then a table that can hold all those fields are created and an insert statement is generated to save the record. The response is a JSON dictionary of the resulting record (done to provide the generated primary key back as well as any set default values).

If it is used with a form whose method is set to GET, then all the mentioned fields are fetched, and the ones that have values are used as filters. The response is again a JSON array of dictionaries. This makes a quickie search form easy, however I also look for a field named sql and if that is present, I just execute that as the query instead. Sometimes only SQL will do.

If the form method is DELETE, then the matching records are deleted. Since responses are JSON, using jquery is a no-brainer.

The entire NSURLProtocol subclass is about two pages of code and works with RAILS style form serialization naming conventions to allow saving/retrieval of hierarchies. It also uses ActiveRecord naming conventions and requires a primary key field of id on each table. The primary key is generated as a guid.

Works great. Dead simple. Don’t even need a server. I will be exploring this architecture more.

Software Design Tip: Minimize Number of Languages

Tuesday, April 1st, 2008

I was recently asked about taking over support for an existing application. I’ll leave out what it does – suffice it to say it is web based, has a simple 3-5 page UI for the public to buy something, and about a 15-20 page set of back end interfaces for trained customer service and admin people to use. So less than 30 screens overall mKay?

The application was said to be written in Java. I know Java – I don’t like it, but I know it. If its small, I could be persuaded to pick up the maintenance.

However, I got a source drop and I was totally appalled. First, it suffers from the usual Java framework-itus.

Its J2EE – so we got Jetty container. They used Hibernate – so we have generated Java code based on some XML schema files. There’s also a mysql database – which duplicates the information in the Hibernate XML schema files. It uses cocoon – cocoon make use of xml and xsl to define navigation and transformations. There is also reporting that uses xsl. Workflows use flow – more xml only they used the Javascript extension so the workflows are actually defined using server side javascript.

Got all that? We have Spring, Coccon, Flow for Javascript (flowscript), Hibernate, Jetty, Javascript, Html, CSS, SQL, XSL and god knows how many dozens of distinct flavors of XML. For a 25 page web app. Wait, did you notice I didn’t mention Java? There is Java – the Hibernate generated classes are used – but indirectly – they may as well not exist at all since all the application code is some fractured XML or Javascript fragment stashed who knows where.

It seems we’ve lost track of something here. “Locality of Reference” In general, all the stuff that deals with the product selection page ought to be visible by looking into the file representing that page, then maybe drilling into components. The problem here is that, everytime I have to drill down, I have to switch languages. And context switches are bad for programmer productivity – mKay?

I’ve turned down the job. I don’t have time to learn all that junk for this little app. The client needs a new installation – for 25 pages that do mostly CRUD to mysql. If I do it, I’m thinking plain old PHP with an ORM. If I can find an ORM for PHP.

So far I’ve looked at Doctrine (not yet ready for production but it looks cool), Propel – and some others. The really off-putting bit is their slavish insistence on creating the xml mapping file – just like Hibernate. Of course, I have an existing database. The XML file they want is in the db. It just isn’t XML. Still, all the information is available for query – so why are they bothering me with this junk? Read the damn schema and make me some classes. I’ll eliminate the many to many mappings by hand. Sheesh. No wonder there’s a software crisis.

Hey framework people, stop making me write monkey code – figure out how to eliminate extra work – not make it. One meta model is enough.

Looking for work again

Monday, March 3rd, 2008

I’ve been doing a lot of PHP lately – shopping cart integration, web service clients, lots of ecommerce stuff. But I’m coming to the end of these projects and am looking for new challenges. Got a project or position that I can do remotely? Drop me a line.

Web Standards Project

Friday, March 17th, 2006

Scoble talks about the Web Standards Project. I’m all for them. Most of the larger websites produce absolutely awful html that is a mishmash of xml-isms, table based layouts, html 3.2, html 4, and lord knows what else.

Most people coding html need remedial training – html has changed a lot since they learned it. And, of course, it doesn’t help that the dominant web browser has been neglected for the last 6 years because its owner thought it had “won” the browsers wars and hoped that the web would just die of neglect.

All hail the new generation browsers for refusing to admit defeat. I think Microsoft now realizes they didn’t win the war – there’s still a strong rebel insugency.

Bubble 2.0

Thursday, March 16th, 2006

Just in case you weren’t sure.

(Updated as the previous link went off the air).

So you think you know HTML and CSS?

Monday, February 13th, 2006

My general survey of the web is that most sites are a mishmash of HTML 3.2, 4, XHTML, CSS, and junk that could most be charitably called “text with angle brackets”. As the manager of the JavaScript team at a certain large internet retailer, I’ve found that poorly written HTML is the number one thing delaying the delivery of Web 2.0, AJAX, DHTML, or just plain better web experiences.

The reason is fairly simple. As soon as a browser encounters broken code it starts to make guesses about what you meant. Different browsers make different guesses. All the browsers are trying to turn your stream of text into a neat tree of elements with suitable decorations that represents the structures defined in the text stream. The JavaScript makes the page appear to be dynamic by manipulating the structure of these trees (called Document Object Model or DOM trees).

When the DOM is malformed, the JavaScript gets confused and the fancy AJAX features stop working. In extreme cases browsers have been known to crash when JavaScript has tried to manipulate a malformed DOM.

The answer is to make your HTML and CSS standards compliant and properly structured. Unfortunately, this is hard for a lot of reasons, not the least of which is that most of the web browsers don’t complain about bad HTML or offer any tools to help you find problems.

Which is why I wrote The Central Scrutinizer. This program will give you a summary of different kinds of errors on your web page from most severe to least. Clicking on an error group will take you to the errors and clicking on an error will show you where it is in your HTML or CSS.

If you find problems with the results, please use the comment form on the Scrutinizer or leave me a comment here. I hope you find it useful.

Here we go

Sunday, February 12th, 2006

I had started one blog years ago but I ended up hating the software and put off dealing with it until I could get around to writing my own.

I’ve started my own but other projects keep intervening and with wordpress now out for free I can’t quite justify the effort right now. So I’ll start with this and see how it goes.

I managed the “Rich Client Platform” team at Amazon.com. Basically we work on making the shopping experience more responsive and friction free using JavaScript (what everyone else calls AJAX). There is a lot of great stuff in the pipe, stay tuned and I’ll announce new features as they roll out.