Smalltalk › Frameworks & Tools › Iliad

New method for building widgets?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

13 messages Options

Nicolas Petton

New method for building widgets?

Hi,

I want to make widgets building a bit more developper friendly.

I thought about replacing the current #contents method (which answers a
block) with something like #buildOn:

For the counter example the difference would be:

ILCounter>>contents [
^[:e |
e h1 text: self count printString.
e a action: [self increase]; text: '++'.
e a action: [self decrease]; text: '--']
]

ILCounter>>buildOn: e [
e h1 text: self count printString.
e a action: [self increase]; text: '++'.
e a action: [self decrease]; text: '--'
]

The same idea could be used application controller methods:

MyApplication>>index [
<category: 'controllers'>
^[:e | e ...]
]

MyApplication>>index [
<category: 'controllers'>
self rootElement ...
]

What do you think? Anyone has a better idea?

Cheers,
Nico

signature.asc (205 bytes) Download Attachment

Bèrto ëd Sèra

Re: New method for building widgets?

Hi!

not sure I fully grasp the implications, but I quite liked the old
version, as I can build subcomponents and change :e so that it's clear
where it goes. For example, when I have a #buildTableRow method, its
#contents looks like this:
MyClass>>#buildTableRow [
^[:table | | row |
row := table tr.
(row td) text: 'first cell'. ]
(row td) text: 'second cell' ]
]

This saves lots of explanations in the comments, and makes it
immediately clear of what kind of object is supposed to build this
stuff.

Much in the same way, the top level "e" (I guess it stands for
"element", right?) can be somehow confusing the first week you use
Iliad, but in the long run it makes the logics behind the whole thing
quite clear and it does help in developing Iliad-style code.

Sure enough, if you get rid of it the first impact is going to be
somehow less, but in the long run, IMHO, you'll make things worse, as
the dev will have to dig the logics out of the Iliad classes, instead
of understanding it right from the way the code is written. Then
again, we are all different, so what is helpful to me may be a problem
for someone else.

Bèrto

2010/5/2 Nicolas Petton <[hidden email]>:

> Hi,
>
> I want to make widgets building a bit more developper friendly.
>
> I thought about replacing the current #contents method (which answers a
> block) with something like #buildOn:
>
> For the counter example the difference would be:
>
> ILCounter>>contents [
> ^[:e |
> e h1 text: self count printString.
> e a action: [self increase]; text: '++'.
> e a action: [self decrease]; text: '--']
> ]
>
> ILCounter>>buildOn: e [
> e h1 text: self count printString.
> e a action: [self increase]; text: '++'.
> e a action: [self decrease]; text: '--'
> ]
>
> The same idea could be used application controller methods:
>
> MyApplication>>index [
> <category: 'controllers'>
> ^[:e | e ...]
> ]
>
> MyApplication>>index [
> <category: 'controllers'>
> self rootElement ...
> ]
>
> What do you think? Anyone has a better idea?
>
> Cheers,
> Nico
>

--
==============================
Constitution du 24 juin 1793 - Article 35. - Quand le gouvernement
viole les droits du peuple, l'insurrection est, pour le peuple et pour
chaque portion du peuple, le plus sacré des droits et le plus
indispensable des devoirs.

Bèrto ëd Sèra

Re: New method for building widgets?

Just to add some clarity, as I'm half sleeping... My persistent
objects are all subclasses of ILWidget, so I can render them directly.
In complex structures I often use collections that are rendered in
tabular form only, this is why being able to document within the
builder method that you are actually messaging a table is important.

It's true that in a perfect world I could have this in a comment, and
I tend to write explanatory comments... too bad that often when doing
bug fixes they end up being the very last thing I read, while I cannot
avoid reading the code.

Bèrto

On 4 May 2010 21:36, Bèrto ëd Sèra <[hidden email]> wrote:

> Hi!
>
> not sure I fully grasp the implications, but I quite liked the old
> version, as I can build subcomponents and change :e so that it's clear
> where it goes. For example, when I have a #buildTableRow method, its
> #contents looks like this:
> MyClass>>#buildTableRow [
> ^[:table | | row |
> row := table tr.
> (row td) text: 'first cell'. ]
> (row td) text: 'second cell' ]
> ]
>
>
> This saves lots of explanations in the comments, and makes it
> immediately clear of what kind of object is supposed to build this
> stuff.
>
> Much in the same way, the top level "e" (I guess it stands for
> "element", right?) can be somehow confusing the first week you use
> Iliad, but in the long run it makes the logics behind the whole thing
> quite clear and it does help in developing Iliad-style code.
>
> Sure enough, if you get rid of it the first impact is going to be
> somehow less, but in the long run, IMHO, you'll make things worse, as
> the dev will have to dig the logics out of the Iliad classes, instead
> of understanding it right from the way the code is written. Then
> again, we are all different, so what is helpful to me may be a problem
> for someone else.
>
> Bèrto
>
>
> 2010/5/2 Nicolas Petton <[hidden email]>:
>> Hi,
>>
>> I want to make widgets building a bit more developper friendly.
>>
>> I thought about replacing the current #contents method (which answers a
>> block) with something like #buildOn:
>>
>> For the counter example the difference would be:
>>
>> ILCounter>>contents [
>> ^[:e |
>> e h1 text: self count printString.
>> e a action: [self increase]; text: '++'.
>> e a action: [self decrease]; text: '--']
>> ]
>>
>> ILCounter>>buildOn: e [
>> e h1 text: self count printString.
>> e a action: [self increase]; text: '++'.
>> e a action: [self decrease]; text: '--'
>> ]
>>
>> The same idea could be used application controller methods:
>>
>> MyApplication>>index [
>> <category: 'controllers'>
>> ^[:e | e ...]
>> ]
>>
>> MyApplication>>index [
>> <category: 'controllers'>
>> self rootElement ...
>> ]
>>
>> What do you think? Anyone has a better idea?
>>
>> Cheers,
>> Nico
>>
>
>
>
> --
> ==============================
> Constitution du 24 juin 1793 - Article 35. - Quand le gouvernement
> viole les droits du peuple, l'insurrection est, pour le peuple et pour
> chaque portion du peuple, le plus sacré des droits et le plus
> indispensable des devoirs.
>

nigol

Re: New method for building widgets?

Hi,

I'm definitelly not Iliad professional, but I agree with Bèrto. The old method looks fine for me. Maybe the new method is more friendly for those comes from Seaside world, but in my opinion the old one is just fine.

Regards,

Martin

Nicolas Petton

Re: New method for building widgets?

Thanks guys for sharing your opinion.

I personally agree with you, I like it the way it is.
Now since some people complained offlist, I wanted to ask on the list.

I'll keep it as it is then :)

Cheers,
Nico

signature.asc (205 bytes) Download Attachment

Bèrto ëd Sèra

Re: New method for building widgets?

You can also tell them that now that I saw this message, I finally
understood the source of my problems with Seaside :))) I simply could
not make out what was rendering what, and being a newcomer I quit
using the framework before eventually digging out the info :))))))))))

After several months (with large intervals due to other impending
jobs) on Iliad the thing I like most is that the code ends up being so
clear that even when you are in a rush for delivery and simply cannot
care for proper comments you can pick it up after a couple of months
and there's no mystery to be solved.

Then again, what is a help for me may be a hell of a problem for
someone else. I suppose I shall see how universal may train of thought
is as soon as we are lucky enough to get more volunteers on this
project and I start hear wild complaints about my poor documentation
:))))))))

Bèrto

2010/5/5 Nicolas Petton <[hidden email]>:

> Thanks guys for sharing your opinion.
>
> I personally agree with you, I like it the way it is.
> Now since some people complained offlist, I wanted to ask on the list.
>
> I'll keep it as it is then :)
>
> Cheers,
> Nico
>

Nicolas Petton

Re: New method for building widgets?

Le mercredi 05 mai 2010 à 23:42 +0300, Bèrto ëd Sèra a écrit :

> You can also tell them that now that I saw this message, I finally
> understood the source of my problems with Seaside :))) I simply could
> not make out what was rendering what, and being a newcomer I quit
> using the framework before eventually digging out the info :))))))))))
>
> After several months (with large intervals due to other impending
> jobs) on Iliad the thing I like most is that the code ends up being so
> clear that even when you are in a rush for delivery and simply cannot
> care for proper comments you can pick it up after a couple of months
> and there's no mystery to be solved.

Hi Bèrto,

Cool to see Iliad fits your need so well! I'm _very_ glad you like it so
much :)

Nico

signature.asc (205 bytes) Download Attachment

Eli Green-5

Re: New method for building widgets?

In reply to this post by Bèrto ëd Sèra

I may be misunderstanding the problem here but if you want to document
the type of element that a widget renders on, you can just change the
name of the parameter.

MyTableRow>>#buildOn: aTable [
| tr |
tr := aTable row.
"etc..."
]

But I'm not sure this is really the relevant case. I think what we're
talking about here is widgets which may very well not be aware of
where they are being rendered: in the body, in a div, in a table cell.
Who knows? ILCalendar, for example, shouldn't know or care what kind
of element it's contained in.

I also think there may be some efficiency gains here. Letting blocks
render themselves is great for the case where it would be excessive to
create an entire object to contain it but if we already have an object
that knows how to render itself, forcing it to create a block seems
counter-productive and a waste of memory / resources.

In the case you show above, it's actually worse because you're
creating more than one block when it's not even necessary to have one:

MyClass>>#contents [
^[:e | | table |
table build: self buildTableRow]
]

MyClass>>#buildTableRow [
^[:table | | row |
row := table tr.
(row td) text: 'first cell'. ]
(row td) text: 'second cell' ]
]

versus:

MyClass>>#buildOn: anElement [
| table |
table := anElement table.
self buildTableRowOn: table.
]

MyClass>>#buildTableRowOn: row [
row := table tr.
(row td) text: 'first cell'.
(row td) text: 'second cell'
]

On Tue, May 4, 2010 at 20:36, Bèrto ëd Sèra <[hidden email]> wrote:

sebastien audier

Re: New method for building widgets?

You're right Eli.

it would be more effective.

Nicolas Petton

Re: New method for building widgets?

In reply to this post by Eli Green-5

Hi Eli,

Le jeudi 06 mai 2010 à 11:51 +0200, Eli Green a écrit :
> I may be misunderstanding the problem here but if you want to document
> the type of element that a widget renders on, you can just change the
> name of the parameter.

True.

>
> But I'm not sure this is really the relevant case. I think what we're
> talking about here is widgets which may very well not be aware of
> where they are being rendered: in the body, in a div, in a table cell.
> Who knows? ILCalendar, for example, shouldn't know or care what kind
> of element it's contained in.
>
> I also think there may be some efficiency gains here. Letting blocks
> render themselves is great for the case where it would be excessive to
> create an entire object to contain it but if we already have an object
> that knows how to render itself, forcing it to create a block seems
> counter-productive and a waste of memory / resources.
>
> In the case you show above, it's actually worse because you're
> creating more than one block when it's not even necessary to have one:

Yes it's true. Now the question is: is it worth it? How much
memory/building time does it waste?

Cheers,
Nico

signature.asc (205 bytes) Download Attachment

Eli Green-5

Re: New method for building widgets?

2010/5/6 Nicolas Petton <[hidden email]>:

>>
>> But I'm not sure this is really the relevant case. I think what we're
>> talking about here is widgets which may very well not be aware of
>> where they are being rendered: in the body, in a div, in a table cell.
>> Who knows? ILCalendar, for example, shouldn't know or care what kind
>> of element it's contained in.
>>
>> I also think there may be some efficiency gains here. Letting blocks
>> render themselves is great for the case where it would be excessive to
>> create an entire object to contain it but if we already have an object
>> that knows how to render itself, forcing it to create a block seems
>> counter-productive and a waste of memory / resources.
>>
>> In the case you show above, it's actually worse because you're
>> creating more than one block when it's not even necessary to have one:
>
> Yes it's true. Now the question is: is it worth it? How much
> memory/building time does it waste?
>

Not much, probably. That's not a major argument but efficiency is
always better if we can obtain it.

I personally do find it slightly more readable. I like to think of
ILWidgets as "the real thing" and blocks as anonymous versions of the
same. They're incredibly useful but if you're already encapsulated
inside a widget, forcing the creation of blocks is also syntactically
noisy.

I don't feel incredibly strongly about this, but if it makes the
framework more appealing and clear to outsiders then it's a definite
win.

Paolo Bonzini-2

Re: New method for building widgets?

On 05/06/2010 01:27 PM, Eli Green wrote:
> 2010/5/6 Nicolas Petton<[hidden email]>:
>>> In the case you show above, it's actually worse because you're
>>> creating more than one block when it's not even necessary to have one:
>>
>> Yes it's true. Now the question is: is it worth it? How much
>> memory/building time does it waste?
>
> Not much, probably. That's not a major argument but efficiency is
> always better if we can obtain it.

Compared to all the ILElements that you have to create anyway, blocks
are very very cheap.

> I personally do find it slightly more readable. I like to think of
> ILWidgets as "the real thing" and blocks as anonymous versions of the
> same. They're incredibly useful but if you're already encapsulated
> inside a widget, forcing the creation of blocks is also syntactically
> noisy.
>
> I don't feel incredibly strongly about this, but if it makes the
> framework more appealing and clear to outsiders then it's a definite
> win.

It would create some difference between controller methods (which you
name like #index and would have "self rootElement table: [...]") and
widgets (which would implement #buildOn:).

So it's not such a definite win...

Paolo

Nicolas Petton

Re: New method for building widgets?

> It would create some difference between controller methods (which you
> name like #index and would have "self rootElement table: [...]") and
> widgets (which would implement #buildOn:).

I agree. Even worse, it would make the building API less consistent
inside widgets too. Currently, you have:

MyApp>>index [
<category: 'controllers'>
^indexWidget
]

MyApp>>foo [
<category: 'controllers'>
^[:e | ...]
]

MyWidget>>contents [
^[:e | e
build: aBlock;
build: self otherMethodContents;
build: subWidget]
]

MyWidget>>otherMethodContents [
^[:e | ...]
]

As you can see, you have ILElement>>build: and "view blocks" everywhere,
and I find it very consistent. We would end up with something like:

MyApp>>index [
<category: 'controllers'>
^indexWidget
]

MyApp>>foo [
<category: 'controllers'>
^[:e | e ....]
]

MyWidget>>buildOn: e [
e build: aBlock.
self otherMethodOn: e.
e build: subWidget
]

MyWidget>>othermethodBuildOn: e [
e ...
]

which I find a lot less consistent.

Cheers,
Nico

signature.asc (205 bytes) Download Attachment