Archive for the ‘Web Development’ Category

Last week, I did loose a lot of time in what should have been a quick ColdFusion hack. My colleagues and I were just trying to set up a web service-based solution for a simple problem: they had a JavaScript page that needed a bit of data for which I already had the code in ColdFusion. So I created a new directory in an existing application, whipped up the required code in ‘index.cfm‘ to return a bit of JSON and tested the result from my browser… only to get an “Error 500 - Application index.cfm could not be found“.

Weird, heh? The required file was there, so why could CF11 not find it? Adding an ‘Application.cfm‘ did not help, neither did repackaging the code in a CFC. On CF8, on the other hand, everything worked as expected. So what was going on?

It took some time, but I did find the explanation: CF11 reserves the directory name ‘api’ for special treatment, so you can’t use it like any other directory name – and of course that was the name I had chosen! Adam Tuttle described the situation nicely in 2015:

Funny you should mention that the issue is inside an /api folder. I’m trying to track down the same problem, except I’m directly accessing an index.cfm (sort of — onRequest intercepts the request and redirects to CFCs as appropriate — it’s a Taffy API) and I’ve found that renaming the folder from /api to … literally anything else… works fine. It’s almost as if something in CF has special meaning at /api, like the special /rest mapping does.

Indeed, renaming my directory solved the problem – too bad it took me so long to find the cause. On to the next problem!

PS. Adam Tuttle has more to say on the subject, but his post on the subject has disappeared: the URL ‘http://fusiongrokker.com/post/coldfusion-11-sometimes-chokes-on-api‘ no longer points to the relevant text, but is redirected to another blog also belonging to Adam Tuttle. There, unfortunately, the post is NOT available. I won’t call this a case of linkrot, but it’s not good either. Luckily, the Wayback Machine has a copy of the page, including a few comments…

Read Full Post »

Brent Simmons isn’t a new name in this blog – I have cited his name several times since 2001. A few days ago he wrote:

It’s been years since I could build the Frontier kernel — but I finally got it building.

The high-level goal is to make that tool available again, because I think we need it.

The plan is to turn it into a modern Mac app, a 64-bit Cocoa app, and then add new features that make sense these days. (There are so many!) But that first step is a big one.

“Frontier Is Interesting”, says Jim Roepcke – click to see what he writes

It’s an interesting development, from several viewpoints. I wrote some of my first “web applications” in Frontier, and that makes that Frontier will always have a special place in my book of tools. It’s also nice to see a relevant piece of software evolve so that it continues to run on modern hardware and OS’s. At some point, I will certainly download and run a copy on my Mac.

But the question is: do I want to go back to developing stuff in Frontier? Do you want to?

Read Full Post »

More than 8 years ago, I wrote about the Google App Engine as a platform. Much as I liked the concept, I also remarked that it would be… great to have a complete development environment within the browser, coupled to a runtime.

Turns out that Fog Creek, the software company founded by Joel Spolsky, has built just that: “a developer playground for building full-stack web-apps fast“. It’s called Gomix – but it was called HyperDev during the development of the product. That ties in neatly with my reference to HyperCard as an example of a simple tool that allows anyone to built the tool she/he needs. Nice work, Joel !

So here it is, my first “app” in Gomix (just for fun and with lots of tongue in cheek):


Read Full Post »

I do find it important to refresh my memory from time to time, even when it comes to something that I do quite frequently, like writing code. A reminder about why some things have to be done in a particular manner, re-reading the exact details about how to do something, or just brushing up on a subject supposedly known only to find that things have changed a bit in last few years: all good reasons to never stop reading.

That’s one reason for me to read “The Basics of Web Application Security” on Martin Fowler’s site. It’s also a good intro to newcomers in the field – and to top it off, it features an xkcd cartoon! What more can you want?

Click the image to see the cartoon in all its glory

Click the image to see the cartoon in all its glory

I’m waiting for further additions to this text!

Read Full Post »

It seems the debate about in-browser editors is ongoing, in a good and serious way. Dave wrote about it again, in “There’s a content-editable community“. He points, amongst other things, to an Indiegogo project called ‘ProseMirror‘. I have only read the project description, not the code; it seems to me that it is part editing tool, part content representation. That makes it similar to Dave’s OPML Editor, and both will allow you to represent the content as you like, depending on the transformation you apply to the content. That’s a good approach, in my view, because it makes the tool very flexible.


Of course, ProseMirror could be the editing environment for a Wiki! Storing Wiki-content in a format that is not dependent on a representation such as HTML is the basis for re-use of that content in as many forms as you need/want. I hope Marijn Haverbeke reaches his goal, and then we’ll see if someone picks up ProseMirror as the basis for a Wiki, a blogging tool, etc. From what I remember of the JSPWiki implementation, it should be relatively easy to whip up a ProseMirror “storage provider”  for JSPWiki that does exactly that: use the ProseMirror content format as the corner stone of a Wiki. Any takers?

PS. If the Indiegogo project should disappear, then you’ll also find more details on prosemirror.net

Read Full Post »

Dave asks: should there be “Editing APIs for Wikis?“.

Wikis have been “invented”, to use that word, to make it possible for anyone to edit a Wiki page inside the browser. In a Wiki, content is more important than fancy layouts. Wiki editors thus prescribe a simple markup system for things like ‘bold’ and ‘italic’ lettering, bullet lists, etc. Creole, the attempt to unify dozens of markups, has never been a success. When going from one Wiki to another you may need to adapt your markup automatisms. These markup languages are rather similar, so in practice adaptation from one to another isn’t too hard.

Would it be nice to have a WYSIWYG editor in your Wiki? For some people, the answer is yes. They will indeed be more comfortable with an editor that resembles the editor they use for writing books or letters. But many Wikis allow you to change the editor used for editing Wiki pages. At work, I have activated the FCKEditor (aka. CKEditor) in JSPWiki, and currently our users can still choose the editing style they prefer.

All/most Wikis store the user’s content in their own markup format, not in HTML. The MyWord Editor that Dave Winer has built works differently, if I’m not mistaken: it is a WYSIWYG layer for HTML editing. It should not be too hard to convert the HTML from a simple HTML editor to whatever markup the Wiki uses. But even for a single editor that would require a convertor for multiple Wiki markup dialects.

Yet another Wiki editor: Eclipse and Textile

Yet another Wiki editor: Eclipse/Mylyn and Textile

In the end, the real question is: what would be the added value of such an API?

The purpose of a Wiki is to capture information and not layout. That is why the built-in editors are relatively simple. For hard-core Wiki authors, an HTML textbox plus knowledge of the local markup language will be enough. Occasional authors will have to make do with the built-in MOLWYSIWYG (More Or Less WYSIWYG) editor. I suspect most occasional wiki authors won’t be authoring texts in more than one Wikis, so they will deal with a single variant only.

Would a common API be a good idea? Of course! But such an API would already exist if it served a greater purpose beyond the technical promise of plug-and-play editors.

If you ask me, Wiki’s would be better served with a common markup language like Creole or Markdown or ReST, rather than an editor API. If you think otherwise, then just build such an API. I’ll be happy to write about it!

PS. For a comparison between Creole, Markdown and ReST, check out “Why Markdown Is Not My Favourite Language“…

Read Full Post »

I have been spending more than a hour trying to find out why a :hover selector on a <span> wasn’t working in Internet Explorer 8 – many documents on the Web are clearly stating that it works. In the end, it was the W3Schools.com website that came to the rescue, in the form of a note:

Note: In IE there must be declared a for the :hover selector to work on other elements than the element.

CSS Selectors explained at W3Schools.com

CSS Selectors explained at W3Schools.com

You had better make sure that the DOCTYPE is indeed declaration is indeed on the first line in your HTML… and then everything works smoothy, as far as I can tell. Whew.

PS. No, I will not try to explain why I still have to build code that has to work in IE8, and not in a somewhat more recent version…

Read Full Post »

Older Posts »