I'm having trouble with an XSL translation in Chrome. I was wondering if there any tools that would allow me to step through the style sheet to see where the problem is.
Use node tests to check the results of XPath queries.
Use the document function to test file paths
Use the JavaScript console to run XPath queries on the XML data source
Use inline templates instead of xsl:include to eliminate path issues
Use comments to eliminate xsl:include statements referencing buggy templates
Use processing-instructions to comment blocks of code that have XML comments
Use an embedded stylesheet to workaround same-origin policy restrictions
Use input tags to print xsl:variable values.
Use attribute value templates to print unknown values
Use simplified stylesheets and parameterized XPath to modularize templates
Use Opera as a cross-reference, since it shows line numbers in its XSLT error messages.
On linux there is a tool called xsltproc which takes an XSL and XML and outputs the transform.
It also shows context around errors.
I've found this most useful when I'm developing as I can test the result of my changes without the need to have a development server up and running. It just works.
However, I've noticed that the results of the transform can differ from that of Chrome for example. I don't know why this is, whether my transform was non-conforming, if Chrome is non-conforming, or if xsltproc is non-conforming.
EDIT My comment about differences between Chrome and xsltproc rendering the transform slightly differently is likely invalid.
I had modified the XML schema somewhat, and since then, xsltproc was generating tags (based on type name of types in the schema) correctly, but Chrome was not.
I was doing hard reloads to avoid Chrome reusing the cache.
I could tell Chrome was using the new xsl as there was other changes included that were being rendered.
Only the schema related tests were not working in Chrome for some reason.
I've since found that now it is magically working, with no changes to the xsl, just on a different day.
So I guess some part of the xsl was being cached somehow (perhaps just the schema bit - totally guessing here)... hence why some debugging in Chrome would be super nice.
Related
I have been using CKE 4.3.4 for a while (in conjunction with ASP.NET 4.0) and it is generally working fine. But I am having great trouble in configuring features in config.js where I need to specify a path - for example, for a custom stylesheet file (config.stylesSet) or a custom image browser (config.filebrowserImageBrowseUrl). I have only been able to get this to work by specifying an absolute url - e.g. //ckeditor/customstyles.js. Although this works, I am unhappy having to do so as it makes running my applications in different environments difficult and is also an issue when testing using IIS Express which does not provide a root name. I have seen suggestions elsewhere that I need to set a BASEHREF global variable, but I can't see why I shouldn't be able to do this within config.js itself rather than in some external script tag or whatever. I feel sure that I used to be able to do something similar with FCKEditor or earlier versions of CKEditor, so would be grateful if anyone could remind me of the correct syntax.
Jon
I'm seeing error messages about a file, min.map, being not found:
GET jQuery's jquery-1.10.2.min.map is triggering a 404 (Not Found)
Screenshot
Where is this coming from?
If Chrome DevTools is reporting a 404 for a .map file (maybe jquery-1.10.2.min.map, jquery.min.map or jquery-2.0.3.min.map, but can happen with anything) first thing to know is this is only requested when using the DevTools.
Your users will not be hitting this 404.
Now you can fix this or disable the sourcemap functionality.
Fix: get the files
Next, it's an easy fix. Head to http://jquery.com/download/ and click the Download the map file link for your version, and you'll want the uncompressed file downloaded as well.
Having the map file in place allows you do debug your minified jQuery via the original sources, which will save a lot of time and frustration if you don't like dealing with variable names like a and c.
More about sourcemaps here: An Introduction to JavaScript Source Maps
Dodge: disable sourcemaps
Instead of getting the files, you can alternatively disable JavaScript source maps completely for now, in your settings. This is a fine choice if you never plan on debugging JavaScript on this page.
Use the cog icon in the bottom right of the DevTools, to open settings, then:
You can remove the 404 by removing the line
//# sourceMappingURL=jquery-1.10.2.min.map
from the top part of your jQuery file.
The top part of the jQuery file will look like this.
/*! jQuery v1.10.2 | (c) 2005, 2013 jQuery Foundation, Inc. | jquery.org/license
//# sourceMappingURL=jquery-1.10.2.min.map
*/
Just change that to
/*! jQuery v1.10.2 | (c) 2005, 2013 jQuery Foundation, Inc. | jquery.org/license */
Purpose of a source map
Basically it's a way to map a combined/minified file back to an unbuilt state. When you build for production, along with minifying and combining your JavaScript files, you generate a source map which holds information about your original files. When you query a certain line and column number in your generated JavaScript you can do a lookup in the source map which returns the original location. Developer tools (currently WebKit nightly builds, Google Chrome, or Firefox 23+) can parse the source map automatically and make it appear as though you're running unminified and uncombined files.
(Read more on this here)
As announced at jQuery 1.11 and 2.1 Released, the source map comment will be removed so the issue will not appear in newer versions of jQuery.
Here is the official announcement:
One of the changes we’ve made in this beta is to remove the sourcemap
comment. Sourcemaps have proven to be a very problematic and puzzling
thing to developers, generating scores of confused questions on forums
like StackOverflow and causing users to think jQuery itself was
broken.
Anyway, if you need to use a source map, it still be available:
We’ll still be generating and distributing sourcemaps, but you will
need to add the appropriate sourcemap comment at the end of the
minified file if the browser does not support manually associating map
files (currently, none do). If you generate your own jQuery file using
the custom build process, the sourcemap comment will be present in the
minified file and the map is generated; you can either leave it in and
use sourcemaps or edit it out and ignore the map file entirely.
Here you can find more details about the changes.
Here you can find confirmation that with the jQuery 1.11.0/2.1.0 Released the source-map comment in the minified file is removed.
Download the map file and the uncompressed version of jQuery.
Put them with the minified version:
Include minified version into your HTML:
Check in Google Chrome:
Read Introduction to JavaScript Source Maps
Get familiar with Debugging JavaScript
The new versions of jQuery require this file http://code.jquery.com/jquery-1.10.2.min.map
The usability of this file is described here http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/
Update:
jQuery 1.11.0/2.1.0
// sourceMappingURL comment is not included in the compressed file.
If you want to get source map file different version, you can use this link
http://code.jquery.com/jquery-x.xx.x.min.map
Instead x.xx.x put your version number.
Note: Some links, which you get on this method, may be broken :)
As I understand the browser, Chrome at least, it doesn't disable the source mapping by default. That means your application's users will trigger this source-mapping request by default.
You can remove the source mapping by deleting the //# sourceMappingURL=jquery.min.map from your JavaScript file.
After following the instructions in the other answers, I needed to strip the version from the map file for this to work for me.
Example: Rename
jquery-1.9.1.min.map
to
jquery.min.map
I was presented with the same issue. The cause for me was Grunt concatenating my JavaScript file.
I was using a ;\n as a separator which caused the path to the source map to 404.
So dev tools was looking for jquery.min.map; instead of jquery.min.map.
I know that isn't the answer to the original question, but I am sure there are others out there with a similar Grunt configuration.
jQuery 1.11.0/2.1.0 the // sourceMappingURL comment is not included in the compressed file.
Assuming you've checked the file is actually present on the server, this could also be caused by your web server restricting which file types are served:
In Apache this could be done with with the <FilesMatch> directive or a RewriteRule if you're using mod_rewrite.
In IIS you'd need to look to the Web.config file.
I'm using a slightly modified version of the example generator from Jekyll's plugins section of their docs (https://github.com/mojombo/jekyll/wiki/Plugins#generators) and I'm curious if there is any way to parse a liquid/markdown file instead of a plain HTML files from the example?
Notice this line:
self.read_yaml(File.join(base, '_layouts'), 'category_index.html')
That category index.html file is the target file which will be used in generated files. My goal is to be able to pass an object to a my generator from my _config file which I can then use to build a bunch of pages from a .markdown file instead. Does anyone know if this is possible or have any recommendations for achieving this? I looked into the Kramdown lib that's used to parse markdown internally, and I'm not opposed to invoking it myself if I have to, just wasn't sure if I was going deeper than I needed to for something that should be so simple. The API for the Page object which my generator creates is here: http://ruby-doc.org/gems/docs/j/jekyll-0.12.0/Jekyll/Page.html
Thanks a ton,
- Keith
You can generate virtually any format you want, from virtually any data source you want, in a generator, because you're writing straight Ruby with full access to the Jekyll object model. For example, here's a generator I put together the other night that fetches GitHub commits during jekyll build.
The question I would be asking is this:
Do I need a plugin to accomplish this?
If so, do I need a formal generator plugin as discussed in the Jekyll docs?
Or should I subclass, monkey-patch, or otherwise change the behavior of the built-in generator?
Also, the differences between Markdown and HTML files in this context (where you control 100% of what gets generated) are mostly nominal. read_yaml IIRC will actually read the front matter from both, so that shouldn't be an issue.
Recently, I thought about how can I improve the quality of the projects, by using Continuous checking of xHTML source at Continuous Integration machine.
Look, we have a project
http://sourceforge.net/projects/jtidy - jTidy
JTidy is a Java port of HTML Tidy, a HTML syntax checker and pretty printer.
It can validate the xHTML through a command-line interface. Or this tool can be extended in the way we need, because all source code are open.
We can overwrite every Selenium validation method, such as assertTextPresent, or any other, so it will be calling the jTidy(by providing current state's HTML source), and if some errors or warnings will occur - it can be saved to Continuous Integration machine build's logs - so any project's related can see this info.
We can not to rewrite all the Selenium methods, to integrate this call on every step, but to make this calls where we want(after DOM manupulations).
Yes, we can use W3C markup validators for our sites, but there isn't any possibility to validate not initial state of page's source with this validators. After page creation, there might be lots of DOM manipulations which can produce markup errors/warnings - we can find it immediately with this scheme.
One of the benefits of using Continuous integration is that you have quick feedback from code - how it integrates with existing code base, test whether unit and functional tests pass. Why not to get an additional useful info, such as instant xHTML markup validation status. The earlier we identify the problem, the easier to fix it.
I haven't found anything on this theme in google yet.
And want to know, what do you think about this idea?
Seems like a worthwhile idea.
I've done two similar things with CI before:
I've used Ant's XMLValidate task to validate static xhtml files as part of the build process
I've used httpunit to pull pages that I then parsed as xml
But the idea of tying into Selenium to validate the content inherently during a functional test run is novel to me.
I think, that idea is brilliant but it is very hard to implement it from scratch.
But this idea is like evolution of build/quality validation process, so it will be released as ready-to-use tool with documentation someday.
Good idea! - in fact I just had exactly the same idea and was just checking to see if anyone had done it before - argh! Looks like you beat me to it :)
I was thinking along the lines of capturing and auto-submitting each page hit by selenium to the w3c HTML and CSS validtors (by file rather than link so state is held) - failing on any errors. I like the jtidy idea though.
Great in principle, but I'm not quite sure how to call it from Selenium. I'd love to see documentation explaining how to run it from Selenese, or from PHPUnit.
Is there a utility that will generate html or css for blocks of code (.net c#) when you post it on a website?
I have seen several websites with very nicely formatted code and I dont believe they do this manually.
Google prettify -
http://code.google.com/p/google-code-prettify/
I prefer Syntax Highlighter implementations (I'm using Wordpress plugin implementation for my blog).
Advantages
It is based on JavaScript and does
not care about what you have on the
server.
Posts with this formatting display
properly on different RSS feeds and
can be copied to clipboard.
It is trivial to extend syntax
rules. I'm using that to highlight
custom operators in Boo-based DSL (see sample post)
Multiple languages are supported
out-of-the-box
(source: googlecode.com)
You can get JavaScript syntax-highlighting scripts, such as this one by Dean Edwards.
This is also a jQuery version apparently based on it which looks good.
CopySourceAsHtml is an add-in for Microsoft Visual Studio 2005 that allows you to copy source code, syntax highlighting, and line numbers as HTML.
http://copysourceashtml.codeplex.com
It's highly configurable, and works much better than the download page would make you expect! Don't know if there is something similar for VS 2008
If you don't have the ability to add the google prettifier CSS reference, this would be a better way to go, as what you get is a complete HTML with the required style. I use it all the time on our developers wiki, and loving it.
An even better solution, if you don't want to bother installing anything, is to just use the little web app I wrote called BlogTrog CodeWindow:
http://www.blogtrog.com
It's easy to use. Just paste your code and embed the results.