I enter the username and password I just created in the web browser and an exception is raised. The method Seaside.WADispachcher>>decodeAuthorization: uses (see below) the class Base64MimeConverter, which is not in my image. So an exception is raised when Seaside tries to decode the username and password it was sent. Does anyone know where to find this class?
Seaside.WADispachcher>>decodeAuthorization: aString ^(Base64MimeConverter mimeDecodeToChars: (ReadStream on: (aString findTokens: ' ') last)) contents
Mea culpa. That one is still on the to-do list. I haven't used the configuration application or authentication so it hasn't bothered me. As to Base64MimeConverter, I need to do a little research on it before deciding what to do.
sortBy: is a Squeak method on arrays, which does not exist in VW. Of course this is fixed with:
Array>>sortBy: aBlock ^self asSortedCollection: aBlock
But now the two problems begin to make me think that there may be some VW-Squeak compatibility package that I am missing. Is this the case?
No. #sortBy: is only used by WAApplicationList, and one other place. I just haven't run across it yet. This is a judgement call, but in other situations like this, Avi simply modified Seaside to be more platform neutral. Early versions of the 2.3 port had a lot more Squeak dependencies than does the current version.
Which reminds me, shouldn't the package Seaside-WebToolKit be listed as a prereq for the package Seaside? Seaside-WebToolKit contains the Seaside namespace, so one can not load Seaside first.
Several people expressed a desire for the VW port to not be locked into WebToolKit. If I made Seaside-WebToolKit a prereq for Seaside, then when somebody else adds Seaside-Swazoo, you would be stuck. OK, I just realized that I could just make Seaside be a sub-bundle of Seaside-WebToolKit and you would have your one click load. BTW - Cincom (Alan Knight) was soliciting input on StORE improvements at Smalltalk Solutions. I believe that better tools for browsing the repository were on the list.
I realize that I could make this change on the cincom repository, but am still new enough at Seaside that I am not sure what I am doing.
I'm pretty new at using the public repository, new with Seaside and new with a major platform port. Avi and I are in discussion about ways to simplify the porting process so that future versions can be re-ported as simply as possible. I think the ball is currently in my court... In the meantime, please keep the messages coming.
On Thursday, September 11, 2003, at 02:26 PM, Pennell, David wrote:
Several people expressed a desire for the VW port to not be locked into WebToolKit. If I made Seaside-WebToolKit a prereq for Seaside, then when somebody else adds Seaside-Swazoo, you would be stuck. OK, I just realized that I could just make Seaside be a sub-bundle of Seaside-WebToolKit and you would have your one click load. BTW - Cincom (Alan Knight) was
But currently Seaside-WebToolKit is a prereq. for Seaside even if it is not listed as such. One can not load Seaside without Seaside-WebToolKit already loaded. If you try to load Seaside first you get 20+ windows complaining of various errors. Most of which seem to be related to the fact that the Seaside namespace is defined in Seaside-WebToolKit. Since most of the classes in the Seaside package are in the Seaside namespace Seaside-WebToolKit is a prereq.
What one wants it to have Seaside a prereq. for Seaside-WebToolKit (or Seaside-Swazoo). Then one gets a one-click install and maintain web server independence. But the Seaside namespace needs to move to the Seaside package first.
---- Roger Whitney Department of Computer Science whitney@cs.sdsu.edu San Diego State University http://www.eli.sdsu.edu/ San Diego, CA 92182-7720 (619) 583-1978 (619) 594-3535 (office) (619) 594-6746 (fax)
David, One solution is to use Base64EncodingReadStream of the Base64Encoding package (located in goodies/other/PostgreSQL) We would then get:
Seaside.WADispachcher>>decodeAuthorization: aString ^(Base64EncodingReadStream on: (aString findTokens: ' ') last) upToEnd asString
and need to add the package as a prereq. of Seaside. Of course this might make it harder to incorporate changes from the Squeak version of Seaside. So it probably would be better to add a Base64MimeConverter class to aVW-Squeak convertibility section. One could just port the class Base64MimeConverter class from Squeak but it would be less work to do:
Base64MimeConverter class>>mimeDecodeToChars: aReadStream ^ Base64EncodingReadStream onStream: aReadStream
And then add:
Base64EncodingReadStream>>contents ^self upToEnd asString
If one also adds the following to the package Seaside/VW-Squeak then one can access via username & password the configuration page.
SequenceableCollection>>copyAfter: anElement "Answer a copy of the receiver from after the first occurence of anElement up to the end. If no such element exists, answer an empty copy."
^ self allButFirst: (self indexOf: anElement ifAbsent: [^ self copyEmpty])
Array>>sortBy: aBlock ^self asSortedCollection: aBlock
On Thursday, September 11, 2003, at 02:26 PM, Pennell, David wrote:
I enter the username and password I just created in the web browser and an exception is raised. The method Seaside.WADispachcher>>decodeAuthorization: uses (see below) the class Base64MimeConverter, which is not in my image. So an exception is raised when Seaside tries to decode the username and password it was sent. Does anyone know where to find this class?
Seaside.WADispachcher>>decodeAuthorization: aString ^(Base64MimeConverter mimeDecodeToChars: (ReadStream on: (aString findTokens: ' ') last)) contents
Mea culpa. That one is still on the to-do list. I haven't used the configuration application or authentication so it hasn't bothered me. As to Base64MimeConverter, I need to do a little research on it before deciding what to do.
---- Roger Whitney Department of Computer Science whitney@cs.sdsu.edu San Diego State University http://www.eli.sdsu.edu/ San Diego, CA 92182-7720 (619) 583-1978 (619) 594-3535 (office) (619) 594-6746 (fax)
seaside@lists.squeakfoundation.org