Re: Need to deprecate JSP files
On Apr 2, 7:09 am, Lew <l...@nospam.lewscanon.com> wrote:
Rahul wrote:
Hi
In my application, there are certain JSP files, that have no use now,
but we cantnt remove those files now.
So, can we make JSP files deprecated as we do classes and methods.
Not in the sense you seem to mean it, no.
JSP files are screens in the application; deprecation applies to methods and
classes in the JVM. While there is a connection, in that JSPs translate to
servlets, they translate to a well-defined servlet type not under your control
nor deprecable, and the method is, ultimately, service(), which will not be
deprecated either.
But that begs the purpose of JSPs, which is to present application screens. I
guess that what you mean is that certain screens in your application are
obsolete, correct?
What you can do is remove all navigation to those screens.
I do not understand why you cannot remove screens from your app if the
requirements change. Screens are a requirements phenomenon, that is, they
exists in the problem domain of the application. Their presence or absence is
not a mere implementation detail.
--
Lew
I agree with your suggestion, but feel obliged to point out that not
all JSPs are written as screens. Some people actually write scriptlet
code in their JSP, which is used as a controller. While this is a
terrible practice, it has occurred severally times I'm sure. So, you
may find that your JSP contains implementation code that it should
have left to a Java file instead. Whoops.
To Rahul:
If you have control over the consumers of your code (I.E. only your
code access the JSP), then I would suggest you simply delete the JSP,
and fix the problems that arise due to its absence. If you DON'T have
complete access, then I would suggest putting some sort of logging
statement in the JSP that prints something like "!!!WARNING!!!
Deprecated JSP. Don't use !!!WARNING!!!" and also note it in your
release documentation until you actually remove it.
Keep in mind that the point of Deprecation is to point out that a
method or class WILL be removed eventually, and that ones own code
should not utilize it any more.