Hi everyone !

I finally made the step of splitting my personal website into two different websites. My javascript-related posts have become way too pervasive.

For RSS readers, be sure to subscribe to http://javascript.neyric.com/blog/feed/ if you’re interested in Javascript.


Bonjour à tous !

J’ai finallement décidé de séparer mon site personnel en deux. Mes articles concernant le javascript sont devenus trop envahissants.

Pour ceux qui me suivent par RSS, n’oubliez pas de vous inscrire à http://javascript.neyric.com/blog/feed/ si vous vous intéressez au Javascript.

inputEx is an open-source javascript form library, built on top of the Yahoo! User Interface (YUI) Library. It is still under development and will be released real soon, under the MIT License.

Another Form Library ?

Why would I create another form library, when we already have so many of them ?

I really like the way the YUI Library is built and I wanted a form library to be very close to the YUI philosophy. I believe the YUI library is really missing something: it has a lot of useful widgets, but you have to integrate them yourself within your forms, over and over again…

Have you ever created a web application or website without any input field ?

Unobtrusive ?

No ! I want the opposite. I hate HTML (although I’m still writing HTML every day for 10 years…). With inputEx, you describe your forms using json !

It’s not all about validation

Validation has been the main milestone for many form libraries. inputEx aims to tackle other issues, such as:

  • Form creation: each field will include its own configuration form. Thanks to a “type” field, we can then provide a form to create forms !

  • Extendability: form libraries always miss the field you need. A good form library should make it easy to create new fields easily. This pitfall has a unique solution: a good documentation !
    Please be patient ! ;)

I made a few updates this week-end. They mostly concern the Container
and Layer classes.

Here are the changes:

  • new Layer.getWiring function to save the state of the wiring. It
    can be customized by overriding Container.getConfig
  • jsBox updated to use the Layer.getWiring function
  • no default width for containers so they can auto-adjust to the
    content
  • Layer.addContainer and Layer.addWire now returns the created
    instance
  • Added the method Container.redrawAllWires and
    Terminal.redrawAllWires
  • Added Layer.removeAllContainers
  • adds a “body” div to the container
  • CSS updates on Containers and Layers
  • adds a focus CSS class on the last mousedown-ed container in the
    layer
  • bugfixes (events “addWire” and “removeWire” added to WireIt.Layer,
    offset in the connections)

I just released the new 0.2.0 version. You can download it here.

Here are the main changes:

  • 2 new classes were added: WireIt.Container and WireIt.Layer
    Every project you might start using WireIt needs a widget that could contain Terminals, and that could be moved around. This is the goal of WireIt.Container.
    The Layer class creates a DIV element that can contain multiple containers and wires. It will be useful to save the state of the containers and connections between the terminals. (It also provide an extensible frame with scrollbars.)
  • Custom events added to create richer interactions when editing the wires.
  • A minified version built with YUI Compressor.
    This javascript minifier is almost perfect: I just wish you could have multiple input files…
    The result file is just below 20k.
  • jsBox: This is a sample application using WireIt.
    Create boxes containing javascript functions, connect them together, and run your program !
  • Many new configuration options, configurable CSS class names, and some new methods in the Wire and Terminals classes.
    Don’t forget to give your feedback in the forum !

Have fun !

The google gears team recently announced the features that will be added in gears 0.3

One of them particularly caught my eyes: the Desktop API. It provides a simple method that lets you create a shortcut icon on the user desktop, to launch your web application. Is’s particularly interesting for an offline-enabled web application, and improves the user experience while making web applications one step closer to Rich Desktop Applications.

However, google doesn’t provide the 0.3.2.0 version yet. If you want to try it, you’ll have to compile it yourself from the gears svn version. (There’s a tutorial to build it under windows, for MacOS, a simple “make” will work)

As the compilation procedure was not so straightforward under windows, here are the xpi files (firefox only) from the latest svn revision (revision 638) :

I’m pleased to announce the first release of WireIt (version 0.1) !

WireIt is a javascript library that allows you to create cool wires like Yahoo Pipes. It is built upon:

Why would you make such a library ? After playing a lot with Yahoo! Pipes, I realized how powerful it was to create mashups. I was already used to visual programming Languages like PureData or Mac OS Automator, but they’re definitly not able to do mashups.

However, Yahoo Pipes has this big inconvenient to run your pipes on their web servers. It has at least two disadvantages. First, it means we will always be restricted to the modules and types they implemented. You could always create a restful webservice and wrap it into a pipe, but the execution time blows up. Second disadvantage, you have to be careful with your data privacy. Indeed, I would like to create some Mashups that could mix with my private data in a more secure way.

That’s how I started to develop a Yahoo pipes-like application, and how I ran into this stumble block: “How the hell did they do those pipes ?”.

Waiting for your feedback,
Eric

I’ve been using Google Gears rather intensively (see Gears In Motion) during the last few months.

I started building an interface that uses all the components of Google Gears (Local Database, Local Server and WorkerPool), and implemented a synchronization engine. The result was a much more responsive offline application with many features that couldn’t have been easily implemented without the local database, and that works great !

Until… one of my coworker tried to import 20.000 records: It took 40 minutes to execute the SQL INSERT statements ! (approx. 120ms/insertion)

We then decided to write this 100 insertions test, which revealed to have surprising results :

  • On MacOS 10.4.11: 2.6ms by insertion (approx. 385 insertions/second)
  • On Windows XP and Vista: 107ms by insertion (approx. 9 insertions/second)
    Please run the test and post your results as a comment indicating your OS/Browser version/Google Gears version.

Any idea why it is so slow on Windows ?

I just released the v0.2 of
Gears In Motion. The project has also migrated to Google Code so that anyone can checkout the SVN version. We also plan to use the “Issue Tracker” so feel free to add any bug/comment/feature request etc…

You can download gim-standalone-0.2.zip and launch gim-standalone.html in Firefox >= 2.

Here is a quick changeset (without the many bugfixes…):

  • Display GIM in a Panel (makes it easy to use in your own project)
  • Improved element liaisons visualization
  • SQL export is now displayed in a field so you can copy/paste it
  • Script that generate the standalone version

I get very excited by the recent release of WebRunner 0.7 : WebRunner is a simple XULRunner based browser that hosts web applications without the normal web browser user interface.”

It lets you use your favorite web applications in a separate process/window with better OS-integration (alt-tab, desktop icon …). Many applications such as Gmail, Google Reader, Facebook and others are already packed. And it is very simple to create your own.

I get even more excited when I found out that Alex Sirota added Google Gears support on WebRunner.

His method is a bit out-of-date (I think he used WebRunner 0.5), so here is the way to do it in 2 steps under Windows (and with WebRunner 0.7) :

  • Tell WebRunner to load the Google Gears extension: open regedit, and add the following key : [HKEY_LOCAL_MACHINE\SOFTWARE\WebRunner\Extensions]
    {000a9d1c-beef-4f90-9363-039d445309b8}=C:\Program Files\Google\Google Gears\Firefox\
  • Make Gears compatible with WebRunner : Open C:\Program Files\Google\Google Gears\Firefox\install.rdf and add those lines after the “em:version” tag :

    
    <em:targetApplication>
    <Description>
    <em:id>webrunner@developer.mozilla.org</em:id>
    <em:minVersion>0.4</em:minVersion>
    <em:maxVersion>1.0.0.*</em:maxVersion>
    </Description>
    </em:targetApplication>
  • The third step Alex describes on his blog is NOT necessary with WebRunner 0.7 (the extension manager is already on)
    The Web Applications schould now be able to use Google Gears (Gears doesn’t tell anymore that the browser is not compatible, and the google javascript object is now available).

Unfortunately, WebRunner crashes as soon as the webapp uses Gears: “Error while loading gears.dll”. After some investigation, I found out that XulRunner wasn’t able to find some dlls (which are under the WebRunner\xulrunner directory). I copied them all into windows\system32, tried again, and now WebRunner crashes without error…

I told myself: “Hey, it’s Windows, it’s not the first time an app crashes without reason…”, and hurried to MacOS X. Since we cannot use the registry to tell WebRunner to load Gears, I put the gears extension directory into /Applications/WebRunner.app/Contents/Resources/extensions, and did the second step. However, WebRunner doesn’t seem to load the extension and gears tells us that our browser is not compatible. I also tried to put it in the profile/extensions directory of WebRunner, without success.

Conclusion: After one day of relentlessness work, I wasn’t able to make it work on Windows, neither on MacOS. I even tried with Gears v0.1.54.0 and v0.1.56.0 with the same results. Did it work for you ?

Copyright © 2000-2015 - Eric Abouaf - Powered by Hexo