In this video of Chapter 11 of Learning Web Development with Seaside we create a form to collect information from the user. We start by launching the Seaside One-click Experience and then defining a new web component to edit events. We create a render content method that initially just shows the class name. We add an initialize method that saves a passed-in event. Now, on the class side we create a constructor method that takes an event and returns a newly initialize component.

Now we go to an earlier web component that lists all the events and add a method to call our new editor component. We modify one of the report columns so that instead of simply displaying information about the event it offers an opportunity to edit the event. When we view the event list in a web browser, we see that data in the ‘What’ column now displays as a link. Clicking on that link takes us to the editor, which simply displays its class name.

Now we will add true editing. We modify the render content method to show a form with labels and entry fields. (If you don’t like the table for styling, hang on a minute…) Using the web browser, we can edit fields in an event and see that they are modified.

Now, we will refactor our form to avoid the use of a table for layout. We create small methods for each element to be edited. Note that instead of table rows we have a div enclosing our elements. Rather than typing each method we are copying them from the tutorial. Finally we modify the render method to call each of our elements.

When we view the form in a browser, we see that the layout is no longer based on a table. To fix the layout, add some CSS styling to show the event editor as a table and note that the layout is now better. We find that the two buttons are treated as one column. We can add an empty field that causes the buttons to move over a column. If we want the buttons in separate columns we need to put them in a span. When that is done they display more evenly.

Now we modify our application to allow the creation of a new event. We add an ‘Add Event’ anchor to the event list, and see that it shows in the web browser. Clicking on the link gives an error since our callback message is not understood. We create the add method so that it creates a new event, allows the user to edit it, and then if the edit was saved the new event is added to the event list. We can try it out and see that saving a new event does give us a new event. Observe that we are using the new component for both editing existing events and collecting information on new events, yet the component does not know how it is being used. This is an example of good encapsulation and code reuse.

Note how we are using the result of the call, which answers true if the ‘Save’ button was clicked, to decide whether or not to add the new event to the saved event list. We can simplify the edit method since we don’t really need to alert the user to which button was pressed.

As we experiment with adding events, we discover that changing the date does not seem to work. Let’s go investigate that problem. Looking closely at the when field we see that we render the date/time but do not have a callback for any edits to the field. Internally this field is a DateAndTime, but it is being displayed as a string. Let’s fix that problem now. We will add an instance variable to our editor to hold another component, a date/time selector. When the component is initialized, we add a sub-component to collect the date/time. Then when we offer the field to be edited, we use the subcomponent rather than a text entry field. Remember to add a #’children’ method to let the Seaside framework know that we have added another component to the page. Finally, we modify the save callback so that the value is copied from the subcomponent to the model.

Now we would like to demonstrate some other form elements. Rather than having ‘who’ be a text entry field, we will modify it to use a drop-down list. We make a similar change for the ‘what’ portion of the event. We will show the where as a text area and modify the CSS to layout the text area. We can modify the report column to show a string for the date/time.

In order to demonstrate checkboxes, radio buttons, and some JavaScript interaction with CSS, we will add an attribute to LBEvent to keep track of whether a game is home or away. We add a ‘gameType’ instance variable and accessors. We then add some instance variables to the event editor to capture some characteristics of the event. We add CSS for hiding a form element.

Now we are going to add a method to render the ‘isGame’ and ‘gameType’ fields. Smalltalk alerts us to the fact that these methods do not yet exist and we confirm the selectors. We add the new methods, one with some JavaScript for an on-click event.

When we run the application from a web browser we discover a bug in the render when method. We should be using the message #’with:’ rather than #’value:’ to the span element. Fixing that in a debugger lets the form display. We can now view the editor and see various form elements. The who field is a drop-down list. The what field is a scrolling list. The when field is a subcomponent with a series of fields. The where field is a multi-line text area. Changing fields, including the date, makes appropriate changes to the event.

When we refresh the application we see that the ‘is game’ checkbox shows and hides the game type field. We modify the save method to store a value for the game type field, either home, away, or nil.

We save our new code and quit the Seaside One-Click Experience.

For more information go to