Standalone HTML Model
Locked
12
12
 
Administrator
|
I'd like to create HTML via a DSL, like Seaside's canvas builder, but without
loading a whole web framework. Any ideas? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Cheers,
Sean |
Re: Standalone HTML Model
|
|
There is ZnHtmlOutputStream, not really a DSL, but it might help.
> On 9 Sep 2017, at 00:15, Sean P. DeNigris <[hidden email]> wrote: > > I'd like to create HTML via a DSL, like Seaside's canvas builder, but without > loading a whole web framework. Any ideas? > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > |
|
|
In reply to this post by Sean P. DeNigris
Hi sean
I want the same :). Now I have to finish my lectures for within two weeks and I should not read this mailing-list :) I do not remember what we did in Pillar. Now if you extract the canvas/builder from Seaside and rename it to avoid conflict I'm all ears. Stef On Sat, Sep 9, 2017 at 12:15 AM, Sean P. DeNigris <[hidden email]> wrote: > I'd like to create HTML via a DSL, like Seaside's canvas builder, but without > loading a whole web framework. Any ideas? > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > |
|
|
In reply to this post by Sean P. DeNigris
On 9/9/17, Sean P. DeNigris <[hidden email]> wrote:
> I'd like to create HTML via a DSL, like Seaside's canvas builder, but > without > loading a whole web framework. Any ideas? > Hello Sean 1. One idea is _not_ to go for a HTML builder DSL but for a document model plus a generator. The generator is a visitor for the document object model. There is the Pillar document model and a visitor already in place. The current challenge - actually it is not a challenge - but just needs some time - is to extract the Pillar document model (easy) and the tests (needs more time) so that it can be loaded as a stand-alone package. See a long discussion in a thread in August about including Pillar in the image. The same then applies for the HTML generator. That is just a file-out from an image which has the full Pillar loaded. So IMHO it is not so much about inventing a new HTML builder DSL but to "mold" exisiting infrastructure into shape. This has the advantage that you can generate other representations easily. 2. Another idea is to look at HttpView2 done 10 years ago and come up with a revised version. http://wiki.squeak.org/squeak/182 "No Files. No HTML. Just Smalltalk code!" A builder: http://wiki.squeak.org/squeak/637 The element hierarchy: http://wiki.squeak.org/squeak/840 Discussion --------------- Comparison of 1 and 2 In 1 you use a document model (DOM) which is independent from the representation in HTML code. Than you have a generator generating the HTML code. The DOM is actually quite close to the HTML DOM. The Pillar DOM is nicely supported in Pharo with the inspector. Neither 1 nor 2 actually take CSS into account. An issue which is important when you generate web pages. So from the Smalltalk data model point of view (web document modeling) you have a Smalltalk object which is then rendered on two output streams - HTML - CSS Things get interesting in particular if you want to generate responsive web sites. The you need to do more on the CSS side and with generating pictures as well. Regards Hannes > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > > |
|
|
Sean,
the question is of course - is it the HTML only model you are interested in or is it rather a 'web document model' (i.e. something which is displayed in a browser) thus including HTML and CSS. --HH. On 9/9/17, H. Hirzel <[hidden email]> wrote: > On 9/9/17, Sean P. DeNigris <[hidden email]> wrote: >> I'd like to create HTML via a DSL, like Seaside's canvas builder, but >> without >> loading a whole web framework. Any ideas? >> > > Hello Sean > > > 1. > One idea is _not_ to go for a HTML builder DSL but for a document > model plus a generator. > The generator is a visitor for the document object model. > > There is the Pillar document model and a visitor already in place. > > The current challenge - actually it is not a challenge - but just > needs some time - is to extract the Pillar document model (easy) and > the tests (needs more time) so that it can be loaded as a stand-alone > package. > > See a long discussion in a thread in August about including Pillar in the > image. > > The same then applies for the HTML generator. That is just a file-out > from an image which has the full Pillar loaded. > > So IMHO it is not so much about inventing a new HTML builder DSL but > to "mold" exisiting infrastructure into shape. > > This has the advantage that you can generate other representations easily. > > > 2. > Another idea is to look at HttpView2 done 10 years ago and come up > with a revised version. > http://wiki.squeak.org/squeak/182 > > "No Files. No HTML. Just Smalltalk code!" > > A builder: http://wiki.squeak.org/squeak/637 > The element hierarchy: http://wiki.squeak.org/squeak/840 > > > Discussion > --------------- > > Comparison of 1 and 2 > > In 1 you use a document model (DOM) which is independent from the > representation in HTML code. > > Than you have a generator generating the HTML code. The DOM is > actually quite close to the HTML DOM. > > The Pillar DOM is nicely supported in Pharo with the inspector. > > Neither 1 nor 2 actually take CSS into account. An issue which is > important when you generate web pages. > > So from the Smalltalk data model point of view (web document modeling) > you have a Smalltalk object which is then rendered on two output > streams > > - HTML > - CSS > > Things get interesting in particular if you want to generate > responsive web sites. > The you need to do more on the CSS side and with generating pictures as > well. > > Regards > Hannes > >> >> ----- >> Cheers, >> Sean >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> >> > |
|
Administrator
|
Hannes Hirzel wrote
> the question is of course - is it the HTML only model you are > interested in or is it rather a 'web document model' Thanks for the detailed replies! Yes, you are right. I should've given more info about my use case. I had some HTML that I was using for an email signature for my organization. Every time we have a new officer, I would dig out and hand edit an existing signature in a dumb text file. This worked as far as it goes, but when I wanted to make a change to the design, I'd have to hand edit them all. So, I thought, let's just do it automagically in Pharo! But then I ended up with a weird hybrid approach where: - PRO: I broke the HTML up into smaller logical pieces in Pharo methods - CON: The individual pieces were still just dumb text (e.g. I had to read through a string to pick out which parts belong to which tag/attribute/inner-text) - CON: I lost the ability to deal with the HTML in its own domain (e.g. open it in Dreamweaver and live edit) I reckoned that I should fully commit to one approach. Either have an HTML template file(s) which Pharo manipulates, or break up the HTML fully into a domain representation. So my goal is to have something which outputs HTML suitable for an email signature based on HTML which I already have in text/file form. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Cheers,
Sean |
|
Administrator
|
In reply to this post by Sven Van Caekenberghe-2
Sven Van Caekenberghe-2 wrote
> not really a DSL I disagree ;) It looks perfect! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Cheers,
Sean |
|
|
In reply to this post by Sean P. DeNigris
On Fri, Sep 08, 2017 at 03:15:56PM -0700, Sean P. DeNigris wrote:
> I'd like to create HTML via a DSL, like Seaside's canvas builder, but without > loading a whole web framework. Any ideas? I wrote this but subsequently decided that loading the whole of Seaside into my image just for this functionality is ok and stopped. http://smalltalkhub.com/#!/~PierceNg/WaterMint-HTML Pierce |
Re: Standalone HTML Model
|
|
I don't know how modular it is, but maybe loading only the 'Seaside-Canvas' package you can use the WAHtmlCanvas to create the HTML content. I used it together with Mandrill client by creating the mail body with the result of `WAHtmlCanvas builder render: [ :html | ... ]`. HTH. Regards, Esteban A. Maringolo 2017-09-11 7:31 GMT-03:00 Pierce Ng <[hidden email]>: On Fri, Sep 08, 2017 at 03:15:56PM -0700, Sean P. DeNigris wrote: |
|
|
In reply to this post by Pierce Ng-3
Hi Pierce Ng
How different is the API from Seaside? Because I would like to use it. I like to think modularly :) Stef On Mon, Sep 11, 2017 at 12:31 PM, Pierce Ng <[hidden email]> wrote: > On Fri, Sep 08, 2017 at 03:15:56PM -0700, Sean P. DeNigris wrote: >> I'd like to create HTML via a DSL, like Seaside's canvas builder, but without >> loading a whole web framework. Any ideas? > > I wrote this but subsequently decided that loading the whole of Seaside into my > image just for this functionality is ok and stopped. > > http://smalltalkhub.com/#!/~PierceNg/WaterMint-HTML > > Pierce > > |
|
|
Interestingly the Seaside team has realized this as well
https://github.com/SeasideSt/Seaside/issues/976 .... On 9/11/17, Stephane Ducasse <[hidden email]> wrote: > Hi Pierce Ng > > How different is the API from Seaside? > Because I would like to use it. > I like to think modularly :) > > Stef > > On Mon, Sep 11, 2017 at 12:31 PM, Pierce Ng <[hidden email]> wrote: >> On Fri, Sep 08, 2017 at 03:15:56PM -0700, Sean P. DeNigris wrote: >>> I'd like to create HTML via a DSL, like Seaside's canvas builder, but >>> without >>> loading a whole web framework. Any ideas? >> >> I wrote this but subsequently decided that loading the whole of Seaside >> into my >> image just for this functionality is ok and stopped. >> >> http://smalltalkhub.com/#!/~PierceNg/WaterMint-HTML >> >> Pierce >> >> > > |
|
|
In reply to this post by Stephane Ducasse-3
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 :) > > Stef Maybe porting Silk and let it write to some simulated DOM could be interesting as well... :-) https://lolg.it/herby/silk Herby > On Mon, Sep 11, 2017 at 12:31 PM, Pierce Ng<[hidden email]> wrote: >> On Fri, Sep 08, 2017 at 03:15:56PM -0700, Sean P. DeNigris wrote: >>> I'd like to create HTML via a DSL, like Seaside's canvas builder, but without >>> loading a whole web framework. Any ideas? >> I wrote this but subsequently decided that loading the whole of Seaside into my >> image just for this functionality is ok and stopped. >> >> http://smalltalkhub.com/#!/~PierceNg/WaterMint-HTML >> >> Pierce >> >> > |
|
|
In reply to this post by Stephane Ducasse-3
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. Pierce |
|
|
In reply to this post by Esteban A. Maringolo
On Mon, Sep 11, 2017 at 10:14:54AM -0300, Esteban A. Maringolo wrote:
> I don't know how modular it is, but maybe loading only the 'Seaside-Canvas' > package you can use the WAHtmlCanvas to create the HTML content. I also experimented with loading enough of Seaside in bits and pieces to get the canvas thing working. Was not successful back then. Pierce |
|
|
In reply to this post by Pierce Ng-3
> Am 17.09.2017 um 12:12 schrieb Pierce Ng <[hidden email]>: > >> 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. > 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 |
|
|
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 :) On Sun, Sep 17, 2017 at 1:29 PM, Norbert Hartl <[hidden email]> wrote: > > >> Am 17.09.2017 um 12:12 schrieb Pierce Ng <[hidden email]>: >> >>> 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 |
|
|
> Am 17.09.2017 um 13:34 schrieb Stephane Ducasse <[hidden email]>: > > 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 <[hidden email]> wrote: >> >> >>>> Am 17.09.2017 um 12:12 schrieb Pierce Ng <[hidden email]>: >>>> >>>> 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 |
|
|
Ok I will try to digest it :)
I do not remember how this is done in Pillar but this is a visitor and it could call a streaming generator. Stef On Sun, Sep 17, 2017 at 2:10 PM, Norbert Hartl <[hidden email]> wrote: > > >> Am 17.09.2017 um 13:34 schrieb Stephane Ducasse <[hidden email]>: >> >> 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 <[hidden email]> wrote: >>> >>> >>>>> Am 17.09.2017 um 12:12 schrieb Pierce Ng <[hidden email]>: >>>>> >>>>> 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 > |
|
Administrator
|
In reply to this post by NorbertHartl
NorbertHartl wrote
> There could be a lot of synergies here because web frameworks, pillar, > PharoJS are all working close to something like that. I first thought along these lines when using Amber. I was writing Bootstrap support and saw that it was already available for Seaside and thought, darn it feels like unnecessary fragmentation here because these are all common, well-defined concepts! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Cheers,
Sean |
|
|
In reply to this post by Sean P. DeNigris
Hi Sean-- > I'd like to create HTML via a DSL, like Seaside's canvas builder, but > without loading a whole web framework. Any ideas? In Pharo on the SqueakJS virtual machine in a web browser[1], I sketch with live DOM objects, and write them out as HTML. This way, the DSL is the actual JavaScript DOM API which is sitting in the web browser anyway, although driven with Smalltalk messages over the JS bridge. I'm also assured that everything I do with the DOM objects is legitimate, and I can handle DOM API errors live in Smalltalk. -C [1] https://caffeine.js.org/pharo -- Craig Latta Black Page Digital Amsterdam :: San Francisco [hidden email] +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS) |
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |