Pharo Spring

January 21, 2011

Pharo Spring and Java (Groovy) Enterprise Integration:

Caveat: Enterprise integration as in through WebServices though a given in the SOA world is not a trifling to work with and is a non-integrated connection. Major Smalltalks do have it, but neither Pharo/ Squeak have it currently in a stable manner near term.

Smalltalk in general has been the most insular to integrate to the enterprise world of computing, due partly to the arrogance/ perceived superiority of its platform vis-a-vis the enterprise world of Java or .Net computing. Past now the decade of denials, all smalltalkers now should find it relatively easier to accept that there is undeniably large asset built in Java/ JVM / J2EE ( primarily Spring ) that is impossible to ignore any further.

To leverage the best the Smalltalk offers in its productivity, efficiency et als, I firmly believe a tighter and more inclusive integration with the Java/ JVM world is to be forged. Primarily what this means is

Direct call interface with JVM as in:

  • JNIPort
  • Redline Smalltalk

Integration with the J2EE stack

  • Integration with Spring Architecture
    • Callable to and from the bean descriptors transparently
    • Utilize the interface to transparently use the now highly proven frameworks of JDBC, MQSeries, Reports as in Jasper or Cognos or thousands of other frameworks that we do not need to reinvent the wheel of.

The primary argument we have to make is that the business logic, complex enterprise development be doable from the Smalltalk environment while all the interfaces that is stable and proven in the enterprise world can be leveraged transparently.

Also this will give rise to the argument that smalltalk work can be safely integrated as a module in a larger context of existing framework of the enterprise IT architecture and be capable of using and sharing the end points as is required.

Pharo Spring: Post this preamble, to introduce this term, as it clearly suggests is deep integration of the Spring Architecture and Pharo Smalltalk. Spring Architecture greatly simplies the enterprise computing in the Java world for standard GUI interfaces, web world both browser/ non browser or a headless no web world. We may over a period of time see great synergies in our GUI world of morphic, Seaside and headless smalltalk that will offer a great incentive to enterprises to adopt Smalltalk as a module in their larger stack.

All Smalltalkers, despite some inherent dislike for the XML based descriptors and dynamism created by external configuration file, will find a huge common philosophical ground in the invocation patterns and orchestration that it brings in.

To integrate deeper with Spring what is required:

  • Be able to have the Spring bean be transparently linkable between Pharo Smalltalk and the other JVM languages of Java, Groovy or Ruby.
    • Callable / reusable as a bean entity. This is currently proposed using the XMLRPC framework to expose a RMI/ Remote proxy mechanism as in a standard distributed world. Both Smalltalk and say the Java/ Groovy end expose their respective Client-Server XMLRPC systems to talk to each bi-directionally. With the two systems proposed to be in the same box/ LAN the inherent intranet latency will not be of huge concern. We can address additional performance concerns much later down the line for servers situated in different distant LANs in a truly distributed environment and even thereof I believe the latency can work towards optimizing it to less than the true EJB style RMI.

This will instantly enable a huge win-win situation for a smalltalk works to quickly plugin to an existing mass base of Spring systems deployed over their favoured App Servers scalably and interact with the existing assets.

  • For a web world of interacting webservers, have a filter mechanism that allows the two systems to bi-directionally redirect links to each other. So a call to a link in Seaside though arrives at the Spring Server, it will redirect to Seaside/ AIDA and smalltalk server will configurably prefix the server:port and web app name prefix strings to the outgoing web page for all its links. All of this should be configured in a simple manner and through the use of configuration files in the spring stack.

Planned Work:

Stage I:

Currently Spring supports a horde of features that are extremely useful in the larger enterprise context but the minimum that I would intend to start and complete as a proof of concept and is usable as a start point are:

  1. Filter adaptor to redirect calls
  2. Bean transparency: bean definition has the extra tag to identify it as Smalltalk bean and have both singleton and prototype capability to begin with.
  3. Integrate XMLRPC module as a scalable unit that can be used more pervasively. ( The issue of datatypes limitation and various other critical note not withstanding, it is far more performant, easy to adapt to than WS Stack. The CORBA/ RMI alternative is a complexity challenge not alluring currently. JNIPort/ Redline Smalltalk will need to mature and again will themselves present a complexity challenge, but perhaps the best alternative currently on a longer term. Alternatives will be explored as we move on to ensure the most performant mode to channel the Smalltalk-Java communications transparently for an end developer)
  4. Pharo Smalltalk linked to the maven/ ant build script to be startable headless/ with UI as required for runtime deployment/ development. Make it integrated to the environment stack of the spring world
  5. Integrate the Smalltalk code management through SVN to have a common code management mechanism
  6. Integrate the build, Unit test mechanism through hudson borrowing from the existing work in that respect.

I guess this much with a small change here n there .. as we go ahead shall be adequate to be a usable proof of concept.

What do I have currently: ( Will update this as I go ahead )

  • PoC on Filter adaptor
  • PoC on XMLRPC
  • PoC on the ant script to invoke PharoUsing Groovy primarily for all the PoC works.. to utilize the power of dynamic behaviour on the JVM side to the maximum, this can be easily converted to Java where required.

    Need to take it from this point onwards to a full blooded implementation, I can argue for with an enterprise to adopt.

Comments, suggestions… ?


Refining Markup Builder

July 14, 2010

Minor success through the last weekend, managed to hook up the markup builder ( HtmlBuilder to be precise) to Seaside: hook action/value callback to the tags and be able to use pure markup or hybrid markup-seaside WA**Tags objects as you wish..

Works like a charm for the Table pagination and hooking the calls to all the page number fetches.. Need to keep refactoring the framework to keep it lean, tight, flexible/extensible, will look through this weekend and commit end of week once.. Have yet to get the JSON/ Ini others completed.. So beyond completing/ incrementing the framework:

* Plugin framework needs a deeper review to keep it lean and clean; can see some pains in use of DNU.. registerPlugin:.. etc..

* Unit Testing needs to test the framework roots better and help in aggressive refactoring

* Review the components framework and its internals to give it flexibility to use PropertyBeans as well as normal construct viz: create a table paginated from a collection of make it play better with DBs later.. but keep watch over time/space complexity while keeping the code clarity intact.

XML is streamed as a markup, I realized even the attributes should behave the same; make the entire API work the same way..

(XMLBuilder new attributesMap
type: ‘submit’;
value: ‘submit’; parent) input: ‘testing’.
( or can also do: HtmlBuilder new attributesMap key: ‘type’ value: ‘submit’ ; )

yields: <input type=”submit”  value=”submit” >testing</input> .. have not as yet removed the attributes: collOfAttribs message ; seems useful for now to retain it as an alternative..

For the component framework of Html thinking of extending it soon for Forms to make it a viable RAD tool for basic apps..; hook csv / DB table reading and presentation automatically with the HtmlBuilderTableTag with its pagination..

Can do lots in this framework and potentially lean one with just one/few objects created to dump a complex XML/Html. Profiling for time/space should yield significant advantage over Seaside type of rendering.

Also thinking if I can integrate my earlier pieces of work: Lean workflow rules engine ; XSD based XML exports; SimpleWeb with complete construct for RAD web app.. with this framework..

TestHtmlBuilder Screen Render

More snippets from MarkupBuilder

July 10, 2010

With namespace:

newBldr := XMLBuilder new.
newBldr currentNsPrefix:  ‘myns’;  xmlPreprocessor;
xmlnsPrefix: ‘myns’ nsUrl: ‘;;
xmlnsPrefix: ‘h’ nsUrl: ‘;;
test: ”
with: [
newBldr copy attributes: #(‘a=”1″‘ ‘b=”2″‘);  currentNsPrefix: ‘h’;  trial;
attributes: #(‘a=”3″‘ ‘b=”4″‘);trial.
newBldr copy  currentNsPrefix: ‘myns’;  trial  ].

to emit: ‘<?xml version=”1.0″ ?><myns:test xmlns:myns=””  xmlns:h=”; ><h:trial a=”1″  b=”2″ ></h:trial><h:trial a=”3″  b=”4″ ></h:trial><myns:trial></myns:trial></myns:test>’

the newBldr copy msg works like a charm…! to keep the same stream all the way through.. but reset the ns ( or anything else one chooses to..).

emit multiple script files:

html := HtmlBuilder new.
html html: ” with: [html head: ” with: [ html jsFileColl: #(‘test1.js’ ‘test2.js’)] . html  body: ” with: [ html h1: ‘text’ ] ] .

| html |
html := HtmlBuilder new.
html html: ” with: [ html linkCssFileColl: #(‘test1.css’ ‘test2.css’) . html  body: ” with: [ html h1: ‘text’ ] ].

now the next step is to integrate callback to anchor tags, buttons.. once that is done I guess this builder can be used with a httpserver to serve pages.. belted out fast n quick.. once extended with more components like the Table  viz: for a Form etc.. it would make it even more easier..

Pick the latest version: MarkupBuilder-Skrish.alpha.1.17.mcz and give it a try..

PS: I do find some issues with latest Pharo build.. 1.1.11409 or maybe bcos of Autotest being loaded.. gives arbitrary bugs in throwing up the debugger ..

Pharo Smalltalk is cool..

July 6, 2010

Pharo is cool.. the pics speaks a thousand words..

Pharo in action screenshot

Pharo in action

MarkupBuilder in Smalltalk

July 6, 2010

Borrowing a leaf from Groovy..

[please read comments: for changes made and my addl replies to critical notes in pharo mailing list.. accepting many as good suggestions to improve the framework for general benefit..]

newBldr := XMLBuilder new.
xmlPreprocessor; attributes: #(‘a=”6″‘ ‘b=”7″‘); test: ‘welcome to builders’ with: [

newBldr attributes: #(‘a=”1″‘ ‘b=”2″‘); trial: ”; attributes: #(‘a=”3″‘ ‘b=”4″‘); trial: ‘testing..’ ;trial ].

or: without going through DNU and array of assocs for attributes:

newBldr xmlPreprocessor; attributes: (Array with: #a->6 with: ‘b’->7); tag: ‘test’ text: ‘welcome to builders’ with: [

newBldr attributes: #(‘a=”1″‘ ‘b=”2″‘); tag: ‘trial’ text: ”; attributes: #(‘a=”3″‘ ‘b=”4″‘); tag: ‘trial’ text: ‘testing..’ ;tag: ‘trial’ ].

newBldr valueStringTrimmed

to get :

‘<?xml version=”1.0″ ?><test a=”6″  b=”7″ >welcome to builders<trial a=”1″  b=”2″ ></trial><trial a=”3″  b=”4″ >testing..</trial><trial></trial></test>’

has its charms to generate the tons of export XML, or SGML in general.. and remember all calls to methods #trial: and #test: are dynamically resolved as they do not exist..! and now extend this to a PropertyBean..

aSimpleBean := PropertiesBean new beanAlias: ‘NewXML’.
aSimpleBean text: ‘TopRoot’.
(aSimpleBean elementProperties) add: #root -> 123; add: #child1 -> 123.

aSimpleBean valueStringTrimmed generates:

‘<?xml version=”1.0″ ?><NewXML>TopRoot<root>123</root><child1>123</child1></NewXML>’

The idea gets a little more interesting.. as we can even cause the same PropertyBean to generate an ini thorugh IniBuilder, json through JSONBuilder, etc..

Specialize the builder with more constructs for say HtmlBuilder now..:

html := HtmlBuilder new.
html html: ” with: [ html
attributes: #(‘onLoad=”1″‘); body: ” with: [ html h1: ‘text’ ] ].

html valueStringTrimmed generates:

‘<html><body onLoad=”1″ ><h1>text</h1></body></html>’


html body: ” with: [  html htmlTableTag tableAttributes: #(‘width=”80%”‘);
headers: #(‘ColumnField01’ ‘ColumnField02’)
rowsArray: #(#(123 32) #(223 32) #(‘asd’ ‘asd’)) ].

can now generate a whole table…!.. just given the header and rows..of any rational size

add plugins to this for href rows on are after each row.. pagination, reading a csv file of data to generate a table.. or db table.. on the fly.. the possibilities are many


Having built up the basic framework now more as an internal trial.. moving from XML outputs to now, I am working on plugging this to Seaside to see if we can use it more potently for renderContentOn: html methods to render easier and extensible html components with JSF like plugin capability..

Wondering if this has extended use for the Pharo.. Smalltalk community to reuse.. the entire capability of a MarkupBuilder system that has:

* Construction of a markup text ( possibly non text..) that can be extended to output to many possible tree based format..: XML, JSON, INI, Properties, etc..

* PropertiesBean that extends the ability to create a class/ instances that can emit at last stage the reqd one/ multiple output formats..

* HtmlBuilder that extends and enables faster html turnaround especially with potential extensible components of Tables, Forms, media/ browser plugin players etc.. Rails like easier access to dump multiple js, css files and little more assist here n there..

* A generic plugin mechanism that can allow per builder instance registry of plugin initialized and respond to..

Just my two cents.. love to see someone comment on this here.. can post the monticello package for anyone to explore if reqd..

Pick the mcz package from the link.. (

Pharo News..

April 29, 2010

Playing with Pharo and waiting for its 1.1 release. Its great to see a free version of Smalltalk at last measuring up to the needs of using it in an business sense and showing it to non-Smalltalker’s and the “IT managers” and not put them off. I am sure this is going to make it difficult for VA and Cincom to create new small-medium shop sales going forward especially with Seaside, Magritte and raft of other frameworks actually being born in Squeak. There obviously is the crying need for better-faster VM, DBMS connectivity natively, Web Services. But if that all does come in, I doubt if there is any space left for commercial Smalltalk but for maintenance of existing customers…!

I am wondering if a Pharo-Groovy bridge and / or Pharo-Ruby bridge would be a good case to make. Solve the issue of interoperability and extensions usage. Invest in a very efficient connector development and you will have all the interfaces for free though to be developed in the Java/Groovy or Ruby. But that is lot more leverage than to natively support 200,000 or more interfaces to stuff we dont even know about..

Would continue to play and check. The new website is also a great start to the advertisement of resurgence in Smalltalk interest. Should stoke the possibility of doing an Indian grouping up for Smalltalk specially look at Pharo. IIIT I believe is using Squeak and am sure have Pharo too being checked out. Need to link up the Indian Smalltalkers now rather than any later..

Re-visiting VM Plugin in VisualWorks

September 19, 2008

Hope to sometime soon revisit this VM plugin in VW ported from Squeak..  Posting this on to kick me to pick it off sooner than later..


Use a Smalltalk framework to write a code that gets converted to a C code , recompiled and pluggable back optimized to your Smalltalk code for those 10% of the code optimization you require…