non-HTML output from Seaside 2.9

Yesterday I succeeded in running the Seaside Counter demo in Curl (www.curl.com) in Squeak 3.10 using Alpha 4 without any XML or HTML output. Doing so required a great many changes to Seaside: MIME type defaults and hard-coded class references.  Seaside should be markup language neutral ( the Curl RTE is in use at about 30% of the global Fortune 100 and in one major government ) The poblem most difficult to detect was affecting WAApplication as there is a preferences default set to MIME 'text/html' in the configuration dict up at WAEntryPoint.  Even when all other problems were corrected, the Curl MIME type was ignored for my builder in its render context. Any generic method used in rendering which hard-codes html document type or html content type or names an Html class remains problematic.  In many cases I could only proceed by creating my own subclass and hardcoding "Curl" in place of "Html" in the offending methods.  At a few palces more generic behavior is actually in the HTml subclass than in the supposed generic parent class (a simpel refactoring issue) It was not possible to produce a package for Curl web content as an alternative to an Html package or XML package or XHTML package due to these issues: my package only runs with some 14 classes hacked to obviate hard-coded HTML bias: so I have a working IMAGE and not a working PACKAGE. Some Mime problems violated the encapsulation of the MIME classes by hard-coding 'text' and 'html' as main and sub values.  This should not be exposed without good reason.  Mime types should be parsed, not hacked. WABuilder has bias in many methods that interfered with creating a Curl subclass HttpResponse has numerous methods hard-coded to contentTypeHtml WAPrettyPrintedDocument has HTML bias in a few methods WAUrl has bias in printON: aStream WARequestHandlingConfiguration has bias in >> describeOn: config: WARequestContext has HTML bias in several methods WAREnderPhaseContinuation has a bias in >>processRendering When I found WASlime >>findBrushSelectors I did not know how to proceed, so I removed the compteing HTML subclasses and left only my Curl subclasses WARoot is worrosime of the various methods in WAUpdateRootVisitor WASession has methods such as beXHTMLString which have to be overridden whenever they are meaningless for non-XML markup It was difficutl to ascertain why the WARenderContext of the Canvas was always holding a WAHtmlDocument. WriteStream has a default contentType tied to MIMEDocument outside Seaside Object has a default contetType the same I

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Thanks for you feedback, we're very much interested in this. You're
the fist one to do this so you're unfortunately the first one finding
all these problems. It would help us a lot if you have any test cases.
That would help us find the bugs, fix them and make sure they stay
fixed.

Also, can you give us a short overview over the Curl syntax, document
structure and escaping? At least I am not familiar with it.

2009/8/27 Robert Shiplett <[hidden email]>:
This setting only affects the Content-Type HTTP header. When you
create a builder you must make sure it has the correct renderer. The
easiest way is to send #bilder to your renderer class.

Agreed, can you give examples?

> WABuilder has bias in many methods that interfered with creating a Curl
> subclass

Can you give examples?

> HttpResponse has numerous methods hard-coded to contentTypeHtml

That comes from Comanche.

> WAPrettyPrintedDocument has HTML bias in a few methods

Indeed but it is a subclass of WAHtmlDocument. It is used for the
halos to pretty print HTML. I don't think this class is useful in your
context.

> WAUrl has bias in printON: aStream

That is true. Do you use #printOn: or do you use #encodeOn: through
your document class?

> WARequestHandlingConfiguration has bias in >> describeOn: config:

Do you mean the default document class?

> WARequestContext has HTML bias in several methods

There are the class extensions from the canvas package. They should
cause not problem as long as you don't send them.

Then there are various defaults if no entry point is in the handler
chain. As long as your entry point implements the correct methods they
shouldn't be used.

> WAREnderPhaseContinuation has a bias in >>processRendering

True, but that is configurable in your application with the
renderPhaseContinuationClass property.

> When I found WASlime >>findBrushSelectors I did not know how to proceed, so
> I removed the compteing HTML subclasses and left only my Curl subclasses

That's just a code checking utility.

> WARoot is worrosime of the various methods in WAUpdateRootVisitor

Can you give examples?

> WASession has methods such as beXHTMLString which have to be overridden
> whenever they are meaningless for non-XML markup

I don't have that method.

> It was difficutl to ascertain why the WARenderContext of the Canvas was
> always holding a WAHtmlDocument.

It should only hold on to a WADocument. Can you give examples (sorry,
it's kinda repeating)?

> WriteStream has a default contentType tied to MIMEDocument outside Seaside

That comes from Comanche.

> Object has a default contetType the same

That comes from Comanche.

Cheers
Philippe
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

2009/8/27 Robert Shiplett <[hidden email]>:
Sorry I'm from Berne. Couldn't you just save the dirty Seaside
packages as Monticello versions? We could then extract the diff.

Cheers
Philippe
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside