In Seaside 2.21, the renderer has the #inHeadDo: method.
For Seaside 2.3, the renderer appears to be significantly changed. Where's the equivalent of #inHeadDo:?
Nevin
On Tue, 25 Mar 2003, Nevin Pratt wrote:
In Seaside 2.21, the renderer has the #inHeadDo: method.
For Seaside 2.3, the renderer appears to be significantly changed. Where's the equivalent of #inHeadDo:?
If you look at the implementation of WAHtmlBuilder>>title:, you'll see that it simply adds a node directly to the document's "head" element. You can model a #meta: method after this. My assumption is that there will be a small finite number of such methods, which will quickly get added to Builder; #inHeadDo: had a really ugly implementation and I don't see the need for the generality, so it's gone.
Avi
Avi Bryant wrote:
If you look at the implementation of WAHtmlBuilder>>title:, you'll see that it simply adds a node directly to the document's "head" element. You can model a #meta: method after this. My assumption is that there will be a small finite number of such methods, which will quickly get added to Builder; #inHeadDo: had a really ugly implementation and I don't see the need for the generality, so it's gone.
Avi
Like this?:
metaTagNamed: aName content: aString document head add: (WAHtmlElement named: #meta attributes: {'NAME' -> aName. 'CONTENT' -> aString}
Avi Bryant wrote:
On Tue, 25 Mar 2003, Nevin Pratt wrote:
Like this?:
metaTagNamed: aName content: aString document head add: (WAHtmlElement named: #meta attributes: {'NAME' -> aName. 'CONTENT' -> aString}
Looks fine to me.
This method (#metaTagNamed:content:) worked fine with the first SqueakMap iteration of 2.3.
But this code no longer works with the latest SqueakMap incarnation of Seaside.
Seems the attributes scheme has changed.
I'm starting to look into the problem now, but if anybody has the easy answer off the top of their heads of how to fix this method...
Nevin Pratt wrote:
Avi Bryant wrote:
On Tue, 25 Mar 2003, Nevin Pratt wrote:
Like this?:
metaTagNamed: aName content: aString document head add: (WAHtmlElement named: #meta attributes: {'NAME' -> aName. 'CONTENT' -> aString}
Looks fine to me.
This method (#metaTagNamed:content:) worked fine with the first SqueakMap iteration of 2.3.
But this code no longer works with the latest SqueakMap incarnation of Seaside.
Seems the attributes scheme has changed.
I'm starting to look into the problem now, but if anybody has the easy answer off the top of their heads of how to fix this method...
OK, easy enough. the attributes: argument is now a dictionary (or rather, a subclass of Dictionary) rather than an array of associations.
Not that it particularly matters, but why was this change made? In fact, precisely *because* it doesn't look like it particularly matters, why was the change made? There must be a reason that I'm not seeing.
On Thursday, Jun 12, 2003, at 18:53 America/Denver, Nevin Pratt wrote:
metaTagNamed:content:
Interesting... I don't find this method in my image at all... I'm using Seaside from CVS, but haven't updated in a couple of weeks.
On another note, could this technique be used to create a way to do the <script></script> tags and add javascript code to the head content?
Brian
Brian Brown wrote:
On Thursday, Jun 12, 2003, at 18:53 America/Denver, Nevin Pratt wrote:
metaTagNamed:content:
Interesting... I don't find this method in my image at all... I'm using Seaside from CVS, but haven't updated in a couple of weeks.
On another note, could this technique be used to create a way to do the <script></script> tags and add javascript code to the head content?
Brian
***************************** ***************************** Here's the earlier posts in this thread, which explains metaTagNamed:content: *****************************
On Tue, 25 Mar 2003, Nevin Pratt wrote:
In Seaside 2.21, the renderer has the #inHeadDo: method.
For Seaside 2.3, the renderer appears to be significantly changed. Where's the equivalent of #inHeadDo:?
If you look at the implementation of WAHtmlBuilder>>title:, you'll see that it simply adds a node directly to the document's "head" element. You can model a #meta: method after this. My assumption is that there will be a small finite number of such methods, which will quickly get added to Builder; #inHeadDo: had a really ugly implementation and I don't see the need for the generality, so it's gone.
Avi *****************************
Avi Bryant wrote:
If you look at the implementation of WAHtmlBuilder>>title:, you'll see that it simply adds a node directly to the document's "head" element. You can model a #meta: method after this. My assumption is that there will be a small finite number of such methods, which will quickly get added to Builder; #inHeadDo: had a really ugly implementation and I don't see the need for the generality, so it's gone.
Avi
Like this?:
metaTagNamed: aName content: aString document head add: (WAHtmlElement named: #meta attributes: {'NAME' -> aName. 'CONTENT' -> aString}
************************
On Tue, 25 Mar 2003, Nevin Pratt wrote:
Like this?:
metaTagNamed: aName content: aString document head add: (WAHtmlElement named: #meta attributes: {'NAME' -> aName. 'CONTENT' -> aString}
Looks fine to me.
************************ ************************
On Friday 13 June 2003 06:48 am, Nevin Pratt wrote:
Brian
Here's the earlier posts in this thread, which explains metaTagNamed:content:
Thanks Nevin, I have already read that thread... What I was musing about is whether that approach would work well for Javascript in the head of the document, or whether some sort of stream based approach would work better. Typically, if you are doing Javascript based navigation, there are two parts: 1) is the code in the <script></script> tags in the head and the other is the event code in the html form element or href, like onClick() or onChange().
Usually, you wouldn't want multiple <script></script> tags in the head, although they would work. If the handlers could be specified in the same methods as the callers of the handlers, thus creating one "submitFunction()" that handled all of the javascript actions on a particular page rendering it would be ideal.
Even another thought is doing is like the style stuff is done, where a dynamic style sheet is created and the link is put in the head... that is probably the way to go, isn't it?
any thoughts?
Brian
On Thu, 12 Jun 2003, Nevin Pratt wrote:
OK, easy enough. the attributes: argument is now a dictionary (or rather, a subclass of Dictionary) rather than an array of associations.
Not that it particularly matters, but why was this change made? In fact, precisely *because* it doesn't look like it particularly matters, why was the change made? There must be a reason that I'm not seeing.
Well, it's not actually a subclass of Dictionary. It's WAHtmlAttributes, which keeps an OrderedCollection of associations, but does present a dictionary-like interface (#at:put:).
You stumbled upon this when building a WAHtmlElement from scratch. The change wasn't made with this case in mind (the only time you need to do this is when adding a head element), but so that WAHtmlRenderer>>attributes: could be deprecated in favor of WAHtmlRenderer>>attributes. That is, where you used to write
html attributes: {'width' -> 23. 'height' -> 42}.
I would now recommend using
html attributes width: 23; height: 42.
This required introducing an HtmlAttributes class that responds to #width:, #height:, #valign:, etc. Currently it does this with DNU, although in the long run it should probably just have all the valid attributes as methods.
There were two reasons for this change. One is that it allows for more abstraction at the attribute level - for example, you could add verbose aliases such as #verticalAlignment: if you were so inclined, or better yet #alignTop, #alignMiddle, #alignBottom.
The other is that it reduces the use of the non-portable {} syntax; this was an issue for the VW port.
Hope that answers your question.
Cheers, Avi
seaside@lists.squeakfoundation.org
-
Avi Bryant -
Brian Brown -
Nevin Pratt