[Seaside] Re: 3.0 merge status (observations and a code variant)

Julian Fitzell jfitzell at gmail.com
Sun Jan 10 23:03:29 UTC 2010 

Hi Robert,

This would all be more appropriate on the Seaside list... (I'm posting
there and CC'ing to Pier's list... could you follow up on the Seaside
list if needed? thanks)

And we've been through this previously, if I recall. The code you
mention below could probably be reduced to just "self handler
documentClass on: self response stream codec: self codec". handler
really never should be nil so what the default is is pretty
irrelevant. If you are using a different class of Document, you need
to configure that document class for your handler. If you don't want
to use the web config UI, it's as simple as:

myApplication preferenceAt: #documentClass put: MyDocumentSubclass

As for the other suggestions, I'm still not convinced. As I said
before, I support your goal of outputting something other than HTML,
but Seaside's RenderLoop is designed to render HTML and
WARenderPhaseContinuation makes several assumptions about doing Html.
Its #updateRoot: calls several HtmlRoot-specific methods and passes
the root to the Libraries, which also all expect an HtmlRoot.  If you
want to use something else with the RenderLoop, that's fine, but I
think you'll need to subclass the Continuations to do it, thus you can
override #processRendering: to do whatever you like. The Continuations
were designed to be subclasses; that's why there's a configuration for
them:

myApplication preferenceAt: #renderPhaseContinuationClass put:
MyContinuationSubclass
myApplication preferenceAt: #actionPhaseContinuationClass put:
MyContinuationSubclass


Julian

On Sun, Jan 10, 2010 at 2:39 PM, Robert Shiplett <grshiplett2 at yahoo.com> wrote:
> "I have to re-write the method "
> WARequestContext
>>>newDocument
>        "Answer a new Document configured to write onto our Response's stream using the current Codec. Try to use the Document class specified by the closest Handler but fall back on WAHtmlDocument if there is none."
>
>        ^ (self handler isNil
>                ifTrue: [ WAHtmlDocument ]
>                ifFalse: [ self handler documentClass ])
>                        on: self response stream codec: self codec
>
> "as"
>
>>>newDocument
>        "Answer a new Document configured to write onto our Response's stream using the current Codec. Try to use the Document class specified by the closest Handler but fall back on the WARenderer default documentClass if there is none."
>
>        ^ (self handler isNil
>                ifTrue: [ WARenderer default documentClass]
>                ifFalse: [ self handler documentClass ])
>                        on: self response stream codec: self codec
>
> to even get my Curl app off the ground.
>
> There are a few other places where I am hitting this (most anywhere up in  the high level of the framework where we drop in an HTML default rather than asking for the default - even immediately after having asked for the app contentType in this case ... which in my case is not WAMimeType>>textHtml )
>
> --- On Sun, 1/10/10, Lukas Renggli <renggli at gmail.com> wrote:
>
>> From: Lukas Renggli <renggli at gmail.com>
>> Subject: Re: 3.0 merge status (observations and a code variant)
>> To: "Magritte, Pier and Related Tools ..." <smallwiki at iam.unibe.ch>
>> Date: Sunday, January 10, 2010, 1:25 PM
>> > Using a vanilla Pharo 11.4
>> install as recommended today at the pharo downloads page
>> with the Seaside.st mcm file all looks to be going well
>> until methods begin to recompile late in the load: the image
>> is 60 MB and Pharo.exe simply consumes the available CPU
>> cycles but the working memory size stays fixed.
>>
>> I don't know a Pharo 11.4 image. That looks more like a VM
>> version.
>>
>> Aha, now I understand. This is installer that tries to
>> unload traits.
>> Very strange, almost like a trojan.
>>
>> I've removed the installer and sake script because they
>> both depend on
>> installer. The other scripts work for me though, I get a
>> working image
>> within a few minutes.
>>
>> Lukas
>>
>>
>> > After 15 - 20 minutes I conclude that it is dead (the
>> UI is unresponsive) and kill it with Process Explorer.
>> > There is no busy cursor, no visible message box, no
>> minimized msg box at the bottom.
>> >
>> > Nothing new gets logged.  I would say it was very
>> close to being done given what is in the frozen view of the
>> Monticello browser ...
>> >
>> > The last change written to .changes was this:
>> >
>> > RBAssignmentNode removeSelector: #assignmentPosition!
>> > !RBLiteralNode commentStamp: 'md 8/9/2005 14:58'
>> prior: 34068596!
>> > RBLiteralNode is an AST node that represents literals
>> (e.g., #foo, #(1 2 3), true, etc.).
>> >
>> > Instance Variables:
>> >        token   <RBLiteralToken>
>>  the token that contains the literal value as well as its
>> source positions
>> >
>> > !
>> > !RBLiteralNode commentStamp: 'md 8/9/2005 14:58'
>> prior: 40424826!
>> > RBLiteralNode is an AST node that represents literals
>> (e.g., #foo, #(1 2 3), true, etc.).
>> >
>> > Instance Variables:
>> >        token   <RBLiteralToken>
>>  the token that contains the literal value as well as its
>> source positions
>> >
>> > !
>> >
>> > --- On Sat, 1/9/10, Lukas Renggli <renggli at gmail.com>
>> wrote:
>> >
>> >> From: Lukas Renggli <renggli at gmail.com>
>> >> Subject: Re: 3.0 merge status (observations and a
>> code variant)
>> >> To: "Magritte, Pier and Related Tools ..." <smallwiki at iam.unibe.ch>
>> >> Date: Saturday, January 9, 2010, 7:26 PM
>> >> > There are also many places where
>> >> OmniBrowser is broken or where classes in O2 have
>> instances
>> >> being sent messages by OB - I have not even
>> bothered
>> >> debuggin those as they do not generally impede
>> finding what
>> >> is needed to get a base image (Squeak 3.10) or
>> Pharo RC-1
>> >> (pharo1.0-10502-rc1web09.12.2) to run Seaside 3.0
>> on Win XP
>> >> SP3
>> >>
>> >> O2 has overrides in OB code. You cannot load both
>> into one
>> >> image.
>> >>
>> >> > Here is my last list of classes where I
>> comment out
>> >> the class-side initialize until I have all nec
>> loaded, then
>> >> uncomment all of those and let fire
>> >>
>> >> This is more a Seaside related comment, but I use
>> the
>> >> following
>> >> script. It works out of the box for me:
>> >>
>> >> [ Gofer new
>> >>         squeaksource: 'Seaside30';
>> >>         package: 'LoadOrderTests';
>> >>         load ]
>> >>
>> >> valueSupplyingAnswers: {
>> >>
>> >>         {'Load Seaside'. true}.
>> >>
>> >>         {'SqueakSource User Name'. ''}.
>> >>
>> >>         {'SqueakSource Password'. ''}.
>> >>
>> >>         {'Run tests'. false}.
>> >>                 }
>> >>
>> >> Lukas
>> >>
>> >> --
>> >> Lukas Renggli
>> >> http://www.lukas-renggli.ch
>> >>
>> >> _______________________________________________
>> >> Magritte, Pier and Related Tools ...
>> >> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>> >>
>> >
>> > _______________________________________________
>> > Magritte, Pier and Related Tools ...
>> > https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>> >
>>
>>
>>
>> --
>> Lukas Renggli
>> http://www.lukas-renggli.ch
>>
>> _______________________________________________
>> Magritte, Pier and Related Tools ...
>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>>
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>

More information about the seaside mailing list