That's rather akin to the claim that if I have 120 cars in my garage, my BMW is actually a transformer, on the grounds that I could decide to drive a Buik instead, isn't it? The idea that I have to know a-priori every possible component I might, potentially, need to render, is the hangup, not to mention the fact that I've got to tote around (and maintain) this "master sheet" of every component I might every have to use.
I mean would you think it "natural" working in a gui environment to require a hidden form with every possible widge you might ever need so that you actual "working" forms had the templates to pull from? It'd be an unnatural act there, and I think it's unnatural here as well. I don't think anybody (with the possible exception of the newest users) are arguing that they're absolutely prevented from doing their work because of the static nature of the Tapesty architecture. Rather I think the contention is that they're required to perform profoundly unnatural acts to make things work, things which to their mind (and mine) ought to be much simpler. --- Pat > -----Original Message----- > From: Mark Stang [mailto:[EMAIL PROTECTED] > Sent: Friday, January 27, 2006 11:18 AM > To: Tapestry users; Tapestry users > Subject: RE: instantiating components directly > > Mike, > I have a page with over 120 components on it. They range from a single > text field all the way up to components that are complex combinations of > fields. The page is a "holder" page we don't every display it. Instead > we have another page that is our View. We reference any one of the > components and display them in our view. Currently, we only show a single > component, but I believe if we put that component in a foreach we could > display any of the 120 dynamically. > > We also have a component that has N number of rows in three columns. For > the N number of rows, we read a list of fields from a database and draw > them in a for-each. We then map those rows in column 2 to a pull-down > with n-options. The end column can is a sub-selection of whatever was > selected in column 2. > > So, you can create as many combinations of components as you need all > dynamically. > > hth, > > Mark > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Thu 1/26/2006 5:49 PM > To: Tapestry users > Subject: Re: instantiating components directly > > We're neck deep in Tapestry 3.0.3 and are struggling with how to handle N > number of components in a form. > > (from thread, below) "I've found that anything you might think of solving > by using dynamic components can be solved as well or better by some other > method which > tapestry /does/ provide." > > If this is true, how would Tapestry solve the following problem? > > (basically this is the problem of putting N text fields in a form, where N > is derived from a db/sml configuration) > > We have a page containing a form, let's say it's an order form. The user > is entering data for various companies, not just their employer. The form > contains a bare minium of form elements / components, e.g., name, address, > item, quantity, price, etc., and these are common to all companies. > > However, depending on the company for whom we are filling out the form, > there may be additional fields. There can be from zero to n additional > fields. These additional fields are configured in a database or XML file. > How do I dynamically generate the addittional, company-specific > components on the form? Note, this is important because each component > must use Tapestry's validation/delegate mechanism to perform server-side > validation. > > Currently, we have resorted to doing client-side validation on the > custom/dynamic form elements & then letting Tapestry perform server-side > validation on the static form components. From a usibility stance, this > is unacceptable. But we're stumped on how to have N components in our > form. We must fulfill this requirement. Yes, we could create 20 extra > components & use conditionals, but we don't want to be limited to any > number--there really could be 50 or 100 or more. > > Thanks, > - Mike > > -------------------------------------------------------------------------- > ------------- > Re: instantiating components directly > Robert Zeigler > Thu, 12 Jan 2006 12:28:46 -0800 > > Yes... but you don't need to use dynamically added components to > accomplish that. You can accomplish it using a static structure, including > direct links. Or, your "tree" component implements the "IDirect" > interface. Then it generates the urls needed, and provides the necessary > listener and gets called-back automatically by the direct service. I think > there are some pretty good reasons to keep the component tree static. For > one thing, page objects are very expensive to create, which necessitates > (the oft maligned) page pooling. However, because you are pooling the > pages, the component tree MUST be static, because you can't guarantee that > the same page instance will be used the /next/ time the page is rendered. > There may be ways around that, but generally, I've found that anything you > might think of solving by using dynamic components can be solved as well > or better by some other method which > tapestry /does/ provide. > (That said, I won't deny wishing for being able to add components at > runtime on occasion. :) > > Robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
