[Seaside] RE: cssClass and cssID (was testing framework)

Avi Bryant avi at beta4.com
Fri Jul 23 21:45:20 CEST 2004


On Jul 23, 2004, at 8:52 AM, Brian Brown wrote:

> I think the second way introduces an unnecessary layer of abstraction 
> - yes, each individual method is cleaner to read the CSS info, but 
> overall it would be much more difficult building that component; I 
> like the conciseness of the first one.

Probably true.

> What about the idea of assigning each component a default css name 
> based on the name of the component. All elements rendered in that 
> component would be in a namespace (from a CSS perspective) like:
>
> MyComponent.table
> MyComponent.h3
>
> etc. This would follow the standard CSS inheritance, giving very fine 
> grained control to each component only if desired.

Yes, this makes good sense.  The question is, I guess, where you hang 
that class.  Do you wrap every component in a div automatically?  But 
some components should be in spans instead, and some probably shouldn't 
be in either.  So are there methods #wantsDiv, #wantsSpan that can be 
overridden?  Or maybe there are #divClass and #spanClass methods, and 
if either is overridden to return something non-nil, then the 
appropriate tag is used (and you could have, by default,

divClass
	^ self class name

)

> This doesn't help with <div /> but those are structural anyway, and it 
> is very useful to see what is being rendered inside of a particular 
> div element when editing the render methods. Just for various text 
> styles, spanClass:with: and spanNamed:with: don't seem too cumbersome. 
> Using this scheme, a #spanText: could also be created that acted like 
> #text:  So instead of:
>
> 	html span: [html text: 'Some words']
>
> you would have:
>
> 	html spanText: 'Some words'.

There's no need for #spanText: - this will already work:

	html span: 'Some words'.

Methods like #span: aren't actually expecting a block specifically 
(though a block is the most common thing to give them), they're 
expecting anything that implements #renderOn:.  It's just that:

BlockContext>>renderOn: aRenderer
	self value

Avi



More information about the Seaside mailing list