Jerry is a jQuery in Java. Jerry is a fast and concise Java Library that simplifies HTML document parsing, traversing and manipulating. Jerry is designed to change the way that you parse HTML content.
I'd be interested to know where this is being used. Having JS jQuery on eg Node.js servers makes sense so you can share server- and client-side code. But if you are manipulating HTML DOM models in Java on the server, there are definitely easier and more performant ways of doing it.
Or maybe there is a completely different use case I am forgetting...
One clever use, and I am planning to do it, is using Jerry as basis for a new generation of template engine, where [X]HTML did not need jsp/php/jsf integration. By using css/jquery selector and with powerfull manipulation on html tree that Jerry provides, we can achieve almost every transformation (data, customization,image insertion,...) without modifying the html template, evolution is easier. Top of it, HTML designers can give us the html/css/jquery selector
IMO, this is a very neat feature in the website, webapp production chain.
It's about parsing and manipulation. As I see, every tool has its own use. If some need the fast(est) code and little memory consumption as possible, he can try, for example, our Lagarto event-base HT(X)ML parser. If requirements allow some slower performance and more memory use, they can use our Lagarto DOM, or, at the end, any other tool they are familiar with. Some people likes XPath, for example. I am using jQuery and like to think in CSS3 selectors. Therefore, if my requirements do not strive for the best possible performances, I would allow myself using a tool that is familiar and easy to use, and fast to code with. So what is easier at some point belongs to a personal choice, imho;)
Comments
kitdavies replied ago:
I'd be interested to know where this is being used. Having JS jQuery on eg Node.js servers makes sense so you can share server- and client-side code. But if you are manipulating HTML DOM models in Java on the server, there are definitely easier and more performant ways of doing it.
Or maybe there is a completely different use case I am forgetting...
taharqa replied ago:
One clever use, and I am planning to do it, is using Jerry as basis for a new generation of template engine, where [X]HTML did not need jsp/php/jsf integration. By using css/jquery selector and with powerfull manipulation on html tree that Jerry provides, we can achieve almost every transformation (data, customization,image insertion,...) without modifying the html template, evolution is easier. Top of it, HTML designers can give us the html/css/jquery selector
IMO, this is a very neat feature in the website, webapp production chain.
Taharqa.
Igor Spasić replied ago:
It's about parsing and manipulation. As I see, every tool has its own use. If some need the fast(est) code and little memory consumption as possible, he can try, for example, our Lagarto event-base HT(X)ML parser. If requirements allow some slower performance and more memory use, they can use our Lagarto DOM, or, at the end, any other tool they are familiar with. Some people likes XPath, for example. I am using jQuery and like to think in CSS3 selectors. Therefore, if my requirements do not strive for the best possible performances, I would allow myself using a tool that is familiar and easy to use, and fast to code with. So what is easier at some point belongs to a personal choice, imho;)
Voters For This Link (34)
Voters Against This Link (0)