tldr: How do I tell whether route_cgi.lsp is running?
A "submit" button on index.nhtml POSTs to script.nl. Instead of getting the desired/expected response from script.nl, I get the full text of the script file.
index.nhtml and script.nl are both in /views, and route_cgi.lsp is in /plugins-active... however, the same thing happened when route_cgi.lsp was in /plugins-inactive.
I got stuck trying to debug because I do not know how to verify whether route_cgi.lsp is loading/running. It doesn't show up in the network debugger (but I don't know if it should), but script.nl does.
I apologize for asking such a simple question. I have no other experience with web frameworks or cgi. I tried google, but all the answers seemed to be specific to PHP or Perl, etc.
Thank you for any help. :)
Hi Ghyll!
Welcome to the newLISP world! Any questions are great and will help others learning.
First questions:
1. Why are You using .nhtml as extension for the views - just use .html and Dragonfly will execute it
2. Working with forms is easier via resources (//http://dragonfly.neocortex.io/dragonfly_routes)
If You'd like just sent me the code as a ZIP and I'll help You out.
Greetings from Germany
Marc
Hi Marc - what happened to //http://www.rundragonfly.com? I went there the other day (problems with Dragonfly and newlisp v10.6) and I didn't understand a thing (although I liked the castle) !
Hi Marc, thanks for the help :) Unfortunately, the code is proprietary, so I can't take advantage of your offer to check a ZIP.
1. .nhtml is for views containing newLISP code, and .html is for views without -- just an easy way to check at a glance.
2. The .nl script is not RESTful, so I don't think it would properly translate to a resource. (Not fixing the cgi bit would also require re-writing all of the other .nl scripts as resources.)
route_cgi.lsp is loading -- I had it print something on the view (apologies for not thinking of this before I posted). The .nl script still isn't running, but I'll keep troubleshooting.
Quote
I just quit a lot of rare used domains including this one. I'll put the Dragonfly Example Site under my current main domain uberberg.com.
Or just Google "dragonfly example-site" (//https://www.google.de/#q=dragonfly+example-site&start=10) to find some Dragonfly users ;-)
Update:
It's here: //http://dragonfly.uberberg.com
Cool, thanks! On Github there are a number of other repos too - e.g. https://github.com/marchildmann/Dragonfly (Last updated 6 years ago... ! :)). And there's a four-year old version (https://github.com/taoeffect/dragonfly-newlisp).
I've been tinkering with my local copy (I had problems when the host upgraded to 10.6, don't know what they were, though). It's still nice and quick though!
Perhaps sometime you can put the definitive latest version on Github and people can start putting in pull requests...
BTW Google Code is
Quote from: "ghyll"
1. .nhtml is for views containing newLISP code, and .html is for views without -- just an easy way to check at a glance.
2. The .nl script is not RESTful, so I don't think it would properly translate to a resource. (Not fixing the cgi bit would also require re-writing all of the other .nl scripts as resources.)
route_cgi.lsp is loading -- I had it print something on the view (apologies for not thinking of this before I posted). The .nl script still isn't running, but I'll keep troubleshooting.
So dragonfly overrides
You should use the
Quote from: "itistoday"
Changing
called from user function Dragonfly:eval-template
called from user function Dragonfly:display-file
called from user function Dragonfly:display-view
called from user function Dragonfly:display-error
called from user function $error-event
with all but the first line repeated dozens of times.
I am using Dragonfly 0.72, and have made only the following changes to Dragonfly:
- route_cgi.lsp moved to /plugins-active
- (constant 'VIEW_EXTENSION ".nhtml") [line 36 of config.lsp]
- (constant 'LOG_LEVEL 'LOG_DEBUG) [line 78 of config.lsp]
I'm continuing to fiddle and troubleshoot, but of course appreciate any help figuring out what might be preventing the .nl script from running. :-)
Quote
called from user function Dragonfly:eval-template
called from user function Dragonfly:display-file
called from user function Dragonfly:display-view
called from user function Dragonfly:display-error
called from user function $error-event
Sounds like some HTML file that has newLISP in it has an improper call to 'find'.
As for segfaults, I can't help there, those shouldn't happen at all, and if they do that's something Lutz would need to help with.
Some functions in newLISP have syntax patterns which can crash the system when not used properly. Most of these deal with hardware access or importing from C-libraries.
Improperly self-modifying code can also lead to crashes. So does using the
These cases are mentioned in the documentation. When properly used, these features are also what makes newLISP unique among scripting languages.
Quote from: "ghyll"
Quote from: "ghyll"
[ERROR]: ERR: list or string expected in function find : nil
called from user function Dragonfly:eval-template
called from user function Dragonfly:display-file
called from user function Dragonfly:display-view
called from user function Dragonfly:display-error
called from user function $error-event
Apparently, all of this trouble was not a problem with Dragonfly or the .nhtml, .html or .nl files I was using. Instead, it was somehow caused/triggered by unrelated data protection software.