Smalltalk › Frameworks & Tools › Seaside › Seaside General

How to approach building a Deltawerken application, Part 1

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

5 messages Options

Stephan Eggermont-3

How to approach building a Deltawerken application, Part 1

Class categories

When building a Deltawerken application called AppName, create the following
class categories:

AppName-Model
AppName-Model-Tests
AppName-Web
AppName-Announcements

Put the domain classes in AppName-Model
Drive the development of the domain classes from tests in AppName-Model-Tests
Put the Seaside related code in AppName-Web
The Announcements for navigating the site go in AppName-Announcements

Once either of those categories gets too large (when you need to scroll the list
of classes in the category), create a fitting new category and distribute the classes.
Now Beach-Parasol allows web testing with Selenium Webdriver, you probably
also want to create AppName-Web-Tests (http://ss3.gemstone.com/ss/Parasol.html)

Accessing the model

To access the model from the web, you either give (at least) one of the domain classes
a class (instance) var or add a separate model class.

In Storyboard, SBUser has a class instance variable users. The class method users
returns these users, and when nil creates a collection of users with a default administrator.
During development, the class method resetUsers allows cleaning up.

The alternative would be to add a class SBModel with a class variable default.
SBModel>>default
^default ifNil: [default := self new]

SBModel>>reset
default := nil

Then add accessors for the entry points
SBModel>users
users ifNil: [users := OrderedCollection new.
self addDefaultUsers].
^users

Describing the model classes

To create editing or reporting forms, describe the model classes
and create an accessor returning an array of methodSymbols

SBStory>>fields
^#( storyNameField #descriptionField typeField sizeField stateField historyField)

At the class side, create a xxxField method for all needed fields.

SBStory has a storyName instance variable. The storyName is
a required string.

SBStory>>storyNameField
^DEStringField new
label: 'Name';
accessor: #( #storyName );
validator: (DEStringValidator new
required: true;
errorMessage: 'Name is required'
yourself);
yourself

SBMember has a user instance variable. In a report, its email is needed

SBMember>>emailField
^SBUser emailField
addToAccessor: #( #user );
beReadonly;
yourself

Creating the application

Add a subclass of WAFileLibrary to AppName-Web. Put the css in mainCss,

SBFileLibrary>selectorsToInclude
^#( mainCss )

Create a application entrypoint. In StoryBoard this is SBMain, a subclass of
WAComponent. It renders its children

SBMain>children
^Array with: self loginForm with: self mainForm

Easiest is to create a copy, change class side description and initialize
Don't forget to add your filelibrary. The sessionClass is often not needed.
Change instance side title and the createLogin and createMainForm methods.

The createMainForm creates a DEPageChoice component. It needs to interact
with the loginForm. When the register button is pressed, the loginForm sends
the SBRegisterUser announcement. The addPage:announcement: makes sure
that the page is shown when receiving the announcement. Deltawerken has
default announcements for logging on and off

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Intrader Intrader

Re: How to approach building a Deltawerken application, Part 1

Stephan Eggermont <stephan <at> stack.nl> writes:

A helpful description - however, I find it disconscerning that there is
no category StoryBoard-Model, StoryBoard-Model-Texts, or
StoryBoard-Announcements in the StoryBoard source.
It is not clear in the description which are class instance variable
names like it the case in the class method fields.

Thanks

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

DiegoLont

How to approach building a Deltawerken application, Part 2

In reply to this post by Stephan Eggermont-3

User management

To set up user management, create an application specific user class. In AppName-Model, create a subclass of DEUser. See accessing the model for using users as model entrypoint.

In StoryBoard you can find the SBUser class. In order to be able to login, use a subclass of the DELoginForm. Override the "userClass" method, and the form is ready to use. It has some tags to allow you to customize the look and feel using css. In Storyboard this is used to allow you to register in addition to logging in.

EditForm and EditPanel

To let the user edit the model, use edit forms and edit panels. An EditForm is for editing a single object. Create an EditForm and set the "subject" to the object to edit. Note that the form needs to know whether it should create a new instance, or needs to make a (field)copy or not. The method to set a subject is "subject: aSubject isNew: aBoolean". The flag indicates if the object is new, and does not need copying or if it is an existing object and should be copied before editing.

The EditPanel is used when you need to edit multiple objects on the same page, and they either should be saved all together, or not saved at all (i.e. if validation of one of the objects fails). The interface of the EditPanel is very similar to EditForm, it has a "addSubject: aSubject isNew: aBoolean" method, that adds another EditComponent to the panel. You can also add EditComponents directly to the EditPanel.

StoryBoard only uses EditForms. The first EditForm you can find is in the SBRegisterUserForm. It is used to add new users, so the isNew flag is set to true. At this point the EditForm is a child of the SBRegisterUserForm, so the save and cancel action should be set. Alternative a EditForm can be shown modal, it returns nil on a cancel and the changed value on save.

createEditForm
^DEEditForm new
subject: SBUser new isNew: true; " create a new user, and allow the edit form to change it "
title: 'Register user'; " title is optional and is shown as a heading "
propertySymbol: #initialEditFields; " normally password cannot be set when editing user, only initially, so a different field set is used "
saveAction: [ self save ]; " is called when the user presses save, and the user is valid "
cancelAction: [ self cancel ]; " is called when the user presses cancel "
yourself

Reports

To display collections reports are most useful. Reports are created by a builder. The builder has more or less the same options as a editForm. Reports should be refreshed when needed by setting the rows on rendering.

In StoryBoard the project overview makes use of a report for showing the projects. The builder is asked in the createProjectReport to create the appropriate report.

createProjectReport
| builder |
builder := DEReportBuilder new
subject: SBProject; " use the description of SBProject to build the report "
propertySymbol: #reportColumns; " use the field set 'report column fields' to build the report "
yourself.
builder addCustomColumn: self teamColumn.
^builder createReportFrom: self accessor: #showProject:

And the render method looks like this:

renderProjectsOn: canvas
self projectReport rows: self projects. " we set this the rows here, to automatically update the content each time it is rendered. "
canvas heading
level: 2;
with: 'Current projects'.

canvas render: self projectReport.

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

DiegoLont

Re: How to approach building a Deltawerken application, Part 1

In reply to this post by Intrader Intrader

On Sep 16, 2012, at 6:44 PM, intrader wrote:

> Stephan Eggermont <stephan <at> stack.nl> writes:
>
> A helpful description - however, I find it disconscerning that there is
> no category StoryBoard-Model, StoryBoard-Model-Texts, or
> StoryBoard-Announcements in the StoryBoard source.
I guess we should have named the category StoryBoard-Data "StoryBoard-Model" and the category StoryBoard-Web-Announcement, StoryBoard-Announcement. Thanks for the issue report, we will fix it.
>
> It is not clear in the description which are class instance variable
> names like it the case in the class method fields.
I do not understand this remark. The only instance variable on the class side is the users. The users have access to the data (through their projects).

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Intrader Intrader

Re: How to approach building a Deltawerken application, Part 1

Diego Lont <diego.lont <at> delware.nl> writes:

> > It is not clear in the description which are class instance variable
> > names like it the case in the class method fields.
> I do not understand this remark. The only instance variable on the class side
is the users. The users have
> access to the data (through their projects).
>

THank you for your comments, it does clarify matters.
As to my last statement, it is not clear; I apologize. What I meant to say is
that the class instance variable users; fields is a class mathod.

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside