What's worth considering is that the reason it exists at all is
purely an implementation detail. There is already a pseudo-dynamic
component creating ability in Tapestry. Consider a Loop component that
contains other components. Somehow, Tapestry, in this case, knows what
to generate at runtime since the iterations in the loop can be
completely unknown beforehand (db, config, etc. driven).
However, putting one loop inside another freaks Tapestry out. This is
just dumb. Treating a component differently based on its placement is
not static, as HLS desires tap to be. It's completely modal. Whatever
logic is used to dynamically create loop/grid/etc. components on the
fly should be a basis for recursive components.
I believe that this "principle" is its primary shortcoming. So much so
that it could be the death of tapestry in certain development
groups/communities. Consider a company that has decided to upgrade
from struts to tapestry. It has years of man hours and tens of
thousands of lines of code invested in its application. However,
struts has been evaluated as a no-go for the app's future. If said
business were to move to tapestry it's developers would encounter a
very easy / quick framework and may be able to build out much of the
existing app in short order. However, in cases where recursion is
needed they will be up against a mt. everest of a learning curve who's
result may stil be unsuitable. This alone is enough for business
interests and concerned tech management to put a halt on tapestry.
Also, consider that recursion is such a universally accepted and
widely used concept (nevermind its usefulness) that existing companies
are sure to have at least a few examples.
Now, even though this example is stupid it is pretty much every single
existing "enterprise" (since java folks love that word) level company
in existence. Maybe it's not a migration from struts and maybe its not
even recursion that's the problem, but every single company that has a
non-trivial application will run into this situation. Sometimes
they'll be able to solve it easily with iteration, sometimes they'll
have to climb walls to do it, other times they'll say f* it and move
onto another framework.
To those of you that say "fine, let them move onto another framework"
you're missing the point. Tapestry is easy to use, has a great
learning curve, a healthy community, etc., etc., etc. Why make
something so common and easy to do elsewhere so freakin hard in
tapestry? It's completely backwards. While principle 1 might be
static, the entire design is focused on ease of component creation
("Tapestry is specifically designed to make creating new components
very easy, as this is a routine approach when building applications."
- same link). If it's specific design is failing, something is wrong.
On 8/20/07, Richard Kirby <[EMAIL PROTECTED]> wrote:
> 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
