Jay Dellinger

+ Follow
since Sep 19, 2002
Merit badge: grant badges
For More
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Jay Dellinger

I've written a small app in Struts 2 and find it a very pleasing experience over previous Struts versions and am looking forward to using it other projects. I'm wondering if the "Struts 2 in Action" book covers any specific enhancements or capabilities regarding internationalization/localization as provided by Struts 2.
16 years ago
Nice. I will definitely have to check that out.
Hi there. I've looked at openlaszlo a couple of times before but didn't have time to try to incorporate it into a project. It looks really useful and easy to develop some very dynamic UI interactions.

My question is, how difficult is it to reskin applications developed in Laszlo. By that I mean, offering the same (or very nearly the same) functionality but completely changing the look and feel of the individual components? Can this accomplished entirely through CSS or are the script modifications required to accomplish this? And does it vary much between Flash and DHTML deployments?

I work on a few projects that are starting to migrate toward using Spring instead of some custom home-grown code. Spring looks great so far, but what are some pros and cons versus HiveMind? It seems to have some nice features as well, and was wondering what others thought. I have only skimmed some information on Hivemind and am not very familiar with it's inner workings yet. Is it worth the effort or should I stick to Spring?
I would suggest using the DataAccessObject pattern and the Factory pattern, both mentioned here:
DAO Pattern
Basically, you can create a Interface that provides all the methods your application uses to retrieve data (e.g. MyApplicationDAO). You can then create database specific implementations of that Interface (e.g. MyApplicationMSSQLDAO, MyApplicationPostgresDAO). Use a Factory to retrieve the correct implementation (MyApplicationDAOFactory.getDAO()). Using this technique several benefits:
1) support for any number of databases (just add a new DAO implementation)
2) allows you to take advantage of database specific features rather than coding to the lowest common denominator.
3) allows easier integration of alternative datasources should the need arise (e.g. XML, LDAP, etc) since your DAO interface hides implementation details from your application. (Hint: Make sure your interface is pure and does not pass any information that would tie you to a specific data implementation)
What are the downsides?
1) More code to write
2) May be duplicating some work (queries, logic, etc) if different databases are similar enough.
(You can alleviate some of this if there are opportunities for one implementation to extend another, just be careful because forcing that relationship where it should not go can cause horrendous code and a maintenance nightmare.)
In my opinion, the benefits far outweigh the costs. I always use this approach even if I only have one implentation of a datasource to support just to make sure that I have flexibility for future changes.

Your app server will already spin off threads to process each request. Your database will handle multiple accesses so that you don't have to worry about anything like access conflicts, file locking, etc. This is assuming that each page is creating it's own connection to the database, since you didn't mention any controller servlets, etc.
What you really need to protect against is improperly sharing the connection in your pages. Don't use a page declaration to (<%! ... %> to define your connection variable. Multiple threads could access the page at the same time and cause problems. Just create your connection in a scriptlet, use it, then dispose of it.
I don't believe you need to worry about transactions if you are just doing a simple insert. Transactions are useful when you need to guarantee that several database changes occurred succesfully. For example, if you had a banking application, and were transferring money from one account to another, you would want to guarantee that both the increment to one account and the decrement to the other both occurred before committing the transaction. If either one fails you would want to roll back all changes.
Also, you may have simplified your example to better illustrate the point, but if not, you should consider using an MVC pattern and moving your database logic out of your view layer. It makes maintenance and reuse much easier. Of course if you just need something quick and functional...jsps will work.
Hope that helps,
Hi Venkat,
ResultSetMetaData will give you meta data about the resultset from your query. If you want information on all the columns in your table, just run a select query to grab all the fields. I don't think it even needs to actually retrieve data, so send something like this:
"select * from table_name where 0 = 1"
Then get your ResultSetMetaData and it should have some useful information for you. There may be a different (better?) query you could run, but that is the basic idea.
It really just depends on what parts of your code need to know about the success or failure of your servlet actions. If you only need to include the results on the JSP, put use request.setAttribute(...). If subsequent calls will also need to know about the transaction result then put it in the session. In general, use the narrowest scope that you can. Most likely, the request object will work fine for you.
20 years ago
You probably do not have an adequate version of java enabled in your browser. I have IE6 on a clean recent build of Windows 2000, and I too get the gray box. However, I've also installed java 1.4.2 from Sun and by enabling the Java plugin and it worked fine. So you either need to install the java plugin or install the microsoft jvm (I can never find it easily).
FYI, you will get a security exception trying to open files from an applet. It violates the "sandbox" security. You would have to digitally sign your applet and request priveleges to open files.
20 years ago
Yeah, depends on the application. As far as code performance, first tip would be use pooled database connections. Next, if you retrieve and display a lot of data, examine what you are showing and determine if you really have to load it fresh on every page view. If you show information that typically will not change for a day or longer, consider loading it on startup and caching it. Just remember to provide a way to manually refresh it at any time (admin page) as well as a scheduled refresh as well (I like to use TimerTasks). Don't create caches that can only be refreshed by restarting the server....that's just messy.
Also, consider running a profiler against your code. If you see an inordinate amount of instances of one or more objects being created to perform repeated tasks, you may want to consider either refactoring that logic, or using object pools. Object pools can help offset performance problems when going from low load to a sudden spike of activity in object heavy code. Also look for a lot of time being spent in specific sections of code...perhaps the logic there could be improved to reduce the slowdown.
Finally, make sure you consider and address multi-threaded access to your cached data. You don't want your caches to get corrupted or invalidated because two threads try to modify at the same time.
my 2 cents.
20 years ago
I usually prefer to do this in a controller servlet as well, but...I often do exactly what you are talking about for test pages, utility pages, and even some basic admin pages.
The easiest way I have found is to simply add a name attribute to your submit button. Then you need a scriptlet to check for that name in the parameters. It will only exist if the form was submitted by pressing that button, otherwise the parameter will be null. No extra hidden fields either. That's always worked for me.

Jay Dellinger
20 years ago
Just wanted to chime in on this as well. I experienced the exact same problem. I isolated my communication class and tested this out. If you create the ObjectInputStream first, it hangs. If you create the ObjecOutputStream first, it works fine. Very strange. But thanks for figuring that out. That's the last thing I would have tried.
This was true on Win2k. Here's my java version.
java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C)
Java HotSpot(TM) Client VM (build 1.3.0-C, mixed mode)
I have not tried on other platforms or versions to see if this behavior is widespread.
21 years ago