I seached and found one no longer available. Perhaps there is something built in - I'm receiving small updates in very large multi-layered documents without adequate explanation of changes, and looking for ways to speed up identifying the changes.
Check psd-tools library. It might help you.
Related
I have a project where i have to present data using a JavaScript library. First, i tried Chart.js with unsatisfying results. My data comes from a server by an XMLHttpRequest. I have noticed that data from approximately 100 data points my chart becomes considerably slower. After about 300 data points it becomes almost unusbale. Especially the zoom plugin. Zooming is nearly impossible. The client machine is very fast, so this should not be the issue.
After a research i found the dygraphs library very interessing. So i tried it. The performance was so much better (at 4000 data points zooming was no problem) that i decided to stick with it. The only drawback is that this library has not many chart types out of the box.
However, here comes my dilemma. After a discussion with my superior he was surprised by my statement that Chart.js is that slow. He told me to make more researches relating this two libraries. He was convinced that Chart.js should be much better than dygraphs because of its popularity. But he never worked with neither of them so i should make the choice. Also he wants to use a library that will be reliable and maintained in the future. I had some problems with my researches because i didn't found a clear answer using google.
Now, can somebody explain me the two libraries regarding their perfomance and maintenance? Which one should i use (in your personal opinion)? Is Chart.js really that slow or can i get more power of it using alternative configuration? Is the popularity really matters for the decision?
Thank you in advance.
A project I am working on makes extensive use of CFCHART. We have run into quite a few usage and performance issues with CFCHART, so I have been tasked to look at some third-party solutions to try out and recommend. Anybody have some reviews and recommendations they'd care to share?
Consider outputting the raw data and using JavaScript / Canvas to generate the charts on the fly. The load is the given to the client.
This makes it easier for screenreaders and people who like to save the data to access it as well.
Some JS charting libraries:
http://code.google.com/apis/chart/
http://omnipotent.net/jquery.sparkline/
http://code.google.com/p/flot/
http://codecanyon.net/item/graphup-jquery-plugin/108025?redirect_back=true&ref=1stwebdesigner&clickthrough_id=23945276
http://www.highcharts.com/
Not dependent on your server side technology (e.g. irrelevant to the fact that you're using CF), I have recently started playing around with HighCharts (http://www.highcharts.com/), and have been very impressed.
Bear in mind, it's not free for commercial use, but you didn't specify as to any such restrictions. Although their pricing seems pretty fair (see http://www.highcharts.com/license)
The Wijmo jQuery library has some nice charting widgets. http://wijmo.com/
We use FusionCharts. They have a comprehensive set of chart and widget types (eg sparklines) and have a very slick, professional finish.
ChartDirector is reasonable and is very advanced. It generates image-based graphs and we don't have to worry about whether or not different browsers support various advanced HTML features or Flash. You can download it, install and run it unlicensed and it will only add a little copyright in the bottom-right 20 pixels of the graph. (Licensing is inexpensive.) It comes with 239+ ColdFusion scripts so that you have plenty of sample code. Their support forums is very active and helpful.
http://www.advsofteng.com/cdcoldfusion.html
Check out the gallery. It has some very impressive samples. You can create just about anything.
http://www.advsofteng.com/gallery.html
You can try jqChart as well.
Thank you to everyone for these suggestions! This gives me a good list of applications to work with. Since there is no one "right" answer for a question like this I made sure to note each answer as useful.
So I understand that there are a few options available as far as parsing straight XML goes: NSXMLParser, TouchXML from TouchCode, etc. That's all fine, and seems to work fine for me.
The real problem here is that there are dozens of small variations in RSS feeds (and Atom feeds too), so supporting all possible permutations of feeds available out on the Internet gets very difficult to manage. I searched around for a library that would handle all of these low-level details for me, but came out without anything.
Since one could link to an external C/C++ library in Objective-C, I was wondering if there is a library out there that would be best suited for this task? Someone must have already created something like this, it's just difficult to find the "right" option from the thousands of results in Google.
Anyway, what's the best way to parse RSS/Atom feeds in an iPhone application?
I've just released an open source RSS/Atom Parser for iPhone and hopefully it might be of some use.
I'd love to hear your thoughts on it too!
"Best" is relative. The best performance you'll need to go the SAX route and implement the handlers. I don't know of anything out there open source available (start a google code project and release it for the rest of us to use!)
Whatever you do, it's probably a really bad idea to try and load the whole XML file into memory and act on it like a DOM. Chances are you'll get feeds that are much larger than you can handle on the device leading to frequent memory warnings and crashes.
I'm currently trying out the MWFeedParser #Michael Waterfall is developing.
Quite easy to set up and use (I'm a beginner iPhone developer).
His sample code for using MWFeedParser to populate a UITableViewController implementation is helpful as well.
take a look at apple's XML Performance sample -- which points to using libXML directly -- for performance and quicker updates to the display. Which may be important if you are working with very large feeds.
Check out my library for parsing Atom feeds, (BSAtomParser) at GitHub. It doesn't care about validating the feed, it does its best at returning whatever is valid. The parser covers most of RFC 4287, even extensions.
Here's my solution: a really simple yet powerful RSS parsing library: https://github.com/H2CO3/RSSKit
Have you looked at TouchCode yet? I don't think it has an RSS processor, but it might give you a start.
http://code.google.com/p/touchcode/
I came accross igasus project on sourceforge today. I haven't used it or really checked it, but perhaps it might help.
From their site:
igagus is a web service for the iPhone that allows aggregation of RSS to be delivered in an iPhone friendly format.
Actually, I was trying to suggest you ask on the TouchCode discussion board, because I remember someone was trying to expand it to support RSS. That might be a decent starting point. But I was being rushed by my wife.
But I see now that TouchCode doesn't have a discussion board. I'd still ask the author, though, he might know what came of that effort.
This might be a reasonable starting point for you. Atom support isn't there yet, but you could help out?
I am in the preliminary stages of planning a project with a client to redo their current website. I took a look at their current site to see what issues they are currently dealing with and upon inspection I noticed that every page is being rendered entirely using XSLT. I am familiar with XSLT, I have used it to render custom controls that need to be refreshed often on the client-side, but never to render an entire page.
Help me become less ignorant, what could be the reasoning behind this? What benefits or disadvantages does this bring to the table?
Server-side:
Advantages:
Clean, concise templates
An easy way to process XML data into HTML
Reasonably fast
Disadvantages:
Programming model unfamiliar and uncomfortable for many procedural-language programmers
Awkward if some or all source data is not in XML
Can be very slow when not used carefully (small changes can have large repercussions)
Client-side:
Advantages:
A convenient way to off-load processing onto client code, where scripts can potentially have much better knowledge of how best to format the resulting HTML.
Disadvantages:
Browser support is all over the map.
Google won't thank you.
Sounds like they did it because they knew XSL-T very well and already had XML data on hand.
I wouldn't like the solution myself. XSL-T isn't the easiest thing to read or write. It doesn't lend itself well to visualizing how a page will look. It cuts designers and web developers out of the process. And it doesn't internationalize well. There's nothing equivalent to Java resource bundles that can pull out locale specific information. I don't consider cut & paste a good solution.
XSLT on client side
Disables progressive rendering. User won't see anything at all until entire stylesheet and data is loaded completely.
Not supported by search engines and other crawlers. They'll see raw XML.
Not supported by older/less advanced browsers.
XSLT in general
Unless you carefully design your stylesheets, they may quickly become difficult to maintain:
with numerous templates it may be very difficult to figure out which templates are applied.
verbosity of XSLT and XML syntax make it hard to understand anything at glance.
XPath tricks are tempting, but nightmare to modify later.
I think XSLT is great when built the right way(We use a framework of templates at work).
Sounds like the All-singing-all-dancing XML fetish.
Since you can do anything with XSLT, might as well do everything. I've had people ask why a data warehouse isn't just XSLT transforms between input, data mart and reports.
Advantage. Everything's in XML.
Disadvantages.
Not very readable. Your page templates are bound up as XSLT transformations with confusing looping and conditional processing features.
Any change to page templates requires an XSLT expert, in addition to the graphic designer who created (and debugged) the HTML and CSS.
Biggest benefit: platform neutral way to render xml
Biggest disadvantage xsl is difficult to maintain
I've once had to work with an xsl over 4,000 lines long that also includes several other xsl templates. Now that was hard to work with!
The answers above provide a good survey of some of the advantages and disadvantages of XSLT. I'd like to add another disadvantage. We have found that you pretty quickly run into scalability issues when using XSLT for moderately large datasets.
When processing XML files, XSLT must load the entire document into memory. With Xalan, this consumes roughly 10x the size of the input file (saxon has an alternative DOM implementation that uses less memory). If any of your input datasets grow beyond a couple of hundred megabytes, your XSLT processor might just flake out.
This project started as a development platform because i wanted to be able to write games for mobile devices, but also being able to run and debug the code on my desktop machine too (ie, the EPOC device emulator was so bad): the platforms it currently supports are:
Window-desktop
WinCE
Symbian
iPhone
The architecture it's quite complete with 16bit 565 video framebuffer, blitters, basic raster ops, software pixel shaders, audio mixer with shaders (dsp fx), basic input, a simple virtual file system... although this thing is at it's first write and so there are places where some refactoring would be needed.
Everything has been abstracted away and the guiding principle are:
mostly clean code, as if it was a book to just be read
object-orientation, without sacrifying performances
mobile centric
The idea was to open source it, but without being able to manage it, i doubt the software itself would benefit from this move.. Nevertheless, i myself have learned a lot from unmaintained projects.
So, thanking you in advance for reading all this... really, what would you do?
Throw it up on an open source website and attach a bunch of good keywords to help search engines find it. If someone's looking for it, they'll find it and be able to use it.
I would say that you should open source it.
If you do have the time, it may be helpful for other programmers who are interested in the project to know the status of the project, and what is next to do on the project. Writing a to do list may be helpful, or writing comments in the code may also help.
If you do not have the time to write up a to do list maybe somebody is willing to take the initiative on the project, find out what needs to be done.
Look at it a different way. The worst that can happen is that your work will go unnoticed, and your efforts will be lost. The best that can happen is that you will be recognized for having the foresight to start such a great project, and open sourcing it.
http://sourceforge.net
This allows you to set up as admin and manage the project.
Of course if somebody does not agree with you they can fork the project and start their own version but that's open source for you.
If you've put time and effort into it, don't let it die a quiet death. Instead share it under the license of your choice on a collaborative site. At the worst, you get nothing in return. At the best, other people like the idea and provide constructive feedback or code. Even better is if you get some time in the future to pick it back up.
Couple of good sites to post it on
codeplex
sorceforge
Definitely, you should open source it, just make the same considerations you made on this question on a place that anybody can see...
Maybe someone will pick it up, or just learn from it
Put it up on github so we can all check it out.