Wednesday 29 April 2009

Proposal 10: Move it all to WARequest

Handling requests is one of the most important atomic tasks of Seaside, because this governs all the rest.

Currently, the knowledge about requests is scattered over different classes. Just two example out of many:

WABrowser -> initialRequest
aRequest fields at: 'class' :.............
(A string used as key and, even worse, one which is impossible to track, because there are so many.)

WAApplication handleRequest:
aRequest fields at: self handlerField..........

This violates encapsulation and it's no object-oriented design. Only the class WARequest should know about its internals, it's data, keys etc. and it should be interrogated by other classes via clear protocols, which hide all internals from these other classes.

I have mentioned this before, but because this bad design was essentially the cause for having to search for a bug yesterday I am bringing this up again.

No comments:

Post a Comment