As Howard has authored - it is Principle 1 of tapestry - see
http://tapestry.apache.org/tapestry5/ towards the bottom of the page.
Richard.
Nick Westgate wrote:
There's been plenty of discussion about this in the past, and using
blocks from a template is the usual solution, eg:
http://www.behindthesite.com/blog/C1931765677/E923478269/index.html
I believe the "static structure, dynamic behaviour" mantra is for the
sake of performance, and a fundamental framework design desicion.
But if you think it's a bug, log a JIRA. At least one of the new devs
might have an opinion about this, but they haven't been on the lists
much recently.
Cheers,
Nick.
[EMAIL PROTECTED] wrote:
Interesting, I hit this same wall a while ago when trying to render a
tree. It seems to be a common occurrence, so supporting it in the
framework would be highly desirable. I ended up doing almost all the
rendering in Java code, using the template only to hold blocks which I
called to render from the Java code. This allowed me to at least specify
some "blocks" of HTML in the template, rather than doing it all in code.
Damien
I couldn't believe it, so I made an example. And I had to discover that
it is true:
org.apache.tapestry.ioc.internal.util.TapestryException
The template for component example.recursive.components.Node is
recursive (contains another direct or indirect reference to component
example.recursive.components.Node). This is not supported (components
may not contain themselves).
I consider this a bug that has to do with the alpha state of T5.
Otherwise I have doubts on the usefulness of T5 at all.
Todd Orr wrote:
I'm also trying to perform this type of recursive structure. I don't
agree that this makes anything simpler. Recursion is a powerful and
concise tool for these situations. I will say that it is often abused,
but this is a perfect use case. A recursive solution to this problem
is far simpler and maybe more "correct" than this iterative approach.
First off, the proposed solution requires complicated logic. Fine,
it's not rocket science, but the recursive alternative (if there was
one in tap) is far easier to read and understand. From a
tech-management point of view the simplicity of the code is a major
factor in its long term maintainability as well as its bugginess.
Secondly, the proposed solution requires adding raw HTML output to
code. This may be a more esoteric and arguable point, but Tapestry
excels in having a clear and easy to use separation between the
view/presentation and the logic components of the application's
construction. Again, with regards to maintainability, it is twice as
hard to maintain code if the concerns are spread throughout
conceptually separate pieces of code.
Third, this approach makes it impossible for any "node" in the tree to
contain any non-trivial nested components. I see that you can create
links...wow. Kinda limiting if you ask me. This limits the usefulness
and extendability of the code. If more complex functionality is
required (lets say by a major client or some other critical business
need) within this pseudo-recursive implementation it might force the
developers to completely switch out frameworks to one more suitable
for the job. This is a huge risk from a business perspective.
While I think these points are painful enough on their own, it does
raise some questions about the framework's usefulness in specific
situations. My main concern is in relation to CMS features. Many
applications require support for some level of features that would be
considered CMS functionality. This static structure imposed makes
creating dynamic sites, well, painful. When you are attempting to
build an application that must adapt to known types of "runtime" or
user-configuration driven alterations that have many variants during
runtime (eg. depth of a tree, etc.) the static structure is limiting.
Tapestry is a great framework. However, the intention of the static
structure, while clearly advantageous in many respects, limits the use
case coverage for the framework at worst and makes certain otherwise
easy tasks very difficult at best.
Perhaps the rules for the static structure could be allowed to bend
from time to time as a nod to those of us that do require greater
flexibility. I'm sure this is easier suggested than done, but what are
the options?
On 7/17/07, Francois Armand <[EMAIL PROTECTED]> wrote:
Dmitry Sidorenko wrote:
Hi all.
Hi,
In my project I need to generate edit form for a class like this:
class Section{
List<Section> subSectionList;
List<Field> fieldList;
}
> [...]
Probably I'm doing something wrong, maybe my task should be done in
completely different manner.. Any ideas?
Is there any way to develop visual editor for such a recursive
classes?
I don't know how T4 works, but if it's like in T5, their is no
support
of recursive template/class.
So, for tree structure, you have to use a non-recursive algorithm (I
think that in your example, you wish to use a non-recursive preorder
traversal).
It's not really natural, but the non-support of recursive structure
seems to bring a lots of simplification with it.
You can look at this How To entry :
http://wiki.apache.org/tapestry/Tapestry5HowToCreateYourOwnComponents
I wish it would help.
Francois
---------------------------------------------------------------------
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]
--
SPRICOM Informatik GmbH
Firmensitz: Brucknerstraße 29, 53721 Siegburg
Registergericht: Amtsgericht Siegburg, HRB 8808
Geschäftsführer: Hans Jörg Hessmann
http://www.spricom.de
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
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]
