JSP 2.0 as JSF component encoders - continued

Question

This is in continuation to this topic:
http://forum.java.sun.com/thread.jsp?forum=427&thread=414850&tstart=15&trange=15
As I look further into JSP 2.0, I am more and more sold to the idea of encoding JSF components thru JSP 2.0 tag files and/or SimpleTag handlers ...
Like, I was trying to figure out how could I derive the functionality of JSF facets from JSP tags - and the answer was amazingly straightforward - fragment attributes ... the tag could treat the fragments as facets while evaluating the body with its normal course ...
If the benefits of tag files/simple tag handlers are felt among the JSF team, I was wondering if the tag file/simple tag handler could be made part of the JSF rendererType paradigm?
I was wondering if it were a feasible idea to work in encoder-decoder pairs? The declarations in faces-config.xml for the renderers could be something along these lines:
If the encoding was with a simple tag handler:
<render-kit>
  <renderer>
    <renderer-type>Component1Renderer</renderer-type>
    <decoder>decoder.Component1Decoder</decoder>
    <encoder type="SimpleTagHandler">encoder.Component1EncoderTag</encoder>
  </renderer>
</render-kit>
If the encoding was with a tag file:
<render-kit>
  <renderer>
    <renderer-type>Component1Renderer</renderer-type>
    <decoder>decoder.Component1Decoder</decoder>
    <encoder type="TagFile">/WEB-INF/tags/component1Encoder.tag</encoder>
  </renderer>
</render-kit>
The above may all be very far fetched but I thought I'd just put across what I had in mind.
Thanks!

Answer 1

This is in continuation to this topic:
http://forum.java.sun.com/thread.jsp?forum=427&thread=4
4850&tstart=15&trange=15
As I look further into JSP 2.0, I am more and more
sold to the idea of encoding JSF components thru JSP
2.0 tag files and/or SimpleTag handlers ...
As has been pointed out by others, this isn't feasible at all unless JavaServer Faces were to choose JSP 2.0 as the minimum platform. However, even if that were to happen, there are some crucial problems in at least two dimensions:
* JavaServer Faces integrates nicely with JSP, but does not
require it. Therefore, the encoding functionality of a
component (or renderer) needs to operate correctly even for
a non-JSP rendering environment. How can that be reconciled
with a desire to use JSP-specific rendering capabilities?
* JSP 2.0 is very cool, but it doesn't deal at all with the
issue of handling an incoming request. Therefore,
a solution that uses JSP as a templating environment (which
violates the "don't require JSP requirement as mentioned in
the previous paragraph"), will STILL require some non-JSP
functionality to do the decoding, validation, and event handling
parts of the application. To me, it does NOT seem like forcing
component writers to master two technologies (instead of one)
would make JavaServer Faces easier to use.
Implementation technology aside, the logic of decoding (what request parameters do I look at?) is very tightly coupled with the logic of encoding (what markup do I generate?). Splitting those two aspects of the problem into different source files, implemented with different technologies, and requiring changes in both placeds when you make changes, seems like something that goes against all the best practices design principles we've all been learning over the past several decades.
If JSP had a way to express the functional logic needed for handling events, validations, and calls to business logic, I might be more sympathetic to this approach -- but it doesn't. It is also interesting to note that Struts (among many other frameworks) has embedded markup generation for user interface components in Java logic (in the case of Struts, it's in the HTML tag library) from the very beginning. Why should it be OK there (and 75,000 downloads per month says it's pretty popular) and not in JavaServer Faces?
Further, why should a page author that is just using components give a rip what the implementation technology is? Isn't that a concern solely of the component writer? I would contend that anyone who builds a non-trivial component, in any technology framework, is going to need functional programming knowledge (be it Java, VB, C#, some XML-based variant, JavaScript, whatever) anyway. Rendering is about 20% of the problem -- the 80% that still needs to be solved is going to require programming knowledge anyway. And JSP, even with all the fantastic things added in 2.0, doesn't address any of those needs.
Craig McClanahan