I started with elm yesterday and I really enjoy using it. Without any experience in front end development I could build a nice looking webpage in only 30 lines of code, which is amazing.
Now I really want to use it in a real life example, I want to build a small blog.
But I need a way to communicate with elm. For example I need to query my database and I get a list of blog entries [Blog] and now I need to pass them to elm.
I am not sure how I would do it. I was looking though the popular haskell frameworks like yesod snap and happstack and the first thing that I found was http://hackage.haskell.org/package/snap-elm-0.1.1.2/docs/Snap-Elm.html
But it seems it is intended for serving static elm files, but I need to pass arguments to it.
Any framework that you would recommend me that already has elm support for serving dynamic elm pages?
And if not, how would you do it?
My idea was just to use elm as a skeleton and then I generate a normal html file with yesod snap or happstack and integrate this file into elm. Would this be possible?
Something that would look like this
container 1000 1000 middle <| displayHtml "/pages/my_generated_html_page.html"
Edit:
My first hacky solution was this
tPage = plainText "<script src=\"http://code.jquery.com/jquery-1.10.1.min.js\"></script>\n
<script> \n
$(function(){\n
$(\"#includedContent\).load(\"/home/maik/b.html\"); \n
});\n
</script> \n
<div id=\"includedContent\"></div>\n"
Unfortunately I am not allowed to use script tags in elm.
I recommend studying elm-lang.org's source code. The majority of it is pure Elm but there are pages that are generated on the server side with Haskell.
Related
I read since some month that NuxtJs 3 will bring a new Nitro engine able to handle both SSR and static generation.
I am unable to find any kind of document, tutorial, video or any about this feature.
But it is really what we need
Imagine to be able to do SSR of a catalogue of products having the single datasheet page, very very intensive to generate and always static in our case, be statically generated.
How can we realize it?
Briefly, how to use both SSR and static and in which sense can we use both with nitro? Which limits and what problema can lead to?
You're looking for this one: https://github.com/nuxt/framework/discussions/560#discussion-3589420
This is planned, no date yet and pretty much what you need. Expect it maybe by the end of the summer.
It should not lead any particular problem.
Is there any elm router that works for version 0.17?
There are several of them that are not compatible with the latest release.
Thank you very much!
Apparently a router is not needed any more, according to https://github.com/etaque/elm-routing-example
Do we need routers?
I don't think so anymore, at least since Elm 0.17 and port modules, and I say that as the author of elm-transit-router, one of the three main routers for Elm 0.16.
We need packages for route parsing: that is, a way to transform the string representation of the path or hash to our app internal model. There are a few packages for this already: Bogdanp/elm-route and etaque/elm-route-parser (disclaimer: I'm the author). sporto/hop also has parsing tools but it isn't yet migrated to 0.17.
For the rest, Elm is already efficient at the job, it's just a few Msg away!
In this example I added a fancy transition effect to illustrate my point: if you implement routing by yourself, you gain more power for specific behaviours.
Note: browser history handling is done with ports for now, but it will be >easy to upgrade when the Elm bindings will be ready.
I'm new to hapi.js and I would try test it out. Is it possible to develop with Hapi.js and coffeescript? Could you supply some example on how to setup hapi.js with coffeescript.
I thought the same approach would be useful. From CoffeeScript.org:
The golden rule of CoffeeScript is: "It's just JavaScript". The code compiles one-to-one into the equivalent JS, and there is no interpretation at runtime. You can use any existing JavaScript library seamlessly from CoffeeScript (and vice-versa). The compiled output is readable and pretty-printed, will work in every JavaScript runtime, and tends to run as fast or faster than the equivalent handwritten JavaScript.
If you know CoffeeScript, then you should be able to translate all examples into CoffeeScript by yourself. Else, you should learn CoffeeScript.
Copy and paste any example code into http://js2.coffee and it will show you how it may look like in coffeescript.
And yes you could easily use coffeescript also with hapi like:
Hapi = require 'hapi'
server = new Hapi.Server()
server.connection
port: 3000
server.start ->
console.log 'Server running at:', server.info.uri
I'm looking for a way to process a web page and associated Javascript from the command-line, so that the resulting DOM model can be outputted.
The purpose for this is to identify forms within the page without doing any nasty HTML (and Javascript) parsing with regular expressions.
Are there any command-line tools that will do this? So hypothetically speaking, a command-line web browser that downloads the content and outputs the DOM as text rather than producing a pretty page.
I don't know of any, but I wanted to highlight one difficulty with what you've suggested:
process a web page and associated Javascript
When would the output be? Many webpages have time-sensitive javascripts, or onclick/onhover scripts which would affect the DOM. Would you want these to be executed? All of them, or only some? It's not trivial to decide when the page is "finished" and ready for the DOM to be output after javascript manipulation. (Before javascript manipulation, it's an easier problem; just wait till the document.DOMReady event...)
Edit: I'm not saying that you don't need javascript execution at all: you might want to handle any document.write sections during loading, as they might write out a form... I'm saying it's hard to know when you've done "enough" javascript...
For java, I've had fairly good experiences with htmlunit.
I've also used the BeautifulSoup python library to parse forms and formdata. No need to specify regexps, as it'll let you traverse the DOM tree without much effort.
Using the dojo toolkit, what is the proper way of locally testing code that will be executed as cross-domain, without making the actual build?
As it appears, there are three possible options (each, with their own drawbacks):
Using local (non xd) XMLHttpRequest dojo.require
This option does not really test the xd behavior, since it dojo.require[s] the js synchronously via XHR.
djConfig.debugAtAllCosts = true;
Although this option does load the required code asynchronously (via the 'script' tag), it also pulls the code in via XHR, parses the dojo.require[s] inside that, and pulls them in. This (using the loader_debug), again, is not what the loader_xd is doing. More info on this topic in a different question.
Creating a cross-domain build
This approach requires a build, which is not possible in the environment which I'm running the code in (We're using our own on-the-fly build process, which includes only the js that is necessary for a particular page. This process is not suitable for development).
Thus, my question: is there a way to use the loader_xd, which does not require an xd build (which adds the xd prefix / suffix to every file)?
The 2nd way (using the debugAtAllCosts) also makes me question the motivation for pre-parsing the dojo.require[s]. If the loader_xd will not (or rather can not) pre-parse, why is the method that was created for testing/debugging doing so?
peller has described the situation. If you wanted to just generate .xd.js file for your modules, you could look at util/buildscripts/jslib/buildUtilXd.js and its buildUtilXd.xdgen() function.
It would take a bit of work to make your own script, but you could look at util/buildscripts/build.js for pointers.
I am hoping in the future for Dojo (maybe Dojo 2.x timeframe) we can switch to a loader that just uses script tags with a module format that has a function wrapper around the module, something that is coded by the developer. This would allow the same module format to work in the local and xd cases.
I don't think there's any way to do XD loading without building and deploying it. Your analysis of the various options seems about right.
debugAtAllCosts is there specifically to solve a debugging problem, where most browsers, until recently, could not do anything intelligent with code brought in through eval. Still today, Firefox will report exception in the console as appearing at the eval site (bootstrap.js) with a line number offset from the eval, rather than from the actual eval buffer, and normally that eval buffer is anonymous. Firebug was the first debugger to jump through some hoops to enhance the debugging experience and permitted special metadata that Dojo's loader injects between the XHR and the eval to determine a filepath to the source. Webkit/Safari have recently implemented this also. I believe debugAtAllCosts pre-dates the XD loader.