Smalltalk Daily 4/18/07: Seaside Example Cleanup

I find myself at odds with this example. It's certainly a valid way of doing things but I don't think its how most Seaside apps are written. The core issue is essentially about MVC vs. just MC. By having the model render itself the seaside component becomes just a controller, but I think they are meant to be views and controllers. I'd have written something more like

EmployeesComponent>>renderContentOn:

 

renderContentOn: html
	self employees 
	       do: [:each | self renderEmployee: each on: html]
	       separatedBy: [html break]

EmployeesComponent>>renderEmployee:

 

renderEmployee: anEmployee on: html
	html strong: anEmployee name

for a simple solution, or maybe

EmployeesComponent>>renderContentOn:

 

renderContentOn: html     
	self employees
	       do: [:each | htm render: (self editComponentFor: each)]
	       seperatedBy:  [html break]

EmployeesComponent>>editComponentFor:

 

editComponentFor: anEmployee
	employeeViews at: anEmployee ifAbsentPut: [EmployeeEditor for:
anEmployee] 

EmployeesComponent>>children

 
children
    "sub components must be returned as children of parent"
	^employeeViews 

EmployeeView>>renderContentOn:

 

renderContentOn: html
	html strong: employee name

for a more complex scenario

Keeping all of the view code in the component and out of the models. I don't think a generic renderOn: in the employee would actually be sufficient for writing a real application because an employee would have many different views depending upon where its being used. In a grid it might look one way, and it could be in several different grids of varying detail, while a read only view page or a full on edit page would look vastly different. I might have just different rendering methods, or possibly, depending upon the complexity of the view, entirely different components for rendering an employee model.

On the other hand, I hear Alan Hollub screaming MVC isn't object oriented and all components must render themselves and we shouldn't use MVC. Some of his points make a lot of sense, but I'm not totally convinced for the reasons I mentioned above. What's your take on this situation?

Ramon Leon
http://onsmalltalk.com

Comment by James Robertson

Ramon,

I'm actually trying to sort through the "preferred" way to do things with Seaside, and the tutorials all use what I'm now told is the old (and being replaced) render framework. So I'm now talking to Michel Bany, and getting suggestions from him as I take these examples forward.

As to the render code being in the domain - well, in the VW UI, it's common to find #displayString in domain classes (and that code will be used to print the object in things like listboxes and dataset (grid) widgets. So bottom line - I'm kind of inured to that level of mixing, and son't really have strong feelings about it

For simple string representation like displayString, I agree, great for select boxes, debugging, or simple lists, but I'm talking about real UI. One renderOn: can't really handle even the simple two cases you'd want, edit object and view object. It seems something that looks OK in a small sample but not at all something I'd see in a real world app. I wasn't really challenging what you did, more trying to start a discussion on the issue, because I do think there is some validity to MVC not being very object oriented. A view must totally violate the encapsulation of a model for it to work, as far as I can see.