Michał Małecki
Heath Borders wrote:
I'm currently developing my JSF renderers inside of a web project for easier testing, so having the environment for me isn't a problem.
Also, i agree that for simple components, using a JSP would be the wrong way to go, but my custom components are increasingly involving nested tables and spans and those are difficult for me to grasp quickly if it isn't in a jsp-like source.
On Mon, 17 Jan 2005 12:56:15 -0800, Craig McClanahan <[EMAIL PROTECTED]> wrote:
On Mon, 17 Jan 2005 14:49:23 -0600, Heath Borders
<[EMAIL PROTECTED]> wrote:
I was actually thinking that I would just use the JSP to code the page and then use jspc to compile it to a java source, and then use it just like a regular renderer.
Doing it this way means you're going to have to fake the JSP page context environment, so its a few more than 50 lines of code, but its probably technically feasible.
That is, put my encode and decode methods inside scriptlet declarations. Lately, my custom components have lots of HTML, but not much decoding. So, maintanence gets very difficult since its harder to read responsewriter code than it is to read JSP code.
Before worrying about wiring this kind of a page into JSF, try writing the renderer for <h:outputText> this way, implementing all the required functionality (for example, only emitting a passthrough attribute if the user specified it), and see if you think the result is still more maintainable than the corresponding Java version. I'm betting you will agree with me that the exercise is intellectually interesting but not desireable if your goal is more maintainable code.
Craig
On Mon, 17 Jan 2005 08:59:05 -0800, Craig McClanahan <[EMAIL PROTECTED]> wrote:
Creating a single JSF component that uses RequestDispatcher.include() inside would make it easy to use a JSP page as a "renderer" -- probably 50 lines of code to do this. But you are going to run into a couple of challenges:
* Real renderers tend to have lots of conditional logic in them. For example, even something as simple as <h:outputText> has conditional logic to render each of the pass-through attributes (onfocus, onblur, ...). Such logic is pretty concise in Java, but very verbose in JSP (you'd need tons of <c:if> statements, or a bunch of custom tags.
* Using the rendering APIs (ResponseWriter) makes it easy to create well formed XHTML output, with proper quoting and escaping on attribute values. Using JSP directly means you have to deal with this all yourself.
* Using a JSP takes care of the *encoding* half of what renderers do, but not the *decoding* half. For input components, you're still going to need a Java class to deal with those things, and now you've got the logic for a single renderer split into multiple source files, instead of all in one place.
* Using the ResponseWriter APIs has an additional benefit if you use components inside a JSF-aware GUI design tool -- the tool can take the output of a complex component (like <h:dataTable> and match up the various parts of the emitted output to the child component that was sthe source of each part. You'd give up that linkage if you used a JSP for the complex component.
In principle, using JSP for a renderer sounds like a great idea. In practice, you should try building one (like I did) -- and you'll see that the results are pretty ugly.
Craig
On Mon, 17 Jan 2005 08:30:53 -0600, Heath Borders
<[EMAIL PROTECTED]> wrote:
The most annoying thing for me about writing custom renderers is the way that you have to write all the HTML code inside of ResponseWriter method calls. This is similar to the problem that JSPs solved with Servlets. Is it possible, then, to use the "extends" page directive on a JSP to have the JSP compile into JSF renderer java code?
I'm sure this would renderer development and maintainence a LOT easier.
-- -Heath Borders-Wing [EMAIL PROTECTED]
-- -Heath Borders-Wing [EMAIL PROTECTED]
