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

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

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 <pierce@samadhiweb.com>:

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

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 <pierce@samadhiweb.com> 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

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<pierce@samadhiweb.com> 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

Am 17.09.2017 um 12:12 schrieb Pierce Ng <pierce@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

Am 17.09.2017 um 13:34 schrieb Stephane Ducasse <stepharo.self@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 <norbert@hartl.name> wrote:

...

...

Am 17.09.2017 um 12:12 schrieb Pierce Ng <pierce@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

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

Am 18.09.2017 um 09:03 schrieb Craig Latta <craig@blackpagedigital.com>:

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.

Sure you can do the same with PharoJS. But there are scenarios where you want to have DOM actions without having a browser. You don't have that problem because you are in the browser Norbert

-C

[1] https://caffeine.js.org/pharo

-- Craig Latta Black Page Digital Amsterdam :: San Francisco craig@blackpagedigital.com +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)

I wrote:

I wasn't aware that one can livecode JS objects with PharoJS, only that PharoJS generates JS source which eventually runs in a browser. Can you give an example?

Well, I evaluated the PharoJS playground expressions, and browsed around the proxy support in the index.js that gets installed in a web browser. I could inject the PjLoadForTest class into the web browser and invoke its JS functions via Smalltalk messages from Pharo. I could send #at:put: to the exposed "window" proxy of the web browser (as long as the arguments were JS literals or proxies), and I could also inspect the "document" proxy, but I got an exception when I tried to invoke document.getElementWithId (via "bridge evalBlock: [document getElementById: 'someID']"). Are arbitrary JS messages supposed to work? There isn't much exception handling support beyond relaying JS error messages. (I guess one way to go would be to use the Chrome Debugging Protocol.) I didn't see how to refer to Smalltalk objects from JS (only JS objects from Smalltalk), so it seems the only Smalltalk blocks one can use as JS callback functions are those which only use objects and functions in JS-land. This might be okay for smoke-testing PharoJS apps, but I think the kind of interactive DOM object sketching I mentioned before would be uncomfortable. -C -- Craig Latta Black Page Digital Amsterdam :: San Francisco craig@blackpagedigital.com +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)