Cody Marquart JavaScript, Groovy, and other technology tips

Cody Marquart

JavaScript, Groovy, and other technology tips

Mar

8

Gradle Buildscript Project Dependency

  By Cody

By default Gradle doesn’t allow for a project to use another project as a dependency within the `buildscript {}` closure. However, I discovered a very quick and easy way to do just that. I’ve posted the snippet from a `build.gradle` as a Gist on github.

/**
 * View it in action:
 * https://github.com/gripes/gripes-test/blob/master/build.gradle
 */
 buildscript {
   project.getTasks().add([name: "gripes", type: GradleBuild]) {
     buildFile = '../gripes-plugin/build.gradle' tasks = ['pluginJar'] }.execute()
 }

This requires an additional task in the `build.gradle` that is being referenced. As can be seen above, the `buildscript {}` is looking for a task `pluginJar`:

 task pluginJar {
   if(!file(project.tasks.jar.archivePath).exists())
     project.tasks.jar.execute()
   }
 }

In this case, the `pluginJar` task is simply checking to see if the current version has been build and exists on the filesystem. If not, then it is built and made available to the dependent project.

Jun

22

Stripes, Groovy and Gradle All-in-One

  By Cody

The Stripes Framework is far superior to the other Java web frameworks available, especially when it comes to quick, lightweight web sites. In an effort to make developing with Stripes even easier, the Gripes Project combines Stripes with the power of Groovy.   To  make it even easier, Gripes uses the build tool Gradle to handle all application dependencies, builds, tests, and deployments.

The main goal of Gripes is allow the creation of a Stripes application in under 5 minutes.  As of version 0.1.5, this is entirely possible.

Be sure to check out the Gripes Project on GitHub.

Source Code / Wiki:  https://github.com/clmarquart/Gripes-Project

Project Overview: http://www.gripes-project.org

 

Oct

10

CMWysi. A jQuery WYSIWYG

  By Cody

Over the past months I have been exploring a new project. I have experienced first-hand the pains of using third-party applications within my web applications and the problems that can ensue. With the continual need for users to have control over their content, it is important for the WYSIWYG editors included in applications not to hinder this ability.

With this, I have been developing a pure JavaScript WYSIWYG editor using the jQuery Library as the driving force. I had a few main goals:

  1. Easily extended
  2. Unobtrusive
  3. Easily include multiple instances

In the end, the project will be available on Bitbucket for open collaboration and released under open source license.

For more information, please visit CMWysi.com and sign up to receive information on when the project is released as Beta and/or opened up for collaboration.

Jul

15

Using jQuery to have external links open in a new window

  By Cody

I usually find it best practice to have links to external sites open up in a new browser window or tab, however with some sites, you may not be in control of all the links entered. If you find yourself wanting to force all external links to perform this way, here is one line of jQuery to make all of your external links open in a window:

$("a:not([href*="+window.location.host+"])").attr("target","_blank");

It’s not foolproof, I suppose this would be a more robust version:

$("a:not([href^="+window.location.protocol+"//"+window.location.host+"])").attr("target","_blank");

Depending on your hostname, the first should be sufficient, but sometimes it better to play it safe.

Apr

11

jQuery DOM Manipulation Before Document Ready

  By Cody

I frequently come across the problem when coding certain aspects of a website, that some code can get repetitive. Not only does the repititous code bulk up the file, it gets extremely annoying to write or copy and paste.

A typical solution would be to use some sort of JavaScript to manipulate the DOM after it loads and alter as necessary. For example, say you have a pod (as on the left side of this page With an updated design, I have yet to incorporate this back into the site), that can vary in size but needs to expand depending on its content. A solution would be:


<div class='pod'>
 <div class='pod-top'></div>
 <div class='pod-mid'> ...Your Content... </div>
 <div class='pod-bot'></div>
</div>

So, for all intents and purposes, this isn’t much of a problem. But, say you wanted to make the HTML more simple. Wouldn’t it be nice to simply be able to use:


<div class='pod'>...Your Content...</div>

every time you wanted to create a new pod?

Of course it would be. So, what next? Well, we can use some JavaScript, say, jQuery.


$(document).ready(function(){
  $(".pod").each(function(){
    $(this).wrap("<div class='side-pod'></div>");
    $(this).before("<div class='side-pod-top'></div>");
    $(this).after("<div class='side-pod-bot'></div>");
    $(this).wrap("<div class='side-pod-mid'></div>");
  });
});

Now this poses another issue. The loading of the page will seem quite choppy, since the DOM needs to finish loading before the Nodes can be accessed by jQuery via the $().ready() method. Of course we can pull the manipulation outside of $().ready(), but unless this occurs after particular node, the code will would be rendered useless. And even if the JavaScript is at the end of the document, before </body>, we’ll still run into a choppy load.

In an attempt to accomplish a seemless load experience while minimizing the required code, I began to explore a plugin option for jQuery. What I’ve come up with, is the jQuery DOM Listener Plugin. It works the same as any other plugin, $(document).listen(".pod",{success:makePod}) where “makePod” would be a standard JavaScript function to perform the manipulation as shown above. If you look at the jQuery DOM Listener page, you’ll notice that top pod will load significantly faster than the second. This is because I have the listener waiting for the first pod to load, and then manipulate it as necessary, while the second is being changed within the $(document).ready();

Basically, the plugin attaches a timeout that continues until one of following conditions are met:

  1. Search Limit Exceeded
  2. DOM is Ready. (In this case, the search is passed off to the find() method and the timer is cleared)

It is possible to ignore both of these cases, and have the listener run continously, which is turned off by default. The timer relies on two things: tolerance(delay) and search limit. Together they will equal the total number of milli-seconds to listen for (ie- a tolerance of 50 and limit of 100 would listen for 5000ms or 5 seconds, after that it will clear the timeout).

I have yet to fine tune the default settings, but in any case, they can be over-ridden to fit your particular need. (Documentation to come soon).

View the jQuery Listener example page for a demonstration of benefit of using the listener function.

Any thoughts on the plugin, please let me know.