Hi Chris,
On 11.09.2020 19:31, Christopher Schultz wrote:
> > P.S.: If possible I would like to write a single tagclass, but use
> > it for two or more different tags, as the implementation would
> > share quite a lot of code. Besides, it might be helpful for
> > debugging.
>
> It seems like this is the wrong approach, unless you just want to use
> this for something like logging.
Not logging, but support for scripting languages.
> I you want the tags to behave differently, then you should have
> separate tag implementations.
In this case the only difference would be that in one case ("script",
"scriptlet") a return value
gets ignored, in the other case ("expression") the return value is used to
print its string value to
the JSPWriter ("out").
> Feel free to build a base class with the shared code and then implement the
> differences in subclasses.
Yes, if there is no easy way to learn about the tag that the tagclass got
invoked for, which seems
to be the case here.
> It's been a loooong time since I wrote a custom tag library but I do
> remember that the whole process was very painful and despite the
> flexibility allowed by the API, lots of common things (like getting
> the tag name!) were either awkward or impossible.
Well, it is not really "painful", just a lot of power, many roads that could be
chosen and
flexibility at hand which at times is overwhelming for a newbie in this corner,
hence my brief
question. :)
> IMO, the JSP effort was a stepping-stone on a path to better
> technologies like Velocity, FreeMarker, and others. If I were king,
> JSP would just go away. Just my POV of course, you are welcome to fall
> in love with JSP. :)
This assumes that the JSPs get written in Java only and one is ready to take on
the learning curves
for additional frameworks.
In this case the aim is to allow scripting languages either via Apache BSF [1]
(like Groovy
implemented in Java, ooRexx implemented in C++) or via the Java scripting
framework [2] ("JSR-223"
[3], "javax.script") to be used for writing JSPs. This may not be
attractive/interesting for
Java-savvy programmers who would create their server pages in Java, but it is
*very* attractive,
even important for non-Java programmers who know one of the supported scripting
languages.
In the end it should be easy to use Tomcat as the (Java-implemented) web server
for web applications
that get implemented in other programming languages. Very much like the Apache
web server [4] which
is written in C and allows other programming languages to exploit it.
---rony
P.S.: Maybe I should come up with a brief posting that tries to explain why it
is important to
support non-Java programming languages in JSPs by default (and if
interestesting to the Tomcat
community I can offer the code under AL, once it is done). Not sure whether all
in the Tomcat
community know that Apache BSF ("Bean Scripting Framework") was created
originally to allow
scripting languages to be used in JSPs! Hence I was very surprised to learn
that scripting languages
are not supported in Tomcat by default.
[1] "Apache Bean Scripting Framework (BSF)":
<https://commons.apache.org/proper/commons-bsf/>
[2] Java package "javax.script" ("JSR-223"):
<https://docs.oracle.com/javase/8/docs/api/javax/script/package-summary.html>
[3] "JSR-223", the "Java specification request 223":
<https://en.wikipedia.org/wiki/Scripting_for_the_Java_Platform> or
<https://jcp.org/en/jsr/detail?id=223>
[4] "Apache Web Server", "Apache HTTP Server Project":
<https://httpd.apache.org/>
