Fri 07 Sep 2007
I run a Google ad on my blog page, I have no illusions of getting rich from it, however my dream is to one day buy a case of beer...
[Read More]Wed 05 Sep 2007
Just wrapping up a project and thought I would share my experience of how God awful it was working with Hibernate on this project. [Read More]
Tue 04 Sep 2007
Was wondering if anyone had experience running Eclipse in a multiuser environment?
[Read More]Wed 22 Aug 2007
Just an FYI to save you some potential troubles. If you are using Maven to deploy your webapp (i.e. build your war file) you must take into consideration that the Maven webapp deploy will only compile Java source files to class files and subsequently move them to the target classes folder (usually WEB-INF/classes in the resulting war).
The defacto way in which Wicket stores a Page class's html counter part is by having the .html file sitting beside the Java class inside the Java package. When deploying using Maven however, those .html files will not deploy and you will wind up with errors like this one:
Instead of placing the .html file next to the Page class in the package, put the .html files in src/main/resources. The only thing you loose is the convenience of having the .html file next to the Page class within your editor. For consistency sake and to avoid naming conflicts, duplicate the package name from the Page class as folders in the resource folder and place the corresponding .html file in the appropriate folder.
The defacto way in which Wicket stores a Page class's html counter part is by having the .html file sitting beside the Java class inside the Java package. When deploying using Maven however, those .html files will not deploy and you will wind up with errors like this one:
WicketMessage: Markup of type 'html' for component 'com.mycompany.wicket.MyPage' not found.
Instead of placing the .html file next to the Page class in the package, put the .html files in src/main/resources. The only thing you loose is the convenience of having the .html file next to the Page class within your editor. For consistency sake and to avoid naming conflicts, duplicate the package name from the Page class as folders in the resource folder and place the corresponding .html file in the appropriate folder.
Tue 26 Jun 2007
When I first tried out DisplayTag I really liked their "Decorator" feature. Basically DisplayTag allows you to throw a List of objects into the Session (or whatever scope you desire) and it will do all the leg work of displaying the List in html format (or PDF/CSV, etc...).
It also allows you to specify a Decorator class which will be instantiated and passed the current java object it is going to render into a row. The Decorator is given the chance to override or provide new properties for the row object.
For instance if you had a property on your object called "getBirthDate()" which returns a Date object, you might want to format the date to a friendly string on the server prior to rendering. No problem, simply create a Decorator class, add the new getBirthDate() method, change the return type to String, and add code which formats the original birthdate. The property is referenced the exact same way as the original property from within DisplayTag in your JSP page, it is simply hiding the original row object's functionality.
As mentioned, there is nothing stopping you from having your Decorator object add new properties as well. Perhaps something like "getCalendarLink()" which will return some javascript to popup a calendar widget with the person's Birth Date selected.
The last time I checked, DisplayTag handled decoration via Reflection. Meaning that when you reference a decorated property through a <display:column> tag, it was DisplayTag handling the access to the decorated property. In one of my recent projects I wanted the decorator functionality, however I wanted it in a generic manner out side of a tag-lib such that I could use a decorated object the same way I would a non-decorated object.
I accomplished this using cglib's "Mixin" functionality. A Mixin (coined I believe by the Ruby people) allows one to dynamically create an object at runtime with an interface and functionality borrowed by one or more objects. This is perfect for the Decorator pattern because we wish to have an object which shares attributes from both a host object and an object which decorates that host.
Because I wish to decorate all objects within a List, I created a DecoratedList which given 1) a List to decorate 2) a Decorator class, will respond to user's get() and iterator() calls on the List by supplying a Decorated version of each underlying host object. The only caveat being, the Decorator class must implement a Decorator interface. The Decorator interface allows the Decorator class to be injected with the host object, such that it may use it's state to render it's own properties. Note: that was not strictly necessary, you could have a Decorator class that didn't rely what-so-ever on it's host object, but those cases are so few and far between it wasn't worth the code to provide such flexibility.
First the Decorator interface:
And now the DecoratedList:
* * That should produce a lists of all the dog's barks and wimpers.
*
* The only assumption is that your decorator class implement the Decorator * interface, that is so it can be passed (and presumably use) the object * that is being decorated. */ public class DecoratedList { private List listToDecorate; private Class decorator; private DecoratedList(List listToDecorate, Class decorator) { this.listToDecorate = listToDecorate; this.decorator = decorator; } private Class getDecorator() { return decorator; } private void setDecorator(Class decorator) { this.decorator = decorator; } private List getListToDecorate() { return listToDecorate; } private void setListToDecorate(List listToDecorate) { this.listToDecorate = listToDecorate; } public static List decorateList(List listToDecorate, Class decorator) { final DecoratedList containerList = new DecoratedList(listToDecorate, decorator); if (!Decorator.class.isAssignableFrom(decorator)) { throw new IllegalArgumentException(decorator.getName() + " argument must implement " + Decorator.class.getName()); } List decoratedList = (List) Enhancer.create(List.class, (Callback) new ListMethodInterceptor(containerList)); return decoratedList; } /* INNER CLASSES BELOW */ private static class ListMethodInterceptor implements MethodInterceptor { private DecoratedList containerList; public ListMethodInterceptor(DecoratedList containerList) { this.containerList = containerList; } public Object intercept(Object listObj, Method methodInvoked, Object[] arguments, MethodProxy proxy) throws Throwable { List listToDecorate = containerList.getListToDecorate(); if ("get".equals(methodInvoked.getName())) { Decorator decorator = (Decorator) containerList.getDecorator().getConstructor(new Class[]{}).newInstance(new Object[] {}); Object objToDecorate = methodInvoked.invoke(listToDecorate,arguments); decorator.setObjectToDecorate(objToDecorate); /* * In the case where both objects have the same method name, the object defined later * in the array passed to createBean wins out over the one defined earlier */ Object delegate = Mixin.createBean(new Object[] {objToDecorate, decorator}); return delegate; } else if ("iterator".equals(methodInvoked.getName())) { final Iterator iter = containerList.getListToDecorate().iterator(); return Enhancer.create(Iterator.class, new MethodInterceptor() { public Object intercept(Object decoratedIter, Method method, Object[] args, MethodProxy proxy) throws Throwable { if ("next".equals(method.getName())) { Decorator decorator = (Decorator) containerList.getDecorator().getConstructor(new Class[]{}).newInstance(new Object[] {}); Object objToDecorate = method.invoke(iter,args); decorator.setObjectToDecorate(objToDecorate); /* * In the case where both objects have the same method name, the object defined later * in the array passed to createBean wins out over the one defined earlier */ Object delegate = Mixin.createBean(new Object[] {objToDecorate, decorator}); return delegate; } else { return method.invoke(iter,args); } } }); } else { Object ret = methodInvoked.invoke(listToDecorate,arguments); return ret; } } } }
I'll write an explanation of the code over the next day or so.
Enjoy.
It also allows you to specify a Decorator class which will be instantiated and passed the current java object it is going to render into a row. The Decorator is given the chance to override or provide new properties for the row object.
For instance if you had a property on your object called "getBirthDate()" which returns a Date object, you might want to format the date to a friendly string on the server prior to rendering. No problem, simply create a Decorator class, add the new getBirthDate() method, change the return type to String, and add code which formats the original birthdate. The property is referenced the exact same way as the original property from within DisplayTag in your JSP page, it is simply hiding the original row object's functionality.
As mentioned, there is nothing stopping you from having your Decorator object add new properties as well. Perhaps something like "getCalendarLink()" which will return some javascript to popup a calendar widget with the person's Birth Date selected.
The last time I checked, DisplayTag handled decoration via Reflection. Meaning that when you reference a decorated property through a <display:column> tag, it was DisplayTag handling the access to the decorated property. In one of my recent projects I wanted the decorator functionality, however I wanted it in a generic manner out side of a tag-lib such that I could use a decorated object the same way I would a non-decorated object.
I accomplished this using cglib's "Mixin" functionality. A Mixin (coined I believe by the Ruby people) allows one to dynamically create an object at runtime with an interface and functionality borrowed by one or more objects. This is perfect for the Decorator pattern because we wish to have an object which shares attributes from both a host object and an object which decorates that host.
Because I wish to decorate all objects within a List, I created a DecoratedList which given 1) a List to decorate 2) a Decorator class, will respond to user's get() and iterator() calls on the List by supplying a Decorated version of each underlying host object. The only caveat being, the Decorator class must implement a Decorator interface. The Decorator interface allows the Decorator class to be injected with the host object, such that it may use it's state to render it's own properties. Note: that was not strictly necessary, you could have a Decorator class that didn't rely what-so-ever on it's host object, but those cases are so few and far between it wasn't worth the code to provide such flexibility.
First the Decorator interface:
And now the DecoratedList:
* * That should produce a lists of all the dog's barks and wimpers.
*
* The only assumption is that your decorator class implement the Decorator * interface, that is so it can be passed (and presumably use) the object * that is being decorated. */ public class DecoratedList { private List listToDecorate; private Class decorator; private DecoratedList(List listToDecorate, Class decorator) { this.listToDecorate = listToDecorate; this.decorator = decorator; } private Class getDecorator() { return decorator; } private void setDecorator(Class decorator) { this.decorator = decorator; } private List getListToDecorate() { return listToDecorate; } private void setListToDecorate(List listToDecorate) { this.listToDecorate = listToDecorate; } public static List decorateList(List listToDecorate, Class decorator) { final DecoratedList containerList = new DecoratedList(listToDecorate, decorator); if (!Decorator.class.isAssignableFrom(decorator)) { throw new IllegalArgumentException(decorator.getName() + " argument must implement " + Decorator.class.getName()); } List decoratedList = (List) Enhancer.create(List.class, (Callback) new ListMethodInterceptor(containerList)); return decoratedList; } /* INNER CLASSES BELOW */ private static class ListMethodInterceptor implements MethodInterceptor { private DecoratedList containerList; public ListMethodInterceptor(DecoratedList containerList) { this.containerList = containerList; } public Object intercept(Object listObj, Method methodInvoked, Object[] arguments, MethodProxy proxy) throws Throwable { List listToDecorate = containerList.getListToDecorate(); if ("get".equals(methodInvoked.getName())) { Decorator decorator = (Decorator) containerList.getDecorator().getConstructor(new Class[]{}).newInstance(new Object[] {}); Object objToDecorate = methodInvoked.invoke(listToDecorate,arguments); decorator.setObjectToDecorate(objToDecorate); /* * In the case where both objects have the same method name, the object defined later * in the array passed to createBean wins out over the one defined earlier */ Object delegate = Mixin.createBean(new Object[] {objToDecorate, decorator}); return delegate; } else if ("iterator".equals(methodInvoked.getName())) { final Iterator iter = containerList.getListToDecorate().iterator(); return Enhancer.create(Iterator.class, new MethodInterceptor() { public Object intercept(Object decoratedIter, Method method, Object[] args, MethodProxy proxy) throws Throwable { if ("next".equals(method.getName())) { Decorator decorator = (Decorator) containerList.getDecorator().getConstructor(new Class[]{}).newInstance(new Object[] {}); Object objToDecorate = method.invoke(iter,args); decorator.setObjectToDecorate(objToDecorate); /* * In the case where both objects have the same method name, the object defined later * in the array passed to createBean wins out over the one defined earlier */ Object delegate = Mixin.createBean(new Object[] {objToDecorate, decorator}); return delegate; } else { return method.invoke(iter,args); } } }); } else { Object ret = methodInvoked.invoke(listToDecorate,arguments); return ret; } } } }
I'll write an explanation of the code over the next day or so.
Enjoy.
Wed 16 May 2007
Fun... Fun stuff :) The scenario was this: We have a web application which was created by a company we just finished purchasing. It's an ASP application that stores and retrieves data from an Access database. It was my job to port this application over to our 64bit Vista server running IIS 7.
The problem was an "Unspecified Error" occurring whenever the webapp tried to access the database. As you may/not know, the driver used to get at Access databases is JET. The unfortunate thing is JET does not have a 64bit driver, nor is there any plan to create one! This was the root of my problem.
Thomas Deml, a helpful Lead Program Manager for IIS had the solution. Read all about it here.
The problem was an "Unspecified Error" occurring whenever the webapp tried to access the database. As you may/not know, the driver used to get at Access databases is JET. The unfortunate thing is JET does not have a 64bit driver, nor is there any plan to create one! This was the root of my problem.
Thomas Deml, a helpful Lead Program Manager for IIS had the solution. Read all about it here.
Mon 09 Apr 2007
I was catching up with an old colleague, Graham Robertson (you may remember him as "the guy who wrote the CVS plugin for Visual Studio". When I had last worked with Graham he was creating a kick-ass Layout Manager for Swing, however when I checked out the latest incarnation of his project I had noticed it had taken a turn to .NET. Here is what he had to say about that:
If you are a .NET developer and long for the ability to have absolute control over your form layout, I urge you to grab a copy of Rapid Layout.NET. You won't be sorry.
Yeah it is the one I wrote in Java. However, it is very difficult to make any money with this tool in Java. I ported the engine to .NET but the designer is actually still in Java. It is really a fantastic product but very difficult to sell ;-(. I really need to hit road and sell it personally. But of course I don't have time to do that.
If you are a .NET developer and long for the ability to have absolute control over your form layout, I urge you to grab a copy of Rapid Layout.NET. You won't be sorry.
Mon 19 Mar 2007
You should take the meaning of "poor" in this entry's title to mean "unfortunate" and not monetarily challenged. The situation I'll describe is probably a universally indelible one. Someone (perhaps even yourself) developed a data model which was to support multiple languages. At implementation time however it was only required to support two.
Let's take a hypothetical look at a database table to store information about Widgets:
CDE - Unique id representing this widget
NAME - Name of the widget in English
NAME_FR - Name of the widget in French
Whenever I get wind of second language support in an app I'm developing, I always break the descriptive fields out into a separate table. It's up to you if you want to have one separate table for each parent table, or if you want to have one master XLAT-type table.
Hibernate supports i18n fields via UserDataTypes joined to a code table where you store the multilingual text. However, we are talking about a situation here where you have no control over an existing data model. For this situation, you can use a kind of "hackish" "but it works(tm)" solution.
Assuming you have a domain object for widget that looks like this:
Your Hibernate mapping file (if you aren't using annotations) might look like this:
Your Data Access Method may look something like this:
Ok, but what about the situations where we need to retrieve the French product name? What do we do? Add another property for the NAME_FR field to our Widget class/mapping? That would be a pain, because now our presentation logic has to figure out which property to use every single time it needs to display widget information to the user.
We could add that extra property and then change the DA method to accept a language indicator and then have the code overwrite the name property with the French property value, something like this:
That works fine when you want to retrieve a single Widget, but what about the DAO methods where you are grabbing lists of widgets? Do you iterate through the list returned by Hibernate and swap property values for each? That seems wasteful. Also, you still have that extra FrenchName property on the Widget object's public interface; that may confuse other developers if they don't understand that the Name property is overwritten with the FrenchName property when appropriate.
Another solution is needed in which the Widget class is kept simple with only one Name property, and the locale you send to the DAO will determine what field Hibernate retrieves for the Name field. Achieving this goal may not be immediately clear because you can't have two mappings setup for one class in Hibernate; one where NAME is mapped to the Name property, the other where NAME_FR is mapped to the Name property and then at runtime determine which mapping should be used. Nor can you "easily" manipulate mappings at run-time to change which db field maps to the Name property (at least not easily!).
To achieve this goal we can create a new
This of course makes some assumptions:
Your Widget class now looks like so:
Note the "protected" constructors on each of the aggregate classes. Hibernate has no problem instantiating classes with protected constructors, this ensures our user's won't try to instantiate the _<lang> versions of the class themselves.
Now we can change our DAO method to read like so:
And your
Notice the mapping for the
Now when you call your DA method, it will return a
Hopefully that solves someone's problem, and hopefully I don't get flamed for promoting such a hack ;)
Let's take a hypothetical look at a database table to store information about Widgets:
------------------- | WIDGET | |-----------------| | CDE | | NAME | | NAME_FR | -------------------
CDE - Unique id representing this widget
NAME - Name of the widget in English
NAME_FR - Name of the widget in French
Whenever I get wind of second language support in an app I'm developing, I always break the descriptive fields out into a separate table. It's up to you if you want to have one separate table for each parent table, or if you want to have one master XLAT-type table.
Hibernate supports i18n fields via UserDataTypes joined to a code table where you store the multilingual text. However, we are talking about a situation here where you have no control over an existing data model. For this situation, you can use a kind of "hackish" "but it works(tm)" solution.
Assuming you have a domain object for widget that looks like this:
Your Hibernate mapping file (if you aren't using annotations) might look like this:
Your Data Access Method may look something like this:
Ok, but what about the situations where we need to retrieve the French product name? What do we do? Add another property for the NAME_FR field to our Widget class/mapping? That would be a pain, because now our presentation logic has to figure out which property to use every single time it needs to display widget information to the user.
We could add that extra property and then change the DA method to accept a language indicator and then have the code overwrite the name property with the French property value, something like this:
That works fine when you want to retrieve a single Widget, but what about the DAO methods where you are grabbing lists of widgets? Do you iterate through the list returned by Hibernate and swap property values for each? That seems wasteful. Also, you still have that extra FrenchName property on the Widget object's public interface; that may confuse other developers if they don't understand that the Name property is overwritten with the FrenchName property when appropriate.
Another solution is needed in which the Widget class is kept simple with only one Name property, and the locale you send to the DAO will determine what field Hibernate retrieves for the Name field. Achieving this goal may not be immediately clear because you can't have two mappings setup for one class in Hibernate; one where NAME is mapped to the Name property, the other where NAME_FR is mapped to the Name property and then at runtime determine which mapping should be used. Nor can you "easily" manipulate mappings at run-time to change which db field maps to the Name property (at least not easily!).
To achieve this goal we can create a new
private method on our DAO:This of course makes some assumptions:
Your Widget class has a
You could even make the naming convention for the static classs more complicated, including the country and language variant much like how ResourceBundle resolution works, but don't make it any more complicated than you have to for now.static class defined on it named: Widget_<lang> Where <lang> is the two digit ISO language code. For example Widget_fr The static class extends WidgetYour Widget class now looks like so:
Note the "protected" constructors on each of the aggregate classes. Hibernate has no problem instantiating classes with protected constructors, this ensures our user's won't try to instantiate the _<lang> versions of the class themselves.
Now we can change our DAO method to read like so:
And your
Widget.hbm.xml file would be updated to read:Notice the mapping for the
name property in the Widget$Widget_fr class, it's mapped to NAME_FR now instead of the default NAME column (if you don't specify a column attribute Hibernate just uses the property name as the column name).Now when you call your DA method, it will return a
Widget_en or Widget_fr object where Hibernate has mapped properly the Name property based on the locale passed in. Your user will never be concerned with which Widget_<lang> they receive because to them it's just a Widget with a properly a localized Name property.Hopefully that solves someone's problem, and hopefully I don't get flamed for promoting such a hack ;)
Wed 24 May 2006
Is a question that I have never gotten a straight answer to from my C++ zealot friends. I hang out with a bunch of guys who write C++ all day, they work on thick-client financial applications and one works on research systems for the government.
When I asked them "where are all the C++ web frameworks" they don't know, and actually they don't care. So when they spout off about how C++ is the only language a *real* programmer would use, I usually rally with the aforementioned question and they quiet down.
I took it upon myself to do some googling and found roughly 1 web application framework for C++: http://jose.med.kuleuven.ac.be/wt/doc/tutorial/wt-sdj.pdf. But it is an example of a thick-client application developer trying to write for the web. He needs a dynamic view tier, something that is adhoc and decorated perhaps with inline-C++ (or some other type of hook to the server).
The other framework I know about is Wexus, by none-other than one of the C++ guys I know. I think he wrote it just so he would have a response to my question :) It can be found here: http://labs.wexussoftware.com/ but I must admit that I know little about it other than it has its own page-scripting language, but I'm not sure if it follows MVC or how evolved it really is.
For Java, I found a truckload. In fact in my opinion there are too many to choose from!
So, I decided I would ask someone who would be in the know. I emailed Bjarne Stroustrup to see if he could confirm my suspicions. Here is a transcript of the email:
(Bjarne's response in bold)
> Craig Tataryn wrote: > Hi Bjarne, I'm professionaly a Java programmer and was wondering > something. In the Java world, we have Sun, and Sun (or a commitee) > produces specifications for things which would benefit the Java > eco-system (if I may use this kitchy terminology). So, two > specifications were produced of significance to the web application > developer: > > Java Servlet Specification > Java Server Pages Specification > > Within the Servlet spec, Sun defined the reference framework for what > a "Web Application" is, and how, if one were to create a web application > container, they could do so by following this spec. > > Of course this caught on like wild fire, and whether one likes or > dislikes Java, the specs setup a nice environment which cultivated Java > as a web-language (dare I say "of choice") for developers. > > I have many friends who are C++ programmers, so I queried them as to > what type of framework they use to build webapplications. They > either a) don't write web applications b) wrote their own framework > (http://http://labs.wexussoftware.com/) or c) use Ruby on Rails. > The last option was described to me as "use the right tool for the job" > > I guess the answer I am looking for is, why hasn't C++ penetrated the > web application frontier? Is it lacking an entity to write a > specification for such a thing? In my googling, I can't even find > commericial web application frameworks for C++. I just don't get it > because it would produce some pretty fast, resource savvy webapps.
You have the answer in the first line "Java has Sun" or maybe more correctly "Sun has Java". That is, there was an organization willing to pay dozens of millions of dollars for development supported by more dozens of dollars for marketing. The C++ community never had that. Instead, many organizations built tools for areas they found important for their own customers. In consequence, the C++ community don't have massive frameworks (unless you count CORBA), just applications (usually massive applications, such as amazon, google, ebay, and amadeus).
There is a lot of C++ "behind the scenes", e.g. financial software, embedded systems, games, infrastructure (e.g. CORBA, JVM), OS. See my applications page. There just isn't a mechanism for that to be seen (like Java's little coffee cup).
- Bjarne Bjarne Stroustrup, http://www.research.att.com/~bs
Sounds like a challenge for the ebays, Amazons and Googles of the world.
Give us your dog food.
