Category Archives: web

Datatable support for Seaside

Esteban Maringolo announced the support of for Seaside.
Here is his announce. 

Hi folks,

This mail is just a heads-up to anybody already using DataTables
( or that developed a Seaside wrapper for it.
I just uploaded my initial working version of DataTables to STHub. If
your current wrapper is better than mine we can merge our efforts.

This initial version supports the basic features to instantiate a
DataTables jQuery object, plus support for AJAX+JSON responses and
also Server-side Processing

I still have to write a proper example of how to use it, but if you
load the DataTables-Magritte package it will include a
DTMagritteReport that you can use to replace the "stock" MAReport.

Once I have time I'll try to set up an example to show the different
ways it can be used. Meanwhile look at the DTMagritteReport class to
see a particular use case. It includes support for server side sorting
(multiple columns), filtering, pagination, search.

To load it with all the dependencies run:

Gofer it
  smalltalkhubUser: 'emaringolo' project: 'DataTables';
  package: 'ConfigurationOfDataTables';

(Smalltalk at: #ConfigurationOfDataTables)project development load: 'Magritte'.

The STHub is:!/~emaringolo/DataTables/


Seaside 3.1.3 is released

Seaside one of the most exciting web frameworks got a new release.

Hi Seaside users,

We have released Seaside 3.1.3 [1].

A big thanks to everyone involved for making this release happen!

best regards,
The Seaside Team


Teapot: a micro web framework for Pharo


I'd like to announce a new micro web framework called Teapot. It follows a
similar philosophy than other lightweight frameworks like
Sinatra/Bottle/Flask/Spark. Teapot is built on top of the Zn HTTP
components, and less than 500 lines long.

More info:!/~zeroflag/Teapot
Gofer it
  smalltalkhubUser: 'zeroflag' project: 'Teapot';


Jasny bootstrap


The Bootstrap wrapping project for Seaside now has also support for the Jasni Bootstrap 
extension (see

Seaside Examples can be found on the following URL's

Hope this is useful.


Merchant – a credit card processing library

Sebastian Sastre announced Merchant – a credit card processing library. The code is available

 It is used in airflowing for his client, in flowing’s invoice system for the consulting services.

All over https and never saving credit cards info (only the gateway’s token of the authorised cards, the sensible data only touches RAM and gets a nice nil on the instVar after the gateway’s result)
We could authorise and capture on debit cards too but the gateway we’re using has debit only for brazilian cards and doesn’t provide the international debit feature (which seems to be kind of a big deal for vendors and banks).
Contact Sebastian Sastre if you want to extend its API to your gateway.
Tagged ,

Renoir: Programmatic CSS builder

Gabriel Omar Cotelli announced today a new library for Pharo.
I’m announcing the first official release of RenoirSt, a DSL enabling programmatic cascading style sheet generation for Pharo.
For the impatient, you can load it in your 3.0 image evaluating:
Gofer it
    configurationOf: ‘RenoirSt’;
or download a ready to use image from the Contribution CI Server ( a ConfigurationBrowser option comming soon).
Visit the project page and GitHub repository for more information on the supported and planned features, and check-out the online tutorial.
I hope you find it useful. Feel free to ask any questions, suggest ideas and improvements, or report bugs (the issue tracker is in GitHub).

Handling of $+ in URLs

There was an interesting discussion about handling URL in Zinc. Zinc is the fully rewritten HTTP client server of Pharo developed by Sven

Zinc has an excellent design and Sven takes really care of it because he uses it in production on the servers of . Zinc is also an important player in the Pharo Web stack with Seaside or other web frameworks (soon there will be a nice new comers around Amber – stay tuned).

Pharo is really grateful for his involvement and contributions. Here is the summary of the discussion:


Johan Brichau reported an issue a couple of days ago concerning the handling of $+ in ZnUrl (Pharo 3’s URL class) and in Seaside’s WAUrl. #bleedingEdge of Zinc HTTP Components fixes the issue, as far as I can see. I want to explain the problem and the solution.

Before october 24 of last year, ZnUrl used a ‘better safe than sorry’ safe set when doing percent encoding of unsafe characters. However, the URL spec defines different allowed characters per URL part. This behaviour was then added to Zinc-Resource-Meta-Core, ZnUrl’s package.

Soon after that a discussion with Jan van de Sandt let to a first small change: since ZnUrl interprets the query part of a URL as key-value pairs, it is necessary to treat $= and $& as unsafe, even though they are not according to the URL spec (which doesn’t concern itself with how the query part is interpreted).

All that time, $+ kept on being interpreted as a space, independent of the safe set. As Johan reported, this conflicted with $+ being a safe character. Which eventually let to the functional problem of not being able to enter a + in an input field, in Seaside.

Why only in Seaside ? Because ZnZincServerAdaptor>>#requestUrlFor: was implemented by printing the interpreted incoming ZnUrl and parsing it again. There, the escaping of $+ disappeared and it became an unintended space.

This situation is now fixed by

Changes to ZnPercentEncoder:
– adding an #decodePlusAsSpace boolean option

Changes to ZnResourceMetaUtils:
– #decodePercent: no longer decodes plus as space
– #decodePercentForQuery: does plus as space decoding
– #queryKeyValueSafeSet no longer includes $+
– #parseQueryFrom: not uses #decodePercentForQuery:

Added ZnDefaultServerDelegate>>#formTest1: to test simple form submit encoding handling

Modify ZnZincServerAdaptor>>#requestUrlFor: to build a WAUrl explicitely from the interpreted parts of the incoming ZnUrl instead of going via printing and parsing

Adding new unit tests
– ZnUrlTests>>#testPlusHandling
– ZnServerTests>>#testFormTest1

I think WAUrl should best be changed as well, but that is not my call.

In code, this summarises the implemented behaviour:

“While percent decoding, a + is translated as a space only in the context of
application/x-www-form-urlencoded get/post requests:
ZnUrl interprets its query part as key value pairs where this translation is applicable,
even though strictly speaking + (and =, &) are plain unreserved characters in the query”

“$+ is not special in the path part of the URL and it remains itself”
assert: ‘http://localhost/foo+bar’ asZnUrl firstPathSegment
equals: ‘foo+bar’.
assert: ‘http://localhost/foo+bar’ asZnUrl printString
equals: ‘http://localhost/foo+bar’.
“$+ gets decoded to space in the interpreted query part of the URL,
and becomes an encoded space if needed”
assert: (‘http://localhost/test?q=foo+bar’ asZnUrl queryAt: #q)
equals: ‘foo bar’.
assert: ‘http://localhost/test?q=foo+bar’ asZnUrl printString
equals: ‘http://localhost/test?q=foo%20bar’.
“to pass $+ as $+ in a query, it has to be encoded”
assert: ‘http://localhost/test?q=foo%2Bbar’ asZnUrl printString
equals: ‘http://localhost/test?q=foo%2Bbar’

I hope this is a good and correct solution. In any case, it fixes the functional problem that $+ disappeared in WAUrlEncodingFunctionalTest – which I took over in ZnDefaultServerDelegate>>#formTest1:

Thanks Johan for the whole discussion !