Site Sponsors:
POJO or ENJO? 
All Java software developers know that the term "POJO" is an acronym stand-in; For quite some time now we have been using that P.O.J.O moniker whenever we wanted to let others know that we wanted to manage a "Plain Old Java Object."



Often data-laden, the job of the POJOs is to typically "get" and/or "set" ("read" / "write") information around our objects.

A massively popular concept, simplicity has surely been a key to success: From automatic code generation to simple coding standards, the humble POJO has provided data-centric couplings for everything from Dependency Injection to Hibernate; There are POJO refractory procedures for every popular Java IDE.



Yet POJOs have one key shortcoming: Their tight coupling to a localized method signature.

In short, when using POJO members (such as "String getName()" or "setGovernmentIdentifier(String SSN)"), we are hammering application-centric dependencies into our code. Dependencies that can make a generic frameworks far more difficult to change.

Of course the use of adaptors, polymorphism, and object factories can help us manage our POJO dependencies. All well and good. But the point of this article is to discuss how Java Developers also have a unique weapon in our language-arsenal: The humble Enumeration.

Enumerated Data Type (EDT)


We have discussed the power of Java Enumeration in our blog before. Yet far from allowing us to better manage return types, those of us who have been marvelling over Java improvements should next add the concept of data management to the list of enum-marvels.

Over the Top


Why use the word "marvel", rather than a less dramatic word?

I'm glad you asked! :-)

Enum Marvel: Simple Syntax


The first thing to note is that an 'Enum in Java is very simple to understand.
public enum MightyEDT {
edtName,
edtAddress,
edtIdentityTheft
}

For those familiar with C/C++, we will recognize the source of the syntax. One might even feel the need to suppress a African-cat-sized yawn. While valid syntax, note the missing ";" in the above?

Enum Marvel: Member Functions


Unlike in C/C++ or .NET however, once we complete the syntax (i.e. add in the semi-colon), we are setting the stage for amazing things.
public enum MightyEDT {
edtName,
edtAddress,
edtIdentityTheft ;

public static void main(String ... args) {
for(MightyEDT ref : MightyEDT.values()) {
System.out.println(ref.ordinal());
}
}
}

In Java - and unlike everywhere elsewhere at the time of this writing - an enumeration can have member functions. Just like a class.

Enum Marvel: Data Indexing


Running the above example (yes, it is a demo folks), one should note that - by default (and much like C/C++ and .NET) - that Java enumerations begin with the index of "0":
    public static void main(String ... args) {
for(MightyEDT ref : MightyEDT.values()) {
System.out.println(ref.ordinal());
}
}

Much like .NET (an unlike C/C++), each enumerated value itself is an Object.... complete with it's own set of common, as well as special 'enum members:
    public static void main(String ... args) {
for(MightyEDT ref : MightyEDT.values()) {
System.out.print(ref + ": " );
System.out.println(ref.ordinal());
}
}

Next, as we consider that the entire world of data management is about tagging data with known, human-palatable values, then we should consider that our newly enumerated-values might become as important to us as is their numerical offsets:
edtName: 0
edtAddress: 1
edtIdentityTheft: 2

Data Tagging


If you know Java, then you might be familiar with the above concepts... You might also be in the middle of likewise stifling an overdue jungle-cat-yawn, as well.

Yet - as Shakespeare might say - here is the rub: What if - rather than moving data about via brittle & breakable POJO signatures, that we instead use a tagged-data value-approach? By using enumerations, might we be able to create an object that will neither break over time, nor create queer signature-dependencies throughout our applications? Even when adding (or removing!) those data-laden getters & setters?

ENumerated Java Objects (ENJO)


Consider what happens when we combine the POJOs 'getters and 'setters with Java's Enumeration.
public enum MightyENJO {
edtName,
edtAddress,
edtIdentityTheft ;

private String[] data = new String[MightyENJO.values().length];

public String get(MightyENJO tag) {
return data[tag.ordinal()];
}

public boolean set(MightyENJO tag, String value) {
if (value == null) {
value = "";
}
data[tag.ordinal()] = value;
return true;
}

}

Adopting the simple get / set pattern shown above, we now have a plausible global convention. A practice we might ever use across all application frameworks. An easy-to-use signature designed to manage the read/write/update of 'stringifiable data types.

Better still, when applied across all data-laden frameworks we might be working on, the above enumerated get/set strategy need never change one framework at the expense of another. All we need do is to either (1) save+parse the .name() as a data prefix (a personal favourite), (2) map the .name() to a column-meta, or (3) simply add/remove enumerated types from the end of the 'enum.



Viva Homogeneity?

Ultimate Marvel: Associating Metadata


By this time in our little presentation you should rightly be asking yourself "so what the heck is the point of all this?"

The point is this: The nature of all data-laden interfaces is to relate stored values to human-consumable meta. Specifically, once armed with an ENJO we are free to associate far more than an enumerated-name to a data-field. -Through the miracle of private enum construction, each enumerated Java-type can optionally store even more meta-data:
public enum MightyENJO {
edtName("The name of your client"),
edtAddress("The address of your client"),
edtIdentityTheft("The Mark of the Beast") ;

public final String toolTip;

private MightyENJO(String toolTip) {
this.toolTip = toolTip;
}

public String get(MightyENJO tag) {
return "looke up the data here";
}
public String set(MightyENJO tag, String value) {
return "assign the data here";
}
}

Decidedly our own polymorphic type, the above signature is far more framework-friendly: In addition to being able to quickly re-factor tags such as "Identity Theft" to "Government Provides For Family", we can also just as rapidly update any associated GUI-displayable meta-data as well.

Type Conversion


We should certainly feel free to overload our 'setter to manage the to-stirng conversion for any requisite data types.

public boolean set(MightyENJO tag, String value) {
if (value == null) {
value = "";
}
data[tag.ordinal()] = value;
return true;
}
public boolean set(MightyENJO tag, float value) {
data[tag.ordinal()] = "" + value;
return true;
}
While human interfaces invariably favor strings, when it is time to do the math (pun intended), native type conversions can just as easily be included:
    public Integer getInt(MightyENJO token) {
return Integer.parseInt(get(token));
}
public BigDecimal getDec(MightyENJO token) {
return new BigDecimal(get(token));
}

How ENJOs Work for Me


To ultimately understand why I took the time to write this article, allow me to relate that I stumbled upon the need for the EDT/ENJO while working on a personal information manager. Starting out as a simple way to manage my bookmarks, this single CRUD-management application has been updated over the years to manage flashcards, invoicing, email, taxes, and even collections of photographs & other files...

While working to store a single Data-Access-Object (DAO) in as many formats as possible (XML, CSV, TDF, SQL ...) I simply got tired of perpetually updating the tool tips, column names, data-dictionary definitions, and the related GUI & Database 'Meta.

When using an Enumerated Data-Type (ETD) however, I discovered that a single ENJO could provide a Java-standard way to change (for example) the "Name" column across all JTables. --In very deed I discovered that from forms & tool-tips to Databases and XML Documents alike, morphing an entire application away from collecting "Names" to something like "Files" or "Email Address" can take but a very few moments.

So while each application was destined to manage far different data over time, at the framework-level each application pretty much managed the exact same brittle set of POJO-empesterd CRUD activities.

Conversely - rather than relying upon unique signature - not only will a single 'enum for Name rapidly re-factor to Email without ripple effect, but even when we added / removed multiple data values efficiences may by now perhaps be obvious. -Having a single opaque, asignature data type even allows cross-format serialization / deserialization routines (XML, CSV, etc.) to update automatically. -One may even choose to name-mangle metadata to support enumerated version identifiers (etc.)

Abstractions


While we may achieve a similar independence with a properly designed abstraction, over time I have found the use of an EDT to be far more forgiving. -Certainly when the goal is to create a deeply embedded cross-application codebase. When requirements change so as even my well designed signature-laden frameworks break, my ENDO Framework can continue to evolve as fast as agility demands.

From a cross-application framework vantage-point therefore, ENDO's can be even more generic (if not easier to manage!) than designing frameworks that rely upon adaptors and / or Generics. Over time I have discovered that enumerated data frameworks are allot less time consuming to both create, as well as to re-purpose.

Conclusion


Of course unlike when using Template<T> the creation of an E.N.J.O remains uniquely Java-ish at the moment. Unlike the Enumerated Java Object however, an Enumerated Data Type can be created for just about any language (even PHP.)

So even though technologies such as C/C++ and .NET lag far behind the way Java enumeration has evolved - allow me to offer up this new EDT/ENJO concept. I do so in the sincere hope that you will find the pattern useful in your cross-framework re-purposing efforts, as well.

[ add comment ] ( 932 views )   |  permalink  |  related link
Scalable Vector Graphics in HTML5 
Surely another interesting addition to the modern web is the HTML5 standard's ability to encode Scalable Vector Graphics.

Vectors


While new to many, the idea of using vectors rather than concepts such as hints & twips (not that TTF technology is not amazing!) dates back even farther than the creation of the Windows Metafile Format (WMF.) --For those interested in the Google, one will discover that the definitive set of stroke-based images typically boils down to a discussion of the plotter-based fonts created by one Dr. A. V. Hershey.



Sadly, at the time of this writing even Wikipedia offers no more than a mere 2 sentences on the Hershey Fonts topic!

For this author however, 30 odd years ago Dr. Hershey's Fonts represented the first truly inspiring collection of vector-based graphical images. -Created at the US Naval Weapons Laboratory in the late 1960s, far from now discussed as being antediluvian, once converted to SVG for HTML5 usage Hershey's pen-up / pen-down images once again seem positively avant-garde.



New Hershey Font Project


Calling each new image a "Glyph" (there are over 2000), the past two Sundays witnessed the creation of yet another project.



Published today, feel free to review our rough-and-ready (decidedly pre-alpha) new project on Sourceforge to add a little 'Hershey to your graphical Programmed and / or HTML efforts.


(*) If you would like to review the font conversion, then interested parties can overlay each new SVC glyph in their native HTML5 / CSS rendition at my Hershey Showcase:

Hershey Showcase

Note that the markup under review can be downloaded from the Sourceforge Project. A modern browser will be required to view this new encoding.

[ add comment ] ( 1386 views )   |  permalink  |  related link
Project Csv9000 - A Minimalist CSV Reader / Writer in Java 
There I was working on an export from AboutTime. Because I was using Microsoft Windows on a client-provided laptop, that ever-present copy of (what has become) darth-Excel was also 'empesterd upon it. (How be it that by adding more graphical coolness, that the Microsoft tools are actually becoming far, far less usable?)

While - before it was outsourced - Excel worked as rationally as WYSIWYG has always demanded, like many other formerly-great products "Microsoft" Excel now makes allot of arrogant & ignorant assumptions. -The most annoying of which last week was to assume that the superior, ever sort-able data format of 'YYYY/MM/DD' was not what any user could *possibly* want to preserve. --So Excel automatically detected & changed the date format to 'DD/MM/YYYY' for each and every one of my hundred-plus log / blog entries.

How enlightened ... (Not!)

Oh well, what does not kill us makes us stronger...

After noting yet another case of ESL under-think (we always get what we pay for folks!), I decided to create a new CSV-Parsing Project. --One designed to survive the assumptions of both the hopelessly under-paid, as well as tenured.

Shortly available on Sourceforge, the goal of this project is to remain the most reliable & robust CSV Reader / Writer available ... brought to us in as few lines of code as possible.

[ add comment ] ( 757 views )   |  permalink  |  related link

<<First <Back | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | Next> Last>>