Markup Builder in Smalltalk

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Markup Builder in Smalltalk

skrish
I may perhaps be unaware of the XML/SGML builder generation from Seaside, love to be pointed out to.., The Html generation of
Seaside uses explicit construct of classes ( WA**Tags) to do so.. Builders in dynamic manner
use doesNotUnderstand: construct to generate the stream..

The strength in this approach is a lighter construction.. just one object creation for the entire sgml stream
creation..

Extensibility too therefore is available by default.. any tag/ attribute can be streamed without any extension
to creating a new class/ method..

The offside though is, it is streaming so no handling the DOM / tree for manipulations..

Infact I feel it can be a good alternative mode to current seaside markup streaming for the Html streaming ( for static content) too..but that is specialization
of its use.. and not as yet worked out for handling the callbacks and all special abilities of Seaside html streaming.

*****
Seaside provides that kind of functionality.

Lukas

2010/7/6 Sudhakar Krishnamachari <skrishnamachari at gmail.com>:
> Is there any general interest in Markup Builder...a la Groovy..?
>
> http://skrishnamachari.wordpress.com/2010/07/06/markupbuilder-in-smalltalk/
>
>
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



--
Lukas Renggli
www.lukas-renggli.ch

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Markup Builder in Smalltalk

jaayer


---- On Tue, 06 Jul 2010 02:37:38 -0700 Sudhakar Krishnamachari  wrote ----

>I may perhaps be unaware of the XML/SGML builder generation from Seaside, love to be pointed out to.., The Html generation of
>Seaside uses explicit construct of classes ( WA**Tags) to do so.. Builders in dynamic manner
> use doesNotUnderstand: construct to generate the stream..

While it may seem desirable to have an API that uses #doesNotUnderstand: (or its equivalent in other languages) to facilitate markup generation by accepting arbitrary messages and taking them to be the names of tags, this approach is not a good idea for at least two reasons: 1) namespace prefixes cannot be specified in this way, as ":" is not a legal character within identifiers in Smalltalk (or in most other languages, for that matter), and 2) unary messages intended to be treated as tag names can collide with already-defined unary messages in the writer class or its superclasses.


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Markup Builder in Smalltalk

Lukas Renggli
>>I may perhaps be unaware of the XML/SGML builder generation from Seaside, love to be pointed out to.., The Html generation of
>>Seaside uses explicit construct of classes ( WA**Tags) to do so.. Builders in dynamic manner
>> use doesNotUnderstand: construct to generate the stream..
>
> While it may seem desirable to have an API that uses #doesNotUnderstand: (or its equivalent in other languages) to facilitate markup generation by accepting arbitrary messages and taking them to be the names of tags, this approach is not a good idea for at least two reasons: 1) namespace prefixes cannot be specified in this way, as ":" is not a legal character within identifiers in Smalltalk (or in most other languages, for that matter), and 2) unary messages intended to be treated as tag names can collide with already-defined unary messages in the writer class or its superclasses.

3) The approach with #doesNotUnderstand: absolutely doesn't scale.
Tools break in subtle ways (editors, debuggers, program checkers).
Debugging is a pain. And it is slow. We've had that in Seaside up to
version 2.6.

Lukas

--
Lukas Renggli
www.lukas-renggli.ch

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project