I'm exploring the idea of replacing an XML->XSLT->HTML workflow with Elm, just to see if I can do it. I found an Elm XML parser, and now I just need to figure out how to read a local file into Elm. I can't seem to find anything anywhere that explains how to do that. How would I go about doing that?
You can't directly read a file in Elm. Depending on your needs, you have a few options:
If your program only needs access to a static file, you can read in the file with Javascript and provide it to Elm as a flag (see here). This is the simplest way if it meets your needs.
If you need to react to changes in the file somehow, you could again read the file in with Javascript but communicate using ports (see here).
A possibly-simpler variation would be to stand up a web server that serves the file, and then interact with it in elm using HTTP requests (see here).
Related
So for re usability, how can I reuse some particular amount of code from one feature file to other feature file.
I don't want to keep functions outside in js files.
As of now, this is not possible with karate.
IMHO, this is not even valid enhancement request. If you really want to reuse the code, it would be better idea to keep outside of feature file in js function and calling them from different feature files as and when needed.
Peter Thomas, author of Karate, mentioned here that reuse of feature is possible and one cannot reuse the particular scenario from feature file.
I don't want to keep functions outside in js files.
You don't have to. Please read the documentation. There are multiple ways for code-reuse:
the call keyword for re-usable features
Background / hooks
calling Java
Examples in the Zend tutorial:
phpunit.xml.dist
local.php.dist
TestConfig.php.dist
.dist files are often configuration files which do not contain the real-world deploy-specific parameters (e.g. Database Passwords, etc.), and are there to help you get started with the application/framework faster. So, to get started with such frameworks, you should remove the .dist extension, and customize your configuration file with your personal parameters.
One purpose I have seen in using .dist extension, is to avoid publishing personal data on VCSs (say git). So, you, as the developer of a reusable app, would use your own configuration file, but put the de-facto get-started config data in a separate .dist-suffixed file. (See Symfony2's documentation, 4th part)
After reading (nearly) the whole ebook and taking a look at the API
i am still asking myself how to realize "traditional" web server behaviour with opa.
I understand (at least i believe that) that opa links external resources specified at
compile time into the executable, making them immutable and permament.
But what if, say, i would want to change the stylesheet of an application without recompiling it?
There seems to be a few methods in the stdlib (apidoc) but they are not covering
what i am used to from other programming languages.
A possible solution i could think of is making use of the internal database,
but that looks like a bit of an overkill for something simple like traditional File I/O.
Edit: this blog post explains more about dealing with external resources in Opa.
Long story short: you'll rarely work with external files in Opa.
Let me try to break this down. Opa will indeed embed resources. But for development mode you indeed just want to be able to tweak them (mainly CSS) and see changes immediately. If you compiled your program in a non-release mode then it will support this kind of actions (try --help, below is an excerpt)
Debugging Resources : dynamic edition:
[...]
--debug-editable-css
Export the CSS files embedded in the server to the file
system, so that they can be viewed and edited during
execution of the application
For many other editable&changing resources one would indede use the database.
And if you really need to work with files (again: with Opa you'll need it much less than with traditional web languages) then take a look at stdlib.io and, for advanced use, at BslFile module with bindings to Ocaml functions for file manipulation.
I think this module is for you :
http://opalang.org/resources/doc/index.html#file.opa.html/!/value_stdlib.io
import stdlib.io
my_css = File.content("css/file.css")
I am not seeing some way to write file, but I think if you need to write you should use the db.
But to read I think this is the solution :)
I'm working on an application that embeds WebKit (via the Gtk bindings). I'm trying to add support for viewing CHM documents (Microsoft's bundled HTML format).
HTML files in such documents have links to images, CSS etc. of the form "/blah.gif" or "/layout.css" and I need to catch these to provide the actual data. I understand how to hook into the "resource-request-starting" signal and one option would be to unpack parts of the document to temporary files and change the uri at this point to point at these files.
What I'd like to do, however, is provide WebKit with the relevant chunk of memory. As far as I can see, you can't do this by catching resource-request-starting, but maybe there's another way to hook in?
An alternative is to base64-encode the image into a data: URI. It's not exactly better than using a temporary file, but it may be simpler to code.
I'd love to ask you how do the guys developing dojo create the documentation?
From nightly builds you can get the uncompressed js files with all the comments, and I'm sure there is some kind documenting script that will generate some html or xml out of it.
I guess they use jsdoc as this can be found in their utils folder, but I have no idea on how to use it. jsDoc toolkit uses different /**commenting**/ notations than the original dojo files.
Thanks for all your help
It's all done with a custom PHP parser and Drupal. If you look in util/docscripts/README and util/jsdoc/INSTALL you can get all the gory details about how to generate the docs.
It's different than jsdoc-toolkit or JSDoc (as youv'e discovered).
FWIW, I'm using jsdoc-toolkit as it's much easier to generate static HTML and there's lots of documentation about the tags on the google code page.
Also, just to be clear, I don't develop dojo itself. I just use it a lot at work.
There are two parts to the "dojo jsdoc" process. There is a parser, written in PHP, which generates xml and/or json of the entirety of listed namespaces (defined in util/docscripts/modules, so you can add your own namespaces. There are basic usage instructions atop the file "generate.php") and a Drupal part called "jsdoc" which installs as a drupal module/plugin/whatever.
The Drupal aspect of it is just Dojo's basic view of this data. A well-crafted XSLT or something to iterate over the json and produce html would work just the same, though neither of these are provided by default (would love a contribution!). I shy away from the Drupal bit myself, though it has been running on api.dojotoolkit.org for some time now.
The doc parser is exposed so that you may use its inspection capabilities to write your own custom output as well. I use it to generate the Komodo .cix code completion in a [rather sloppy] PHP file util/docscripts/makeCix.php, which dumps information as found into an XML doc crafted to match the spec there. This could be modified to generate any kind of output you chose with a little finagling.
The doc syntax is all defined on the style guideline page:
http://dojotoolkit.org/reference-guide/developer/styleguide.html