Smalltalk › Instantiations

Understanding Anchors for moving between pages in Seaside

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

4 messages Options

Totally Objects

Understanding Anchors for moving between pages in Seaside

This is making me feel really stupid. Either I have lost half my brain
or things really are difficult in Seaside - and I know which answer I
think it is - grin.

I have run throught the To Do List tutorial and have implemented this
so that it works correctly.
I have then transferred this to a single page of my new application
which worked fine.

I now need to put some links on the top of the page to enable the user
to use other functionality.

I have sorted out how to use WAAnchor to provide a link to an external
web site. However, I need to add a home page to the page I have
working.

I have created another Seaside class and would now like to link to it
keeping the current session going.

Let us say the the existing class is called OBSWCarInput and I want to
link from this page to a class called OBSWDefaultPage.

I have searched the web and everone covers the simple link as used in
the To Do list but I can't find anything that covers linking to
another class.

I did try html anchor callback: [ OBSWDefaultPage new] with: 'Home'
but this didn't work.

Any help would be appreciated.

David

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

SebastianHC

Re: Understanding Anchors for moving between pages in Seaside

Hi David,

first I would like to give you a little hint for your further investigations,... but I guess you know it.

http://book.seaside.st/book

Second to your question.

If you don't really need access a previous state of the component you want to open you just implement:

html anchor callback: [self show: MyOtherComponent new] with: 'MyLinkToOtherComponentLabel'.

But if you want to access a component wich you have already used an you want to access the previous state you need to have a place where you keep your states.
This can look like:

html anchor
callback: [self mainComponentOrMenu selectComponent: MyOtherComponent " or #MyOtherComponent , or some other sort of key"];
with: 'MyLinkToOtherComponentLabel'

This would mean that some other accessible component or even the session or some handler has in instancevariable in form of a dict which keeps such initialized components.
I think you will find something like this in the Scriptaculose or jQuery Testexamples, or even in the Announcemnt package.

Such mainComponentOrMenu would habe in his rendercontentOn: method something like:

renderContentOn: html

html render: self currentSelectedComponent

I hope this helps you a little further.

Regards
Sebastian

Louis LaBrunda

Re: Understanding Anchors for moving between pages in Seaside

In reply to this post by Totally Objects

Hi Dave,

Perhaps an overview of one way of building a Seaside web app will help. I'm not a Seaside expert but I am working on a Seaside project at the moment. I think it was Joachim who put me on to this approach a few years ago when I first started working with Seaside, so if you like it, he deserves the credit, if not lay the blame with me.

Create your own sub-class of WASession - to hold session state data.

Create your own root component - so Seaside will flow through it to render you web pages.

I divide each web page into three parts. A top/header/logo section, a work region and a bottom or footer section. If the the top and bottom sections are complex enough, they should be components. There should be a work region component for each page of your web app. In your session object make a way to keep track of your work region components and which one is the current one to render. You can do this anyway you like.

I usually sub-class WAObject and make it like something called XXXCurrentComponents and have the session object hold an instance. It contains a lookup table keyed by symbols used to name each web page. The values are the components that render those pages. Again it keeps track of the current page to render and maybe the last page rendered among other stuff.

Seaside will run through #renderContentOn: of your root components every time it wants to render a page.

In the #renderContentOn: of your root, you render the top. work region and bottom of the page like so:

wrc := self getWorkRegionComponentFromSession.
html render: self logoComponent.
html render: wrc.
html render: self footerComponent.

or if your top and bottom parts are not too complex, they can be rendered from methods in the root:

wrc := self getWorkRegionComponentFromSession.
self renderLogoOn html.
html render: wrc.
self renderFooterOn: html.

Now to get to your question. Often, Seaside web apps get data from the web pages they render and the flow of the app may be controlled by that data and the button pushed or whatever resulted in a submit. For this, I like buttons over anchors. Seaside will set the URL up to come back to your app. The callbacks on the buttons will run code you want run for that button. This code is normally a method of your component that rendered the button and the data fields. This is nice because the data is right there for you to do what you want with it. At the end of whatever you are doing, you tell you session object or the object holding the components, what component (page) you want to render next. You then fall out the end of the method. Seaside will do what it wants to and then go back through your root component (#renderContentOn:). The next page is rendered and the app flows on.

For example, lets say you have a page with among other things has three buttons, A, B and a cancel button. You might render them like so:

html submitButton value: 'A'; callback: [self doA].

html submitButton value: 'B'; callback: [self doB].

html cancelButton value: 'Cancel'; callback: [self doCancel].

The method #doA might end by setting up to move on to page "A". The method #doB might end by setting up to move on to page "B". The method #doCancel might end by setting up to move back to the previous page.

Note, that with the components saved in the lookup table, the state of the app and each page is maintained if your app wants to go back to a previous page. This often means that the user should not use the web browser back button but that is up to your app care about and deal with if it is a problem.

With the above approach you can use anchors to flow your app but I think buttons of whatever causes a submit are easier to deal with.

Also note that HTML doesn't have a cancel button but Seaside does. It is a submit button with the callback set to a priority that gets the callback run before all the other callbacks (somewhat hidden ones for input fields). This allows Seaside to cancel updating your object that the input fields are connected to.

Well this is long enough, I hope it helps.

Lou

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/l8udPKtaggMJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

jtuchel

Aw: Understanding Anchors for moving between pages in Seaside

In reply to this post by Totally Objects

David,

Don't worry, getting your head around Seaside and the way it handles things can be hard.

First of all, while the web typically consists of pages, Seaside works with Components. Every render cycle builds a full page with all visible components in it, but that's completely hidden from the developer. If one component delegates to another one by using call: or show: this will just show another component instead of the caller. But the rest of the page is still the same.

So calling/showing is just swapping one component for another one, not replacing the whole page. In fact, Seaside always renders the same page (root component), awhich in turn decides which components it will render by following all subcomponent's delegations (call/show).

In contrast, a classical link in plain html tells the browser to load another page.

Seaside generates a link that asks the Browser to reload the very same url, meaning it returns tio thesame Component. In addition to that, a link has a callback associated, which in turn can do a show/call, or just change some state on the server data, or simply do nothing. Unlike Web Connection or a tyical Servlet Application, a Seaside app does not navigate from page to page, but presents a front-controller servlet that gets reloaded ever and ever again. All calling/showing is just changing the tree of objects that get asked to render themselves on the next render cycle.

Notice, however, that you can also render anchors that simply point to another URL (the classical kind of link), but you leave the Seaside context by following these. Example: a Link to a wikipedia page or a Yahoo search. That's another story...

So if you say "page" do you mean navigating elsewhere, or do you mean replacing the complete tree of visible objects?
In the latter case, what you want to do is normally have the root component or, as Lou explains in his example, one of its subcomponents, call/show another component.

This is where the trouble starts: How does a Component on the third level tell the root component to call another component? How deeply do I have to couple my components? A component can easily replace itself with another one by call/show, but it cannot access its parent component, and thus cannot have that call/show another one.

For more on this, I encourage you to read the Seaside Book's chapter on Composing.

I hope this was somewhat helpful in understanding what's going on...

Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/jK7p9Z1Q9FAJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.