What's the difference and why??

I'm trying to find out why I need to write the method below using one of
the two ways below:

generateMainPageLinks: html
    html unorderedList: [
        html listItem: [html anchorWithAction: [self renderMain: html]
text: 'Home'.].
        html listItem: [html anchorWithAction: [self renderAbout: html]
text: 'About'.].
        html listItem: [html anchorWithAction: [self renderEnroll: html]
text: 'Enroll'.].
        html listItem: [html anchorWithAction: [self renderContactUs:
html] text: 'Contact Us'.].
    ].


generateMainPageLinks
    self html unorderedList: [
        self html listItem: [self html anchorWithAction: [self
renderMain: self html] text: 'Home'.].
        self html listItem: [self html anchorWithAction: [self
renderAbout: self html] text: 'About'.].
        self html listItem: [self html anchorWithAction: [self
renderEnroll: self html] text: 'Enroll'.].
        self html listItem: [self html anchorWithAction: [self
renderContactUs: self html] text: 'Contact Us'.].
    ].

Now, since I'm not passing in any arguments to this method (at least for
now), I'm wondering why I need to specify "html" on the first
version of the code (and have the ":").. On the second one, if I don't
put the "self" in front of the various "html" items, I get compilation
errors
saying it doesn't know what they are..  I'm sure it's one of those
fundamental SmallTalk things I'm missing here, but this one beyond me..

Now, before you get too carried away, I've NOT tried running this code
on the bottom, but have run with the top one.  Any
insight as to what I'm missing would be greatly appreciated!

-- Rick

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

>         html listItem: [html anchorWithAction: [self renderMain: html]
> text: 'Home'.].
Does this really work? You do rendering in a callback block. This
doesn't make sense.

> Now, since I'm not passing in any arguments to this method (at least for
> now), I'm wondering why I need to specify "html" on the first
> version of the code (and have the ":")..
html is the rendering context on which you render. If you come from a
Java background this is very much like the #paintComponent(Graphics)
method. You can store it in an instance variable at the beginning of
#renderContentOn: instead of passing it around to every render method,
but this in general not done.

> On the second one, if I don't
> put the "self" in front of the various "html" items, I get compilation
> errors
> saying it doesn't know what they are..
Probably because there's not instance variable referncing the rendering context.

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

Philippe Marschall wrote:
>>         html listItem: [html anchorWithAction: [self renderMain: html]
>> text: 'Home'.].
>>    
> Does this really work? You do rendering in a callback block. This
> doesn't make sense.
>
>  
Yes, it seemed to work for me.. Now, whether or not it's right is
certainly up for discussion..
I'm still both a Seaside and Smalltalk newbie (as I mentioned before),
so if I'm doing something
wrong, please let me know..  Any ideas on how to write such a set of
code and where to put
it (or not to) would be greatly appreciated!
> html is the rendering context on which you render. If you come from a
> Java background this is very much like the #paintComponent(Graphics)
> method. You can store it in an instance variable at the beginning of
> #renderContentOn: instead of passing it around to every render method,
> but this in general not done.
>
>  
Ok I think..  I don't have much of a Java background -- mostly C/C++..
I'm not sure I follow
completely here. Ideally, what I'm looking to do is have a method in my
WATask derived
class so that it can pass a set of generated page links to each "task"
(e.g. update contact info,
main page, generate reports, etc.. These links will be common to each
page and I'd rather
not embed them into each class that does the actions I want (thereby
duplicating code)

-- Rick



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

> Yes, it seemed to work for me.. Now, whether or not it's right is
> certainly up for discussion..
> I'm still both a Seaside and Smalltalk newbie (as I mentioned before),
> so if I'm doing something
> wrong, please let me know..  Any ideas on how to write such a set of
> code and where to put
> it (or not to) would be greatly appreciated!

Well then, let's go.

> html listItem: [html anchorWithAction: [self renderMain: html] text: 'Home'.].
What is exactly happening here:
- you render a list item
- inside that list item you render anchor with text 'Home' <a
href="...">Home</a>
so this will look about like this:
<li><a href="...">Home</a></li>
now when someone clicks that link, #renderMain: get's sent to self
with the now no longer valid html renderer as argument, this argument
is thus completetly useless. I don't know what happens in
#renderMain:, but you obviously can't do rendering so calling it
#renderXXX is a not a good idea.

Depending on what you want to achieve, I see two ways to do it.

First.

html listItem: [
    html anchorWithAction: [ self homeClicked ] do:  [ self renderMain: html ] ]

This makes a list item with a anchor inside, inside that anchor is
whatever you render in #renderMain:. When someone clicks the link,
#homeClicked gets sent to the component.

or

html listItem: [html anchorWithAction: [ self homeClicked ] text: 'Home' ].


This makes a list item with a anchor inside, inside that anchor is
just 'Home' like in your current code. When someone clicks the link,
#homeClicked gets sent to the component.


Now I'm not sure I follow completely ;)
With links you don't mean links outside of your seaside application,
do you? Can you somehow implement the behavior in a superclass of all
your components that do these "tasks"? Or put it into a real WATask
and call it from your components? Or put it into an a component that
is around the inner components?

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

Philippe Marschall wrote:
> [ ... ]
Good samples snipped.. I'll play around with them further.. Thanks!
>
> Now I'm not sure I follow completely ;)
> With links you don't mean links outside of your seaside application,
> do you? Can you somehow implement the behavior in a superclass of all
> your components that do these "tasks"? Or put it into a real WATask
> and call it from your components? Or put it into an a component that
> is around the inner components?
In my case, I've got an existing PHP application that I'll have to admit
isn' very OO like and I'm
trying to re-write it from scratch using Seaside and am having to
rethink things completely mostly
due to the totally different approach that Seaside takes compared to
more traditional (old school)
web development setups.  To that end, what I am trying to get going is
to have a site that has some
general links for people who are not logged in, so that they can find
out what my site is about
(e.g. an "about" page or two).. There will then be the main login page
which prompts the user for
a username/password (which I've already got working by the way -- works
great!).   Once logged
in, the user is present with various functions they can perform such as
"update contact info", or
perhaps "view my reports", etc.   I initially had this coded as a
subclass of WATask to control the
stepping from one thing to another, but am not sure this is the right
approach.. I think I was thinking
of having a list of anchorWithActions for each function the user can
perform and each one of those
action blocks could just do a "new" on the class that knows how to deal
with that action.  Anyway,
I'm not sure I really need the WATask based class or if I can get away
with using something based
on WAComponent instead.  My initial idea for going down the WATask path
was that I could control
the login processing a bit easier that way.. However, If I can get away
with using the anchorWithActions
for each function to be performed, perhaps my WATask is going to only be
a couple of lines as it is
today.  It currently looks like :

MySite>>go
    self hasUser ifFalse: [self session user: (self call: MSLogin new)].
    self call: (ContactInfoView new).

The above code is forcing the ContactInfoView class to be performed
after the user logs in, but that
may turn into more of a "main" sort of class that can print the "MOTD"
(message of the day) and nothing
more (other than some links to the functions the user can perform).

Any suggestions on whether this is a good approach or not would be
greatly appreciated!  I'll have to
admit that the entire Smalltalk environment + Seaside is getting more
appealing to me as time goes by
and I get more hours under my belt working out issues, etc.. Its much
more interesting than playing
games with the Zend Debugger + text editor + reloading pages,etc as I'm
used to doing for PHP
development.

-- Rick

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

Hi Rick - let's step back for a sec and talk about a different  
structure....

:)

What *I* do, and others may have different patterns for their seaside  
apps, is to create a main page component, and #call: (this is  
Smalltalk notation for denoting a message send, or a method call in C+
+ parlance) the components that I want to show up on the page. So, as  
a simple example, you might have an initialize method:

initialize
        mainPage := MainPage new.
        aboutPage := AboutPage new.
        enrollPage := EnrollPage new.
        contactPage := ContactPage new.
        menuArea := MenuArea on: self.

mainPage, aboutPage etc. are instance variables on your main App  
class - say MyWebApp, where the initialize is located.


Then, in MyWebApp>>renderContentOn:

renderContentOn: html
        html divClass: 'sidebar' with: [html render: menuArea].
        html divClass: 'contentarea' with: [html render: mainPage].

Then in MenuArea class, you would have a class side method like:

on: aComponent
        ^ (self new) parent: aComponent

... back on the instance side (a setter for parent):
parent: aComponent
        parent := aComponent

(parent being an instance var)

parent
        ^ parent

and then:

renderContentOn: html
        html unorderedList: [
        html listItem: [html anchorWithAction: [self parent  
clearAllDelegates] text: 'Home'.].
        html listItem: [html anchorWithAction: [self parent mainPage  
call: self parent aboutPage] text: 'About'.].
        html listItem: [html anchorWithAction: [self mainPage call:  
self parent call enrollPage] text: 'Enroll'.].
        html listItem: [html anchorWithAction: [self mainPage call:  
self parent call contactPage] text: 'Contact Us'.].
    ].

This means that you have to have accessor method for the instance  
variables that get initialized on the MyWebApp class so that you can  
call "self parent enrollPage" from the MenuArea component. You could  
also create convenience methods on your menu page, like:

enrollPage
        ^ self parent enrollPage


Anyway, I hope this gives you a different idea of how you can do some  
things. Feel free to ask any other questions!

Brian

On Feb 24, 2006, at 10:35 PM, Rick Flower wrote:

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

Brian Brown wrote:
> Hi Rick - let's step back for a sec and talk about a different
> structure....
Yea.. I was hoping someone might give me an idea of a better way to
proceed!  Thanks! That makes sense and I was thinking about doing something like that so I
wouldn't need to instantiate new instances of each
class on the fly..
> Then, in MyWebApp>>renderContentOn:
>
> renderContentOn: html
>     html divClass: 'sidebar' with: [html render: menuArea].
>     html divClass: 'contentarea' with: [html render: mainPage].
Excellent!
> Then in MenuArea class, you would have a class side method like:
>
> on: aComponent
>     ^ (self new) parent: aComponent
Ahh.. When might I ask does this get invoked?  Is this part of object
instantiation when the above
"html render: menuArea" gets rendered?
Do you mind if I ask what "clearAllDelegates" does?  I found that it is
part of Seaside, but didn't see anything that
really explains what its for..
> This means that you have to have accessor method for the instance
> variables that get initialized on the MyWebApp class so that you can
> call "self parent enrollPage" from the MenuArea component. You could
> also create convenience methods on your menu page, like:
Thanks again.. I'll try this out.. I guess I've never gotten into
writing web pages in true OO before and am having a hard time
of it..

-- Rick


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

On Feb 27, 2006, at 2:51 PM, Rick Flower wrote:

> Brian Brown wrote:
>> Hi Rick - let's step back for a sec and talk about a different  
>> structure....
> Yea.. I was hoping someone might give me an idea of a better way to  
> proceed!  Thanks!

No problem :)

Yeah, you don't want to instantiate a new component class for every  
render. You normally get one per session.

This get's called from that initialize method above, so you have an  
instance of the MenuArea class sitting in the menuArea ivar (short  
for instance variable). The html render: menuArea doesn't instantiate  
a new version of the class, it simply sends the current html renderer  
to the renderContentOn: method of the MenuArea class.

Does that make sense?


This is one of the very cool parts of Seaside... the #call: #answer:  
methods. What happens is that you send the #call: message with a  
WAComponent subclass as the argument. The component that was called  
becomes the delegate for the calling component. For all intents and  
purposes, it replaces the calling component until it issues an  
#answer message, then the "control" is returned to the calling  
component. The renderContentOn: method of the top delegate is the one  
that is rendered, all the other delegates in the chain are  
effectively invisible. You can chain as many of these #call:s as you  
want. clearAllDelegates removes the delegate chain, so the root  
component is the one that is rendered again.

I hope this shed a bit of light on the subject, but it may be  
confusing from my description ;)



>> This means that you have to have accessor method for the instance  
>> variables that get initialized on the MyWebApp class so that you  
>> can call "self parent enrollPage" from the MenuArea component. You  
>> could also create convenience methods on your menu page, like:
> Thanks again.. I'll try this out.. I guess I've never gotten into  
> writing web pages in true OO before and am having a hard time
> of it..
>

Try to think of it more like GUI programming on a desktop rather than  
some template based web framework. In a normal web app, pages are  
short lived, but in seaside an object that renders a page stays  
around for your session and can have much greater functionality.

Brian


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

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

Brian Brown wrote:
> This get's called from that initialize method above, so you have an
> instance of the MenuArea class sitting in the menuArea ivar (short for
> instance variable). The html render: menuArea doesn't instantiate a
> new version of the class, it simply sends the current html renderer to
> the renderContentOn: method of the MenuArea class.
>
> Does that make sense?
Yes, Sounds good to me..
Cool.. I had read about the #call / #answer methods, but didn't realize
there was a way to nuke the stack so to speak.. I'll have to try
this out..

> Try to think of it more like GUI programming on a desktop rather than
> some template based web framework. In a normal web app, pages are
> short lived, but in seaside an object that renders a page stays around
> for your session and can have much greater functionality.
>
That's a pretty good analogy.. It really is more like writing a desktop
program than doing any other sort of web development.

Thanks again!

-- Rick

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

[ ... ]

Brian -- is it safe to assume that I can ditch the use of the WATask
setup that I'm using now and switch back
to using a main application class subclassed from WAComponent -- correct?

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

Well, you certainly can... I have used a WATask as an application  
entry when I was doing authentication:

go
        self hasValidUser ifFalse: [self session user:
                        (self call: (MyLogin new greeting: 'Please Login!'))].
        self call: (MyWebApp new).

I do it differently now, but have also used WATask's for managing  
successive components that I wanted to run.


In your case, I wouldn't use a WATask.


Brian

On Feb 28, 2006, at 12:36 AM, Rick Flower wrote:

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

Brian Brown wrote:
> In your case, I wouldn't use a WATask.
That's kinda what I thought as well.. I guess if I'm not going to use a
WATask, I'd need to code up the renderContentOn: method to not only
display my links near the top of the page, but also display the login
form crud as well..  In MyWebApp, can I do something like this :

renderContentOn: html
    html divClass: 'sidebar' with: [html render: menuArea].
    html divClass: 'contentarea' with: [html render: mainPage].
    html divClass: 'loginarea' with: [html render: loginArea].

where loginArea is an instance of a Login class which has a
renderContentOn: method that looks something like :

renderContentOn: html
    html form: [
        html defaultAction: [self confirmLogin].
        html heading: 'Welcome to MyWebApp' level: 3.
        html bold: 'Enter login name:'.
        html textInputWithValue: '' callback: [:v | self login: v].
        html br; br.
        html space; space; space; bold: 'Enter password:'.
        html passwordInputWithCallback: [:c | self password: ((MD5 hash:
c) asHexString asLowercase) ].
        html paragraph.
        html attributes value: 'Login!'.
        html submitButton.
    ].

What I'm hoping for as a result is that I would get my menu links (care
of the "menuArea" class), my "mainPage" body (whatever that turns out to
be), and a "loginArea" as defined above..  Now, I'd obviously have to
put some sort of conditional flag on the rendering of the "loginArea"
object since we don't need/want to display it AFTER someone logs in --
that can be accomplished by looking at my session variable to see if
we've got a "user" object yet (easy).  I can't believe this stuff is
starting to make sense.. Bizzare!

Comments?

-- Rick

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

Rick Flower wrote: you can also do, for instance:
       html divClass: 'sidebar' with: [self loginArea].

if

initialize
    loginArea := loginClass new.

loginArea
    ^loginArea.

But, is that not a good way to go?
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Rick Flower wrote: Hmm.. I'm apparently wrong on something above.. While the page initially
renders great, when I hit the "login" button,
Seaside gives me the following error :

Components not found while processing callbacks: #(a MSLogin)

I'm guessing this has to do with the fact that Seaside no longer has the
object lying around or something along those
lines.. Do I need to play the games like you showed above with the
'MenuArea' class and have a class-side method
to store an object instance?  Now I'm starting to feel a bit like a fish
out of water.. I guess I should have knocked on wood!

-- Rick

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

Brad Fuller wrote: You've got me on that one -- for me, the first one seems to be easier to
understand for me
anyway.. Perhaps someone else can chime in the validity of the bottom one..

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

You need to return loginArea from children.

children
    ^Array with: loginArea
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Yes, I meant to put that in my response, but forgot to.... you need  
to implement the #children message on MyWebApp like:

children
        ^ Array with: menuArea with: mainPage with: loginArea

Also, What I do now for login is like so (this is 2.6 Canvas  
rendering syntax, but you get the idea):

renderContentOn: html
        html heading: 'Welcome to my world' level: 3.
       
        self session loggedUser isNil
                ifFalse: [
       
                        html div
                                class: 'navigation';
                                with: [html render: navWidget]
                        html div
                                class: 'mainPage';
                                with: [html render: mainPage].

        html div
                class: 'footer';
                with: [html render: loginWidget].


So the footer always gets rendered, but if there is no valid session  
user, then the navWidget and mainPage do not get rendered.

I've been meaning to publish my login widgets and such, but haven't  
gotten around to it yet ;)

Brian


On Feb 28, 2006, at 5:57 PM, Ramon Leon wrote:

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

Hi :)

Really interesting discussion :)
there another way to do now?
I have seaside 2.6a3-lr22

Thanks

Cédrick

--------------------------------
L'ENIT vous invite a sa journee portes ouvertes le 17 mars 2006 de 13h30 a 19h30
 Visite des locaux,  animations, cadeaux a gagner.

 Enit , 47 avenue d'Azereix 65000 Tarbes
 Bus N°1, arret ENI

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

Cédrick Béler wrote:
> euh... I don't find #clearAllDelegates in my image !  Is it normal ?
> is there another way to do now?
> I have seaside 2.6a3-lr22
Hmm.. Neither did I.. I had it coded up in one of my classes and just
tried using it and I get the message not
understood.. I did a search of the image and the only reference to it is
in my class.. FWIW, I'm running Seaside
2.5b8.

-- Rick


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

Yeah, I guess that is old.... There is a method on WAComponent called  
#home

It gets rid of all the delegates a component has, so just sending  
#home to your component will do what clearAllDelegates did.

Brian

On Mar 2, 2006, at 7:11 AM, Cédrick Béler wrote:

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