Hello.
This sequence covers the Seaside web framework,
an innovative way of building web apps in Pharo.
Seaside is powerful and flexible.
It is based on the concept of reusable, stateful components,
on top of a stateless protocol, HTTP, in Web applications.
Seaside is secure by default, of course.
It integrates all the latest Web 2.0 techniques,
like Ajax, etc., and REST architectures.
This is the Seaside URL.
You can refer to it for documentation like the free online Seaside book.
It also offers a set of Seaside tutorials.
Lastly, you can ask questions on the Seaside mailing list.
An active community will reply to any questions you may have.
A little history: Seaside has been in production since 2002.
It is actively maintained.
The Seaside framework is the basis
for many Pharo success stories.
Those stories are online on the Pharo site, pharo.org.
As you'll see, there are many web projects,
and most use the Seaside framework.
As I was saying, Seaside is a web framework
centered on the component concept.
These components are reusable and stateful.
It has a domain-specific language to render the components in HTML.
The rules for composing these components
will be covered in a later sequence.
A web application is just a root component.
Seaside makes it possible to debug applications on the fly,
in the Pharo debugger.
In a later sequence of this course, you will learn
how to use metadata to generate forms automatically.
These are some of the examples
of web applications built with Seaside, in production since 2002.
I'll zoom in on a few of them.
This application makes extensive use of graphs,
and other interlocking components that make a complex application.
Here's another example of an application you can find on Pharo's website.
It features reporting tables
that are quite complex, interlocking with each other.
That can be built very simply with the Seaside framework.
The main concept in Seaside is the component.
A component is a subclass of WAComponent
supplied by the Seaside framework.
A component is reusable and stateful.
It can be rendered in HTML in the form of , etc.
In Seaside, a web application has a root component -
in this case, WACounter,
saved in the system as a web application.
It will be named "Counter," and accessible as such, from the URL.
Here's an example of my Counter application, in the URL.
It's a component rendered in HTML, here.
The value of the counter is zero. We have two links, here.
You click on ++ to increase the counter value,
and on -- to decrease the value.
The code for implementing this application is very simple.
I create a subclass of WAComponent: WACounter.
It has an instance variable named count.
The initialization method sets the counter to 0.
One method increases the value, the other decreases it.
Now we need the HTML part,
so the counter is rendered in HTML.
All we have to do is endow it with a method,
renderContentOn, a parameter.
The parameter will help us generate the HTML code.
Here's the example, with the addition of "renderContentOn"
to the counter class.
I use this parameter, a conventional Pharo object.
It's an instance of the class WAHtmlCanvas, supplied by Seaside.
I send messages to this object to generate the HTML code,
and a heading and an anchor, or link.
The "callback" message enables me to specify
a block of code to execute when I click on the link.
Here, when I click on the link called ++,
the "self increase" method is executed.
Clicking on -- prompts the execution of the "self decrease" method.
It's so simple.
If an error occurs when I click on a link; i.e., in a callback,
I knowingly have inserted a "halt" point. It could be an error.
I've inserted a halt point in the decrease method.
"Self" will halt if the counter is decreased below zero.
That will bring up the debugger.
As you see, if I do this in my web application,
the debugger is displayed here.
Here's the program's application stack, with the method "RenderContentOn"
and the decrease, here.
We did stop on haltIf.
I can modify the code right here,
press "Proceed,"
and my application will receive the HTML response
as if nothing had happened.
Another problem in Web applications is the "back" button.
When the user clicks on "back,"
it desynchronizes the server and client.
Imagine I increase the counter 5 times. Now it reads "5" on my screen.
Then I click on the back button in my browser.
The counter now reads 4.
But the server isn't updated about my back-button click.
So if I click again on ++, the screen will display a 6.
The problem is, the server side thought we were still on 5.
5+1 = 6.
Seaside makes it very easy to handle the back button.
We define a new method on the counter class: "states."
It will return the array for which the state is to be preserved
when the back button is hit.
In this case, it is only the object self: the counter.
Now, if I press "back," and then click on ++,
I should see 5 again.
Callbacks are actually blocks of code
that contain all of Pharo's power.
I can write any Pharo code in this callback.
I took a more complex example here.
I can use an alternative "if" to say if I increase the counter + 1
or + 2, depending on whether the count is odd or even.
For even numbers, the counter will increase faster than for odd.
As you see, Pharo is really a powerful language
in these callback blocks.
To return to the preceding example, if I click on ++ here,
it brings me to a new window,
telling me it is an even number.
Next, I'll show you how to write a greeter application.
The user enters his first name.
He types it in here, and when he clicks on "Say Hello,"
we want to display a string of characters: "Hi" and the user name
he entered in the beginning, here.
It's very easy to code for that in Seaside.
I create a subclass Component of the class Greeter.
The instance variable is Username.
The method renderContentOn I'm showing you here
displays the field "Username."
The next line is textinput.
That's the text field you saw before, where the user writes "Bob."
I will have one callback.
This time, it is a block with a parameter, "value."
The value parameter of this block will be the string of characters
the user entered.
We can store it in the instance variable
of the Greeter component UserName.
Next, when the "submit" button is clicked,
I'm going to call a new component, using the command selfinform.
I tell it to display the string "Hi, Bob."
I concatenate the character string "Hi" with the text entered as UserName.
I hope those of you who are used to coding web applications
noticed that Seaside does not require
manual request parsing to find parameters in requests or URLs.
It does not require XML configuration files, or indeed, files or pages.
I did not say anything about links to the next page.
The only thing I talked about was components:
objects and messages.
I talked about callbacks
and the ability to debug live, using the Pharo debugger.
In sum, it's easy to build web applications in Seaside.
There is one root component. Components can be combined
to build more complex applications.
A component renders itself in HTML with renderContentOn.
We have an extensible domain-specific language
that generates HTML code for each component.
We'll cover that in greater detail in the next video.