Sorry for posting this quite late or missing the January update (depenting on the point of view). The new year started with a high workload at the office so that there weren't many days were I wanted to continue working at home. So this is pretty short.
The Lister Annotation is gone and the Editor Annotation is about to follow. This reduced the codebase a little but produced Prototypes with a higher readability. Prototypes are the classes of entities that CRUDr displays. These classes have to be annotated using the Prototype Annotation.
I'm currently thinking about pre releasing an alpha version with the readonly components implemented.
One of the most intuitive optimizations the JVM performs is method inlining. It adresses two performance issues and if kept in mind might lead to a code that's better structured and readable. Methods as a concept are quite expensive. To call a method, the JVM has to find the target for dynamic invocation, has to store the current scope on stack, has to jump to the method in question. After executing the method, the JVM has to retrieve the saved scope from the stack and resume working where it left of. Additionally method calls reduce the effectiveness of other optimization methods.
But thanks to the automatic method inlining that's of (close to) no concern to the developer.
I was finally able to track down the elusive bug mentioned in last month's SOTP, where 1:n relationships weren't displayed correctly after the model of the master component got changed. Since they weren't updated along with the rest of the displayed data, I was hunting for the place where the model chain was broken. As the model chain was in fact unbroken, this search took me a couple of days but didn't help at all. The reason why the data wasn't displayed corretly was the fact that these relations were constructed with a wrong type of model provider and thus a properly chained but completely wrong model was used. Now it kind of works but this spot needs more work done before I'm happy with this.
As a lookout, Wicket-CRUDr will see a change of paradigm. Right now, everything you want scaffolded has to be annotated and everything you want to edit has to be annotated to. This will change so that every method on the wrapper starting with "get" or "is" will result in this property displayed unless annotated with @Ignore and likewise every method starting with "set" will result in this property beeing editable unless ignore-annotated.
Now, that the project is a little more than 7 months old and taking it slow due to other obligations, I'd like to offer a little summary on the current state of the project.
I've spent a couple of hours starting a demo application using Wicket-CRUDr to show and keep track of what the framework can do right now. This application is the current Proof of Concept for the project, so whenever I run into an issue, I stop working on the application and fix the framework instead. This is necessary since there is no such thing as a project plan or even QA beyond Unittests. Main issue right now is a bug where somewhere between a displayed object and the list it contains, the model-chain is broken so that the model of the list isn't updated. Since the framework relies heavily on builders and factories this is quite hard to track (as usual when there are factories involved).