18 February 2006
How DRY I am, except for the framework
Last year I published one entry regarding "BEA Workshop Annoyances".  I've moved on to other projects as of three months ago, but I was reminded of another Workshop annoyance I encountered, by a Bruce Eckel's article posted on reddit, which the author began with some observations about the DRY principle, the one that says "Don't Repeat Yourself".

In a nutshell, I had devised a system whereby I populated an array with values from the database, and this array was used both to populate a drop down menu, and to validate the value provided for the same field.  This was necessary because of an extraordinary use case, where the data entry form could be populated from an uploaded Excel spreadsheet, in which case it was entirely possible that the uploaded data might not match the choices from the pulldown menu.

In which case the validation message printed properly, that "blahblah" wasn't a valid value, but the framework also performed some highly undesirable magic under the hood.  It added the invalid value to the array of possible values and displayed it in the drop down menu.

So I would like to thank Workshop/Beehive/NetUI for making me look like an idiot in front of the project manager after I'd been proudly pontificating about the DRY principle.  No wonder, as Bruce Eckels put it, the principle is practically ignored: when it should work some corporate mandated framework steps in to make sure it won't.

Actually there was a workaround, I don't remember it precisely, but it was some sort of horrible hack that had to be implemented on the client side, involving looping over the array either through JSP scriptlet or Javascript code, and removing the unwanted element.  The shame of it is, that otherwise Workshop did some wonderful things.  Through its use of "annotations" (this was pre Java 1.5 so they were not annotations in that sense), I never had to touch a struts xml configuration file.  I even had a subsequent phone interview with a leading Struts author, and he wanted to pick MY brain about this.

If only the developers of this, and other frameworks (Ruby on Rails included from what I hear), could consistently do just enough for the developer, and then get out of the way, instead of performing some magic they think makes sense.  Whereas I was attempting to adhere to DRY, these framework developers need to adhere to the principles of test driven development.  Surely the developers of Workshop/Beehive/NetUI did not create a test that added the unwanted element to the source array of elements for the UI widget, and then conclude that the test passed.

Just my $0.03.  Inflation.
Posted by htmatters at 6:16 AM | Comments (1)
2 February 2006
Why Python makes sense for web development
Forgive me for rehashing such a hackneyed idiom, but I can explain why Python makes sense for web development in one statement:

data = {"foo": "bar"}

Executing the above in Python, followed by: print(data["foo"])
results in the output:  "bar"

This would be mind numbingly straightforward except for the following exercise, which should be able to be completed by even more readers than the above, because they don't have to have Python installed.

Copy the statement: data = {"foo": "bar"}

In between script tags within the head tags of an HTML document, then set the onload attribute of the body tag to: alert(data["foo"])

This too results in the output: "bar"

Furthermore, not only do Javascript and Python share the same general syntax for defining the above literal representation of an associative array -- Javascript "objects" and Python "dictionaries", but they also share the same syntax for defining literal ordinal arrays:

arr = ["foo", "bar"]

Now, in either language, accessing: arr[0]
results in: "foo"

It gets better.  These structures can be arbitrarily nested within one another.  JSON, or "Javascript Object Notation", starts with an associative array as its outermost structure, but there's no reason to not start with an ordinal array:

superbowls = [{}, {"winner": "Green Bay", "loser": "Kansas City", "score": "35-10"}]

After defining the above in either language, the statement: superbowls[1]['winner']
results in the same output in both: "Green Bay"

Javascript and Python do not necessarily allow all types of data to represented identically, so in order to take advantage of their commonalities subsets of each would be required.  As a for instance, in Javascript booleans can be represented by the barewords true and false, whereas in Python the same values would be represented by the capitalized versions True and False.  Both languages however evaluate 0 as false and non-zero integers as true, so this case is easy enough to work around.  It won't always be so easy, but still it seems promising and worthwhile.  One carefully constructed Javascript/Python data structure could be used to configure both client side and server side functionality, debunking the myth that the two tiers must be engineered in two entirely different manners, thereby doubling development costs, etcetera.
Posted by htmatters at 8:13 PM | Comments (0)