[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-smalltalk] Iliad: did widgets change, too?

From: Nicolas Petton
Subject: Re: [Help-smalltalk] Iliad: did widgets change, too?
Date: Wed, 11 Nov 2009 10:19:31 +0100

Le mercredi 11 novembre 2009 à 07:12 +0200, Bèrto ëd Sèra a écrit :
> Hi!
Hi Bèrto,

> it may have been because of some misunderstanding of mine on previous
> versions, but I'm currently a bit puzzled at the way examples in 0.7.1
> look. My existing code was deriving a hierarchy from
> - Iliad.Widget
>   - LocalizedWidget
>      - AmbaradanLocalizedWidget
>        - WidgetSearch
> the actual WidgetSearch class had a #contents message in <building>
> that was making the HTML for the form. I was now to implement the
> effect of making a search and had a new look at how widgets work in
> examples (say, the Blog example)... and I find that
> 1) there is no direct hierarchy from Iliad.Widget, the widget is a
> subclass of Object and turns into a widget by an #asWidget message
> 2) components are not declared in a #contents message, but rather at
> class level, with a #descriptionFieldname message

This is a special case. The blog example is using Magritte descriptions,
and widgets are auto-generated. If you want to take a look at an
example, you can see the todo-list, which uses common widgets, and hash
routes to dispatch AJAX requests.

The blog example is explained here:

> Now I'll better describe what I'm trying to do. My example app is here
> (it works with ff3.5 only
> AFAIK) what I want is to enable the search widget and have it print
> out its results in the central white space (which is currently not a
> widget proper, but simply a div called 'centralDiv'). On showing up
> the results it must append the query to the widgetHistory on the left,
> so that one can keep track of his own searches.

It seems you have coupled widgets here. There are several approaches to
your problem.

First, in Iliad 0.7 you can build anonymous widgets.
This can be useful for your central content, because this way you have
state in your central div.

centralWidget := self widgetFor: [:e | e div: class: 'centralDiv']

This widget can later show anything you want, like the results:

self centralWidget show: anotherWidget

This may not be the flow you want here, because two consecutive search
actions will stack 2 widgets on top of your anonymous central widget.

In Iliad 0.7 we also added similar control flow methods named
#replace:with:, and #replace:with:onAnswer:

They work exactly like #show:* methods, except that several widgets
can't be stacked, so this example:

self replace: widget1 with: widget2.
self replace: widget1 with: widget3.
widget3 answer

will give control back to widget1.

You can also use Widget>>retreiveControl.

Finally, if you have actions which have effects on several widgets, you
can use #dependentWidgets hook methods. Those methods are used to
automatically update some widgets whenever a sepcific widget is marked
as dirty.

All those control flow methods are documented in Iliad.Widget, in the
'control flow' method protocol, so maybe if my explanations are not
helpful, you can understand it better by reading the comments.



Attachment: signature.asc
Description: Ceci est une partie de message numériquement signée

reply via email to

[Prev in Thread] Current Thread [Next in Thread]