I have been considering a solution to this, which I don't think would
change too much. The idea is that we have a component pool much like
we have a page pool. When the template is loaded, the components are
read in so they are ready. So instead of referencing them by object
in memory, they could be referenced by name. All instances of the
component should be the same anyway. The increased cost in time would
be in the look up having to pull them from a pool of components and
not through direct references.
You could even have the option to not use page components and have
them created automatically if you link to a component. You would have
access to the page from the component and specify required things
(ie CSS files) needed in the head tags, and then if they are not
already there, it would add them.
There may be some things I am missing, but I think it could be done
and much of the structure of the current code looks like it could be
done without having to change the entire project.
Just a thought because I agree with the parent's assessment.
Stephen
On Mar 3, 2006, at 9:45 AM, Todd Orr wrote:
IMHO, the biggest feature that Tapestry is missing is solid dynamic
component generation. Time and time again you'll see devs asking the
same question in the forums, "how do I dynamically generate..." Each
time someone points out the block, the for, or the if constructs. Yet
these always seem way more difficult than they should be. Even with
these tools, content management systems are notoriously difficult to
build with Tapestry. Since Tapestry makes most things easier, this
seems to be ironic. I began using Tapestry because most of my
development time was cut in half, but the dynamic form development
tasks I had to perform were tripled in time! Now, I could be the
crappiest dev on earth, but I doubt it considering all the trouble
everyone else has with this task and Tapestry. Because Tapestry is
static, the very idea of dynamic components seems to leave a bad taste
in Howard's mouth (and the mouths of die-hard enthusiasts). Yet it
shouldn't, dynamic form generation is a very real, and fairly common
task. It should be a first class citizen in the land of Tapestry.
Just to make sure the tone of this post isn't misunderstood: I love
Tapestry. Yet, everything can stand some measure of
improvement/rethinking.
On 3/3/06, Mark Stang <[EMAIL PROTECTED]> wrote:
Look at http://www.nextapp.com (a.k.a. echo2).
regards,
Mark
-----Original Message-----
From: Apache [mailto:[EMAIL PROTECTED]
Sent: Fri 3/3/2006 5:04 AM
To: tapestry-user@jakarta.apache.org
Subject: How to improve Tapestry
I think Tapestry already makes a big step forward
but still there is a lot of things that could be made more dynamic
and free programmers of templates and component definitions.
In my opinion everything could be in the database instead of
configuration files.
In my idea world there should only be Java Classes
and no XML/Html/Page files.
I only want to tell the system to "genrate a form with the fields
I tell you" and to tell it which fields are editable - the rest
should be done automatically. Maybe you could tell how to order or
align them, but I dont want to write any html templates.
-------------------- m2f --------------------
Sent from www.TapestryForums.com
Read this topic online here: <<topic_link>>
http://www.tapestryforums.com/viewtopic.php?p=14479#14479
-------------------- m2f --------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
