Re: [Help-smalltalk] [ANN] a new lightweight web framework for GST

[Nicolas Petton]

Le dimanche 21 juin 2009 à 11:57 +0200, Joachim Jaeckel a écrit :
> Hi Nico,
> 
> > I forgot to explain something that is probably important...
> 
> Indeed... ;-)
> 
> > That's fine as long as your widget is stateless (and if so you don't
> > need widgets, just elements which are stateless), 
> 
> Okay. If I would like to use Elements instead of Widgets, from which 
> class should I subclass? 

Elements are just stateless objects that know how to build themselves in
HTML.

So if you have a view method where you don't need widgets, just write it
with elements only:

index [
        <category: 'views'>
        ^[:e |
                e h1: 'Hello world'.
                e text: 'Thi part of my application is obviously stateless. I 
don''t
need widgets here'] 
]


> (I haven't currently found another class of 
> elements, which provide the #contents method, or do I have to handle 
> elements in a different way?)

No, just use them in view methods, you don't have to create subclasses.

> 
> Maintaining state means also, if I #show another widget, and would like 
> to go back afterwards to the same dialog...?

Yes, that, but not only. Take a look at the counter widget. It maintains
state to the client: it's count value.

If this counter wasn't saved as an instance variable of the application,
a new one would be built for each request, so it wouldn't work...

> 
> That would also mean, that widgets need to #build only once? (Mmmhh, no, 
> #build is the process to build the page-content, isn't it?)

#build is the process of building HTML. each widget can be built
separately, and that's actually what is happening when a widget is
updated with an AJAX request, only the updated widget is rebuilt.

> 
> If I need a statefull widget in one place, then all the parent-pages 
> should also be a widget.

> 
> Homepage --calls--> Login --calls--> Register
> 
> The content of "Homepage" is unimportant, would every time newly 
> generated, Login is a oneTime dialog, there's also no need to maintain 
> state (as an Example...) but Register should maintain state, to have the 
> possibility, to display an error message and to choose another username, 
> etc. if the username is already existent. In this case, Login and 
> Homeapge should also be Widgets, because I could save Register in Login 
> and Login in Homepage and Homepage in the Application...?
> [ I know, the above example lacks a bit of logic, normaly Login is also 
> statefull, because of error-messages for wrong user-input. ]

Yes, that's the idea. Widgets are stateful hight level html builders.
ELements are just low level objects for building html.

> 
> 
> Yesterday evening, I wrote another blog-post about Iliad, would it be 
> possible for you, to have a look at it (even for the future, for new 
> posts), that mistakes which I probably do in using the framework attract 
> attention as early as possible?

Another cool post :) Thanks!

The blog post great, don't worry. Maybe you could show how to use
actions in links and in forms? this mechanism is the basis of stateful
ressources in Iliad.

 If you don't know how to use action blocks, I can provide you several
examples, but looking at this: 

entries do: [ :each |
                (ul listItem anchor) text: each key; action: each value

It seems that you already know that ;)

Cheers!

Nico

> 
> Regards,
> Joachim.

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