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.sudha...@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.al...@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 <step...@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 >>> >> >> >
