VASmalltalk – Smalltalk Experience

First I have to say: I’m relative new to WWW development and I only have a general, limited knowledge about WWW programming, CGI, FastCGI, Apache, HTML, CSS, Flash, Silverlight, XML, Json, load balancing …. and this posting showed a typical life in a long day (actually lots of days) of a programmer with limited knowledge …

I’m in the process of writing a demo using Seaside, VASmalltalk, Apache and CouchDB with lots of JSON and all that stuff. The idea was to present votes result to all kinds of devices using browsers and in a graphical way like the ones used in television.

CouchDB was my database. Mainly due to interests and the good support for replication. The programm feeding the CouchDB was written in C# (.NET). JSON support and CouchDB support is available from third party libraries free available from the Internet. They are not that good, but they offer a good start and one can improve them. The export of data from C# to CouchDB was easily done in a relative short amount of time. I had mainly to fight with VisualStudio, when an invalid JSON file was exported. Debugging in Smalltalk is still another world …

CouchDB has the advantage, that the API is IP based and language independent – a good candidate for Smalltalk, but VA had no support for CouchDB. Therefore I had to write a wrapper for it. But as we know: we are highly productive using Smalltalk …

CouchDB means JSON. VA has no support for JSON. But as we know: we are highly productive using Smalltalk … and then I wrote a wrapper for an external C parser.

Working with JSON objects showed up another problem: this native directory like structure access (as in C#) showed up to be very ugly and produces error situations very easily. This is a solution for a demo, but not for intensive programming. Therefore an additional tool has (still) to be written: call a JSON object via Smalltalk and import the JSON object/document into my modeller as an object model and produce the needed Smalltalk and C# code from this model.

CouchDB support was there, JSON support was there, Raphael is working. More or less the demo was working (without CSS and texture images). That was fine.

Then I tried to produce a reduced image to get a working standalone example server. More or less with lots of tries and fights with missing classes, missing constants (all users going this way seem to get through this … look at the Instantiations forum) I managed to get this going on our Windows based machines. Wonderful and the results were ok.

I did the same approach under my Desktop Ubuntu machine and also here: the reduced image was running.

But the production machine was on a headless Linux servers with NO GUI. The reduced VA image will not run there, because it NEEDS the running X server. Ok, I had to switch to the Server Workbench and build a reduced image there – but I’ve not managed yet to produce a running headless server. My subclasses of WAFileLibrary were not delivering anything … ???

While in the stage of producing these reduced images I recognized, that there is no real good documentation about how to start a Seaside system – not using the browser GUI, but only with Smalltalk code.

Even with the browser-based configuration GUI I noticed, that the configuration page seems to be pretty powerful – but is missing a documentation for that. In several drop-down boxes classes can be selected – but what do they do, what are the differences ? No documentation.

The same with exception handling – several choices to select – but documentation !?

Ok, I gave up the headless Linux server target – this seems to be “only” a matter of time and time and time (hoping that my tremendous productivity using Smalltalk will help me here). I decided to do my demo under Windows. The rest can be done later.

I did further programming on this project and noticed, that I rather would like to have a full UTF-8 development IDE. Every string put into/read from the CouchDB must be UTF8 … and these code pages needed conversion here and there … VA offers no additional support for UTF8 (except for conversion)- but I wrote a wrapper against the gnome UTF8-helper C-functions to get more help using UTF8.

The first demo was shown and yes, the graphics produced via Raphael were well accepted – but of course: where is Apache in this demo ?

Today I did the switch from a standalone Smalltalk-WWW-server (which would never be accepted as a production solution) and put the Smalltalk system behind an Apache system and even the CouchDB. Creating virtual hosts und several rewrite statements within Apache and both: CouchDB and my Smalltalk system were producing pages- but no graphics, no css and other missing stuffs. Well, that happens, when using subclasses of WAFileLibrary.

Resources were still missing: all those javascript files and style sheets delivered in the head of a HTML page were not there. Ok, I had to rewrite it and “Dynamic Web Development” told me, that it is the usual step to switch from that Smalltalk-only approach to the Smalltalk and WWW-Server approach. Chapter 22.3.x is telling very much about that way.

Now to rewrite the resource accessing parts. I wanted to include all the library stuff and insert references to external URLs. Chapter 17.2 in the book is talking about this stuff and tells me: rewrite WAComponent>>updateRoot: method. Fine.

You can read ” …. add new styles or script using the messages WAHtmlRoot>>addScript: and WAHtmlRoot>>addStyles: “.

That’s it. No example in the image. The method command seems to say, that the parameter aString seems to be the source code of Javascript. That will lead to one of those typical Seaside links – no reference to an external WWW-server. That can not be the solution. The next sentence is:

“The object returned by both stylesheet and javascript understands url:
which allows you to specify the URL of the stylesheet or JavaScriptfile”

and an example is included:

anHtmlRoot stylesheet url: 'http://seaside.st/styles/main.css'

Hm, I needed to add two stylesheets (and four javascript libraries). But reading this code seem to indicate, that only one url is possible. I read this line again and again – no help. The source code indicates, that only one url is possible. Well, the solution is simple – browse the source code to understand the example (!!!!).

The line means:

anHtmlRoot
  add: ((WALinkElement root: ...)
           beStylesheet;
           beCss;
           url: .... )

Wouldn’t it be much nicer, if the line could be written like:

anHtmlRoot addStylesheetWithUrl: 'http://seaside.st/styles/main.css'

Ok, I solved this problem. Now to the url in the example above. I decided to get the way chapter 17.1 showed: use resourceUrl: method. I looked around, but did not find any receiver in the updateRoot: method understanding resourceUrl:. Well again one has to search and search and yes: aHtmlRoot objects does not understand resourceUrl: – but it understands absoluteUrlForResource: !! Now consider a source code line like:

anHtmlRoot addStylesheetWithResourceUrl: '/css/main.css'

Wonderful readable – but not there …. and I’ve noticed several other situations, where not c-like method names would be more helpful.

You may notice, that I’m still working on my demo and Seaside shows up its power, but documentation is missing. In the VA world I hope to get more information with the upcoming 8.0.3 about points like: deployoing, debugging and all that stuff. Also more information about all these different application available in VA and why they are structured this way.

After all the demo is working – it shows the power of Seaside. Without any questions. I also do not know, how to write such a demo in C# – without using ASP.NET, suitable for Linux distribution (yes, one could use Mono I know).

But this demo showed still lots of beginners problems and I think, that I’ve not used the power of Seaside at all.

For the first time I was able to use Google and got answers about Smalltalk problems. Seaside made that possible.

This entry was posted in Smalltalk. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s