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 |
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 |
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 |
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 |
-----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 |
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 |
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 |
(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 |
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 |
Free forum by Nabble | Edit this page |