One of my gripes with building rpms is that by default they clean out the build directory every single time you build. Which means that if you're trying to troubleshoot a particularly thorny install problem at the end of a long compile you can waste a lot of time waiting for the rpm to build again. To keep it from clearing out the build directory you can add the -D option to your %setup task like so:
%setup -q -D -n mozilla
my life has improved immensely. Just make sure not to check it in.
-tim
This was so long ago, I'd forgotten about it. Apparently a patch I submitted to JasperReports made it in:
The source
That's so super cool. I should put that on my resume.
I've built a Now Playing applet for KEXP. It's very rough. There's a windows version and a linux version. Good luck with getting the windows version working. I remember it being a bit of a bear. If you make any changes let me know and I'll update it. There are some ugly hacks in there right now.
Get it here:
http://www.loadedguntheory.com/devblog/pages/kexp/kexp.tar.gz
I'm sure someone's done this before, but I'm working on making a fairly robust php xsl templating library. It's based on the php xsl extension, but I do some preprocessing of the xsl template so that I can have essentially "tag libraries" ala java. My pages are starting to look like jsp 2.0 xml pages (which I happen to really like). I'm now creating tags like this:
<lgt:input name="address" title="Address 1:" />
On the backend it's just translating these into xsl:call-template calls. It's the model of simplicity, and really removes my big beef with xml templating. Then I'm planning on using the registerPhpFunctions function of the xsl library to load in the new 'filter_data' extension. Fields such as my input tag above will call filter_data to help reduce the risk of cross-site scripting. I think with a good enough tag library this could really be a simple and elegant templating language that could easily be ported to java. Alas filter_data is not yet out in a production php version. I might have to hack together a placeholder for now.
Now I just need to convert my architecture to easily serialize my data to xml.
I like decoupled code design as much as the next guy, but can I please complaing about java's xml APIs? I mean I understand that it's nice to be decoupled, and having a factory return you an xml processor is pretty nifty, but the underlying implementations are NEVER compatible! Never! It's like playing russian roulette with the classloader. Will you load the xml library I want first, or the one that gives me random errors? Will the two identical webservers load the same library? Who knows? One day I might restart the server and everything might break! What fun!
I'm off to couple some code, as I don't feel that setting system properties in the middle of my code is really an elegant solution...
I love overloading the paths of my scripts. You might notice that this page has an html extension. The script itself is actually the file 'director' and everything after that are part of the query string masquerading as path elements. I'm always forgetting the proper request elements to do this in Java (requestURI or URL?) so I figured I'd put my standard function down here for posterity:
private String[] getExtendedPath(HttpServletRequest request) {
String uri = request.getRequestURI();
uri = uri.replaceFirst(request.getContextPath(), "");
uri = uri.replaceFirst(request.getServletPath() + "/", "");
return uri.split("/");
}
So I've been working on a project using Hibernate Annotations. I had a class with a OneToMany collection that kept causing me problems. Rather than deleting the records when I cleared out the collection, it was trying to update the primary key to null. After much searching I found the solution:
@OneToMany(mappedBy="project", targetEntity = RoleCountModel.class, cascade = CascadeType.ALL)
@org.hibernate.annotations.Cascade(org.hibernate.annotations.CascadeType.DELETE_ORPHAN)
@OnDelete(action = OnDeleteAction.CASCADE)
@JoinColumn(name = "ORDER_ID")
private List roles = new ArrayList();
What a pain. Turned out after working on fighting with it for a day, that the most important piece for the Cascaded deletes to work is the "mappedBy" attributeon the @OneToMany annotation. Even though said attribute is refered to constantly in the documentation as being optional. Ah well, it works now and that's what matters.
Sharing Code is overrated as we all know due to the fragile Base Class problem. Therefore I recommend that you write the same code multiple times. If the code changes in one place you then don't have to change it in the other. For instance:
sub Object totalAmounts(Abc obj) {
return obj.value1 + obj.value2;
}
sub Object totalAmounts(Def obj) {
return obj.value1 + obj.value2;
}
If possible place these methods in different class files so that you don't confuse future developers.
I've been playing with Java Servlet Filters lately. They're really cool, and work beautifully once you've got them working, but they are a pain to setup. This is yet another Java API that needs help. Of course I'm working on 2.3 servlet filters, maybe this is all fixed in 2.4.
I've also been playing with Batik and SVG, which worked really well. I've got a servlet that replaces tokens in an svg file and adds in svg barcodes. Then I have a filter that can convert the output SVG to PDF. And I have another filter that can add automatic printing commands to the PDF. It's very cool and modular.
Note: While this article is under the Creative Commons license at the bottom of this page, the actual technique and code is released into the public domain. Please do with it whatever you wish (including using it in commercial products).
So debugging JavasSript in Internet Explorer has been a pain for quite a while. The tried and true method is to riddle to your code with alerts. This works well enough unless you're trying to figure out a sticky problem in a loop or with a mouseover.
I figured why not build a simple DHTML logger that could be easily included into a page and that would take care of popping up an absolute positioned logging div at the bottom of the page. Now all I need to do is include my .js file, and put in statements like this:
Note: While this article is under the Creative Commons license at the bottom of this page, the actual technique and code is released into the public domain. Please do with it whatever you wish (including using it in commercial products).
The Problem
The Suckerfish Dropdowns were originally described on A List Apart. They're great cross-browser drop-down menus that are implemented entirely in CSS. Unless of course your site needed to support Internet Explorer. To do so a small javascript hack was added. These menus looked great, required little code, and were fast. The problem occured when you put a menu on the same page as a form select. When the drop down covered the select in Internet Explorer, it suddenly hid behind it. An example can be found here:
Obviously this was a deal breaker for a lot of people.
The Solution
The Technique
It has been known for a while selects bleed through most divs and spans in Internet Explorer, you can place an iframe over the select and they no longer bleed through.
Let's say for example that there is a select in a form that we want to cover up with a warning message under certain conditions. In mozilla just a little positioning and the proper z-index value will allow the warning message to cover the select. In Internet Explorer the select shows through.
DANGER!
The traditional answer to this problem was to set visibility to hidden on the select when we wanted to cover it with the div. The problem occurs when the div doesn't completely cover the select. Suddenly your users have disappearing elements.
Before:
Nuclear Reactor Power:
After:
DANGER!
Nuclear Reactor Power:
It doesn't take the most astute user to wonder where the select just disappeared to, and it completely destroys the illusion that the Danger message is popping up on top of the select. Additionally if your site has a lot of forms you'll end up having custom javascript on every page to hide and unhide form elements which has the tendency to break.
The iframe is the one element that internet explorer respects as covering all elements. So all we have to do is add an iframe with the exact same dimensions as our warning popup and put it's z-index just under the div.
DANGER!
Nuclear Reactor Power:
So that's an elegant solution to the problem.
Adding to the Suckerfish Dropdowns
So how do we add this to the suckerfish dropdowns? First we add our iframe line, just below the bottom of our menu definition:
Well, now we have a big ugly iframe in the middle of the page. Let's go ahead and style that ID. We'll give it a z-index of 10. And hide it for the time being.
On mouse over we move the iframe to cover our menu. But the onmouseover event is happening on our title. So we need to get the submenu for the current menu (I leave it to you, the reader, to implement sub-sub menus):
var submenu = this.getElementsByTagName("UL");
If the submenu has length (i.e. has items) we go ahead and find the size of the menu. Internet Explorer has many properties that describe the size of a block element. You can find out more in Microsoft's article Measuring Element Dimension and Location. All we do is use these properties to size the iframe to the exact size of the submenu.
We also add the code to the onmouseout function to make the iframe invisible again.
iframe.style.display = "none";
And that's pretty much it. "Hold up", you say, "Now I just have a blank space where my menu once was. It is covering up the selects nicely though...". One last thing. We need to change the z-index of our submenu so that it will be on top of our iframe. All we need to do is change the style of our li tag.
li { /* all list items */
float: left;
position: relative;
width: 10em;
z-index: 20;
}
That's it. A simple solution that doesn't involve writing custom javascript for every page on your website. A modified version of the original page can be found below:
When the beasts of hell (marketing) compel you to finally build a popunder. And let's say this popunder must pop up 'x' number of times (where x > 1). If you use the same code each time you could run into a problem where IE stops popping up windows after 1. An example of this code is found below:
function popup {
window.open('ad.html', 'ad_window', 'height=100,width=100,top=100,left=100,resizable=yes,status=no');
}
To fix this problem, you must change your window name each time. I generally just use the session variable that tracks how many times I've popped the popup.
function popup {
window.open('ad.html', 'ad_window_', 'height=100,width=100,top=100,left=100,resizable=yes,status=no');
}
I just found a new low today. It's approximately this code:
// Find next available id
String sql = "SELECT id " +
" FROM some_table" +
" ORDER BY id desc";
stmt = conn.prepareStatement(sql);
rs = pstmt.executeQuery();
count = 0;
int max = 999;
while (rset.next()) {
int tonum = -1;
try {
tonum = Integer.parseInt(rset.getString("id"));
if (tonum > 0 && tonum > max) {
max = tonum;
}
}
catch (NumberFormatException nfe) {
tonum = -1;
}
} // each row
// next available id
max++;
So apparently rather than creating a sequence or doing a:
SELECT max(id) + 1
FROM some_table
We are possibly pulling 999 rows out of the database in order to find the next ID. This is just sad. This is instant fire people code.
