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 |
> 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 |
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 |
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 |
> 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 |
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 |
Free forum by Nabble | Edit this page |