3.0 merge status (observations and a code variant)
Robert Shiplett
grshiplett2 at yahoo.com
Mon Jan 11 01:15:30 MET 2010
Julian
Perhaps this would help: I am not asking for different behavior in the render loop. I firmly believe that we should only subclass for behavior.
I also think that a web framework is the sort of thing that should tell you what you are expected to provide - but not to reimplement key pieces of the framework for an alternate text content-type.
Nothing that alternative document content markup requires necessitates those changes: the markup simply does not close the tag with the name of the element. Its name for "hr" is "hrule" but its name for "br" is "br". It is not XML. It is as declarative as HTML. So I handle that as a document class and some tag classes and a canvas subclass and maybe a Brush subclass if needed. Some of my tag subclasses just subclass an Html Tag class.
I think that the content type of the page that a web app opens is the content type of the cargo of that http response.
Putting the class for a RenderPhaseContinuation subclass into configuration properties seems a stretch ... at least the charset issue is surely going to have to come back to the document from the app class (if Seaside is to be used in India, for example: app is in English or Hindi or Telegu or whatever and documents are in whatever char-encoding they are in.
Even more so in those countries with a mix of Han and non-Chinese or Arabic and roman.
In the spirit of /htdocs but with UNICODE URI's
Robert
hypertext-doc guy
--- 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