yeah the key concept is that its PROPERLY FACTORED. lol
On 1/27/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > 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 > > > >
