Re: Recursion of components

[Todd Orr <to...@gmail.com>]

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 <fa...@linagora.com> 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: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: Recursion of components

[Todd Orr <to...@gmail.com>]

I think this issue is a moot point. But I will say that the tree
example is a perfect example because of it's nature.

> Any tree can be easily walked through like a list,
> but then rendered (indented) to look like a tree to the user.
Of course it can. That's not really the point. The point is that it is
far more complex, verbose, and therefore error-prone. Using recursion
to create a tree is the "best" way in these terms.

If recursion existed you wouldn't even need a "tree component". You
could just create a component that deals directly with the problem
domain (domain object) and have it recurse on itself to do any number
of things - in this case, create a tree - with such minimal
difficulty. Here we are forced to create a framework (a tree
component) simply to display a tree.

It not a question of whether it's possible to do recursive work
iteratively. It's simply a question a why - why do something that is
so simple via a recursive algorithm in a far more complex iterative
manner.

I know this is "principle 1", and its is the Tapestry way, and etc.
I'm still failing to see the major difference between a loop
(iterative) and nested components (recursive). In both cases the
actual number of components displayed is determined at runtime. In the
case of the loop we know that some combination of components (within
the loop) will be displayed some number of times at runtime. With
recursion we still know both of these things. So, I still need to
explore where the relevant code is, but my gut is telling me there
should be some work around to allow recursion as a depth bound process
(compared to the loop's breadth bound) - for lack of better words.

If you love the iterative approach, by all means go ahead and work
that way. If, on the other hand, you feel that recursion is the right
tool for these types of jobs and shouldn't be supplanted with
alternative iterative approaches with excessive code. No, it's not
science fiction, rocket science, or any extremely complicated
stereotype to perform recursive work iteratively. It is simply more
work than it should be.

On 8/23/07, Davor Hrg <hr...@gmail.com> wrote:
> I can't really see why is not having recursive components
> such a problem.
>
> Any tree can be easily walked through like a list,
> but then rendered (indented) to look like a tree to the user.
>
> So, rendering recursive data, like BeanEditForm should be
> no science fiction. Like any other thing, providing a good
> example can suffice. Using recursiive component to create
> a tree is the first thing we can think of, but it doesn't mean
> it's the best way.
>
> Davor Hrg
>
> On 8/22/07, Francois Armand <fa...@linagora.com> wrote:
> >
> > Hello Todd,
> >
> > 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.
> > >
> >
> > I read again my post and saw that I didn't express myself properly (put
> > it on my low level in English).
> > I should have write :"The non-support of recursive structure seems to
> > bring a lots of simplification with it _for Tapestry internal,
> > replication and performance problematics_". It seems to be a design
> > choice, and as I'm not a Tapestry developer, I can't explain exactly why
> > it was done, even if replication/pool of pages seems to be around.  I
> > came from functional programming projects where this kind of structure
> > is quite common, so personaly, I find that it's a real lake.
> > > 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.
> > >
> > If you look at the source code for "for" component, you will see that it
> > is far from being trivial. It also deals with raw output, and different
> > case are need if the loop is in a form or not...  But the use of "for"
> > component is quite simple. You could design a "Tree" component that
> > handle this stuff and just use it elsewhere in a simple way. with a
> > clear separation between template using this component and the
> > component. It's what I did in a tree component :
> >
> > http://svn.forge.objectweb.org/cgi-bin/viewcvs.cgi/interldap/interldap-wui-t5/trunk/src/main/java/org/interldap/wui/tapestry/components/Tree.java?view=markup&rev=97
> >
> > > 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.
> > >
> > Ok, so here, the problem is that the tree component is not well designed
> > (or not as much generic as it should be). Perhaps a real tree component
> > in standard lib would be good. But it has little to do with the lack of
> > recursion structure, that is painful. A tree structure would be (at
> > best) a bypass for this lack.
> >
> > --
> > Francois Armand
> > Etudes & Développements J2EE
> > LINAGORA SA - http://www.linagora.com
> > Tél.: +33 (0)1 58 18 68 28
> > -----------
> > InterLDAP - http://interldap.org
> > FederID - http://www.federid.org/
> > Open Source identities management and federation
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: Recursion of components

[Davor Hrg <hr...@gmail.com>]

I can't really see why is not having recursive components
such a problem.

Any tree can be easily walked through like a list,
but then rendered (indented) to look like a tree to the user.

So, rendering recursive data, like BeanEditForm should be
no science fiction. Like any other thing, providing a good
example can suffice. Using recursiive component to create
a tree is the first thing we can think of, but it doesn't mean
it's the best way.

Davor Hrg

On 8/22/07, Francois Armand <fa...@linagora.com> wrote:
>
> Hello Todd,
>
> 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.
> >
>
> I read again my post and saw that I didn't express myself properly (put
> it on my low level in English).
> I should have write :"The non-support of recursive structure seems to
> bring a lots of simplification with it _for Tapestry internal,
> replication and performance problematics_". It seems to be a design
> choice, and as I'm not a Tapestry developer, I can't explain exactly why
> it was done, even if replication/pool of pages seems to be around.  I
> came from functional programming projects where this kind of structure
> is quite common, so personaly, I find that it's a real lake.
> > 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.
> >
> If you look at the source code for "for" component, you will see that it
> is far from being trivial. It also deals with raw output, and different
> case are need if the loop is in a form or not...  But the use of "for"
> component is quite simple. You could design a "Tree" component that
> handle this stuff and just use it elsewhere in a simple way. with a
> clear separation between template using this component and the
> component. It's what I did in a tree component :
>
> http://svn.forge.objectweb.org/cgi-bin/viewcvs.cgi/interldap/interldap-wui-t5/trunk/src/main/java/org/interldap/wui/tapestry/components/Tree.java?view=markup&rev=97
>
> > 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.
> >
> Ok, so here, the problem is that the tree component is not well designed
> (or not as much generic as it should be). Perhaps a real tree component
> in standard lib would be good. But it has little to do with the lack of
> recursion structure, that is painful. A tree structure would be (at
> best) a bypass for this lack.
>
> --
> Francois Armand
> Etudes & Développements J2EE
> LINAGORA SA - http://www.linagora.com
> Tél.: +33 (0)1 58 18 68 28
> -----------
> InterLDAP - http://interldap.org
> FederID - http://www.federid.org/
> Open Source identities management and federation
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>

Re: Recursion of components

[Francois Armand <fa...@linagora.com>]

Hello Todd,

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.
>   

I read again my post and saw that I didn't express myself properly (put 
it on my low level in English).
 I should have write :"The non-support of recursive structure seems to 
bring a lots of simplification with it _for Tapestry internal, 
replication and performance problematics_". It seems to be a design 
choice, and as I'm not a Tapestry developer, I can't explain exactly why 
it was done, even if replication/pool of pages seems to be around.  I 
came from functional programming projects where this kind of structure 
is quite common, so personaly, I find that it's a real lake.
> 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.
>   
If you look at the source code for "for" component, you will see that it 
is far from being trivial. It also deals with raw output, and different 
case are need if the loop is in a form or not...  But the use of "for" 
component is quite simple. You could design a "Tree" component that 
handle this stuff and just use it elsewhere in a simple way. with a 
clear separation between template using this component and the 
component. It's what I did in a tree component : 
http://svn.forge.objectweb.org/cgi-bin/viewcvs.cgi/interldap/interldap-wui-t5/trunk/src/main/java/org/interldap/wui/tapestry/components/Tree.java?view=markup&rev=97

> 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.
>   
Ok, so here, the problem is that the tree component is not well designed 
(or not as much generic as it should be). Perhaps a real tree component 
in standard lib would be good. But it has little to do with the lack of 
recursion structure, that is painful. A tree structure would be (at 
best) a bypass for this lack.

-- 
Francois Armand
Etudes & Développements J2EE
LINAGORA SA - http://www.linagora.com
Tél.: +33 (0)1 58 18 68 28
-----------
InterLDAP - http://interldap.org 
FederID - http://www.federid.org/
Open Source identities management and federation


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: Recursion of components

[Jonathan Glanz <jg...@densebrain.com>]

Cesar, I've never tried it but I'm sure you could write a component that simply used the request dispatcher to include another resource, such as a rails page or a struts page etc

It may take a little work but there shouldn't be anything stopping you

Jon
Sent via BlackBerry by AT&T

-----Original Message-----
From: "César Les" <ce...@gmail.com>

Date: Tue, 21 Aug 2007 10:54:05 
To:"Tapestry users" <us...@tapestry.apache.org>
Subject: Re: Recursion of components


maybe Tapestry should support alternatives to components like Rails do
with Partial Templates. So whe can choose the right tool for the right
job.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

RE: Recursion of components

[Mark Stang <ms...@pingidentity.com>]

You can always "render" them from a different page.  Store them in a different page and draw as needed.  I have one page, I just substitute different components as needed.

Mark J. Stang
Software Engineer
office: +1 303.468.2900
Ping Identity



-----Original Message-----
From: Thiago H de Paula Figueiredo [mailto:thiagohp@gmail.com]
Sent: Tue 8/21/2007 10:52 AM
To: Tapestry users
Subject: Re: Recursion of components
 
On Tue, 21 Aug 2007 12:54:05 -0300, César Les <ce...@gmail.com> wrote:

> maybe Tapestry should support alternatives to components like Rails do
> with Partial Templates. So whe can choose the right tool for the right
> job.

As far as I know, you don't really need to *instantiate* components on the  
fly most of the time: just *rendering* the component again would suffice.  
Example: AJAX in Tapestry 4.1.

-- 
Thiago H. de Paula Figueiredo
Desenvolvedor, Instrutor e Consultor de Tecnologia
Eteg Tecnologia da Informação Ltda.
http://www.eteg.com.br

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: Recursion of components

[Thiago H de Paula Figueiredo <th...@gmail.com>]

On Tue, 21 Aug 2007 12:54:05 -0300, César Les <ce...@gmail.com> wrote:

> maybe Tapestry should support alternatives to components like Rails do
> with Partial Templates. So whe can choose the right tool for the right
> job.

As far as I know, you don't really need to *instantiate* components on the  
fly most of the time: just *rendering* the component again would suffice.  
Example: AJAX in Tapestry 4.1.

-- 
Thiago H. de Paula Figueiredo
Desenvolvedor, Instrutor e Consultor de Tecnologia
Eteg Tecnologia da Informação Ltda.
http://www.eteg.com.br

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: Recursion of components

[César Les <ce...@gmail.com>]

maybe Tapestry should support alternatives to components like Rails do
with Partial Templates. So whe can choose the right tool for the right
job.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: Recursion of components

[Todd Orr <to...@gmail.com>]

>  >putting one loop inside another freaks Tapestry out. This is just dumb.
> I absolutely agree if this is true, in T4 I used nested loops without
> issues though?
Yes. Nested loops do work fine in tapestry. I was not being as
specific as I should have been. As loops are iterative they work fine.

> Also, with most projects changing frameworks means keeping business
> logic but chucking most of the view, which two frameworks are so alike
> that the view remains in-tact?
I'm not suggesting that the view remain intact. Only that the process
for creating certain parts of the view may be similar. Although
frameworks range in how things are done, most support standard
programming practices. I don't think anyone would disagree with the
statement that recursion is a standard programming practice. I think
its safe to say that the majority of modern languages support it.

Maybe I need to examine the internals of Tapestry a bit more to
address my confusion, but I really don't see the difference between a
loop and recursion as it pertains to tapestry knowing the page
structure. In both cases the actual number of of times the body will
render at runtime is unknown beforehand. In both cases, conceptually,
there is a block of code that may or may not render some other blocks
of code. The only difference I see is that in the case of the loop the
iterations (or breadth if you will) are unknown and in recursion the
depth is unknown. Is that really an insurmountable issue for tapestry?


On 8/21/07, Peter Stavrinides <p....@albourne.com> wrote:
> Hi Todd
>
> Interesting comments, particularly this:
>  >putting one loop inside another freaks Tapestry out. This is just dumb.
> I absolutely agree if this is true, in T4 I used nested loops without
> issues though?
>
> For more complex components like the grid component I disagree though,
> even the largest frameworks restrict what you can nest and use
> recursively if you use a very complex component.
>
> Also, with most projects changing frameworks means keeping business
> logic but chucking most of the view, which two frameworks are so alike
> that the view remains in-tact?
>
>  > Why make something so common and easy to do elsewhere so freakin hard
> in tapestry? It's completely backwards.
> Again I agree with you... the attraction of components is to remove the
> boilerplate code (for productivity), but what Tapestry is missing is not
> really in its implementation of components, but perhaps decent support
> for an alternative way of doing things, i.e.: embedded scripting, much
> like .Net or ColdFusion, In my humble opinion this would provide the
> flexibility you are alluding to. Property binding with components is
> great... Tapestry can cover most situations, but for anything outside
> the norm you need to go back to the most basic programming constructs,
> which is missing in Tapestry.
>
> and that's my two cents worth.
> Peter
>
> Todd Orr wrote:
> > 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 <rb...@capdm.com> 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.
> >>>
> >>>
> >>> damien@synect.com 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 <fa...@linagora.com> 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: users-unsubscribe@tapestry.apache.org
> >>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>> --
> >>>>> 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: users-unsubscribe@tapestry.apache.org
> >>>>> For additional commands, e-mail: users-help@tapestry.apache.org
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >>>> For additional commands, e-mail: users-help@tapestry.apache.org
> >>>>
> >>>>
> >>>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >>> For additional commands, e-mail: users-help@tapestry.apache.org
> >>>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >>
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: Recursion of components

[Nick Westgate <ni...@key-planning.co.jp>]

Nested loops work fine in T5 of course. I believe he is describing recursion.

Cheers,
Nick.


Peter Stavrinides wrote:
> Hi Todd
> 
> Interesting comments, particularly this:
>  >putting one loop inside another freaks Tapestry out. This is just dumb.
> I absolutely agree if this is true, in T4 I used nested loops without 
> issues though?

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: Recursion of components

[Peter Stavrinides <p....@albourne.com>]

Hi Todd

Interesting comments, particularly this:
 >putting one loop inside another freaks Tapestry out. This is just dumb.
I absolutely agree if this is true, in T4 I used nested loops without 
issues though?

For more complex components like the grid component I disagree though, 
even the largest frameworks restrict what you can nest and use 
recursively if you use a very complex component.

Also, with most projects changing frameworks means keeping business 
logic but chucking most of the view, which two frameworks are so alike 
that the view remains in-tact?

 > Why make something so common and easy to do elsewhere so freakin hard 
in tapestry? It's completely backwards.
Again I agree with you... the attraction of components is to remove the 
boilerplate code (for productivity), but what Tapestry is missing is not 
really in its implementation of components, but perhaps decent support 
for an alternative way of doing things, i.e.: embedded scripting, much 
like .Net or ColdFusion, In my humble opinion this would provide the 
flexibility you are alluding to. Property binding with components is 
great... Tapestry can cover most situations, but for anything outside 
the norm you need to go back to the most basic programming constructs, 
which is missing in Tapestry.

and that's my two cents worth.
Peter

Todd Orr wrote:
> 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 <rb...@capdm.com> 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.
>>>
>>>
>>> damien@synect.com 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 <fa...@linagora.com> 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: users-unsubscribe@tapestry.apache.org
>>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>             
>>>>> --
>>>>> 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: users-unsubscribe@tapestry.apache.org
>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>
>>>>>
>>>>>           
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>>
>>>>         
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>       
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>>     
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>   


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: Recursion of components

[Todd Orr <to...@gmail.com>]

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 <rb...@capdm.com> 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.
> >
> >
> > damien@synect.com 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 <fa...@linagora.com> 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: users-unsubscribe@tapestry.apache.org
> >>>>> For additional commands, e-mail: users-help@tapestry.apache.org
> >>>>>
> >>>>>
> >>>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >>>> For additional commands, e-mail: users-help@tapestry.apache.org
> >>>>
> >>>>
> >>>>
> >>>
> >>> --
> >>> 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: users-unsubscribe@tapestry.apache.org
> >>> For additional commands, e-mail: users-help@tapestry.apache.org
> >>>
> >>>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: Recursion of components

[Richard Kirby <rb...@capdm.com>]

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.
>
>
> damien@synect.com 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 <fa...@linagora.com> 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: users-unsubscribe@tapestry.apache.org
>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>>
>>>>
>>>
>>> -- 
>>> 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: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: Recursion of components

[Nick Westgate <ni...@key-planning.co.jp>]

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.


damien@synect.com 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 <fa...@linagora.com> 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: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>>
>>
>> --
>> 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: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: Recursion of components

[da...@synect.com]

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 <fa...@linagora.com> 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: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>>
>
>
> --
> 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: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: Recursion of components

[Hans Jörg Hessmann <he...@spricom.de>]

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 <fa...@linagora.com> 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: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>>     
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>   


-- 
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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org