Adding Slug Generation To cuid For ColdFusion

Yesterday, I released cuid for ColdFusion - a ColdFusion port of the cuid library. In my initial write-up, I omitted the "slug()" method because it felt only tangentially related to the concept of UUID generation. However, after a conversation with James Moberg, I decided to add slug generation into the library in an attempt to be more compliant with the other implementations of cuid. That said, I have added it as a separate component.

View my cuid For ColdFusion project on GitHub.

Right now, the cuid for ColdFusion library contains two components:

• Cuid.cfc
• Slug.cfc

The Cuid.cfc ColdFusion component is used to generate cuid tokens, as demonstrated yesterday. The Slug.cfc ColdFusion component is used to generate smaller, less random tokens of varying sizes that are useful in situations in which the predictability and global uniqueness of the token is far less of a concern.

Like Cuid.cfc, Slug.cfc exposes a single public method for token generation:

<cfscript>

	slug = new lib.Slug();

	for ( i = 0 ; i <= 10 ; i++ ) {

		writeOutput( "Slug: " & slug.createSlug() & "<br />" );

	}

</cfscript>

When we run this ColdFusion code, we get the following output:

Slug: y60ai83
Slug: y61ai82
Slug: y62ai8x
Slug: y63aipt
Slug: y64aio1
Slug: y65aiga
Slug: y66aio8
Slug: y67ai84
Slug: y68ain7
Slug: y69aira
Slug: y6aai5f

At first, the createSlug() method produces tokens that are 7 characters long. As the internal counter increases, however, the tokens can grow to be 10 characters long. But, never longer.

While Slug.cfc and Cuid.cfc have a decent amount of overlap in internal functionality, I have opted to keep them as separate components because I feel like they have separate reasons for being. Yes, they both have fingerprints; and yes, they both have internal counters; and yes, they both produce bits of randomness. But, ultimately, they have different guarantees about size, form-factor, and randomness. And, they are intended for different use cases. As such, they feel more unlike than they are alike.

If anything, I should factor-out the parts that they have in common (like atomic counters and JVM inspection) and then consume those shared features as "behaviors" inside the two components. At the moment, however, that feels over-architected for the relative simplicity of the library.

If anyone else has any suggestions, I'm all ears!

Want to use code from this post? Check out the license.

Short link: https://bennadel.com/3422