Iliad: did widgets change, too?

Hi!

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

So, at application level:

actionsContents [
        <category: 'building'>
        ^[:e |
            | div |
            div := (e div)
                class: 'actions';
                yourself.
            div a
                text: 'new post';
                action: [self addPost]]
    ]

behaves more or less like I was used to. Yet, addPost goes

addPost [
        <category: 'actions'>
        self
            show: (((BlogPost new asWidget)
                addValidatedForm;
                yourself) addMessage: [:e | e h3:'Add new post'])
            onAnswer: [:ans | ans ifNotNil: [self model posts add: ans]]
    ]

which shows the form on a blank page and processes the input. At this
point I see a 'model' thing that kind of naturally recalls views and
controller we already met, but I cannot remember seeing anything that
would explain how to use them properly.

Now I'll better describe what I'm trying to do. My example app is here
http://www.voxhumanitatis.net/ambaradan (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.

I'm not asking you to write code for me, obviously, but I'd really
appreciate a basic guidance as per what is a "canonical" approach to
widgets in Iliad, so I can avoid wasting time :)

Berto
--
==============================
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.


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

Le mercredi 11 novembre 2009 à 07:12 +0200, Bèrto ëd Sèra a écrit :
> Hi!
>
Hi Bèrto,
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:
http://smalltalk.gnu.org/blog/nico/iliad-examples-explained-part-ii


> Now I'll better describe what I'm trying to do. My example app is here
> http://www.voxhumanitatis.net/ambaradan (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.


HTH,

Nico

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