In the Year 2000
I was bringing up some discussion on where our development group would like to go with web page development. A lot of stuff started popping into my head as we talked.
The cause for the discussion in the first place is that things have become unbelievably hard to manage in our web pages-- a hodge-podge of HTML, Javascript, Custom tags, Scriplets, and JSTL. I brought up a few solutions and reworked a bit of my previous post on Development with CSS, mainly from the standpoint of the programmer (I might write another blog on this).
But to go off on a tangent-- here we have JSP technology. An unbelieveably flexible medium to create your applications with (Scriplets/Javascript/HTML/Tags). But to use our stuff as an example, maybe too flexible. I'm not saying that there is anything at all wrong with JSP, but in the future I'm going to use the JSP medium as a strong reflection of what we choose for frameworks and tools. I don't want to end up with Java code that reads like some of our old JSP pages, a little Java, a dash of proxies, a pinch of Aspects, with a little bit of specialized scripting languages.
Although, I do remember reading an article only a short while back on how future applications will just be specialized vendor tools thrown together. Not that it isn't that way now.
Maybe it isn't so much what we use for frameworks and tools, but how we use them. My example of the JSP page, everything is boiled together at the top. This is where component-based development would come in handy-- programmer develops a component that encapsulates client/server behavior in a standardized way, then the JSP page is just a compilation of custom tags only that hide all of the other concerns.
The cause for the discussion in the first place is that things have become unbelievably hard to manage in our web pages-- a hodge-podge of HTML, Javascript, Custom tags, Scriplets, and JSTL. I brought up a few solutions and reworked a bit of my previous post on Development with CSS, mainly from the standpoint of the programmer (I might write another blog on this).
But to go off on a tangent-- here we have JSP technology. An unbelieveably flexible medium to create your applications with (Scriplets/Javascript/HTML/Tags). But to use our stuff as an example, maybe too flexible. I'm not saying that there is anything at all wrong with JSP, but in the future I'm going to use the JSP medium as a strong reflection of what we choose for frameworks and tools. I don't want to end up with Java code that reads like some of our old JSP pages, a little Java, a dash of proxies, a pinch of Aspects, with a little bit of specialized scripting languages.
Although, I do remember reading an article only a short while back on how future applications will just be specialized vendor tools thrown together. Not that it isn't that way now.
Maybe it isn't so much what we use for frameworks and tools, but how we use them. My example of the JSP page, everything is boiled together at the top. This is where component-based development would come in handy-- programmer develops a component that encapsulates client/server behavior in a standardized way, then the JSP page is just a compilation of custom tags only that hide all of the other concerns.
posted by Jacob Hookom at
1:45 AM
0 Comments:
Post a Comment
<< Home