----- Original Message ----- From: "Magic Hat" <[EMAIL PROTECTED]> To: "Craig Miskell" <[EMAIL PROTECTED]> Cc: "Tapestry Developer" <[EMAIL PROTECTED]> Sent: Wednesday, October 09, 2002 5:37 AM Subject: Re: WebObjects -> Tapestry (was Re: [Tapestry-developer] Re: instances vs class/id vs type)
> > On Wednesday, Oct 9, 2002, at 02:40 Europe/Zurich, Craig Miskell wrote: > > > Yep, doing an experimental project of exactly that right now. There's > > a > > few conceptual hurdles, but it's not terribly difficult. > > Care to elaborate about the "conceptual hurdles"? > > > The HTML ports really easy (replace <WEBOBJECT NAME=Blah> with > > <picktagname jwcid="Blah">), and the wod isn't too bad - not really > > line > > for line, but the concepts are the same, and a lot of the binding names > > are identical. > > > > I'm seriously contemplating writing a "Tapestry for the WebObjects > > developer" introduction kind of things, for our internal use (if we go > > with Tapestry). If others would be interested, I could see about > > getting > > it released to the world+dog. > > Sounds great! And would be really helpful as I suspect that there are > several WO people lurking around Tapestry in the hope of an exit > strategy from Apple's heavy embrace... > > > Of course, somebody would have to explain > > to me the reason for Engine and Visit being separated (as compared to > > Session in WO) :-) > > Ummm... Right. Why don't we start with that? I'm pretty much clueless > about Tapestry, but have a fare amount of experience with WOF. > > In a traditional, component/session based WOApp the following elements > need to be taken care of: > > - A subclass of WOApplication which define the entry point to an > application. Tapestry has the engine and engine services. The home service is used to start the application. The default home service (it can be overriden) loads a page named Home and displays it. > > - A subclass of WOSession for storing values with a life span longer > than a request/response loop. Tapestry allows developers to persist the values of properties on pages and even inside individual components. The Visit object is used to store any global state (state that crosses page boundaries). > > - Some subclasses of WOComponent to implement your custom behavior. These are new pages and components. > > How does that translate into Tapestry? Specially the > WOApplication/WOSession? > > Also, WOF has the notion of a "request handler". For example, there is > a default handler that will deal with request for components. Or > resources. Or direct action. And so on and so forth. I think a "request handler" in WOF is approximately an "engine service" in Tapestry. It works with components to construct URLs during rendering, than is involved in dispatching when request is triggered by such a URL. > > Now, I'm using my own request handlers to provide things like a rss > feed, permanent links to random objects and document retrieval among > other things. > > Is there something equivalent to a WORequestHandler in Tapestry? > > Also, is there something akin to a WOSwitchComponent: > > "WOSwitchComponent provides a way to determine at runtime which nested > component should be displayed. This component is useful when you want > to decide how to display information based on the state of the > application." I've thought about this, but it can be accomplished today with either a series of Conditional components or with Block and RenderBlock. > > I guess I have more questions, but that would be a fair start :-) > > Thanks for any insights! > > Cheers, > > PA. ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Tapestry-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/tapestry-developer
