HyperTextMatters
3 October 2005
 
BEA Workshop Annoyances
Weblogic Workshop does not permit overloaded methods in Workshop classes
No HotScripts newsletter column is due from me this month as they got a month behind with sending them out.  Therefore I've decided to try something different.  For October I plan to provide a journal of my "enterprise" Java development experiences.  I got this idea over the weekend, and something I've run into just now has inspired me to create my first such entry.

From the title you see that I'm using BEA Workshop; this is not by choice.  I began by using Spring for the first month and a half on this project, but then per corporate edict got forced into using Workshop a couple of months ago.  It's not ALL bad, but....

This morning I'm creating a new Workshop "control".  I've created several of these over the past couple of months while I learned Workshop.  For all intents and purposes they are ordinary Java code, but the file extension is something different, ".jcs" for my particular instance this morning.  My high level understanding of what happens to this code, is that when you "build" your application, Workshop creates proxies based on these controls with non-standard extensions.

In the past this had constrained me from performing tasks in certain ways.  For instance, I tried to create a general purpose form validator using Reflection.  However, this seems to have created a conflict, I'm guessing because Java proxies are themselves reflection-based.

This morning however I'm not trying to do anything as advanced as Reflection.  I'm just trying to overload a method.  This is for a use case where data can either be uploaded, or it can be keyed directly into a form.  In the end I want to represent this data the same way, for both validation and manipulation ("CRUD": create, read, update, delete) purposes.  In the "keyin" use case I want to pass the data directly from the form, but in the "upload" use case I want to pass in a two-dimensional string array return by parsing the uploaded CSV file.

So I simply want to overload the same method, to take keyed-in data as it's input in one case, and uploaded CSV data in the other.  But this is the error I get from Workshop:

"Weblogic Workshop does not permit overloaded methods in Workshop classes"

This sort of thing is the reason why, two months after switching to Workshop from Spring, I'm barely further along then I was at the outset.  Under Workshop I'm continually having to come up with workarounds because of constraints it places on developers.  Maybe I'll touch on some more of these constraints later this month (or even just later this week), but for now it's back to work.  I just had to blow off some steam though, its just ridiculous to me that BEA has chosen to disabled such a basic object oriented feature as method overloading.
Posted by htmatters at 11:52 AM | Comments (3)
9 September 2005
 
Java Objects ColdFusion Views
The August 2005 issue of a prominent ColdFusion magazine wastes several pages on OO with ColdFusion.  Let's face it, CFC's are about as object oriented as PHP4: neither are enterprise-ready.  For one, they both lack the "Interface" construct, an absolute must for genuinely robust object oriented architectures.  There are other shortcomings as well, but interfaces provide an acid test as to developers' understanding of objects: if you don't grok interfaces, you shouldn't be leading an enterprise OO project.  All is not lost for ColdFusion however, it's advantage over PHP4 being it's foundation: Java.  Let Java do the OO "heavy lifting", and then leverage the servlet API's getServletContext().getRequestDispatcher() functionality to subsequently forward both request and response to ColdFusion templates.  OO with ColdFusion itself is not necessary to its continued thriving, rather it can provide the view component of MVC under Java.
Posted by htmatters at 6:54 AM | Comments (0)
11 August 2005
 
ColdFusionMX7 Servlet Development
How to start developing servlets under ColdFusionMX7 (in 150 words or less ;)
Posted by htmatters at 7:40 AM | Comments (0)
2 August 2005
 
Plain JSPs, Just Plain Wrong
Plain JSPs, with business, data access, and view logic rolled into one, should never be used for anything but the quickest and dirtiest prototype.  Period.
Posted by htmatters at 7:18 AM | Comments (0)