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" <tapestry-user@jakarta.apache.org>
To
"Tapestry users" <tapestry-user@jakarta.apache.org>, "Tapestry users"
<tapestry-user@jakarta.apache.org>
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]
