Refining Markup Builder

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 PropertyBeans..to 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..

More snippets from MarkupBuilder

With namespace:

newBldr := XMLBuilder new.
newBldr currentNsPrefix:  ‘myns’;  xmlPreprocessor;
xmlnsPrefix: ‘myns’ nsUrl: ‘http://www.w3.org/myns’;
xmlnsPrefix: ‘h’ nsUrl: ‘http://www.w3.org/html5′;
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=”http://www.w3.org/myns”  xmlns:h=”http://www.w3.org/html5″ ><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..

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

Pharo in action

MarkupBuilder in Smalltalk

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.
newBldr 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.. (http://squeaksource.com/PharoGoodies/MarkupBuilder-Skrish.alpha.1.17.mcz).

XSD based XML Exports Framework

For nearly all projects now it is a requirement to export all outputs as XML. Schema is well defined and has to be adhered to for the exports. In all but the current project requirements pre-existing or additional formats as in csv, fixed file formats too are required. If the schema defined is a known superset of the formats of output it would be easy to rake up a meta framework code that takes the XSD file as an input and creates the comprehensive scaffolding of the export code and leave a minimal section of methods to be filled into for the runtime data values and custom changes for exports in other formats being the only intrusive effort from development.

This is a basis for something like the servingXML project too a lot more generic and comprehensive dependent on a XSL like template being filled in and used.

In the context of a Smalltalk based application there is an attempt to work through this meta framework that yields a benefit of over 60x (execution time) over basic and amateurish attempt to construct XML nodes at runtime to export the XML file.