Re: [Help-smalltalk] Re: Iliad - updatePage: aPage

[Nicolas Petton]

Le mardi 14 juillet 2009 à 08:19 +0200, Stefan Schmiedl a écrit :
> On Tue, 14 Jul 2009 01:57:30 +0200
> Nicolas Petton <address@hidden> wrote:
> 
> > Le mardi 14 juillet 2009 à 01:21 +0200, Paolo Bonzini a écrit :
> > > > Indeed, I thought about that when refactoring Application building
> > > > process. I thought that maybe being allowed to update any part of
> > > > the page could still be usefull, to add a script at the end of
> > > > the body, or add a css class to the body element.
> > > 
> > > This can be useful.
> 
> ah ... because the "e" I'm using to build the views on is at least
> one div below body, right?

Yes, every widget (so every application) is built inside a "_widget"
div.

>  And with the page not being available to
> the application any more, it would be non-trivial to get to the
> body element.
> 
> For the sake of the discussion: updateHead: and updateBody:?

What would be the reason for having two methods?

> 
> I still haven't explored how Iliad deals with decorators and what
> kind of things they can do. Assuming that they can wrap their contents:
> Would it make sense to implement the body tag as decorator?

Hmm. I'm not sure I like the idea. How could this be useful? The body
element is just an element :)

> 
> > 
> > That's also what I think, but I wanted to know other opinions.
> > 
> > What I would like now is to implement #updatePage: in Iliad.Widget
> > directly, so every widget would have a chance to udpate the page, load
> > css and js files on the fly, etc.
> 
> Be careful, there be dragons ... if you leave that to the widget, you 
> (as framework provider) will probably have to deal with annoying load
> order issues, which you can't fix in general, or at least complaints
> like "why does it load that plugin five times in a row?"

I'm sure there are ways to deal with it ;)

Cheers!

Nico

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