> 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

Reply via email to