iliad and blocks

Hi, I was going to write this as a comment to one of Joachim's post but
maybe it's better to post here.  The relevant post is
http://smalltalk.gnu.org/blog/joe/one-step-further-iliad and some
comments may not make sense without referring to there.

Joachim builds a PageTemplate widget, and I'm not sure I like the idea
of returning blocks from the methods there (like #mainContent).  I would
rather use something like #renderMainContentOn:

UrPics.PageTemplate subclass: UnknownHome [
     renderMainContentOn: e [
         e h1: 'UnknownHome Object!'.
     ]
]


Another idea could be to add

BlockClosure extend [
     renderOn: e [ self value: e ]
]

and implement Widget>>renderOn: like this

renderOn: e [ e add: self build ]

This way, you could simply return "^Login new" from the message #login
in Joachim's Menu widget.

Now maybe I misunderstood Iliad's architecture (which I haven't looked
at in detail yet), so the above does not make sense.  Just throwing 2 cents.

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Hello Paolo.

First of all, thanks for your comment!

> Joachim builds a PageTemplate widget, and I'm not sure I like the idea
> of returning blocks from the methods there (like #mainContent).  I would
> rather use something like #renderMainContentOn:
>
> UrPics.PageTemplate subclass: UnknownHome [
>     renderMainContentOn: e [
>         e h1: 'UnknownHome Object!'.
>     ]
> ]

This was indeed one of my first approach in splitting the page into
parts. (... and for me, it looks a bit more like seaside, which I got
used to ...) but then I decided against that, because it would break the
usual Iliad kind of style (ooohhh, hope I could make me understand...!)
And I (excuse me) wouldn't like to use several different ways of doing
the same thing in "one" code...

But I'm a noob to smalltalk and the way of coding in it, I'm open to
every suggestion! (I think, I have also to rework my kind of blocking []
code. I saw that most smalltalk-code uses another style...)

Best regards,
Joachim.


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

>> Joachim builds a PageTemplate widget, and I'm not sure I like the idea
>> of returning blocks from the methods there (like #mainContent).
>
> Why don't you like it? I think blocks are expressive and less verbose
> here.

They *are* good as a shortcut, especially since you cannot afford an
extra argument to the view messages (like #indexOn: -- that would be
ugly!).

I just don't think that using #value: as "the" protocol for rendering
is clean, because it makes it harder to return some other object in a
polymorphic way (for example a widget itself).  If everything has
to implement #value: sooner or later you run into conflicts, or into
something that expects more protocol from BlockClosure.

It just leads to hacks like the infamous Symbol>>value: method.  If it
was me, I would not even call #value: from
#select:/#reject:/#collect:.  I would use two methods, one for
#select:/#reject: and one for #collect:, and then implement those on
Symbol, Regex, and whatever else.  This would allow things like:

    'paolo' select: #($a $e $i $o $u $y) -> 'aoo'
    #('paolo' 'bar' 'baz') collect: '(.a)[oz]' -> #('pa' nil 'ba')
    #('paolo' 'bar' 'baz') select: 'a..' asRegex -> #('paolo')

(Of course, finding good names for the methods would be another thing.
 That's why the above idea is not in GNU Smalltalk yet...).

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Off list Nicolas suggested using #build: which is just a wrapper method
calling #value:.  With it, Joachim's #contents message would look like

My reply is...

Even better for me would be:

Element >> build: aBuildable
        <category: 'building'>
        aBuildable buildOn: self

BlockClosure >> buildOn: anElement
        <category: 'building (Iliad)'>
        self value: anElement

Widget >> buildOn: anElement
        <category: 'building'>
        e add: self build

and then keeping the block structure for #contents, like

     contents [
         ^[ :e |
             e
                 build: self headerContent;
                 build: menu;
                 break;
                 build: self mainContent;
                 build: self footerContents.
         ]
     ]

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Le lundi 22 juin 2009 à 15:05 +0200, Paolo Bonzini a écrit :
> Off list Nicolas suggested using #build: which is just a wrapper method
> calling #value:.

Sorry, I didn't mean to answer off list. I forwarded the email.

You're proposal is just great!
Thanks, I'm committing it right now :)

Cheers!

Nico

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Nicolas Petton wrote:
> Le lundi 22 juin 2009 à 15:05 +0200, Paolo Bonzini a écrit :
>> Off list Nicolas suggested using #build: which is just a wrapper method
>> calling #value:.
>
> Sorry, I didn't mean to answer off list. I forwarded the email.
>
> You're proposal is just great!
> Thanks, I'm committing it right now :)

:-)

I guess then #render:/#renderOn: vs. #build:/#buildOn: is just a matter
of Seaside vs. Aida legacy.

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Le lundi 22 juin 2009 à 15:16 +0200, Paolo Bonzini a écrit : Yes, probably :)

>
> Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Hi guys,

Paolo Bonzini pravi:

> I guess then #render:/#renderOn: vs. #build:/#buildOn: is just a matter
> of Seaside vs. Aida legacy.

This is not just a matter of naming.  Both approaches are actually
pretty different.

While #render renders HTML immediately and directly to the response,
#build in both Iliad and Aida builds first a composite tree of the
Widget/Component/Page, then the next step is actual rendering of HTML to
the response.

That's why they are "painting" the page while we are "composing" it.

Best regards
Janko



_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

> While #render renders HTML immediately and directly to the response,
> #build in both Iliad and Aida builds first a composite tree of the
> Widget/Component/Page, then the next step is actual rendering of HTML to
> the response.
>
> That's why they are "painting" the page while we are "composing" it.

That's not true, if you refer to Seaside as "they".

While we use the metaphor of painting, what the backend does with the
sequence of rendering commands is left open (and can even be changed
on the fly). Earlier versions of Seaside did compose an intermediate
tree of nodes. Although that code is not part of Seaside anymore,
different backends are still supported. For example the halos provide
a pretty printed and syntax highlighted output of the generated HTML.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Lukas Renggli wrote:
Ok - Janko and Lukas, stop!! :-P

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk