The engine is a convienient place to put non-client specific logic. In the Vlib, its a good place to put EJB lookups. You'll notice that listener methods use the engine to find an EJB, but then invoke methods directly on it. The code is more complicated than a typical bit of example code because I put retry loops around all EJB operations. You can bounce the EJBs and Vlib will recover gracefully.
You could put such stuff in the Visit as well, but you may not always have a Visit (it is created only when first referenced), and you'll always have an Engine. The Visit contains information about a specific client's visit to the application. Yes, the kind of thing you'd normally put in the HttpSession, but strongly typed and generally more convienient. This is one of the two directly supported forms of server-side state (the other being persistent properties). Page flow is handled in the code, yes. The HTML template is almost purely View (in MVC), and the Java class is almost purely Controller. The page specification links the two (I guess that makes it Controller as well). Sometimes you need to "support" the View (for example, "what color should this text be, based on data stored in some object") ... that turns into a property of the class, and some wiring in the specification. ----- Original Message ----- From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, October 24, 2002 5:14 PM Subject: [Tapestry-developer] newbie trying to figure out tapestry > Hi, > > I've been through the documentation and tutorials, and this thing > won't congeal in my head. > > I'm really confused about the division of logic. For instance in the > VLib tutorial application, a lot of the server-side lookup plumbing is > in the Engine class, I have no idea why. And apparently page flow > is handled directly in the code (that may or may not be a negative, > I'm trying to decide). > > What I do understand is that the visit class holds session-type > information. And I understand the mechanics of how to build > components (the tutorial was very clear about that). > > But I have a bunch of why-type questions. I'm coming from a Struts > world and the benefits of its MVC paradigm and the decoupling that > gets you are very clear in my head. When I look at tapestry code > what I think I see is an event-driven model, but the separation of > concerns/duties is not so clear to me. > > So, I guess my first question is, what do people on this list see as > the basic responsibilites of various sections of this framework? For > instance is the Engine class supposed to handle interaction with the > business layer, as in VLib? (if so that could result in a very large > class). > > Regards, > Steve > > > > ------------------------------------------------------- > This sf.net email is sponsored by: Influence the future > of Java(TM) technology. Join the Java Community > Process(SM) (JCP(SM)) program now. > http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0003en > _______________________________________________ > Tapestry-developer mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/tapestry-developer > ------------------------------------------------------- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0003en _______________________________________________ Tapestry-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/tapestry-developer
