I have yet to look into any of those. I was considering trying some kind of XML approach, though. This isn't a really high priority for me, but I'll let you guys know if I come up with a workable solution.
On Wed, 19 Jan 2005 19:24:47 +0100, MichaÅ MaÅecki <[EMAIL PROTECTED]> wrote: > Have you think about using some other template engine - > freemarker/velocity/xmlc? They are not so strongly coupled to the web > and servlet environment > 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] > >>> > >>> > >>> > > > > > > > > > > -- -Heath Borders-Wing [EMAIL PROTECTED]
