That sounds like one crazy set of requirements ;)
I don't know how you will possibly handle the layout issues involved, but it
wouldn't be far-fetched to do something like(taken from
http://jakarta.apache.org/tapestry/tapestry/ComponentReference/RenderBlock.html
):
<foreach looping element here>
<span jwcid="<your field type block name>@Block" >
<span jwcid="[EMAIL PROTECTED]" />
</span>
<span jwcid="<your field type block name>@Block">
<span jwcid="[EMAIL PROTECTED]" />
</span>
</for>
Your page would then hand out blocks depending on the type of field you need
to render "for each" loop. I've used a similar technique for handling
varying data type renders, but they were always based around rendering a
custom component "form" configuration.
Ie if I had a classification system for ummm... "pets", I might have a
different form component grouping for each pet:
Dog:
<number of cats chased>
<likes to be pet>
<known to bite>
Cat:
<number of dogs hissed at>
<definitely hates everyone>
etc...
hope that helps..
jesse
On 1/26/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> 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
>
