April 18, 2007 9:20:46.755
On today's Smalltalk Daily, I clean up yesterday's example so as to be more conformant with web and Seaside standards.
[Ramon Leon] April 18, 2007 21:10:26.000
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
do: [:each | self renderEmployee: each on: html]
separatedBy: [html break]
renderEmployee: anEmployee on: html
html strong: anEmployee name
for a simple solution, or maybe
do: [:each | htm render: (self editComponentFor: each)]
seperatedBy: [html break]
employeeViews at: anEmployee ifAbsentPut: [EmployeeEditor for:
"sub components must be returned as children of parent"
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?
James Robertson] April 20, 2007 10:01:40.436
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
[Ramon Leon] April 20, 2007 21:42:52.670
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.
comments(3) | permanent link | printer friendly | del.icio.us | diggIt | next | prev