Re: Franch Seaside tutorial translation

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

Re: Franch Seaside tutorial translation

Serge Stinckwich-4
Damien Cassou a écrit :
> Hi,
>
> I've started to translate a Seaside tutorial into french :
> http://community.ofset.org/wiki/Seaside
>
> Can people help me ? Read what I wrote or wrote other
> parts, or other tutorials.
>

Ok, i finished the french translation of the Seaside tutorial here :
http://community.ofset.org/wiki/Balade_avec_Seaside

Avi, maybe you could link it from the Seaside tutorial page ?

I would like to start translating the tutorial here :
http://www.shaffer-consulting.com/david/Seaside/
David, do i have the permission to make a translation ?


--                                                         oooo
Dr. Serge Stinckwich                                     OOOOOOOO
Université de Caen>CNRS UMR 6072>GREYC>MAD               OOESUGOO
http://purl.org/net/SergeStinckwich                       oooooo
Smalltalkers do: [:it | All with: Class, (And love: it)]   \  /
                                                             ##

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

Re: Re: Franch Seaside tutorial translation

cdavidshaffer
Serge Stinckwich wrote:

>
>
> I would like to start translating the tutorial here :
> http://www.shaffer-consulting.com/david/Seaside/
> David, do i have the permission to make a translation ?

Sure...that would be great.

David

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

Re: Franch Seaside tutorial translation

Serge Stinckwich-4
David Shaffer a écrit :
> Serge Stinckwich wrote:
>
>>
>> I would like to start translating the tutorial here :
>> http://www.shaffer-consulting.com/david/Seaside/
>> David, do i have the permission to make a translation ?
>
> Sure...that would be great.
>

Ok, thanks you. I start a new page here :
http://community.ofset.org/wiki/Tutoriel_de_David_Shaffer

There is no page for the "back button" ?


--                                                         oooo
Dr. Serge Stinckwich                                     OOOOOOOO
Université de Caen>CNRS UMR 6072>GREYC>MAD               OOESUGOO
http://purl.org/net/SergeStinckwich                       oooooo
Smalltalkers do: [:it | All with: Class, (And love: it)]   \  /
                                                             ##


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

Re: Re: Franch Seaside tutorial translation

Avi  Bryant
In reply to this post by Serge Stinckwich-4

On Jan 12, 2006, at 3:18 AM, Serge Stinckwich wrote:

> Damien Cassou a écrit :
>> Hi,
>> I've started to translate a Seaside tutorial into french :
>> http://community.ofset.org/wiki/Seaside
>> Can people help me ? Read what I wrote or wrote other
>> parts, or other tutorials.
>>
>
> Ok, i finished the french translation of the Seaside tutorial here :
> http://community.ofset.org/wiki/Balade_avec_Seaside
>
> Avi, maybe you could link it from the Seaside tutorial page ?

Sorry for the delay, this is now done.

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

Re: Re: Franch Seaside tutorial translation

Damien Cassou-3
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> Sorry for the delay, this is now done.

Thanks

- --
Damien Cassou
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD3Jll3hhx1vOEX5sRAhapAKCEt3PDoQRCPbT7U4AMCrKli27ShQCeM39j
HL1f/jEx70tvvQHO27soKBI=
=O6mJ
-----END PGP SIGNATURE-----
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Re: Franch Seaside tutorial translation

Damien Cassou-3
In reply to this post by Avi Bryant
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> Sorry for the delay, this is now done.

Can you link the base page instead of one of the tutorials ?
http://community.ofset.org/wiki/Seaside

- --
Damien Cassou
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD3Jmx3hhx1vOEX5sRAmLmAKClJ/9oSxGe3pp8aOX1tyNHDFpuKgCePe8X
ldgPoHFf8hDpF7xqsDg5ubs=
=nmA4
-----END PGP SIGNATURE-----
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Tiny URL processing ala Seaside

Nevin Pratt
In reply to this post by Avi Bryant
Hi All!

I think we are all familiar with the service offered by
http://www.tinyurl.com, for transforming huge URL's into tiny ones.  
I've been running a similar mechanism in my Seaside app for maybe half a
year now.  For example, on my site, both of the following URL's do the
same thing:

   http://www.bountifulbaby.com?tiny=100

               and

   
http://www.bountifulbaby.com/seaside/index/birthingsupplies?searchstring=1007&searchtype=items&searchall=f

If you try both of the above URL's, you will see that the URL arguments
"searchstring=1007&searchtype=items&searchall=f" (from the second URL)
are used by the Seaside component to prepopulate the search panel.  The
URL argument "tiny=100" will cause the Seaside component to reference a
dictionary, where the "100" is a key, and
"/seaside/index/birthingsupplies?searchstring=1007&searchtype=items&searchall=f"
is the value.  So, the 100 is transformed into the bigger URL, which in
turn is then looked at for arguments for populating the search panel.

Using a dictionary in this manner, it is trivially easy to support tiny
URL's.

Should a mechanism like this be put into the general Squeak distribution?

Nevin

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

Re: Tiny URL processing ala Seaside

Avi  Bryant
(Sorry for the delay on the reply)

On Jan 29, 2006, at 12:56 PM, Nevin Pratt wrote:

> Hi All!
>
> I think we are all familiar with the service offered by http://
> www.tinyurl.com, for transforming huge URL's into tiny ones.  I've  
> been running a similar mechanism in my Seaside app for maybe half a  
> year now.  For example, on my site, both of the following URL's do  
> the same thing:
>
>   http://www.bountifulbaby.com?tiny=100
>
>               and
>
>   http://www.bountifulbaby.com/seaside/index/birthingsupplies?
> searchstring=1007&searchtype=items&searchall=f
>
> If you try both of the above URL's, you will see that the URL  
> arguments "searchstring=1007&searchtype=items&searchall=f" (from  
> the second URL) are used by the Seaside component to prepopulate  
> the search panel.  The URL argument "tiny=100" will cause the  
> Seaside component to reference a dictionary, where the "100" is a  
> key, and "/seaside/index/birthingsupplies?
> searchstring=1007&searchtype=items&searchall=f" is the value.  So,  
> the 100 is transformed into the bigger URL, which in turn is then  
> looked at for arguments for populating the search panel.
>
> Using a dictionary in this manner, it is trivially easy to support  
> tiny URL's.
>
> Should a mechanism like this be put into the general Squeak  
> distribution?

This strikes me at first glance as strangely circular.  The reason to  
have named arguments in the query string in the first place is to  
have bookmarks that can live longer than a single squeak image -  
otherwise you could just use the opaque session/continuation ids.  So  
you're replacing an opaque identifier that indexes into an in-image  
Dictionary with meaningful, external identifiers, and then replacing  
those with a different opaque identifier that indexes into an in-
image Dictionary?  Why not just clear away all the cruft and go back  
to _s and _k, and make your sessions really long lived?

Ok, there *is* a good answer to that, which is that sessions use a  
lot more memory than your tiny-url dict does.  But it seems like we  
might be able to solve that for this purpose without going through so  
many lossy indirections.

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

Re: Tiny URL processing ala Seaside

Nevin Pratt
Avi Bryant wrote:

> (Sorry for the delay on the reply)
>
> On Jan 29, 2006, at 12:56 PM, Nevin Pratt wrote:
>
>> Hi All!
>>
>> I think we are all familiar with the service offered by http://
>> www.tinyurl.com, for transforming huge URL's into tiny ones.  I've  
>> been running a similar mechanism in my Seaside app for maybe half a  
>> year now.  For example, on my site, both of the following URL's do  
>> the same thing:
>>
>>   http://www.bountifulbaby.com?tiny=100
>>
>>               and
>>
>>   http://www.bountifulbaby.com/seaside/index/birthingsupplies?
>> searchstring=1007&searchtype=items&searchall=f
>>
>> If you try both of the above URL's, you will see that the URL  
>> arguments "searchstring=1007&searchtype=items&searchall=f" (from  the
>> second URL) are used by the Seaside component to prepopulate  the
>> search panel.  The URL argument "tiny=100" will cause the  Seaside
>> component to reference a dictionary, where the "100" is a  key, and
>> "/seaside/index/birthingsupplies?
>> searchstring=1007&searchtype=items&searchall=f" is the value.  So,  
>> the 100 is transformed into the bigger URL, which in turn is then  
>> looked at for arguments for populating the search panel.
>>
>> Using a dictionary in this manner, it is trivially easy to support  
>> tiny URL's.
>>
>> Should a mechanism like this be put into the general Squeak  
>> distribution?
>
>
> This strikes me at first glance as strangely circular.  The reason to  
> have named arguments in the query string in the first place is to  
> have bookmarks that can live longer than a single squeak image -  
> otherwise you could just use the opaque session/continuation ids.  So  
> you're replacing an opaque identifier that indexes into an in-image  
> Dictionary with meaningful, external identifiers, and then replacing  
> those with a different opaque identifier that indexes into an in-
> image Dictionary?  Why not just clear away all the cruft and go back  
> to _s and _k, and make your sessions really long lived?
>
> Ok, there *is* a good answer to that, which is that sessions use a  
> lot more memory than your tiny-url dict does.  But it seems like we  
> might be able to solve that for this purpose without going through so  
> many lossy indirections.
>
> Avi


Seaside 2.3 doesn't have _s and _k in the URL.  I've just started
playing with Seaside 2.5, and if not for that, I would be totally lost
by what you mean with "go back to _s and _k".  But I think I see it now.

Anyway, you mentioned "memory" as the answer to your question.  Well,
the answer (for Seaside 2.3) is actually four-fold:

   1. Long lived sessions eat memory very rapidly (eg, your answer).
   2. Long lived sessions compound security issues.
   3. Seaside 2.3 did not support bookmarkable URL's
   4. Short "easy-to-remember" URL's are nicer to the customer than long
randomly encoded URL's :-)

I think the issues surrounding #1 above are relatively well-known to all
of us, so I won't dwell on it further.

The issues surrounding #2 are when one user "hijacks" another user's
session, which probably occurs most often because the first user emails
their URL to the second user, without realizing they just handed over
their session "keys to the kingdom" when they did that.  Shorter
sessions reduce the risk of damage due to session hijacking.

Avi, at one time I remember you talking about explicitly tying the
session to the IP address-- was that ever done?  If so, then hijacking
risk is almost completely eliminated, regardless of session lifetime.

As for issue #3, long ago I came up with a relatively simple scheme for
making a single Seaside 2.3 application have multiple entry points.  For
example, the main entry point is, of course, the home page, accessed in
the usual way:

   http://www.bountifulbaby.com

But if I instead wanted to start the application from within the
supplies section of the website, this URL could be used:

   http://www.bountifulbaby.com/seaside/index/birthingsupplies

The only difference between the above two URL's, so far as Seaside is
concerned, is a difference in what component becomes the first rendered
component in the application.  In either case, once the application is
begun by the user, from there it continues in the usual Seaside
fashion.  Well, almost.  There is still one more (subtle) difference.  I
also made changes that caused Seaside to ignore (and also preserve)
anything in the URL between the "/seaside/" part of the URL and the
session gobbly-de-gook at the end at the end of the URL.  Thus, with the
second URL above, the '/index/birthingsupplies' portion of the URL stays
in the URL throughout the Seaside session.  This makes it so that if the
session ever expires, it faults back to the same URL as it began with,
whatever that happened to be.

At the time I did this, Seaside had a real problem with bookmarkable
URL's, and this scheme solved my need for bookmarkable URL's (the
"birthingsupplies" component of the website is only one of many, many
components that can be indexed into in this manner).  I understand that
for Seaside 2.5 (and above), there have been great strides made in
bookmarkable URL's, but care to give me a pointer on how to do it?

As for issue #4, it is a no-brainer.  If you want to be able to give a
customer a seamingly static URL into a Seaside application, shorter is
always better than longer.  Appending "?tiny=" and then some short
number is about as short and clean as I could think of.  Doesn't matter
if Seaside has to work a little harder to resolve it-- the important
thing here is something easy for our customers.

In any case, Seaside 2.5 (and above) may change my thinking on a few things.

Nevin

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