[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Help-smalltalk] Iliad - asResponse implementation
From: |
Stefan Schmiedl |
Subject: |
Re: [Help-smalltalk] Iliad - asResponse implementation |
Date: |
Sun, 21 Jun 2009 19:25:24 +0200 |
On Sun, 21 Jun 2009 17:09:29 +0200
Nicolas Petton <address@hidden> wrote:
> Committed. I also modified the other classes that implemented
> #asResponse.
>
> Thanks again :)
You're very welcome.
CalendarWidget seems to be missing a date instance var.
s.
address@hidden iliad $ svn diff
Index: trunk/More/Widgets/CalendarWidget.st
===================================================================
--- trunk/More/Widgets/CalendarWidget.st (revision 1353)
+++ trunk/More/Widgets/CalendarWidget.st (working copy)
@@ -39,7 +39,7 @@
Widget subclass: CalendarWidget [
- | month |
+ | month date |
<comment: nil>
<category: 'Iliad-Core-Widgets'>
>
> Cheers!
>
> Nico
>
> Le dimanche 21 juin 2009 à 16:27 +0200, Stefan Schmiedl a écrit :
> > While looking around in Iliad source code, I noticed that
> > Object>>asResponse is implemented using Object>>printString.
> >
> > Dolphin Smalltalk makes a -- quite useful -- distinction
> > between
> >
> > printString - what the developer wants to see
> > displayString - what the user gets to see
> >
> > Since we're living in a console based environment, I guess
> > that printString gets exercised quite a lot there.
> >
> > So here's my question: How about
> >
> > Object extend [
> > asResponse [
> > <category: 'converting'>
> > ^Iliad.Response ok
> > nextPutAll: self displayString;
> > yourself
> > ]
> > ]
> >
> > Also, I'm seeing that Iliad.Response supports the "usual"
> > streaming methods #nextPut: and #nextPutAll. What about
> >
> > Object extend [
> > asResponse [
> > | response |
> > <category: 'converting'>
> > response := Iliad.Response ok.
> > self respondOn: response.
> > ^response
> > ]
> > respondOn: aResponse [
> > <category: 'responding'>
> > self displayOn: aResponse.
> > ]
> > ]
> >
> > I think that this approach could avoid (repeatedly) building
> > and printing strings. And it would offer a non-intrusive
> > new method #respondOn: to override in subclasses. So I could
> > eat my cake and keep it, too:
> > printOn: for console work,
> > displayOn: for (possibly embedded) content representation,
> > respondOn: for responding the object
> >
> > Note that I'm just venting hot air, as I have yet to write
> > my first line of Iliad-related code .-)
> >
> > s.
> >
> >
> > _______________________________________________
> > help-smalltalk mailing list
> > address@hidden
> > http://lists.gnu.org/mailman/listinfo/help-smalltalk
--
Stefan Schmiedl
EDV-Beratung Schmiedl, Berghangstr. 5, D-93413 Cham
im Büro: 09971 9966 989, am Handy: 0160 9981 6278