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. - A subclass of WOSession for storing values with a life span longer than a request/response loop. - Some subclasses of WOComponent to implement your custom behavior. 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. 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 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
