"currently WARenderPhaseContinuation>>processRendering: sets contentType for a
response with WAApplication" as
WARenderPhaseContinuation>>processRendering: aResponse
aResponse contentType: self application contentType. [...]
WAApplication
^ self mimeType seasideMimeType
charset: self charSet;
yourself
"and that is sent before getting the document instantiated (which follows
immediately.)
Of course that is no issue if all you ever return are web documents using that application
'preference' e.g. iso-8859-1 and text/html. But my application is running in a
browser where a 404 page is just a 404 (i.e, an html page) but one content page may be
Content-Type h-markup and another may be Content-Type c-markup and this in English but
that in Telegu."
The system configuration option for a render loop subclass looks even worse from where I
sit - and quite unnecessary even if it is a design feature.
Not that other web frameworks are not stickier. One that almost gets this web content
type issue right is Apache Wicket. Some other frameworks do truly descend into properties
file/configuration Hades and some, like Lift, code themselves into an HTML-only
strait-jacket where text documents are concerned (bizarre for a language like Scala.) Yet
for bare-bones CGI, JSP and PHP, Content-Type is an utterly trivial matter. Only when a
framework is built do things start to go wrong on this one simple issue.
Doing something simple should be simple; doing something complex should be possible.
R
--- On Sun, 1/10/10, Julian Fitzell <jfitzell(a)gmail.com> wrote:
From: Julian Fitzell <jfitzell(a)gmail.com>
Subject: Re: 3.0 merge status (observations and a code variant)
To: "Seaside - general discussion" <seaside(a)lists.squeakfoundation.org>
Cc: "Magritte, Pier and Related Tools ..." <smallwiki(a)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(a)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(a)gmail.com>
wrote:
> From: Lukas Renggli <renggli(a)gmail.com>
> Subject: Re: 3.0 merge status (observations and a
code variant)
> To: "Magritte, Pier and Related Tools
..." <smallwiki(a)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(a)gmail.com>
> wrote:
> >
> >> From: Lukas Renggli <renggli(a)gmail.com>
> >> Subject: Re: 3.0 merge status
(observations and a
> code variant)
> >> To: "Magritte, Pier and Related Tools
..."
<smallwiki(a)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
> >>
> >
> >
_______________________________________________
--
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