[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