How FormLis has Changed Appearance over Time.

I thought it would be cool to record all the different looks FormLis has had, you know just for posterity reason. Some time in the future I’ll try to dig up even older stuff — and maybe figure out approximately when these things were.

Version 1

version 1

Version 2

version 2

Version 3

version 3

FormLis: Security Interface Added & Bug Fixes

The security interface lets you control who can use your databases and who can modify them. I haven’t rolled it out to everyone yet, I’ll do that once I document it. Users who want to play with it earlier can send me a private email.

Bug Fixes

  • Tables in forms no longer show the ‘add row’ button in read mode.
  • Fixed the preview ability for new views. A Previous bug had made these previews empty.
  • Fixed a page error that sometimes put extra garbage characters at the end of the page
  • Fixed a page error that caused the last field to not render properly if it was the very last thing on the page.
  • Fixed a bug where FormLis would mistakenly think a document you were editing had been deleted in the meantime. This was a minor user-interface glitch.

p.s. FormLis has no outstanding bugs anymore — which is a good sign. However, I’m sure there are unencountered bugs yet to be discovered (and fixed).

Minor FormLis Enhancements

  • Added a ‘Markup Quick Guide’ to the left hand panel of the designer.
  • Pages now present their last-modified date. This should help your browser manage it’s cache.
  • Successful logins send you back to the page + task you wanted to do, rather than just to the page you we’re looking at.
  • Groups implemented internally. But no interface for them yet =(
  • Minor Bug fixes.

I was trying to migrate to multipart/form-data encoding rather than x-www-form-encoded. This is a necessary step for handling file-uploads. Unfortunately, I didn’t get it implemented in time, but I now know enough about multipart/form-data encoding to declare it’s the worst, most ambiguous, and most difficult to parse standard I’d ever seen.

Some New Little Features

Little update:

  • Keyword fields can now have numbers as well as text. So you can make a field (perhaps GST?) that is a drop down with both numbers like 0.06, 0.05 and text like “NA”. This is nicer, because views can total numbers.
  • Also added a view word asNumber to take a string like “3.14″ and convert it into a number 3.14
  • Also added a view word today which returns today’s date. It’s like the word now, but doesn’t include the current time.
  • Also improved date equality, so you can say things like [/my-datetime-field] today = in views to determine if the field refers to today. Useful for views that should only show data relevant to today (like a todo list).

A Big Update:

Internally, FormLis uses a new security model. Previously my security model was some heuristic code that looked at the document owner and who you were to decide your permissions.

The new model uses database backed rules. Long term this will let users customize security. For example, granting some group administrative access, while restricting others.

The catch is there is no interface to this yet, nor an interface to specify groups. So you’re stuck with the default security, which exactly imitate the old system — you won’t notice any changes.

More FormLis Speedups

In an earlier post I reported some FormLis Speedups. I’m happy to report further speed ups.

Now I’ve sped up FormLis further by reducing the amount HTTP requests. I did it by:

Before the changes, a page needed ~6 requests (the page, 2-5 images, 2-3 css files). Now it’s about ~3 requests: the page, a single css file, and 1 sprite sheet and the css and sprite sheet get cached so future pages don’t ask for them.

The pingdom test showed that it took about .6 milliseconds to get the page, and then another .8 to get the CSS and sprite sheet. Once those are cached FormLis can display a page in about .6 seconds compared to about 2 seconds before — a 4x speed increase.

Fixed Some IE rendering problems.

Recently I had to demo FormLis on Internet Explorer, and (horrors!) it didn’t look right at all. My HTML is standards compliant, and super simple to achieve portability. But I guess I should have tested it on Internet Explorer. Heres what it should look like:

What FormLis should look like

What FormLis should look like

It looks proper on IE8 now, but I don’t have access to IE7 and earlier. However I’ve found, which can generate previews of a page under different browsers. I’ll have to see how many I can get.

The problem was that IE doesn’t treat HTML5 tags as generic block elements even though the web standards say it should.

FormLis Speedups

I’ve made some recent improvements to FormLis in preparation for adding user security features.

Speed Improvements
FormLis responds sooner; Long pages and reports seem much quicker because you get the first paragraphs/rows almost immediately.
Cookies Not Required
Persons who’ve disable cookies (e.g. for privacy) will still be able to use FormLis, with no loss of features.

As I said, I’ll be working towards adding user security features to let you customize which users can read, edit and/or delete pages and reports. Sometimes its important to keep collected data private.

Sat, Jan 8 2011: I’ve sped up the site further, see my post on reducing http requests.


Get every new post delivered to your Inbox.

Join 34 other followers