oh brilliant, I really like this design very much. Definitely will look a bit deeper into this .��

I guess it makes sense to pass the source files as string when the web app is finished to speed up loading times.��

I really like this workflow for creating web apps. Well done guys.��

On Wed, Oct 29, 2014 at 9:31 AM, S Krish <krishnamachari.sudhakar@gmail.com> wrote:

"would it not be better to have the html / css and js code outside the image ? so instead to load files instead of return strings ? "

GET: '/index.html' -> [ self openspaceHtml ];��

can be modified to:

GET: '/index.html' -> [ self�� fetch: 'html/openspace.html' ];��

and the fetch: method can be coded to return the file statically stored..���� ( increase efficiency by using a cache with change detection on say filesize / timestamp )



On Tue, Oct 28, 2014 at 1:51 AM, kilon alios <kilon.alios@gmail.com> wrote:
would it not be better to have the html / css and js code outside the image ? so instead to load files instead of return strings ?��

this would make it easier to edit the code for html/css/js . GT js integration no idea how that works, does GT has for example syntax highlighting or other js specific features ?��

Even though I always have been a supporter of Amber the IDE has still a very long way to go. Dont know about Seaside, but I assume for Seaside js code will still be something foreign. I think in practice would be better to use the IDE tools offered by firefox and chrome, though its still possible to use both amber and these tools, amber does not produce readable js code. No clue about React and SqueakJS. I am very new to web dev so probably I miss a lot, but frankly I found the fragmentation so shocking and so many negative opinions about the whole workflow that I have been reluctant to invest as much time as I have invested in Pharo. But then the things I do are not so web orientated as other people. But still I am very interested into this.

SqueakJS looks definitely ��very interesting.��

On Mon, Oct 27, 2014 at 10:05 PM, Stephan Eggermont <stephan@stack.nl> wrote:
Kilon wrote
>Really nice I now see the teapot stuff, for example this
>
>GET: 'demo/common/style.css' -> [ self styleCss ];
>
>is really flexible meaning you can interpret http addresses and map them to pharo methods. This a really cool idea indeed, I see now why people are excited about teapot. Excuse my ignorance about web >development but html/css and js always scared me away :D

I found it a very easy way to get some existing javascript app delivered fast from Pharo.
It needs a lot of refactoring and cleaning up to become maintainable though. Separate classes
for the angular components, and the canvas from Seaside to structure the html.

A more difficult aspect is how to create the javascript. For (qc)magritte applications it
looks like a builder should be able to generate form components and a json data binding.
With GT it should even be possible to integrate javascript development directly in the
pharo image.

And it might be better to use React or Amber or SqueakJS

Stephan