Iliad - updatePage: aPage

Hi Nico,

what exactly is updatePage: aPage for?

We all seem to be using it to update head information and guessing
from the position in respondOn: it is not intended to modify the
body element.

        | page |
        page := self defaultPageClass new.
        self buildOn: page body.
        self updatePage: page.
        page respondOn: aResponse

So why not call it "updateHead: aHead" and use it like

        | page |
        page := self defaultPageClass new.
        self buildOn: page body.
        self updateHead: page head.
        page respondOn: aResponse

Later,
s.


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

Le lundi 13 juillet 2009 à 21:52 +0200, Stefan Schmiedl 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.


Now, if everyone think it's completely useless, then I agree,
#updateHead: would be more convenient.

Cheers!

Nico

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

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

Paolo


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

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.

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.

Nico

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

On Tue, 14 Jul 2009 01:57:30 +0200
Nicolas Petton <[hidden email]> 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? 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:?

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?

>
> 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?"

s.

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

Le mardi 14 juillet 2009 à 08:19 +0200, Stefan Schmiedl a écrit : 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 :)
I'm sure there are ways to deal with it ;)

Cheers!

Nico

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

On Tue, 14 Jul 2009 08:59:34 +0200
Nicolas Petton <[hidden email]> wrote:

> >  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?

descriptive method names? I'm not sure of those myself, I just thought
I'd bring them up.

> > 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 :)

Aha... then decorators have to be widgets for that to be an argument :-)

really off to work now,
s.

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