Thomas Fuchs and Amy Hoy are back with another web site, this time Freckle, a new take on time tracking.
Thomas posted about it on his site and shared that it uses an early build of scripty2 which lead me to peak around on GitHub. It looks nice indeed.
You can see the evidence of Script.aculo.us throughout the UI. The calendar morphs between months as you flip around. Jumping between headers rolls around nicely (e.g. reporting mode from insertion). Inline modal popups. Nicely done.
The level of quality is “It runs and some pages render!” This build is not at all suitable for normal browsing use. Please don’t use it with your usual Firefox profile. There are numerous known issues starting with bogus memory management (leaking everything in the parser!), lack of fragment parsing support, lack of quirks mode, HTML elements being represented as DOM nodes that behave like XHTML elements and the integration with CSS layout being inefficient. The baseline Gecko source isn’t synced with the trunk, so the other parts of Gecko don’t have all the latest patches. The parser doesn’t reflect the most recent spec changes. meta element-based encoding declarations and BOM sniffing don’t work.
If a page doesn’t render, try reloading or navigating back and forth.
Sam Ruby talked a little about the implementation:
He starts from a single source, in Java. The Java code can be compiled to Java byte codes, JavaScript source, or C++ presumably making use of Mozilla libraries for things such as memory management. If he can do that, it seems to me to be a rather small leap from there to producing C++ using, say, either Ruby or Python libraries for memory management, as well as a thin binding to the language. C# would also be a reasonable target.
If this could be done, and made available under a liberal license, it could go a long way towards making available consistent and performant implementations of the HTML5 parser algorithm everywhere.
Eiten Suez, author of jMatter, has been up to some fun hacking recently. He just released CanvasTurtle a JavaScript and Canvas version of the old favourite TurtlePascal.
Project Deploy is a simple Web application that lets you make a few choices on what your Web project needs, and then it generates a directory structure for you:
It offers a couple unique features from other project folder downloads such as customization, valid XHTML, HTML, and CSS, but the most unique is bookmarking.
Deploy*'s bookmarking feature allows the user to go through the form only one time and then bookmarking the next page (deploy.php). When the user returns to that bookmark it instantly generates another .zip folder with all the settings the user had previously entered.
If you have a Mac you could add that bookmark to your dock and it's only a click away. Windows and Linux users could also add the bookmark to their desktop and it will always be right there waiting.
This is just the beginning of course. You could imagine that it would get a whole lot more useful if you could deploy to a cloud and have a project setup for you. Imagine if the options were more like "Give me Rails 2.2 with jQuery." There is room to take this further.
Wouldn't it be nice to take a view of your application and see where the behaviour has been added? That is what is shown above, and it is courtesy of Allan Jardine and his new Visual Event tool.
Once you hover over an event, you get to see the code that will run:
Each type of event has its own icon, and all you need to do is use the bookmarklet to run it on any page.
When working with events in Javascript, it is often easy to loose track of what events are subscribed where. This is particularly true if you are using a large number of events, which is typical in a modern interface employing progressive enhancement. Javascript libraries also add another degree of complexity to listeners from a technical point of view, while from a developers point of view they of course can make life much easier! But when things go wrong it can be difficult to trace down why this might be.
It is due to this I've put together a Javascript bookmarklet called Visual Event which visually shows the elements on a page that have events subscribed to them, what those events are and the function that the event would run when triggered. This is primarily intended to assist debugging, but it can also be very interesting and informative to see the subscribed events on other pages.
It turns out that there is no standard method for finding out what listeners have been attached to any particular node in a document, so I've resorted to parsing the event cache stored by the various Javascript libraries. Currently only jQuery and YUI are supported, but additional libraries can be added with ease.
Allan is keen to hear your thoughts. What would you like to see?
One common issue in my experience are intricate dependencies between the UI and data models. Decoupling these is a huge benefit with respect to maintainability. The PubSub model is a great way to do it!
I've got a brief post along with a demo and sample code for a really compact PubSub tool, as well as a short discussion on the somewhat non-trivial javascript that makes it work with minimal code.
Voting has started in Dojo land to take in John Resig's Sizzle next-gem CSS selector engine.
This is incredibly exciting, as it shows how Ajax libraries are working together more and more. Instead of reinventing the wheel in different ways for each project, is it possible to find some core pieces that can be nicely shared? Of course, if our world was nicer and we could share code by linking in a nice way maybe this would happen more.
As I mentioned in my thanksgiving note, the work that the Ajax library developers do is hugely important and impactful, and having them work together can only be great news.
Take a look at this public email to the Dojo Foundation on the vote:
Overview
The Sizzle project is a JavaScript library for performing selections
across a DOM tree using CSS selectors. The library is designed to be
standalone (have no external dependencies), lightweight, fast, and
extensible. This culminates in a library that is perfectly suited for
integration into other libraries. While it's feasible that a developer
may use Sizzle directly the target audience for it is other library
authors.
All of the code for the project has been written by John Resig and is
released under an MIT license. There are some patches pending from
some other contributors (namely Prototype).
Right now the following libraries are adopting or are looking to adopt
Sizzle as their primary CSS selector engine:
It's likely that Sizzle will become the unified engine behind a
majority of the JavaScript libraries on the market (if not in numbers
then certainly in market share).
The project is owned by John Resig who will serve as BDFL/Project lead
if the project is accepted. There is no formal voting process, as of
yet, but it's likely that one will come about, considering the number of
projects using the codebase.
If the project is accepted to the foundation then all contributors to
the project will be required to have a CLA and follow the policies of
the Dojo foundation.
It's very likely that Sizzle will eventually expand into other areas
of JavaScript libraries (such as DOM manipulation and event binding).
That last line excites me too! It is interesting to see this happen in the Dojo Foundation. Remember, Dojo was founded out of toolkits coming together to aggregate forces. Kudos to everyone involved, and good luck!
You may remember Sanjiv Jivan as the GWT-Ext developer that changed over the debacle. He then went on to start work on a GWT version of SmartClient libraries and has now released SmartGWT 1.0.
It is a tour de force of not only a huge widget library, but he explains how it is much more:
So what's so smart about SmartGWT? Let me try to explain. SmartGWT is not just another Widget library. While most Ajax frameworks focus primarily on presentation and displaying mostly read-only data, either local or via XML / JSON, SmartClient was built with server side integration in mind. Most enterprise applications are not just about about data presentation, but about being able to propagate data changes made by the user to the backend. So while its tempting to use library X that has a cool tree widget, it's not until you actually try to use it your application that you encounter the real world hard problems. For example, how do you take data from your business objects on the server to not only display in a tree widget, but also be able to update your data model when, say, the user reorders the tree nodes or make edits / deletes in the UI. How do you display hierarchical data where nodes may have hundreds of children? And so on..
Most Ajax frameworks stop short and leave it up to the user to manage state on the client side and propagating the changes to the server. This is not a trivial problem! Over the past few years UI widget libraries have improved significantly and there are now various options available to users. Simply put, having good looking widgets is not the hard problem today. In addition to having good looking widgets, having end-to-end integration of the UI components with the backend is the hard problem. It's this 20% of the functionality that takes 80% of the time in building most enterprise applications.
The showcase will give you a good feel for what is out there, and it contains some interesting items including:
Miller Columns: The ColumnTree provides an alternate navigation paradigm for Tree data, sometimes called "Miller Columns" and seen in iTunes
Nested Grid: A convenient way to display 1-n relationships
Printable Views: SmartGWT supports printable views of its components.
Tile View: Representation of data as "tiles". Again, TileGrid supports data binding so sort / filter and edits can be easily performed.
Calendars : A Google Calendar like widget that supports databinding so edits and drag drop changes can easily be propgated to the server for persisting.
TreeGrid : Supports multiple columns, editing, column locking, lazy loading and more.
Really amazing work. Sanjiv recently had a Q&A session with InfoQ where he talks about the approach taken in developing SmartGWT and the his thoughts on the differences between SmartClient and Ext.
A common use for forms is user authentication. To indicate that
an HTTP URL requires authentication through such a form
before use, the HTTP 401 response code with a WWW-Authenticate challenge "HTML" may be used.
For this authentication scheme, the framework defined in RFC2617
is used as follows. [RFC2617]
challenge = "HTML" [ form ]
form = "form" "=" form-name
form-name = quoted-string
The form parameter, if
present, indicates that the first form element in the
entity body whose name is the
specified string, in tree order, if any, is the login
form. If the parameter is omitted, then the first form
element in the entity body, in tree order, if any, is
the login form.
There is no credentials production for this
scheme because the login information is to be sent as a normal form
submission and not using the Authorization
HTTP header.
The idea makes total sense to me. The old HTTP BASIC style of authentication is a dying bread due to the annoying popup style and implementation. It needs a shake up, don't you think?
Erik Arvidsson seems to be having fun going through exersizes getting JavaScript to do something his way. The latest little foray is Using catch-alls to implement super.
Firstly, catch-alls are the ability to use the SpiderMonkey only __noSuchMethod__ meta programming trick. The good news is that this seems to be coming to ECMAScript Harmony (I hope we here how the ECMA working group meeting went in Kona soon!).
Erik used this trick to build a createSuper method:
Greg Salisbury has released a new JavaScript debugger called XBug that "currently runs on the Windows XP/Vista platform, but, it can also be used to debug webpages on Windows or Linux servers. It's cross-browser compatible, and works with Chrome, Firefox 2/3, IE 6/7, and Safari 3. After selecting your web page, you can then trace or step through your javascript code in real-time. Set breakpoints, and watchpoints in a separate code window, see a trace log while your code is executing, inspect variables, and even get an indexed list of the functions/methods in your scripts."
I noticed the new iPod Engraving Gallery that is a nice use of Coherent to show a slick UI with engraving suggestions.
I was also talking to a friend that has leopard beta bits and he was playing with an updated Dashcode. It appears that the Coherent library is now used for the widgets too. Yay data binding!
Kojax is a mobile development platform, according to my sources, that will allow Microsoft- — and third-party-developed — applets run in an Ajax-like way, using a combination of Visual Studio tools and JavaScript, on Java-based mobile phones.
, Scriptaculous
