I'm don't believe that would solve my problem, because when I render the page, I never know what components I need until I read the database. Yesterday, company A may have 5 custom fields to add to the form, and today they may have 20--or maybe there is still 5, but the default values have changed because a new law went into affect. Or maybe they just got re-labeled. Pre-defining X number of components wouldn't do it.
It seems that Tapestry is more interested in keeping the specification file as the center of the universe, rather than the components. It seems to me, and other devs, that the specification file should be a convenience--a way of quickly & conveniently create components. In fact, our UI folks could create them when they code the HTML. At then end of the day, it seems that Tapestry should be about components, not a religious adherence to the specification file. I don't say that in a mean-spirited way, but from my Tapestry experience, it seems simply to be the case. If that's true, that static components are the rule in Tapestry, then perhaps Tapestry is forcing itself to become a niche product. And then Tapestry would seem like an awful lot of extra dev work, just to play with static, xml-defined components. Perhaps Tapestry wouldn't need layout managers (could css do the job?). But it seems like minimal coding from Tapestry's team to be able to expose & expand the code that would allow you to add components (validatible components) dynamically. Again, it seems, to me, like it would be an enormous addition to Tapestry's feature set--and market value--not just an addition of theoretical/architectural completeness. With so many developers asking for this functionality, what is the philosophy keeping it from being added to Tapestry? Am I missing a key concept or rule that can't be broken? Thanks for the continued dialog & suggestions, - Mike "Mark Stang" <[EMAIL PROTECTED]> 01/27/2006 11:18 AM Please respond to "Tapestry users" <[email protected]> To "Tapestry users" <[email protected]>, "Tapestry users" <[email protected]> cc 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
