Hi Christian, > 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?
No, not really. You can define your own component (say A) that contains the original component (say B). You can then bind B's parameters (the ones that get repeated everywhere) to the standard values that are provided by A. If there are parameters that you need to specify from the outside, define them as parameters of A, and pass them to B using inherited bindings (they have been created with this use in mind). Finally, instead of using B in your application, use A. You won't have to repeat the standard parameter values anymore. This is exactly analogous to the case where you have to call one function with the same arguments a lot of times in an application. The right way to fix it is to define a new function that invokes the original one with the default arguments, and use the new function instead. Basically, you can look at it this way: Function in programming == Component in Tapestry Now, whether a function would just call another with standard arguments (== the component described above) or would perform a sequence of actions (== a more complex component) is up to you. As you no doubt know from programming, if you need to call a function with the same arguments on a number of places, it is very likely that in the future you will need to do other identical actions on those very same places, hence having a function is a good idea anyway. Exactly the same applies to components. In our experience working with pages directly and employing "copy-paste" may be simpler, but at the end you will save a lot more time when you modify the damn thing if you use comonents. I hope this perspective is more clear. > 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. A component without parameters is just one line in the specification. With the "implicit components" (see http://tapestry.sourceforge.net/wiki/index.php/AnonymousComponents for details) this will refer only to the HTML template and will be even shorter: <span jwcid="@Body"> or <span jwcid="@Insert" value="visit.username"> Is there something more minimal than that? > 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. What Howard has successfully managed to avoid with the current design is the significant creation of new objects that will result from what is suggested. The creation of new objects is universally accepted as the number one cause for performance problems in Java. On the other hand, I think it is well understood by the people involved with Tapestry that the current approach (detach and all) is not that easy to work with. > 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? There are a couple of things that make this easier. First, please check the documentation on the initialize() method. It is called both from the constructor and detach(). Since you have to initialize the vars at construction anyway, using it for that purpose kills two birds with one stone, and you don't have to worry about detach(). This is currently available only for pages. Presumably there will be a similar mechanism for components as well. Second, you will be able to declare transient properties in the spec in the same way you declare persistent ones, which will automatically take care of initialization. You are of course free to use either the manual or the automatic approach. > 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!). See initialize() above -- doing it that way is both simple and error-resistent. The automatic (declarative) way of doing things may bring further benefits in the future, however, since it can be easily extended and improved without a modification of the developer's code. One example is initialization of properties (especially persistent ones) only on demand, rather than in all cases. Of course, the performance benefits of those may not be that important to some people. > 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. See above for Implicit Components and read about Tapestry Lite on the Wiki. It may be just for you. > regards, > Christian Best regards, -mb ------------------------------------------------------- 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
