Very good point. I'm still new to Tapestry. But what you said confirmed my research on Tapestry. Thanks.
On 1/27/06, Mind Bridge <[EMAIL PROTECTED]> wrote: > > Hi, > > Consider the following: > > - The base of Tapestry is IRender > - All Tapestry components and pages implement the IRender interface > - You can render an IRender in the Java code by calling it directly, or > you can use the Delegator component to render it in a template > - What is on the other end of the IRender makes no difference at all -- > it could be another page, for example. An object could be stored into a > database, and return an IRender as its presentation. > > - You can use the Block and RenderBlock components as another way (a > clearer one in some cases) to have dynamic behaviour > - The Block that is rendered may be in an entirely different page > > - As an example of the implications of the above, we've had a > DynamicForm component that does exactly what you describe for several > years now. The contents of the form are defined by users with > administrative rights and are stored in the database. When the form > rendered, the fields are fetched from the database and a RenderBlock > component in a loop is used generate the form. (actually, its > capabilities are far more complicated than that, but this example will > suffice). The Block that is rendered at each iteration depends on the > value/type of the object. > > > Perhaps a Wiki article describing the dynamic behavior in Tapestry is > essential. I do not think that instantiating components directly is an > efficient solution at all, even though it is closest to the mind. > > > [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 > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
