I don't think tapestry limits the number of persistent properties for declared components, it's just the components that are defined in a For loop.
Since tapestry probably reuses the component instance as it iterates through the for loop, each bind/unbind of the component is going to be bound to the same session property. It kind of makes sense when you consider that the component persistent properties are stored in the HttpSession using the page name and component id path. I am guessing that although the component is rendered multiple times (via the for loop), the component has the same id path for every iteration. >From the tapestry wiki << The above is technically correct, but <property-specification> inside a component can still use the persist="yes" attribute and be persistent! The mechanism is exactly the same for pages as it is for components, just the HttpSession attribute key is a bit longer (it incorporates the page name, the component id path and the property name). >> ----- Original Message ----- From: "Jesse Kuhnert" <[EMAIL PROTECTED]> To: "Tapestry users" <users@tapestry.apache.org> Sent: Wednesday, May 2, 2007 4:31:23 PM (GMT-0500) America/New_York Subject: Re: how to get maximum component portablity? I'm not sure I understood anything from either email. Could you give an example that is more generic ? Tapestry doesn't limit the number of persistent properties that anything can have. On 5/2/07, Phillip Rhodes <[EMAIL PROTECTED]> wrote: > > Just wanted to add a significant point to email below. > > Tapestry allows only one instance of a Persistent property per component > per page. > > If you component is in a For loop and your component uses a Persistent > property, Your component will be bound to the same persistant property value > in each iteration of your for. > > I'm not reporting it as a problem, but rather, just something to remember > in tapestry application development. > Thanks. > Phillip > > > > ----- Original Message ----- > From: "Phillip Rhodes" <[EMAIL PROTECTED]> > To: users@tapestry.apache.org > Sent: Wednesday, May 2, 2007 10:06:39 AM (GMT-0500) America/New_York > Subject: how to get maximum component portablity? > > Hi everyone, > > I am kind of stuck and would like to have some different perspectives on > this problem/solutions. Using t4. > > I have a a list of items that I am displaying. > For each order, I display an EditItemLink component. > The ItemEditLink takes a parameter of an Item. > The ItemEditLink contains a DirectLink (parameters are the itemid property > of the order) > Clicking on the ItemEditLink calls a listener in the ItemEditLink > (editItem) passing into the listener the itemid of the item to be edited. > > Now here is where I am stuck. > Ordinarily, a developer would create a "ItemEdit" type of page with a > persistent page property of Item. They would retrieve the Item using the > itemid in the ItemEditLink listener, set the ItemEdit page properties, and > activate that page. > So, the ItemEditLink is dependent on an ItemEdit page to work. > > > I can't use the above approach because: > The EditItemLink component is in a component library that is used in many > different applications, this library component can call either a library > page (which will not have any of the ui/navigation) of the containing > application. That won't work. > Another approach is the component just call an application page, I would > get the ui/nav (from the border) since it's an application page, but I would > have to re-implement all the methods/logic in the page class that would > normally be provided by the component library. This is due to lack of > multiple inheritance in java (can't extend both application base page and a > base page class provided in the component library). > > > What I thought would work is to not navigate to different pages from my > library components. > Could the EditItemLink component provide an item edit form without > depending on anything in the containing page? > > Thanks and sorry for the long post! > > Phillip > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Jesse Kuhnert Tapestry/Dojo team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
