3.0 merge status (observations and a code variant)
Robert Shiplett
grshiplett2 at yahoo.com
Mon Jan 11 00:43:27 MET 2010
Julian
Perhaps if you consider this:
Most of my issues vanish if the >>processRendering method asks the document for its content-type instead of asking an application to look in its preferences, i.e.,
"Prepare the response"
"Create objects we need"
document := self requestContext newDocument.
aResponse contentType: document contentType.
For example: how is the WAApplication to be sure of what the character-encoding is without asking the document? At the moment the WAApplication class sets charset for the response in its >>contentType method.
Robert
--- On Sun, 1/10/10, Julian Fitzell <jfitzell at gmail.com> wrote:
> From: Julian Fitzell <jfitzell at gmail.com>
> Subject: Re: 3.0 merge status (observations and a code variant)
> To: "Seaside - general discussion" <seaside at lists.squeakfoundation.org>
> Cc: "Magritte, Pier and Related Tools ..." <smallwiki at iam.unibe.ch>
> Date: Sunday, January 10, 2010, 5:03 PM
> 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
> >
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>
More information about the smallwiki
mailing list