----- Original Message ----- From: "Christian Sell" <[EMAIL PROTECTED]> To: "Howard M. Lewis Ship" <[EMAIL PROTECTED]> Cc: "Tapestry-Developer" <[EMAIL PROTECTED]> Sent: Sunday, December 15, 2002 1:36 PM Subject: Re: [Tapestry-developer] tapestry critique
> >>Instead, there should be a way to configure components globally (in the > >>application specification, or even optionally in an external, reusable > >>file which can be included in the application specification. These > >>definitions should be accessible to all pages (components?) in the > >>application. > > > > > > Since you are new to Tapestry, you are missing some of the subtleties. > > > > The Border component from the Tutorial exists, not to be reused, but to > > demonstrate how you can use the RenderWrapped component to create a new > > component that wraps around existing components, and not even have to write > > Java code to do it. > > > > In a real application, you might still have some form of Border component, > > but it will be specific to your application. > > > > If you look at the Workbench, it does just that. It has a Border component > > that provides the tabbed navigation across the top. Because it is specific > > to the Workbench application, the pages within the application merely used > > the Border, without configuring it. It figures out the rest from the name > > of the renderring page. > > I dont understand. Lets suppose I have a 3rd party library which gives > me a component (e.g., a calendar) that is to be included on every page > of my application. This component requires a few parameters which > control the appearance. These are the same all across my app. Would I > have to re-specify the component and parameters on every page? Typically, you'll create a standard Border component for your application, and configure the Calendar just once, inside your app-specific Border. Every page that uses the Border gets the Calendar as well, configured identically. > > And even if I tried to solve this with component composition, like > Joseph Panico suggested, I would still have to create the new component, > and add a reference in every page file using it. What I want to do is > define/configure the component only once, and then reference it from > HTML templates without having to add references to every jwc and page file. > > Am I making sense? > > > Almost everything you see in a Tapestry specification page specification, > > its template, and the specifications and templates of embedded components > > turns into objects. Objects to represent the static template, component > > instances for the embedded components, objects to represent bindings, > > assets, connected parameters. In many cases, Maps are used so that objects > > can be retrieved by name or id. > > > > So, a page instance is the root of a complex, tangled tree. > > > > To reserve that tree of objects to a single session is problematic. First, > > there's the memory usage; each client will have its own copies of each page > > that is ever visited by the user ... that adds up (1000's of users X dozens > > of pages). > > Of course I am not talking about all the page data (HTML and all) - just > about the java object that holds the state. That should be rather small > - probably not bigger than the wrapper you have to create to maintain > the state elsewhere. About serializablility - it seems totally > reasonable to require/recommend that all non-persistent variables be > declared transient, and all persistent ones be of serializable types. In Tapestry, these two things merge together; so you don't talk about "page.persistentState.myProperty", you just talk about "myProperty" or "page.myProperty". This is much more natural, for me and most others I think, than to keep them separate. You need properties, you code accessor methods like any other JavaBean. But there are costs, as we've discussed. > > > > More importantly, in a cluster environment, all server-side state must be > > Serializable, to allow it to be shared and moved between servers in the > > cluster. That means the page instances and everything within must be > > serializable. It also means the HttpSession will bloat (and large > > HttpSessions are not handled well by most application servers). > > > > When you get down to it, few pages have more than one or two persistant > > differences between HttpSession ... so Tapestry concentrates on those tiny > > differences rather than duplicating the whole enchilada. > > > > If you check on the Wiki, you'll see that this is one of the main areas > > being investigated for 2.4. There will be some kind of mechanism that will > > allow you to simply define, in your specification, which JavaBeans > > properties are transient and which are persistant. Tapestry will take care > > of the rest. The current thinking is it will create a subclass, on the fly, > > that implements or overrides your accessor methods to take care of value > > tracking, initialization, and cleanup. > > but if the (Java) page object is pooled, there would still have to be > that detach() method, which would have to clean up all transient state > variables, right? So the declaration you mention above would only take > care of the fireObservedChange calls - which I said I dont mind at all. > In fact I would rather keep coding them myself than have some subclass > generated (reminds me of EJBs, yuck!). You'll have the option, of course. If you want Tapestry to generate the correct methods in a subclass, you will need to specify your properties. If you want to code initialize() and detach(), you can do that as you would today. > > BTW, your statement in the other thread about the XML not being visible > due to Spindle does not always hold - many people are not using > Eclipse/Spindle, and some (like me) prefer editing the XML even then. > > regards, > Christian > > ------------------------------------------------------- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ _______________________________________________ Tapestry-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/tapestry-developer
