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?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.
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?
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.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).
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!).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.
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
