The Goldfish Chronicles

When I released XmlWriter 1.0 on Sourceforge, I screwed the licensing up and used an Apache license rather than a generic BSD-template one. Interesting seeing where 1.0 crops up in util libraries

http://dbunit.sourceforge.net/xref/org/dbunit/util/xml/XmlWriter.html
http://www.jahia.org/javadoc-dev/org/jahia/utils/xml/XmlWriter.html

Since then I’ve moved to 2.2, stopped using Sourceforge as I found it a pain in the arse and got the license fixed.

TDD is a good solid way to code, if you’re a bottom-up coder. I’m a top-down coder, so TDD is useless.

Often, I begin coding [following the sketched out design] at the top level with interfaces and a scaffold to drive the interfaces. The interfaces are all then stubbed out where implementation is necessary with a Null pattern version of some kind.

I can’t write a Unit Test here as I’m not at the unit level, and won’t be writing units until near the end of the coding session. When I reach that point, it is unlikely my framework will be suited to units and so I face the choice of either hacking the framework to make my low-level implementations into good ‘units’, or not having a low level unit test.

Effectively it’s white-box vs black-box. TDD and Unit Tests are white-box, bottom-up development. This fits a scenario in which you know exactly what you’re going to code etc etc, RUP blah blah. In a top-down scenario, you’re able to be far more creative at the code level, without having to design down to the implementation level [just the interface level], but chances are you won’t have good units.

Maybe the solution is that top-down development be used for a prototype phase, then all code thrown away and a bottom-up TDD phase is used. Prototype phase could even be called 1.0 with TDD phase 2.0.

On a positive note, I do find TDD very useful for utility style methods, where top-down and bottom-up coding are effectively the same. I also find it useful when I’m given a series of test-data as a part of a requirement.

Annoyed that I can’t set filters up easily for a JSP page, in JSP.

Instead I have to implement the Filter interface in a class [well I could implement in the JSP, but that seems fugly even to a JSP fan like me].

Effectively I have a generic ‘_save.jsp’ which handles the saving to the persistence layer. I want to be able to wrap this with pre-persist and post-persist fragments, so I’m looking at a form like:

<persist:form type=”com.example.Bean” prepersist=”Bean.pre” postpersist=”Bean.post”>
…
</persist:form>

which translates to a <form> and various hidden tags. The action would point to “_create.jsp”, though it’s tempting to move it to a taglib as it’s easier to install this across projects. I guess <pre> and <post> can be blocks in the <form>.

[_save.jsp by the way is for a persist:form which has an id= and id_name= set.]

Obviously I’m just rambling here. A way to plug pre and post hacks into a generic ‘method’, at the JSP level.

The taglib approach seems workable. Hmm. Talking to the blog appears to be just as good as talking out loud [annoys wife] or to a colleague.

[Continuing on from a linux user group on Java meeting today]

My negative to xdoclet is that it creates a cryptic system. I agree with
Dave, that it makes it harder for someone new to, say Struts, to learn
Struts if all the bits have been xdoclet’d, but my complaint is far more
central:

Let’s take a tag library as an example. Our Tag is in:

[ignore illegal package name]
package org.jug-l.example;

import *;

/**
* @jsp:tag name=”ifTomorrow”
*/
public class IfTomorrowTag extends TagSupport {
….
}

and somewhere in our JSP we have:

….

As a new coder to the JUG-L system, I am tasked with fixing a bug with the
tomorrow code. I find the jsp and start to delve. I find that the
ifTomorrow tag and decide it sounds like a suspect. My next step is
to…erm…well…that’s it. How do I see where the code is?

find . -type ‘*.java’ | xargs grep ‘ifTomorrow’

is all very well and good, but most Java coders are not savvy with the
command line. They can do a search in Windows, but that’s a pretty slow
way to work, relying on the gui search stuff to slowly pump things back.
That might be the personal opinion of a command-line fan.

If I am coding for myself, it would be easy to find. I would be working in
project FUTURE, so the code would be in:

org.jug-l.future.taglib

though it’s possible it might also be in org.jug-l.taglibs.future, because
I might be managing things differently. And it will be in a class called
IfTomorrowTag. What luck.

However, once you throw a group of coders together, relying on naming
conventions is a very risky business.

Some of you may be suggesting that I could just look in the .tld file.
Sure. Once I unpack the war file, find it and look at it. It’s possible
that with a more basic, less automated build system, I might also have a
.tld sitting wherever xdoclet left it, but the more automated a build is
the better it is, so relying on a messy build system to save you isn’t too
good.

So that’s why I think xdoclet is a dangerous idea. It has the same problem
when used for Struts, for EJB and probably for most other uses.

It does however have big pluses. Code generation is a very good idea. I
like the ‘X’ part of xdoclet. It’s the doclet part that is bad. Generating
locals, remotes, etc with a good naming scheme [xdoclet lets you set the
name…baaad…though maybe you can default now, been 2 years since I used
xdoclet for ejb] is good. But unenforced naming conventions fall apart in
the face of multiple developers.

There is also one xdoclet bit I’m looking forward to using, if someone
ever codes it:

public class Person {

/**
* @read
* @write
*/
String name;

}

All that said, I can quite easily see myself using xdoclet for myself, but like perl, I’m wary of joining a team with varying habits/experience who indulge in such.

Last weekend I released simple-jndi 0.8.

There are some example zips now to show how to do some things, and connection pooling is available via DBCP. There are also 0 dependencies now unless you use a feature that requires a dependency.

The site hopefully details this all clearly [or clearly compared to most of the half-brained thoughts that leak from inside my skull].

http://www.osjava.org/simple-jndi/

Must admit that the constant flow of spam comments to the blog had gotten me annoyed at the whole world of blogging, so I stopped.

Taken the time now to disable comments across the whole blog [tempted to do it for all flamefew webloggers] after attempts to quieten things by recoding bits of the MT comment code failed to reduce it enough to make it livable. Though it did reduce a fair amount so a lot of MT-spammers are using robots that don’t look at the comment page itself to see if there is magic in there.

Site rebuild and hopefully the google cache will lose these losers.