upgrading methods

>> What is the best way to upgrade Seaside and pier, and the packages for
>> Seaside? Is it ok to go to the latest (or near) MC package and "Merge"?
>>
>> Any methods on how you update would be MUCH appreciated! This is a bit
>> confusing - it's not brain surgery, just a bit confusing to me.
>
> Update in this order:
>
> - Seaside
> - Scriptaculous
> - Magritte
> - Pier
>
> For Seaside 2.7 there are some things you need to do to recreate your
> dispatcher configuration (discussed here and written in the commit
> comments of Seaside).
>
> The latest versions of these packages should work. In case you run
> into some problems just ask again, I've done this a 100 times already
> ;-)

>> What is the best way to upgrade Seaside and pier, and the packages for
>> Seaside? Is it ok to go to the latest (or near) MC package and "Merge"?
>>
>> Any methods on how you update would be MUCH appreciated! This is a bit
>> confusing - it's not brain surgery, just a bit confusing to me.
>
> Update in this order:
>
> - Seaside
> - Scriptaculous
> - Magritte
> - Pier
>
> For Seaside 2.7 there are some things you need to do to recreate your
> dispatcher configuration (discussed here and written in the commit
> comments of Seaside).
>
> The latest versions of these packages should work. In case you run
> into some problems just ask again, I've done this a 100 times already
> ;-)

> Lukas Renggli wrote:
>>> What is the best way to upgrade Seaside and pier, and the packages for
>>> Seaside? Is it ok to go to the latest (or near) MC package and "Merge"?
>>>
>>> Any methods on how you update would be MUCH appreciated! This is a bit
>>> confusing - it's not brain surgery, just a bit confusing to me.
>>
>> Update in this order:
>>
>> - Seaside
>> - Scriptaculous
>> - Magritte
>> - Pier
>>
>> For Seaside 2.7 there are some things you need to do to recreate your
>> dispatcher configuration (discussed here and written in the commit
>> comments of Seaside).
>>
>> The latest versions of these packages should work. In case you run
>> into some problems just ask again, I've done this a 100 times already
>> ;-)
>
> Glad you've done it 100times! cause I got a problem.
>
> I merged the latest Seaside 2.7. And I did the following from recent
> messages:
>
>     WAComponent allSubclassesDo: [ :each | each initialize ].
>     WADispatcher resetAll.
>
> Each of these replied with a seaside config username/password, which I
> supplied.
> Each of these replied if I wanted to create a new Pier, which I said
> 'no' (since I already have one.
>
> Now, there is not access at /seaside/config, nor my pier app.
>
> from the browser:
>
> Internal Server Error
> MessageNotUnderstood: UndefinedObject>>isEmpty
>
> Comanche/6.2 (unix) Server at www.<my_domain> Port 9999

>> >     WAComponent allSubclassesDo: [ :each | each initialize ].
>> >     WADispatcher resetAll.
>
> After doing this you need to stop and restart the server, so that it
> catches the new dispatcher.
>
>> UPDATE: Twice I stopped WAKom and restarted. The 3rd time, I stopped it,
>>   waited, and restarted and Seaside came up. Don't know if it was a
>> browser cache problem or what.
>>
>> But, I don't have my Pier app. And, I want my Pier app!
>
> Excellent, now re-initialize Pier:
>
>     PRPierFrame initialize.
>
> Answer: yes (create an entry point) - no (create a new kernel) - a
> Kernel (select your old kernel) - accept (suggested entry point) - ok
> (try in the web browser).

>> >     WAComponent allSubclassesDo: [ :each | each initialize ].
>> >     WADispatcher resetAll.
>
> After doing this you need to stop and restart the server, so that it
> catches the new dispatcher.
>
>> UPDATE: Twice I stopped WAKom and restarted. The 3rd time, I stopped it,
>>   waited, and restarted and Seaside came up. Don't know if it was a
>> browser cache problem or what.
>>
>> But, I don't have my Pier app. And, I want my Pier app!
>
> Excellent, now re-initialize Pier:
>
>     PRPierFrame initialize.
>
> Answer: yes (create an entry point) - no (create a new kernel) - a
> Kernel (select your old kernel) - accept (suggested entry point) - ok
> (try in the web browser).

> Lukas Renggli wrote:
>>> >     WAComponent allSubclassesDo: [ :each | each initialize ].
>>> >     WADispatcher resetAll.
>>
>> After doing this you need to stop and restart the server, so that it
>> catches the new dispatcher.
>>
>>> UPDATE: Twice I stopped WAKom and restarted. The 3rd time, I stopped it,
>>>   waited, and restarted and Seaside came up. Don't know if it was a
>>> browser cache problem or what.
>>>
>>> But, I don't have my Pier app. And, I want my Pier app!
>>
>> Excellent, now re-initialize Pier:
>>
>>     PRPierFrame initialize.
>>
>> Answer: yes (create an entry point) - no (create a new kernel) - a
>> Kernel (select your old kernel) - accept (suggested entry point) - ok
>> (try in the web browser).
>
> Ok, another problem. I upgraded per your advice for the order. I saved
> as new version just so I could get back to where I was.
>
> Seaside ran fine when updating. No problem.
> But, when I run the new version I rcv from the browser:
>
> ======
>  Internal Error
> MessageNotUnderstood: WAStandardFiles>>urlOf:
>
> [] in WAStandardFiles(WAFileLibrary)>>updateRoot: {[:each | (each
> endsWith: #Js) ifTrue: [aHtmlRoot javascript url: (sel...]}
> Array(SequenceableCollection)>>do:
> WAStandardFiles(WAFileLibrary)>>updateRoot:
> WAStandardFiles>>updateRoot:
> [] in WAApplication>>updateRoot: {[:each | each default updateRoot:
> anHtmlRoot]}
> OrderedCollection>>do:
> WAApplication>>updateRoot:
> WASession>>updateRoot:
> WARender>>buildDocRoot
> WARender>>buildResponse
> [] in WARender>>render {[:u | url := u. self buildResponse]}
> [] in WASession>>respond: {[:cc | url := self actionUrlForContinuation:
> cc. response := responseBlock...]}
> ResponseContinuation class(Continuation class)>>currentDo:
> WASession>>respond:
> WARender>>render
> [] in WARender>>go {[self render]}
> BlockContext>>on:do:
> WARender>>withRenderNowHandler:
> [] in WARender>>go {[self withRenderNowHandler: [self render]. self
> shouldRedirect ifTrue: ...]}
> BlockContext>>on:do:
> ======
>
> If I: WADispatcher resetAll
> I rcv DNU: WAFileHandler: #basePath
>
> WAFileHandler>>registerAsHandler: aString sends the message:
>
>   handler := self new basePath: aString.
>
> aString is: 'files'
>
> WAFileHandler is trying to initialize, but there is no #basePath
>
> So, I did something wrong during updating.
>
> Any hints????
>

> Brad Fuller wrote:
>> Lukas Renggli wrote:
>>>> >     WAComponent allSubclassesDo: [ :each | each initialize ].
>>>> >     WADispatcher resetAll.
>>>
>>> After doing this you need to stop and restart the server, so that it
>>> catches the new dispatcher.
>>>
>>>> UPDATE: Twice I stopped WAKom and restarted. The 3rd time, I stopped
>>>> it,
>>>>   waited, and restarted and Seaside came up. Don't know if it was a
>>>> browser cache problem or what.
>>>>
>>>> But, I don't have my Pier app. And, I want my Pier app!
>>>
>>> Excellent, now re-initialize Pier:
>>>
>>>     PRPierFrame initialize.
>>>
>>> Answer: yes (create an entry point) - no (create a new kernel) - a
>>> Kernel (select your old kernel) - accept (suggested entry point) - ok
>>> (try in the web browser).
>>
>> Ok, another problem. I upgraded per your advice for the order. I saved
>> as new version just so I could get back to where I was.
>>
>> Seaside ran fine when updating. No problem.
>> But, when I run the new version I rcv from the browser:
>>
>> ======
>>  Internal Error
>> MessageNotUnderstood: WAStandardFiles>>urlOf:
>>
>> [] in WAStandardFiles(WAFileLibrary)>>updateRoot: {[:each | (each
>> endsWith: #Js) ifTrue: [aHtmlRoot javascript url: (sel...]}
>> Array(SequenceableCollection)>>do:
>> WAStandardFiles(WAFileLibrary)>>updateRoot:
>> WAStandardFiles>>updateRoot:
>> [] in WAApplication>>updateRoot: {[:each | each default updateRoot:
>> anHtmlRoot]}
>> OrderedCollection>>do:
>> WAApplication>>updateRoot:
>> WASession>>updateRoot:
>> WARender>>buildDocRoot
>> WARender>>buildResponse
>> [] in WARender>>render {[:u | url := u. self buildResponse]}
>> [] in WASession>>respond: {[:cc | url := self
>> actionUrlForContinuation: cc. response := responseBlock...]}
>> ResponseContinuation class(Continuation class)>>currentDo:
>> WASession>>respond:
>> WARender>>render
>> [] in WARender>>go {[self render]}
>> BlockContext>>on:do:
>> WARender>>withRenderNowHandler:
>> [] in WARender>>go {[self withRenderNowHandler: [self render]. self
>> shouldRedirect ifTrue: ...]}
>> BlockContext>>on:do:
>> ======
>>
>> If I: WADispatcher resetAll
>> I rcv DNU: WAFileHandler: #basePath
>>
>> WAFileHandler>>registerAsHandler: aString sends the message:
>>
>>   handler := self new basePath: aString.
>>
>> aString is: 'files'
>>
>> WAFileHandler is trying to initialize, but there is no #basePath
>>
>> So, I did something wrong during updating.
>>
>> Any hints????
>>
>
> Luckily I saved the image in increments. I went one back and it seems to
> work.
>
> What I merged for the last image version, that didn't work, was
> Pier-Magma
> rsrss
> Pier-Blog
>
> And, I also tried to merge FileLibrary, in this last version, but I
> could never get it to merge. When I pressed the Merge button in the
> Merge Dialog box, it just did nothing.
>
> So, could any of these packages be the cause of the above trace?
>

> Brad Fuller wrote:
> > Lukas Renggli wrote:
> >>> >     WAComponent allSubclassesDo: [ :each | each initialize ].
> >>> >     WADispatcher resetAll.
> >>
> >> After doing this you need to stop and restart the server, so that it
> >> catches the new dispatcher.
> >>
> >>> UPDATE: Twice I stopped WAKom and restarted. The 3rd time, I stopped it,
> >>>   waited, and restarted and Seaside came up. Don't know if it was a
> >>> browser cache problem or what.
> >>>
> >>> But, I don't have my Pier app. And, I want my Pier app!
> >>
> >> Excellent, now re-initialize Pier:
> >>
> >>     PRPierFrame initialize.
> >>
> >> Answer: yes (create an entry point) - no (create a new kernel) - a
> >> Kernel (select your old kernel) - accept (suggested entry point) - ok
> >> (try in the web browser).
> >
> > Ok, another problem. I upgraded per your advice for the order. I saved
> > as new version just so I could get back to where I was.
> >
> > Seaside ran fine when updating. No problem.
> > But, when I run the new version I rcv from the browser:
> >
> > ======
> >  Internal Error
> > MessageNotUnderstood: WAStandardFiles>>urlOf:
> >
> > [] in WAStandardFiles(WAFileLibrary)>>updateRoot: {[:each | (each
> > endsWith: #Js) ifTrue: [aHtmlRoot javascript url: (sel...]}
> > Array(SequenceableCollection)>>do:
> > WAStandardFiles(WAFileLibrary)>>updateRoot:
> > WAStandardFiles>>updateRoot:
> > [] in WAApplication>>updateRoot: {[:each | each default updateRoot:
> > anHtmlRoot]}
> > OrderedCollection>>do:
> > WAApplication>>updateRoot:
> > WASession>>updateRoot:
> > WARender>>buildDocRoot
> > WARender>>buildResponse
> > [] in WARender>>render {[:u | url := u. self buildResponse]}
> > [] in WASession>>respond: {[:cc | url := self actionUrlForContinuation:
> > cc. response := responseBlock...]}
> > ResponseContinuation class(Continuation class)>>currentDo:
> > WASession>>respond:
> > WARender>>render
> > [] in WARender>>go {[self render]}
> > BlockContext>>on:do:
> > WARender>>withRenderNowHandler:
> > [] in WARender>>go {[self withRenderNowHandler: [self render]. self
> > shouldRedirect ifTrue: ...]}
> > BlockContext>>on:do:
> > ======
> >
> > If I: WADispatcher resetAll
> > I rcv DNU: WAFileHandler: #basePath
> >
> > WAFileHandler>>registerAsHandler: aString sends the message:
> >
> >   handler := self new basePath: aString.
> >
> > aString is: 'files'
> >
> > WAFileHandler is trying to initialize, but there is no #basePath
> >
> > So, I did something wrong during updating.
> >
> > Any hints????
> >
>
> Luckily I saved the image in increments. I went one back and it seems to
> work.
>
> What I merged for the last image version, that didn't work, was

> So, could any of these packages be the cause of the above trace?
>
> --
> brad fuller
>   http://www.Sonaural.com/
>   +1 (408) 799-6124
>
>
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

> Brad Fuller wrote:
> > Brad Fuller wrote:
> >> Lukas Renggli wrote:
> >>>> >     WAComponent allSubclassesDo: [ :each | each initialize ].
> >>>> >     WADispatcher resetAll.
> >>>
> >>> After doing this you need to stop and restart the server, so that it
> >>> catches the new dispatcher.
> >>>
> >>>> UPDATE: Twice I stopped WAKom and restarted. The 3rd time, I stopped
> >>>> it,
> >>>>   waited, and restarted and Seaside came up. Don't know if it was a
> >>>> browser cache problem or what.
> >>>>
> >>>> But, I don't have my Pier app. And, I want my Pier app!
> >>>
> >>> Excellent, now re-initialize Pier:
> >>>
> >>>     PRPierFrame initialize.
> >>>
> >>> Answer: yes (create an entry point) - no (create a new kernel) - a
> >>> Kernel (select your old kernel) - accept (suggested entry point) - ok
> >>> (try in the web browser).
> >>
> >> Ok, another problem. I upgraded per your advice for the order. I saved
> >> as new version just so I could get back to where I was.
> >>
> >> Seaside ran fine when updating. No problem.
> >> But, when I run the new version I rcv from the browser:
> >>
> >> ======
> >>  Internal Error
> >> MessageNotUnderstood: WAStandardFiles>>urlOf:
> >>
> >> [] in WAStandardFiles(WAFileLibrary)>>updateRoot: {[:each | (each
> >> endsWith: #Js) ifTrue: [aHtmlRoot javascript url: (sel...]}
> >> Array(SequenceableCollection)>>do:
> >> WAStandardFiles(WAFileLibrary)>>updateRoot:
> >> WAStandardFiles>>updateRoot:
> >> [] in WAApplication>>updateRoot: {[:each | each default updateRoot:
> >> anHtmlRoot]}
> >> OrderedCollection>>do:
> >> WAApplication>>updateRoot:
> >> WASession>>updateRoot:
> >> WARender>>buildDocRoot
> >> WARender>>buildResponse
> >> [] in WARender>>render {[:u | url := u. self buildResponse]}
> >> [] in WASession>>respond: {[:cc | url := self
> >> actionUrlForContinuation: cc. response := responseBlock...]}
> >> ResponseContinuation class(Continuation class)>>currentDo:
> >> WASession>>respond:
> >> WARender>>render
> >> [] in WARender>>go {[self render]}
> >> BlockContext>>on:do:
> >> WARender>>withRenderNowHandler:
> >> [] in WARender>>go {[self withRenderNowHandler: [self render]. self
> >> shouldRedirect ifTrue: ...]}
> >> BlockContext>>on:do:
> >> ======
> >>
> >> If I: WADispatcher resetAll
> >> I rcv DNU: WAFileHandler: #basePath
> >>
> >> WAFileHandler>>registerAsHandler: aString sends the message:
> >>
> >>   handler := self new basePath: aString.
> >>
> >> aString is: 'files'
> >>
> >> WAFileHandler is trying to initialize, but there is no #basePath
> >>
> >> So, I did something wrong during updating.
> >>
> >> Any hints????
> >>
> >
> > Luckily I saved the image in increments. I went one back and it seems to
> > work.
> >
> > What I merged for the last image version, that didn't work, was
> > Pier-Magma
> > rsrss
> > Pier-Blog
> >
> > And, I also tried to merge FileLibrary, in this last version, but I
> > could never get it to merge. When I pressed the Merge button in the
> > Merge Dialog box, it just did nothing.
> >
> > So, could any of these packages be the cause of the above trace?
> >
>
> (I know I keep replying to my own messages, but I think logging this is
> good for others. )
>
> Ok, I found another problem. The version that I thought worked does not.
> It bails on any updates to Pier pages (removing them, saving them.) So,
> I went another version back. This version seems to work (HA! Famous Last
> Words!) I've added pages, removed them, moved them, etc... so at least
> that works.
>
> To recap, this version has Seaside, Pier and Magritte from SqueakMap
> Then, I upgraded in stages.
>
> ==
> What this version does not have is:
> Upgraded Magritte
> Upgraded Pier
>
> ==
> What this version has is:
> Latest Seaside (2,7a1-mb.203)
> Latest Scriptaculouse (lr-171)
> Latest Seaside Installer
>
> (no other Seaside packages)
>
> BTW, this is all on v3.9 final
>
> Does this not point to a problem up dating Pier and/or Magritte?. That's
> my first questions.
>
> Should I not Merge but instead Load this packages?

> --
> brad fuller
>   http://www.Sonaural.com/
>   +1 (408) 799-6124
>
>
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

> Carl Gundel a écrit :
>> Is it possible to do something like this with an image button?
>>
>>  html imageButton
>>    callback: [ self doStuff ];
>>    url: self buttonUrl;
>>    submitFormNamed: 'myform'
>>
>> It works with anchors, but not image buttons.
> Carl,
> If the image button is enclosed in the form, then it will submit the form,
> therefore image button does not implement #submitFormName:
> Maybe you are trying to place your image button outside the form or
> even trying to place it inside another form with the idea of submitting
> two forms or more (not a recommended practice IMO)^then you
> may want to try using #onClick: like in the check box implementation
> of #submitFormName:

> But, be that as it may, thanks for the help, I really appreciate it!
> You've been very helpful.
>
>
> brad
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

> 2007/2/23, Brad Fuller <[hidden email]>:
>> Philippe Marschall wrote:
>> > FileLibrary is part of Seaside since October last year and since then
>> > has been developed inside Seaside. Merging it is not a clever idea.
>>
>> Clever or not, there are several comments on this ml that suggested
>> merging was preferable to loading. Don't know who said it. In fact, I
>> 'loaded' my first upgrade test of Seaside/Magritte/Pier. It was
>> disastrous. At least now I have the latest Seaside running ;-)
>
> I feel there is some confusion about loading versus merging.
> Loading replaces the code in you image with the code of the version
> you load. This is similar to checking out a specific CVS/SVN revision.
> Merging tries to figure out what changed between the code in the image
> and the code of a version and only load those changes. Although this
> sounds like a good idea, figuring out takes much more time than just
> loading everything. This is more like a CVS/SVN update.

> Philippe Marschall wrote:
> > 2007/2/23, Brad Fuller <[hidden email]>:
> >> Philippe Marschall wrote:
> >> > FileLibrary is part of Seaside since October last year and since then
> >> > has been developed inside Seaside. Merging it is not a clever idea.
> >>
> >> Clever or not, there are several comments on this ml that suggested
> >> merging was preferable to loading. Don't know who said it. In fact, I
> >> 'loaded' my first upgrade test of Seaside/Magritte/Pier. It was
> >> disastrous. At least now I have the latest Seaside running ;-)
> >
> > I feel there is some confusion about loading versus merging.
> > Loading replaces the code in you image with the code of the version
> > you load. This is similar to checking out a specific CVS/SVN revision.
> > Merging tries to figure out what changed between the code in the image
> > and the code of a version and only load those changes. Although this
> > sounds like a good idea, figuring out takes much more time than just
> > loading everything. This is more like a CVS/SVN update.
>
> yep, I got that. Thanks.
>
> >
> > to sum up:
> > Loading is the right thing unless you have a branch or local changes.
> > You neither need to load nor merge file library.
>
> Why? It's a separate package. Is it now included in another package?

> 2007/2/23, Brad Fuller <[hidden email]>:
>> Philippe Marschall wrote:
>> > 2007/2/23, Brad Fuller <[hidden email]>:
>> >> Philippe Marschall wrote:
>> >> > FileLibrary is part of Seaside since October last year and since
>> then
>> >> > has been developed inside Seaside. Merging it is not a clever idea.
>> >>
>> >> Clever or not, there are several comments on this ml that suggested
>> >> merging was preferable to loading. Don't know who said it. In fact, I
>> >> 'loaded' my first upgrade test of Seaside/Magritte/Pier. It was
>> >> disastrous. At least now I have the latest Seaside running ;-)
>> >
>> > I feel there is some confusion about loading versus merging.
>> > Loading replaces the code in you image with the code of the version
>> > you load. This is similar to checking out a specific CVS/SVN revision.
>> > Merging tries to figure out what changed between the code in the image
>> > and the code of a version and only load those changes. Although this
>> > sounds like a good idea, figuring out takes much more time than just
>> > loading everything. This is more like a CVS/SVN update.
>>
>> yep, I got that. Thanks.
>>
>> >
>> > to sum up:
>> > Loading is the right thing unless you have a branch or local changes.
>> > You neither need to load nor merge file library.
>>
>> Why? It's a separate package. Is it now included in another package?
>
> It is included in seaside, last October the classes were moved into
> Seaside. Since then the development of the stand-alone package has
> stopped and only the classes in the Seaside package have been
> improved. Pier and Seaside will no longer work with the old,
> stand-alone version of FileLibrary.