[Seaside] Another refactoring question : Where to put the 'view' or 'edit' logic for data classes?

Miguel Enrique Cobá Martínez miguel.coba at gmail.com
Sat Aug 21 19:31:32 UTC 2010


El vie, 20-08-2010 a las 21:31 -0700, Rick Flower escribió:
> Hi all..
> 
> Still working on the refactoring.  For those of you that have Seaside  
> based apps, where do you keep the view/edit logic for each data class/ 
> object that will be viewed or edited by a user?  I was thinking of  
> just putting some sort of logic directly in each data class but if I  
> need to do both a view and edit operation that limits the flexibility  
> without extra logic..
> 
> Should I just go for separate classes that each do either a view or  
> edit function for each needed data class?  Or are there better  
> suggestions out there?

I use different classes for the editors/viewers/listers of my domain
objects, for example:

domain class
---------------
AzObject subclass: #AzPreferences
	instanceVariableNames: 'preferences'
	classVariableNames: ''
	poolDictionaries: ''
	category: 'Azteca-Model'

Editor
---------
AzPreferencesEditor class>>preferences: anObject
	^ self new
		preferences: anObject;
		yourself


AzPreferencesEditor>>renderContentOn: html
	html div
		class: 'title';
		with: (self legendFor: self preferences).
	self renderPreferencesOn: html.

AzPreferencesEditor>>renderPreferencesOn: html
	html form: [
		html paragraph: [ self renderLocaleOn: html ].
		html paragraph: [ self renderButtonsOn: html ]]

AzPreferencesEditor>>renderLocaleOn: html
	html label with: self session l10n locale.
	html break.
	html select
		list: AzLocale localeList;
		selected: self preferences l10n;
		callback: [ :value | self preferences l10n: value ];
		labels: [ :value | value localeString ]

AzPreferencesEditor>>renderButtonsOn: html
	html submitButton
		on: #save of: self;
		text: self session l10n save

Viewer
--------
AzPreferencesViewer class>>for: anObject
	^ self new
		preferences: anObject;
		yourself

AzPreferencesViewer>>renderContentOn: html
	html div
		class: 'title';
		with: self session l10n preferences.
	self renderPreferencesOn: html.

AzPreferencesViewer>>renderPreferencesOn: html
	html table
		class: 'info';
		with: [
			html tableRow: [ self renderLocaleOn: html ]]

AzPreferencesViewer>>renderLocaleOn: html
	html tableHeading
		with: self session l10n locale.
	html tableData: self preferences l10n localeString


This way the domain object can be tested alone without having mixed
front end functionality with domain object functionality.

Cheers
-- 
Miguel Cobá
http://miguel.leugim.com.mx



More information about the seaside mailing list