Just have to throw in my 2 cents, VisualWave which has been around for
years did shield developers from having to deal with request and response
fields, yet I don't recall it being that painful to debug/walk thru the
guts of Wave. There is a balance between convenience and
understandability. Mind you, I have not had a chance to yet walk-thru the
code myself but I trust that if six senior Smalltalkers which includes
Ralph are having a hard time that there is probably room for improvement :)
which brings up the fact that I tried to run the CallbackDemo i.e. as per
the instructions on the pdf and got the following:
Unhandled exception: BlockClosure [] in Object>>doesNotUnderstand:
SmallWiki.HtmlWriteStream(Object)>>doesNotUnderstand:
SmallWiki.HtmlWriteStream>>doesNotUnderstand:
optimized [] in SmallWiki.CallbackDemo>>renderFormRadioGroup
BlockClosure>>renderOn:
SmallWiki.HtmlWriteStream>>render:
optimized [] in SmallWiki.HtmlWriteStream>>form:action:
BlockClosure>>renderOn:
SmallWiki.HtmlWriteStream>>render:
SmallWiki.HtmlWriteStream>>tag:do:keepTight:
SmallWiki.HtmlWriteStream>>tag:do:
SmallWiki.HtmlWriteStream>>form:
SmallWiki.HtmlWriteStream>>form:action:
SmallWiki.CallbackDemo(SmallWiki.Action)>>renderForm:
SmallWiki.CallbackDemo>>renderFormRadioGroup
SmallWiki.CallbackDemo>>renderForm
SmallWiki.CallbackDemo>>renderContent
optimized [] in SmallWiki.TemplateBodyContents>>renderBodyWith:on:
BlockClosure>>renderOn:
SmallWiki.HtmlWriteStream>>render:
optimized [] in SmallWiki.TemplateBody>>renderDivFor:on:with:
BlockClosure>>renderOn:
SmallWiki.HtmlWriteStream>>render:
SmallWiki.HtmlWriteStream>>tag:do:keepTight:
SmallWiki.HtmlWriteStream>>tag:do:
SmallWiki.HtmlWriteStream>>div:
SmallWiki.HtmlWriteStream>>divNamed:with:
SmallWiki.TemplateBodyContents(SmallWiki.TemplateBody)>>renderDivFor:on:with:
SmallWiki.TemplateBodyContents>>renderBodyWith:on:
optimized [] in [] in SmallWiki.Action>>renderBody
OrderedCollection>>do:
optimized [] in SmallWiki.Action>>renderBody
BlockClosure>>renderOn:
SmallWiki.HtmlWriteStream>>render:
SmallWiki.HtmlWriteStream>>tag:do:keepTight:
SmallWiki.HtmlWriteStream>>tag:do:
SmallWiki.HtmlWriteStream>>div:
SmallWiki.HtmlWriteStream>>divNamed:with:
SmallWiki.CallbackDemo(SmallWiki.Action)>>renderBody
optimized [] in [] in SmallWiki.Action>>render
BlockClosure>>renderOn:
SmallWiki.HtmlWriteStream>>render:
SmallWiki.HtmlWriteStream>>tag:do:keepTight:
SmallWiki.HtmlWriteStream>>tag:do:
SmallWiki.HtmlWriteStream>>body:
optimized [] in SmallWiki.Action>>render
BlockClosure>>renderOn:
SmallWiki.HtmlWriteStream>>render:
SmallWiki.HtmlWriteStream>>tag:do:keepTight:
SmallWiki.HtmlWriteStream>>tag:do:
SmallWiki.HtmlWriteStream>>html:
SmallWiki.CallbackDemo(SmallWiki.Action)>>render
SmallWiki.CallbackDemo(SmallWiki.Action)>>execute
optimized [] in SmallWiki.Structure>>processAction:
BlockClosure>>on:do:
SmallWiki.Folder(SmallWiki.Structure)>>processAction:
SmallWiki.Folder(SmallWiki.Structure)>>processSelf:
SmallWiki.Folder(SmallWiki.Structure)>>process:
optimized [] in SmallWiki.Server>>process:
BlockClosure>>on:do:
SmallWiki.SwazooServer(SmallWiki.Server)>>process:
SmallWiki.SwazooSite>>helpResolve:
Swazoo.URIResolution>>visitResource:
[] in Swazoo.URIResolution>>visitChildrenOf:advancing:
OrderedCollection>>do:
Swazoo.URIResolution>>visitChildrenOf:advancing:
Swazoo.URIResolution>>resolveTransparentComposite:
Swazoo.URIResolution>>resolveServerRoot:
Swazoo.ServerRootComposite>>helpResolve:
Swazoo.URIResolution>>visitResource:
Swazoo.URIResolution class>>resolveRequest:startingAt:
Swazoo.HTTPServer>>answerTo:
optimized [] in Swazoo.HTTPConnection>>getAndDispatchMessages
BlockClosure>>on:do:
Swazoo.HTTPConnection>>getAndDispatchMessages
optimized [] in [] in Swazoo.HTTPConnection>>interact
BlockClosure>>on:do:
optimized [] in Swazoo.HTTPConnection>>interact
BlockClosure>>on:do:
optimized [] in Process class>>forBlock:priority:
----------------------------------------------------------------------
SmallWiki.HtmlWriteStream(Object)>>doesNotUnderstand:
Receiver:
a SmallWiki.HtmlWriteStream
Instance Variables:
collection = '<!DOCTYPE html PUBLIC "-//W3C...
In the meanwhile, since I am new to SmallWiki, it would be very helpful if
somebody documented the key spots in the code one should study
On Wed, 21 Jul 2004 23:44:04 +0200, stéphane ducasse
<ducasse(a)iam.unibe.ch> wrote:
Hi ralph
Are you talking about the old SmallWiki (one) or the new one with
Seaside?
Because I can understand that the old one may be difficult to understand
since lukas
tried to minic seaside wtihout seaside. But now when you read the code
of the store shop provided
as an example for seaside I do not understand how callbacks would make
code difficult to read.
When I see the complexity of the code and compare with the one of
seaside, I'm puzzled.
So can you clarify that point?
Thanks
On 21 juil. 04, at 23:05, Ralph Johnson wrote:
>> In my opinion callbacks are great. They make a huge improvement of the
>> abstraction over the dumb and error prone HTTP-protocol: basically they
>> remove all the manual handling of request and response fields.
>
> Callbacks make your system impossible to understand. Half a dozen
> experienced Smalltalkers have been banging our heads against the
> callbacks
> for three days.
>
> We are trying to find out when to commit an action, and what arguments
> the
> action used. Because the request is handled automatically, it is hard
> (it
> may be impossible) to intercept the request. Because the callbacks in
> an
> action are executed multiple times, it is hard to tell when something
> important it happening.
>
> You are falling into the fallacy that shorter code makes for a simpler
> system. Callbacks might be easy for you to write, but they are hard for
> everybody else to read, and in the long run are a bad idea.
>
> I would MUCH prefer a completely manual handling of request and response
> fields.
>
> -Ralph Johnson
>
--
Using Opera's revolutionary e-mail client:
http://www.opera.com/m2/