> Am 17.09.2017 um 13:34 schrieb Stephane Ducasse <stepharo.s...@gmail.com>: > > Norbert can you explain the difference between "a HTML model that can > be used for streaming, too, instead just the streaming." > because indeed in Pillar we have another HTML exporter and I would > like to reuse :)
The difference is having a streaming API like seaside that uses brushes to write a HTML tag with its attributes and uses blocks to nest tags. This way at the end of the code you don't have a document model but a serialized form of the DOM that depends on the canvas you use. The standalone HTML model would be a DOM on which you can work afterwards. You can navigate, decorate etc. before serializing this the a html string. For the PharoJS this would ease the development in the pharo image. For pillar it would be a theoretical improvement to convert a pillar DOM to a HTML DOM and this to a HTML string representation. But as long as the benefits aren't clear the intermediate step for pillar likes a bit too much. But I have the strong feeling it would be good if there would be more directions you can go. We have a good XML parser that produces a XML DOM. We have pillar with its own DOM that can be converted to HTML. I don't know what SOUP is producing. And we have web frameworks where people have different ways producing for the web. I see potential in supporting multiple ways of reading and writing HTML and making this experience much more powerful. Norbert >> On Sun, Sep 17, 2017 at 1:29 PM, Norbert Hartl <norb...@hartl.name> wrote: >> >> >>>> Am 17.09.2017 um 12:12 schrieb Pierce Ng <pie...@samadhiweb.com>: >>>> >>>> On Mon, Sep 11, 2017 at 06:25:55PM +0200, Stephane Ducasse wrote: >>>> Hi Pierce Ng >>>> How different is the API from Seaside? >>>> Because I would like to use it. >>>> I like to think modularly :) >>> >>> Hi Stef, >>> >>> I modeled it after Seaside's API. However, it was really just a start and >>> needs >>> much more work. I created this when investigating writing web apps in Cuis, >>> hence the perceived need for a standalone library. Eventually I ran out of >>> time >>> and decided to stick to full Seaside loaded into Pharo. >>> >> So you've built something like seaside canvas? I like to emphasize that >> seaside is not really a standalone HTML model but (as the name says) a >> canvas which streams markup. >> What we should explore is the possibility of having a HTML model that can be >> used for streaming, too, instead just the streaming. There could be a lot of >> synergies here because web frameworks, pillar, PharoJS are all working close >> to something like that. >> >> my 2 cents, >> >> Norbert