Seaside component usage pattern

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Seaside component usage pattern

Nir Oren
Hi All,

I'm trying to get my head around Seaside, and was wondering what the
``best practice'' for the following (rather common) scenario is:

I'd like to have a webpage such that a little login box appears on the
top right if the user isn't logged in (together with things like a
``register now'' option), and a welcome message/logout option there if
the user is logged in. The rest of the page's contents should remain
unchanged.

So to me, there should be a login/status component as a child of the
main page component. If the user selects ``register'', the main page
should change to a registration page (and the login/status component
should temporarily vanish).

This means that selecting register on the child component should cause a
different rendering of the main component (or, in fact, a different
class to appear as the main component). What is the best way to handle
this situation?

Keep well,
Nir

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Seaside component usage pattern

Philippe Marschall
http://onsmalltalk.com/programming/smalltalk/maintaining-loose-coupling-in-seaside-components/

2008/8/15 Nir Oren <[hidden email]>:

> Hi All,
>
> I'm trying to get my head around Seaside, and was wondering what the ``best
> practice'' for the following (rather common) scenario is:
>
> I'd like to have a webpage such that a little login box appears on the top
> right if the user isn't logged in (together with things like a ``register
> now'' option), and a welcome message/logout option there if the user is
> logged in. The rest of the page's contents should remain unchanged.
>
> So to me, there should be a login/status component as a child of the main
> page component. If the user selects ``register'', the main page should
> change to a registration page (and the login/status component should
> temporarily vanish).
>
> This means that selecting register on the child component should cause a
> different rendering of the main component (or, in fact, a different class to
> appear as the main component). What is the best way to handle this
> situation?
>
> Keep well,
> Nir
>
> _______________________________________________
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Seaside component usage pattern

Nir Oren
Wow, that was fast! Many thanks, I can't believe I didn't find it with
all my googling for it.

Nir

Philippe Marschall wrote:

> http://onsmalltalk.com/programming/smalltalk/maintaining-loose-coupling-in-seaside-components/
>
> 2008/8/15 Nir Oren <[hidden email]>:
>> Hi All,
>>
>> I'm trying to get my head around Seaside, and was wondering what the ``best
>> practice'' for the following (rather common) scenario is:
>>
>> I'd like to have a webpage such that a little login box appears on the top
>> right if the user isn't logged in (together with things like a ``register
>> now'' option), and a welcome message/logout option there if the user is
>> logged in. The rest of the page's contents should remain unchanged.
>>
>> So to me, there should be a login/status component as a child of the main
>> page component. If the user selects ``register'', the main page should
>> change to a registration page (and the login/status component should
>> temporarily vanish).
>>
>> This means that selecting register on the child component should cause a
>> different rendering of the main component (or, in fact, a different class to
>> appear as the main component). What is the best way to handle this
>> situation?
>>
>> Keep well,
>> Nir
>>
>> _______________________________________________
>> 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
>

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