Lambda the Ultimate

1. We are indeed multi-platform - we've just released the Win version first. Many of our own developers use the Linux version we have to build Curl (much of Curl is built in Curl). We just didn't have the bandwidth to release both versions at once.

2. We plan to open-source much of Curl. We will keep hold of the core so that no one gets into a JVM-type of situation with Curl, but everything else will be open. Again, its been a bandwidth issue of why we haven't open sourced right now.

3. The documentation is available in PDF format to make it easier to see online. But look at our IDE, Surge Lab. The same documents are done in Curl, and provide a very cool interactive playpen.

In anyone has more questions, I'm happy to reply.

Pam

Just to set the record straight on a number of issues that /. raised:

As one who has spent way too much time in forms & javascript of late (& who therefore has not posted his fairshare on Lambda), my questions are rather much simpler. Is there a better way to get information from the user than html forms?

Lotsa effort has been placed on scriptinng and/or presentation logic, but in my mind the current forms stuff is garbage. No masking. No grids. No etc... All the effort in XML and XSL has not improved the situation one bit. We're still stuck with the same stuff that was present in html 1.0. Seems that all the competition in browsers had little effect on the forms input types.

Anyhow, does Curl improve on the situation of user input, or is it a slave to the html standards and object model? If it is, then I have no impetus to switch from JavaScript, as I see problems with JavaScript to be more in the browser object model than in the language itself.

My past is very heavy in HTML/JS/CSS/DHTML front end and PHP/JSP/Perl/C++/Java backend development with whatever db in a supporting role. Forms have always been a nightmare for me as well - maintaining state between HTTP requests (did the user actually fill out their name yet?), presenting a nice UI that the user finds navigable and intuitive, combined with not wanting to overpower the user or send down essentially a full fledged application.

Curl offers a nice middle ground here. We provide the simplicity of your standard Weby UIs offered in HTML and so on with the power of your hardcore Java / C++ UIs.

We have the baseline inputs: TextFields (yes TextAreas are coming next release, our bad), DropdownLists, ComboBoxes, RadioButtons, ScrollBoxes, etc. in the Core of the language. But, you can easily extend these components by either subclassing them or creating your own to act and behave as you wish.

Additionally, an important quality is the ability to sanity check a user's input - if they are filling out an address form and select a certain state, then the applet can check the zip is appropriate for example. That sort of client side data verification is just the tip of the iceberg though since that is doable today.

What is much more dificult is making the form 'live'. In Curl, a rendered Web page is a live program - anything can affect anything else - including text to text. Very easily you can have forms in Curl where components are appearing / disappearing based on the user's interaction.

For example, why have the question "what is your dog's name" after the question "do you have a dog" if the user never checks yes? The second question can appear in the form when the user checks affirmative and disappear when checked in the negative.

The text above the form can be blank and after the user types his/her name into the form, text appears saying "Hello xyz" or whatever. The whole thing is live and interactive and a new ballgame.

Curl also has a repetoir of graphical containers like horizontal, vertical containers, tables, overlay boxes, canvases, grids, etc. which help the programmer achieve the desired form layout rapidly.

Oh yeah, and handling user input events like key presses, pointer motions, and so on are simple and can obviously do cool things like affect the graphical hierarchy of the page (mousing over a picture or a piece of text can make text somewhere else change or close part of the form or whatever).

Cheers, Brent

The project I'm currently working on is presenting a dynamic graphical tree (something similar to a directory) using geometric shapes on a chart rather than an explorer type view (though that view type is supported as well). Each of these nodes on the tree represents classes of information, providing a drill down to input forms.

I can easily see how handling tree structures would be a whole lot easier in Curl than in JavaScript (given the influence of Lisp on the language), but right now my concerns are more mundane. The html standard forms are shot full of holes as I'm sure you are quite cognizant (Select boxes have no sizing, no standard masking capability, no grids, etc...).

Java Applets were supposed to be the cure for these ills of client side logic, but I think they ended up with a server side infrastructure language - which probably should not have been a surprise given the server side bias of Sun and IBM.

It sounds like Curl is in a good position to fill the void between the html forms and applets. TextAreas are necessity in my current application, so I hope you get them in their soon (don't forget to put a maxsize constraint in there as well - another oversight of the html standard).