C:\Documents and Settings\gusaros\Desktop\fixformat>java FixedTesting
Exception in thread “main” java.lang.NoClassDefFoundError: org/apache/commons/lo
gging/LogFactory
at com.ancientprogramming.fixedformat4j.format.impl.FixedFormatManagerIm
pl.(FixedFormatManagerImpl.java:48)
at FixedTesting.main(FixedTesting.java:30)

Thank you.

I have a great, working library that does what you intend on doing with your library. Wouldn’t you like to join forces instead or splitting in two different ways?

Take a look:
http://tinyurl.com/32cybz

And for code refer the original version, in Portuguese:
http://blog.felipecoury.com/jep/2008/02/java-text-import-export.html

Please e-mail me if you think it’s a good idea to join forces.

Best regards,
Felipe Coury.

Have fun!

Niels came with a bunch of good suggestions on how to change the api and I will go in that direction.

But of course you are free to download the source and compile your own version. Just execute the following svn command:
svn checkout http://fixedformat4j.googlecode.com/svn/trunk/ fixedformat4j-read-only

The api is tested and works as described on fixedformat4j.ancientprogramming.com, but keep in mind that the first final version will vary a bit in usage from the current trunk version.

Ex: on my current project a number like 100.50 is to be formatted like this in string representation: 000010050+, where the signing is prepended.

Niels: I agree with the record implementation dependency and I will remove it.

To fully be able to do what you suggest I have to change the api a bit more.
Today a record modifies a StringBuffer behind the scenes as you manipulate the data through setters. That gives the user the posibility to hand in a StringBuffer and still hold a reference to an always updated buffer. We took that approach on my current project. That was neat when we had a text file with 50 different records and only had to load in and modify 10 of those before exporting the data. It was easy to export the data as we held a reference to all the stringbuffers, both those modified by record ojects and those we kept unmodifed.

It will not be a bit more hardwork (if not impossible) to keep a reference to an updated stringbuffer in your suggested POJO approach - but I like the idea of being able to export any object. The stringbuffer will suffer probably suffer then

My suggestions to api changes:
- To create an “empty” record you just create an instance like any other pojo. That makes it possible to load such objects through, say JPA.
- Do you want to create one from an existing text you have to go through the RecordManager (former RecordManager) as I dont want to force a interface implementation.
- The same goes for exporting, you have to go through the RecordManager.

The API will look Something like this:

//Empty record
MyRecord record = new MyRecord();


//A record instance loaded with text
MyRecord record = RecordManager.create(MyRecord.class, "This is a record foobar 00004200");


//export of record data
String export = RecordManager.export(record);


About adding annotations to the setters and getters it is actually possible today as well. I just included the possibility to add those to properties as well, to reduce duplication of annotation data on setter getter pairs.

Annotations - naming: Instead of @FixedFormatField, @FixedFormatPattern etc. why not settle for @Field and @Pattern? The package name of the annotations com.ancientprogramming.fixedformat4j… should surely be enough to signify that we are dealing with fixed formats?

A more important point for me, though, is the interface Record which has one method, String export()

As I understand the API a record is supposed to implement the interface. In your examples you declare your record classes as abstract so you won’t have to implement an empty export() method.

I can see why it is syntactically nice to be able to write

myRecord.export();

However, having to implement an empty method (or declare your entire class abstract) is in my view a very severe restriction to put on record classes - mostly because it is not really needed.

What I would prefer would be remove the interface Record and replace it with an annotation, much like the JPA @Entity

@Record
public class MyFixedRecord {

@Field(offset = 1, length = 10)
String getMyField() {
...
}
...
}

Furthermore I would like to have the option of putting @Field and @Pattern annotations on getters rather than fields. This would give more flexibility, e.g. the fixed format record could wrap another class and delegate its properties.

All this would of course require your FixedFormat helper classes to do a bit more work - you would need something like a FixedFormatManager (just as JPA makes use of an EntityManager).

However, the advantage of this approach is that there will be very few restrictions on the Record class. It can be a POJO or it can be something else entirely. In fact, you could have a class that is both a JPA @Entity and a FixedFormat @Record

@Entity
@Record
public class MyEntityWhichCanAlsoBeExportedInFixedFormat {
... yada yada yada
}

Now that would be rather cool, wouldn’t it?