V
VisionSet
I/we have inherited a 'Java' web application that is written in a style
that has to be seen to believed. We need to refactor/rewrite it!
The application is a content management system dealing with orders,
users, questionaires, products etc. Our clients write plain html with
some minimal custom tags that are actually html comments. Our JSP's
parse these in and render new html with relevent forms.
Here is a quick tour of its 'architecture'
JSPs seem to be exclusively written in raw scriptlet and parse the
client html:
// replace tags on the fly
while (data.indexOf("<!--CONTENT?") >= 0) {
String contentTag = "<!--CONTENT?";
String contentTagReplace = data.substring(data.indexOf(contentTag),
data.indexOf(" -->", data.indexOf(contentTag)) + 4);
you get the idea!
Helper classes have no encapuslation and are just a series of heavily
nested hashTables keyed by whatever parameter was convenient at the
time.
Data access is raw and dynamically built sql without even a prepared
statement in sight. MySQL is the DBMS, we don't envisage a change, but
obviously a good architecture won't preclude this.
Decoupling is non-existent, encapsulation is non-existent, the OO
concept has completely escaped the author.
Where the heck do we start?
Obviously we want JSPs written as view only using JSTL.
We should probably have our clients essentially write a minimalist JSP
that we use as @includes?
We don't want any more of the ludicrous custom parsing.
I don't want to write raw SQL, I think hibernate is an option, does it
handle dynamic querying these days, what other option is there.
I don't think we will go down J2EE route, but it is possible.
We may not use Struts, JSF, Tapestry but would like to consider the
most suitable framework before dismissing it.
The team is small, the author has left and half the team is brand new.
I think we should have a period of discovery and analysis and write
some UML analysis to eventually objectify this mess.
The product is on-line, making money but further developement that is
being demanded is obviously painfully slow and hack upon hack.
Any advice on a suitable approach would be appreciated.
TIA
Mike W
that has to be seen to believed. We need to refactor/rewrite it!
The application is a content management system dealing with orders,
users, questionaires, products etc. Our clients write plain html with
some minimal custom tags that are actually html comments. Our JSP's
parse these in and render new html with relevent forms.
Here is a quick tour of its 'architecture'
JSPs seem to be exclusively written in raw scriptlet and parse the
client html:
// replace tags on the fly
while (data.indexOf("<!--CONTENT?") >= 0) {
String contentTag = "<!--CONTENT?";
String contentTagReplace = data.substring(data.indexOf(contentTag),
data.indexOf(" -->", data.indexOf(contentTag)) + 4);
you get the idea!
Helper classes have no encapuslation and are just a series of heavily
nested hashTables keyed by whatever parameter was convenient at the
time.
Data access is raw and dynamically built sql without even a prepared
statement in sight. MySQL is the DBMS, we don't envisage a change, but
obviously a good architecture won't preclude this.
Decoupling is non-existent, encapsulation is non-existent, the OO
concept has completely escaped the author.
Where the heck do we start?
Obviously we want JSPs written as view only using JSTL.
We should probably have our clients essentially write a minimalist JSP
that we use as @includes?
We don't want any more of the ludicrous custom parsing.
I don't want to write raw SQL, I think hibernate is an option, does it
handle dynamic querying these days, what other option is there.
I don't think we will go down J2EE route, but it is possible.
We may not use Struts, JSF, Tapestry but would like to consider the
most suitable framework before dismissing it.
The team is small, the author has left and half the team is brand new.
I think we should have a period of discovery and analysis and write
some UML analysis to eventually objectify this mess.
The product is on-line, making money but further developement that is
being demanded is obviously painfully slow and hack upon hack.
Any advice on a suitable approach would be appreciated.
TIA
Mike W