Difference WAStaticHtmlCanvas >< WAHtmlCanvas

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Difference WAStaticHtmlCanvas >< WAHtmlCanvas

Claus Kick
I am still in the process of trying to understand how Seaside works, so
please bear with me :)

I am gathering notes for myself and possible a former colleague or two,
so I am intruiged about really understanding what is going on.

Today I had a look at The WACanvas hierarchy, but I do not understand
the difference between WAStaticHtmlCanvas and WAHtmlCanvas.

What is meant by "This canvas can be used to generate static/RESTful
HTML pages." if WAHtmlCanvas also knows about HTML, hence static things?

WARenderCanvas is the class where all the callback items are being
stored, so the difference between that and the other two is clear.

If somebody could be so kind as to shed some light on this (probably
unimportant question)?

Cheers,

Claus
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

RE: Difference WAStaticHtmlCanvas >< WAHtmlCanvas

Ramon Leon-5
> Today I had a look at The WACanvas hierarchy, but I do not
> understand the difference between WAStaticHtmlCanvas and WAHtmlCanvas.
> Cheers,
>
> Claus

Look closer, WAHtmlCanvas is an abstract class, #document must be overridden
by subclasses.  They are mostly the same thing, WAStaticHtmlCanvas is just a
concrete implementation for it.  If WAStaticHtmlCanvas didn't exist and you
used WAHtmlCanvas directly, you'd have the WARenderCanvas inheriting from an
implementation class.  With the current implementation, WAStaticHtmlCanvas
is free to grow without messing up WARenderCanvas, it's cleaner the way it
is, one abstract class with two concrete implementations.  

I'm looking at 2.8 btw, it may have changed in 2.9.  It does look like
#textArea needs pushed up, it's the same in both subclasses.

Ramon Leon
http://onsmalltalk.com


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Difference WAStaticHtmlCanvas >< WAHtmlCanvas

Philippe Marschall
2008/3/12, Ramon Leon <[hidden email]>:

> > Today I had a look at The WACanvas hierarchy, but I do not
>  > understand the difference between WAStaticHtmlCanvas and WAHtmlCanvas.
>
> > Cheers,
>  >
>  > Claus
>
>  Look closer, WAHtmlCanvas is an abstract class, #document must be overridden
>  by subclasses.  They are mostly the same thing, WAStaticHtmlCanvas is just a
>  concrete implementation for it.  If WAStaticHtmlCanvas didn't exist and you
>  used WAHtmlCanvas directly, you'd have the WARenderCanvas inheriting from an
>  implementation class.  With the current implementation, WAStaticHtmlCanvas
>  is free to grow without messing up WARenderCanvas, it's cleaner the way it
>  is, one abstract class with two concrete implementations.
>
>  I'm looking at 2.8 btw, it may have changed in 2.9.  It does look like
>  #textArea needs pushed up, it's the same in both subclasses.

It's still like this, I reported a bug:
http://code.google.com/p/seaside/issues/detail?id=31

Cheers
Philippe
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Difference WAStaticHtmlCanvas >< WAHtmlCanvas

Claus Kick
In reply to this post by Ramon Leon-5
Ramon Leon wrote:

>>Today I had a look at The WACanvas hierarchy, but I do not
>>understand the difference between WAStaticHtmlCanvas and WAHtmlCanvas.

> Look closer, WAHtmlCanvas is an abstract class, #document must be overridden
> by subclasses.

Ok, missed that. I think I read the arrow-down symbol as arrow-up.

> They are mostly the same thing, WAStaticHtmlCanvas is just a
> concrete implementation for it.  

One thing to mention there: the class comments should reflect that then.

 > If WAStaticHtmlCanvas didn't exist and you
> used WAHtmlCanvas directly, you'd have the WARenderCanvas inheriting from an
> implementation class.  

My understanding was: WAHtmlCanvas provides the basic tags and
WARenderCanvas adds the callback items.

 > With the current implementation, WAStaticHtmlCanvas
> is free to grow without messing up WARenderCanvas, it's cleaner the way it
> is, one abstract class with two concrete implementations.  

I agree, it is cleaner that way.

> I'm looking at 2.8 btw, it may have changed in 2.9.  It does look like
> #textArea needs pushed up, it's the same in both subclasses.

I was wondering about that as well, but forgot to ask about it.  Doesnt
it need actually to be deleted in WAStaticHtmlCanvas? The other input
elements are all in WARenderCanvas.

Cheers,
Claus
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

RE: Difference WAStaticHtmlCanvas >< WAHtmlCanvas

Ramon Leon-5
> I was wondering about that as well, but forgot to ask about
> it.  Doesnt it need actually to be deleted in
> WAStaticHtmlCanvas? The other input elements are all in
> WARenderCanvas.
>
> Cheers,
> Claus

Yes actually, seems only the WARenderCanvas should have form elements since
forms aren't static html.

Ramon Leon
http://onsmalltalk.com

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Difference WAStaticHtmlCanvas >< WAHtmlCanvas

Philippe Marschall
2008/3/12, Ramon Leon <[hidden email]>:

> > I was wondering about that as well, but forgot to ask about
>  > it.  Doesnt it need actually to be deleted in
>  > WAStaticHtmlCanvas? The other input elements are all in
>  > WARenderCanvas.
>  >
>  > Cheers,
>  > Claus
>
>
> Yes actually, seems only the WARenderCanvas should have form elements since
>  forms aren't static html.

Well but then also only WARenderCanvas should have #anchor. I see no
problem of WAHtmlCanvas having #form #xxxInput and #anchor. If you're
willing to add names to fields there should be no reason why you
shouldn't be able to use them in WAStaticHtmlCanvas.

The current state is simply inconsistent.

Cheers
Philippe
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside