• blizzaga (unregistered) in reply to NoOneKnows
    NoOneKnows:
    blizzaga:
    The real WTF is that you did not provide a IRuleFactory that can initialize rules from a simple configuration file such as <ValidationRules type="Initech.Practices.Enterprisey.Validation.ValidationRules, Initech.Practices.Enterprisey.Validation.dll, Version=1.1.2.3, PublicKeyToken=1e9a2c36f"> <addRule type="Initech.Practices.Enterprisey.Validation.NotNullRule,, Initech.Practices.Enterprisey.Validation.dll, Version=1.3.2.4, PublicKeyToken=1e9a2c36f" objName="myObject" objectRetriever="Initech.Practices.Enterprisey.ObjectRepository.NullableObjectRetriever, , Initech.Practices.Enterprisey.ObjectRepository.dll, Version=1.6.2.3, PublicKeyToken=1e9a2c36f" />

    It's more enterprise to use the short assembly name and no PublicKeyToken, that way you can load your rule validator in a new appdomain for every call and slip-stream in new rule assemblies without shutting down the app! Five 9s here we come!

    Thanks for the advice, but the proper way to accomplish this in .Net would be to deploy a publisher policy assembly to the GAC along with the updated rule validator. This publisher policy assembly would contain redirection rules to tell the class loader that version 1.1.2.3 can safely be replaced by version 1.2.1.4. This way, we can still have hotswappability, without the risk of breaking the running code when updating to NotNullRule 1.4 which is not backwards compatible.

    As for the public key token, I wouldn't risk removing it, otherwise a malicious user who has access to the configuration file and the executable files may be able to inject a FileNotFoundRule into the validation rules, thus turning any perfectly valid occurrences of "FileNotFound" into rejected data.

  • Sebastien (unregistered)

    Actually some time ago I had in my mind a "Validation Framework". In fact I implemented it using annotations I would put on my model classes like @NotNull or @MaxLength(5) above a String. But a few days after it was done I discovered that I had just been busy reinventing the wheel, because there was already something similar, which is called Oval (http://oval.sourceforge.net/) and is related to "AOP" (aspect oriented programming)...

    Funny thing is that I never used my "framework" or Oval in any application i've worked on since then, wonder why...

  • jock@law (unregistered)

    No. Native speakers of any language do not make errors in that language. It's not possible.

  • Dennis (unregistered)

    I'm sorry, but you're all wrong. Here is the corrected text:

    "I'm always amazed at the lengths some people will go to 'enterprise up' them there Java apps"
  • claudiu (unregistered) in reply to snoofle
    snoofle:
    claudiu:
    mister:
    I don't see the WTF. The purpose seems to be to add "rules" to an object, maybe for some kind of form validation check. Uses "addrule" to... well, add a rule to any item that needs it, then "checkrules" and it checks them all, warning about any errors.
    This will be OK for a validation framework if you passed the object to be tested in the the call to check() like check(Object o) not in the constructor of the rule. Because it is in the constructor you need to recreate the rule every time you validate a new object.
    This may be necessary to work in threaded environments. Without more context, there's no way to know if this is appropriate.
    As long as you don't keep any state variables in the rule you don't need to worry about any concurrency problems. If the object to be checked is object to multiple threads access the responsibility of synchronizing belongs to the rule engine not to the rule itself. Even better, synchronizing should be done by the caller of the rule engine.
  • stgma (unregistered)

    This is not a WTF.

  • Redeemer (unregistered) in reply to Sam
    Sam:
    TWTF is that "o" (and, therefore, whether or not o==null – we're not checking a mutable field here, and last time I checked Java doesn't let you overload "==") is set when the Rule is constructed. So, unless there's some reason you might want to later decide not to ever check() the rules, why bother with all the enterprisiness?

    Still, respect to Ben for turning himself in.

    Yeah, i dont feel that this is a candidate for a WTF wrt to architecture atleast.. being slightly less efficient, doesnt automatically make it a WTF. anyways.. how is this for a better implementation :)

    if(xml == null{
    addRule(new Rule(){ 
                public void check() throws RuleException {
                    throw new RuleException(ErrorMessages.ErrorCode.OBJ_IS_NULL, "xml");
                }
            });
} else {
    // This part may not even be required, except to ensure that the rule count is same in either condition:
    addRule(new Rule(){ public void check()});
}

    Havent checked the code for syntax errors, but you get the picture.. isnt this better? or do i need to visit the "Architects Anonymous" too?

  • Architect Anonymous (unregistered) in reply to savar
    savar:
    If java allowed you to pass a function as a parameter, then case closed.
    It does. It's called a functor, and it's exactly what the author is doing. I don't see the problem.
  • Ben (unregistered)

    It isn't a WTF - it's another hamcrest.

    http://code.google.com/p/hamcrest/

  • anon (unregistered) in reply to mister

    Ok, I agree with you here, if its used as part of a given design pattern (E.g. Chain of Responsibility) then I really don't see a problem. If this is part of a parser where you are adding given validation rules then it seems like an acceptable design.

  • Stephan (unregistered)

    I don't see a WTF either. Sometimes, there is more to a rule definition than just checking a value once. Especially field states for mandatory, optional, forbidden, readonly and hidden fields are information you need more often.

    So if you have a collection of rules regarding a certain field, these rules can be interpreted by a GUI to display different field colours, block input etc. The execution of the rule could be timed by a keystroke or an independent timer which just processes abstract rule collections for a field, and the rule set created by adding lots of rules could be recycled for different purposes (DB import, GUI, JUnit tests etc.)

    Additionally, you have on code segment creating rule definitions, even if these rules are executed in different places. You have not a undefined cloud of business decisions strewn out through numerous classes.

    Calling an architect is a good idea, but one should know what architecture is for in the first place.

  • palinurus (unregistered)

    I have been going through some relatively old code of mine while pair programming with other guys and sometimes it has been awkward to just seat there looking at some of my wtfs and trying to figure out what I was thinking, and come up with some kind of reasonable explanation for it. If you find it by yourself you just laugh at it and whatever but then seating there, realizing this can probably go to codesod and thinking that they probably are thinking the same thing, well that is just priceless.

  • gavin (unregistered)

    The one time this kind of thing could be necessary is if you are creating a chain of validators; your base class of validator would simply be class ValidateBase { public abstract boolean isValid(String text){} }

    or some such. You would then have classes such as ValidateNumerical ValidateNotEmpty ValidateNotContainingStarTrekTrivia

    You then create an array of instances of validators and run each value through the chain.

    Theoretically, ValidateNotNull could be one such validator.

  • steve (unregistered)

    TRWTF is that I'd bet a lunch that addRule() actually checks the rule when it's called.

    It takes a new Rule object, it doesn't return anything, and he doesn't pass it a pointer to a list that the new Rule should be added to - so what happens to the Rule you created?

    I'm betting that it just checks the rule and then chucks it into the bitbucket.

    The alternatives are even worse: a static list of rules which addRule() updates a global list of rules which addRule() updates an XML file of rules that addRule() updates a relational database of rules that addRule() updates a flat file which addRule() appends the serialized Rule object ...I think I'll stop coming up with these ideas now.

    I hope it just checks the rule.

Leave a comment on “The Enterprisey Null Test”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article