The Javadocs of the Servlet spec (javax.servlet.jsp.tagext) give a pretty good idea of the lifecycle of the different tag classes. However, you might indeed be best of reading a book first.
Martin -----Oorspronkelijk bericht----- Van: Derek [mailto:[EMAIL PROTECTED] Verzonden: dinsdag 27 april 2004 4:09 Aan: Tag Libraries Users List Onderwerp: Re: Tag Object Model? Ok, I would highly recommend O'Reilly's Java Server Pages -- it's half JSP and half how to write custom JSPs. It goes through the life-cycle of the various custom tag implementations. Derek On Apr 26, 2004, at 8:09 PM, Steven J. Owens wrote: >> --- Glenn Nielsen <[EMAIL PROTECTED]> wrote: >>> It sounds like you are referring to how the Java source code >>> for a JSP is generated. This is based on the JSP spec and >>> the vendors implementation of it. If you are using Tomcat > > Somewhat; while I'm most particularly interested in the taglib > object model, I imagine it'd only make sense in the context of the > general jsp object model. > >>> you might want to ask on the tomcat-user or tomcat-dev >>> lists if such a thing exists for Jasper which implements >>> JSP pages in Tomcat. >>> >>> If you are interested in writing custom tags the JSP >>> spec is your best source of information. > > The spec does cover this topic, specifically in chapter 11, the > JSP Container, and chapter 12, the Core API, it's a bit too much > trees, not enough forest. Chapter 12 especially discusses each of the > various objects but doesn't provide a coherent overview of how they're > typically set up and invoked. Likewise, chapter 13, the Tag Extension > API, details each of the objects, but doesn't give a summary of how > the objects are set up and invoked. > > Don't get me wrong, I live sun's specs, they're a dream compared > to most other vendor docs, but I'm still looking for something a bit > more organizational in approach. > > On Mon, Apr 26, 2004 at 07:16:11AM -0700, Derek wrote: >> Of course, there are JavaDocs available for JSP in Tomcat: >> >> http://jakarta.apache.org/tomcat/tomcat-5.0-doc/jspapi/index.html > > Yup, I'm looking for something that would discuss these objects > and how they interact with each other and with their container. For > example, in the servlet world what I'm looking for would look sort of > like this: > > 1) The browser sends a request for a given URL to the servlet engine. > > 2) The servlet engine checks the URL mappings which are defined in > each webapp's WEB-INF/web.xml to see which servlet should answer the > request. > > 3) If that servlet hasn't been invoked before, the servlet engine > instantiates the servlet class, otherwise it gets the existing instance > of the servlet class. > > 4) When a servlet is first instantiated, the engine invokes > servlet.init() method, passing in a ServletContext object that > contains the servlet engine configuration information. The servlet's > init() method does any setup necessary. If it can't do the setup > necessary, it can throw ServletException to tell the engine > something's wrong. > > There's a corresponding servlet.destroy() method that gets called when > the servlet engine is shutting down or otherwise taking the servlet > out of service. > > 5) The servlet engine wraps the incoming request in an > HttpServletRequest object, which includes properties for various > headers and attributes, parameter parsing, methods for using the > servlet engine session and other scaffolding, and the input stream of > the request. > > The servlet engine wraps the output stream in an HttpServletResponse, > which includes the output stream, properties for setting response > headers, > and controlling how output sent to the output stream will be buffered, > and > the output stream itself. > > 6) The servlet engine invokes the servlet's appropriate doFoo() method, > which is usually doGet() or doPost(), but depends on what HTTP action > the request specified. The HttpServletRequest and HttpServletResponse > are passed in as parameters in the method call to doFoo(). > > Note that the servlet's doFoo() methods MUST be multi-thread-safe, > since they will be hit by multiple threads simultaneously. In a > nutshell this means that the servlet shouldn't touch any instance > variables (unless you know what you're doing). Multi-threaded > programming is not trivial to explain, but there are several tactics > that the servlet spec is designed to make it easier, we'll get into > those later. > > 7) The servlet can do whatever processing it needs to do, and then > send back response headers by using HttpServletResponse's setHeader() > method, and send back HTML using the java.io.PrintWriter returned by > HttpServletResponse's getWriter() method. > > Note that generally you have do any header setting before you start > sending output back through the PrintWriter. This is because the > HttpServletResponse object is modeling the underlying process, and to > a degree obscuring it. Normally with HTTP you send back to the > browser a set of header lines, followed by a blank line as a > separator, followed by the body content (the result looks much like a > typical email). > > A lot of actions, like client-side redirects, are handled by sending > specific headers back to the browser. You can't send body content > without sending the blank line separator. Once the blank line is > sent, you can't send any more headers. So do any header manipulation > and figure out if you'll need to redirect before you start sending > body content to the browser. If you mess this up, various methods > like response.sendRedirect() will throw IllegalStateException. > > Note: Servlet engines may buffer body content output, but you can't > control that or count on it. > > 8) When the servlet's doFoo() method is done sending output, it just > returns. > > > -- > Steven J. Owens > [EMAIL PROTECTED] > > "I'm going to make broad, sweeping generalizations and strong, > declarative statements, because otherwise I'll be here all night and > this document will be four times longer and much less fun to read. > Take it all with a grain of salt." - Me at http://darksleep.com > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
