I'm trying to setup an environment for Clojurescript. The problem I'm having is not knowing how to set it up so that I can connect to a Clojurescript Browser REPL from emacs, so I can evaluate forms right from the editor and have it show up in the browser.
Things I've tried:
I tried using Cemerick's piggieback and piggybacking on nREPL. I don't really know how to configure it from the documentation. I was able to get it to work after figuring out I had to make an index.html file in the root of the project folder. Except the server doesn't serve my assets.
I tried setting up inferior-lisp with the bash script from the Clojurescript wiki. However, whenever I try to run the inferior-lisp-program I'm getting "Wrong type argument: stringp, nil".
Here's my ideal workflow:
I have a project folder/resources/public folder that has my assets and html files. I can start a web server that serves those files somehow, either by ring or using python's simple http server. I'd be able to connect to a REPL from emacs and evaluate forms into it.
Cemerick to the rescue again: Austin (https://github.com/cemerick/austin) is exactly what you're after.
Austin gives you two options: either a REPL where the JS is evaluated in a browser (a "project REPL"), or a more complete, integrated browser-connected REPL. It sounds like the latter is what you're after, and you need to dig a little harder for its docs: https://github.com/cemerick/austin/tree/master/browser-connected-repl-sample
To get the browser-connected REPL working, Chas's example is fairly straightforward to follow, and boils down to:
Add a little middleware or template magic to append a JS script element to your HTML page, and that script needs to contain the output of (cemerick.austin.repls/browser-connected-repl-js)
Start up nREPL, start up your ring server, and then
(def repl-env (reset! cemerick.austin.repls/browser-repl-env (cemerick.austin/repl-env)))
to create a REPL environment.
Turn the nREPL session from a Clojure to a ClojureScript REPL with
(cemerick.austin.repls/cljs-repl repl-env)
Connect to your still-running Ring server app with a browser, and you should be connected.
(.alert js/window "Hi!") should prove it.
Using the standard Emacs nREPL commands will work as expected, compiling ClojureScript into JavaScript and sending it to the browser for evaluation.
The main difference between Piggieback and Austin is those first and second steps: the atom is used by the middleware to add an inline JavaScript block that connects back to the nREPL. Since the HTTP URL is determined at runtime, the Ring server and client-side JavaScript need to work in concert.
FWIW I created a function in my user namespace to speed connecting the CLJS REPL:
(defn cljs-browser-repl
"Fire up a browser-connected ClojureScript REPL"
[]
(let [repl-env (reset! cemerick.austin.repls/browser-repl-env
(cemerick.austin/repl-env))]
(cemerick.austin.repls/cljs-repl repl-env)))
I had similar problems after following the tutorial on https://github.com/clojure/clojurescript/wiki/Quick-Start
What helped me was the last suggestion on
https://groups.google.com/forum/#!topic/clojure/_JWvqc3fENQ
Replacing the meta tag in index.html with
<meta content="text/html;charset=UTF-8" http-equiv="content-type">
With Figwheel main, setting up a live-reloading, browser-connected REPL has become much simpler. Figwheel.main compiles your Clojurescript source as you change it, and allows to to evaluate code in the browser.
Define your dependencies in deps.edn. :paths specifies folders to look for source code.
{:deps {org.clojure/clojure {:mvn/version "1.9.0"}
org.clojure/clojurescript {:mvn/version "1.10.339"}
com.bhauman/figwheel-main {:mvn/version "0.1.9"}}
:paths ["src"]}
Define your application entry point in dev.cljs.edn. Here, "dev" becomes the build name.
{:main example.core}
Create some ClojureScript code in src/example/core.cljs.
(ns example.core)
(let [msg "Change msg in src/example/core.cljs and see what happens!"]
(js/alert msg))
Start the REPL.
To use Emacs:
Run M-x cider-jack-in-clojurescript
Select figwheel-main as your build target
Set :dev as your build name.
With a terminal:
Run clojure -m figwheel.main -b dev -r. -b dev sets the build, and -r launches a REPL on load.
For further information, refer to Figwheel's well-made documentation.
Related
Is there a way to reuse steps in our features from "other" step files?
I.e. I have a project with login page, and topbar that I want to test after login:
Got LoginPage.feature and LoginPage.js step file, everything works fine, all tests run correctly.
I would like reuse steps “Given user open TestPage login page” and “When user login using valid credentials” from LoginPage.js in TopBarCmp.feature:
But it always ends with error:
Long time ago I used Specflow(Cucumber for .net) and it was normal to ruse steps with same singatures across all features.
What is correct way of handling that kind of situations, where we would like to use some part that was already automated?
Looks like you can put them either on cypress/integration/common or in cypress/support/step_definitions and they will be available to share across features
this article explains it better https://www.linkedin.com/pulse/part-2-hands-on-test-automation-project-cypress-reis-fernandes
so I am working on a school project in which we have designed a web application that takes in much user info and creates a pdf then should display that pdf to the user so they can print it off or save it. We are using Play! Framework 2.1.3 as our framework and server and Java for the server side. I create the pdf with Apache's PDFbox library. Every thing works as it should in development mode ie launching it on a localhost with plays run command. the issue is when we put it up to the server and launch with plays start command I it seems to take a snapshot of the directory (or at least the assets/public folder) which is where I am housing the output.pdf file/s (i have attempted to move the file elsewhere but that still seems to result in a 404 error). Initially I believed this to be something with liunx machine we were deploying to which was creating a caching problem and have tried many of the tricks to defeat the browser from caching the pdf
like using javascript to append on a time stamp to the filename,
using this cache-control directive in the play! documentation,
"assets.cache./public/stylesheets/output.pdf"="max-age=0",
then I tried to just save the pdf as a different filename each time and pass back the name of that file and call it directly through the file structure in the HTML
which also works fine with the run command but not the start.
finally I came to the conclusion that when the start command is issued it balls up the files so only the files that are there when the start command is issued can be seen.
I read the documentation here
http://www.playframework.com/documentation/2.1.x/Production
which then I noticed this part
When you run the start command, Play forks a new JVM and runs the
default Netty HTTP server. The standard output stream is redirected to
the Play console, so you can monitor its status.
so it looks like the fact that it forks a new JVM is what is causing my pain.
so my question really is can this be gotten around in some way that a web app can create and display a pdf form? (if I cannot get this to work my only solution
that I can see is that I will have to simulate the form with HTML and fill it out from there) --which I really think is a bad way to do this.
this seems like something that should have a solution but I cannot seem to find or come up with one please help.
i have looked here:
http://www.playframework.com/documentation/2.1.x/JavaStream
the answer may be in there but Im not getting it to work I am pretty novice with this Play! Framework still
You are trying to deliver the generated PDF file to the user by placing it in the assets directory, and putting a link to it in the HTML. This works in development mode because Play finds the assets in the directory. It won't work in production because the project is wrapped up into a jar file when you do play dist, and the contents of the jar file can't be modified by the Play application. (In dev mode, Play has a classpath entry for the directory. In production, the classpath points to the jar file).
You are on the right lines with JavaStream. The way forward is:
Generate the PDF somewhere in your local filesystem (I recommend the temp directory).
Write a new Action in your Application object that opens the file you generated, and serves it instead of a web page.
Check out the Play docs for serving files. This approach also has the advantage that you can specify the filename that the user sees. There is an overloaded function Controller.ok(File file, String filename) for doing this. (When you generate the file, you should give it a unique name, otherwise each request will overwrite the file from a previous request. But you don't want the user to see the unique name).
I have had some experience writing container-bound scripts, but am totally new to web apps.
How do I debug (e.g. look at variable values, step through code etc) a web app? In a container bound script it was easy, because I could set breakpoints, use the apps script debugger - how do I go about this in a web page e.g. when I execute a doPost?
In his excellent book "Google Script", James Ferreira advocates setting up your own development environment with three browser windows; one for the code, one for the live view (in Publish, Deploy as web app, you are provided with a "latest code" link that will update the live view to the latest save when it is refreshed), and one for a spreadsheet that logs errors (using try/catch wrapped around bits of code you want to keep an eye on).
In Web Apps, even the most basic debugging of variables through Logger.log() does not work!
A great solution to have at least simple variable logging available is Peter Herrmann's BetterLog for Apps Script. It allows you to log into a spreadsheet (the same as your working spreadsheet or a separate one).
Installation is very simple - just add an external resource (see the Github readme) and a single line of code to override the standard Logger object:
Logger = BetterLog.useSpreadsheet('your-spreadsheet-key-goes-here');
Remember, that the spreedsheet that you give here as a parameter will be used for the logging output and thus must be writable by anybody!
BetterLog will create a new sheet called "Log" in the given spreadsheet and will write each log call into a separate row of that sheet.
So, for me, I debug the front-end using inspector, I haven't found a way to step through code yet, but you can use 'debugger' in your javascript (along with console.log) to stop the code and check variables.
to debug the backend, what I've been doing is to write my functions like
function test_doSomething(){
payload = "{item1: 100, item2: 200}" //<- copy paste from log file
backend_doSomething(payload)
}
function backend_doSomething(payload){
Logger.log(payload)
params = JSON.parse(payload)
...
}
Then after refreshing your project on the backend, you can look at executions, grab the payload from the log file, and paste it into your test_doSomething() function.
From there, you are re-creating the call that you want to debug and you can run that, stepping through the backend code as usual.
I've already read posts like Passing PHP arguments into NetBeans into a page that features symfony url-routing
but I cannot make things work.
I would like to run the following page:
http://localhost/s/web/frontend_dev.php/travel
So I tried first the "Local Website Configuration" with Netbeans 6.9.1. As stated in the linked thread there is an issue here since I can point to the project url and to the "web/frontend_dev.php" index file but I am not able to have "/travel" as an argument since Netbeans always prefixes it with ? for parameter passing which I don't want.
I the mentioned thread the solution is supposed to be using the Script Config option. Fine
I can point to php.exe and I can point to the index file again at web/frontend_dev.php but although I can pass arguments like /travel there it still does not work since it creates a whitespace in the call:
php.exe ./web/frontend_dev.php /travel
which does not work either.
It is easier to use the following:
Set the Debug URL to "Do not open Webbrowser" (Project->Properties->Run Configuration->Advanced)
Start the debugging session with Netbeans (Netbeans doesn't start a browser but waits for a XDebug connection)
Use the easy XDebug-Firefox-Plugin to start XDebug for you Symfony App (easy XDebug)
Thats it. This is working perfectly for my Symfony apps
As far as I undersand you, this is a std-situation when there is no 101-path-mapping from file-path to URL-path.
In Eclipse you can either define a completely new path-mapping or make Eclipse request a certain URL-path. In your case you would just define localhost as your server and '/s/web/frontend_dev.php/travel' as the path to attach.
I'm pretty sure there is a similar option in NetBeans as this is in times of mod-rewrite and Zend FW a very common situation.
Due to circumstances beyond my control, my production Camping site appears at mysite.example.com/mysite. I'm pretty sure this is a common Apache / Passenger configuration issue, and I'm not interested in how to fix it right now because the server is out of my control. Suffice to say, the controller for "/" points there and I can't change that any time soon.
Now, for a long time, this wasn't an issue, because R(MyIndexController) points to the correct place. However, I serve my site's CSS using a Rack::Static call to make $SITE_ROOT/public accessible. This means that the stylesheet is at mysite.example.com/mysite/css/style.css. Here's where the problem comes in: the Camping URL() method, when called in my layout, gives http://mysite.example.com, not http://mysite.example.com/mysite. So I can't get it to point to the /css subdirectory, because it's missing a "hop" in the middle. When I run rackup locally, everything is fine (because this file is at localhost:8080/css/style.css), but on the production server I don't know how to fix it.
My question: is there another method (maybe directly from Rack?) that I should be calling instead? I really want to avoid hardcoding it, and/or having a hack to determine whether I'm running locally (for debug) or in production, for every rendering of the layout.
ETA: OK, this gets stranger. Obviously I've abstracted out some of the actual details above, part of which I think I "over-scrubbed". The "top level" URL is actually more akin to /mysite/rest (the developer-centric HTML presentation of our RESTful interface), as opposed to /mysite/management (accounts) or /mysite/ui (JQuery'd / "nice" UI). These are set up in our config.ru, via run Rack::URLMap.new(Hash['/rest' => RestModule, '/ui' => PrettyInterfaceModule, '/management' => UserManagerModule], etc.
So in answer to the comment below, R(Index), from a view in the RestModule, actually returns /mysite/rest/. As an example, I have a "home" link in the layout, which looks like a :href=>R(Index), and generates code that looks like <a href="/mysite/rest/">. The server is configured to serve files from ./public directly at the "site root", so ./public/css/style.css actually does apppear at http://mysite.example.com/mysite/css/style.css, as noted previously. It's that link that I'm having trouble automatically generating, and it's because of the Rack::URLMap that I thought I may have to rely on a native Rack method (not a Camping abstraction) to locate this resource.
So in this case, URL() actually returns http://mysite.example.com/mysite/rest/?
What about something like this?
URL().merge('../css/style.css')
This is an old question so I assume that you did already find a workaround but the new passenger + apache (or ngnix) behaves correctly for camping as far as I could replicate. Your app would be on the Documents root and all the includes in the /public folder so /public/css should be routed correctly regardless of you using a sub folder /mysite or not as passenger doesn't make a difference (again) as far as I can replicate. Therefore this should be easily solvable with passenger 3 + Apache or ngnix.