Re: Recursion of components
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 :
Re: Recursion of components
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=markuprev=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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Recursion of components
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 [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
Re: Recursion of components
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Recursion of components
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 [EMAIL PROTECTED] 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.
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Recursion of components
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 ATT -Original Message- From: César Les [EMAIL PROTECTED] Date: Tue, 21 Aug 2007 10:54:05 To:Tapestry users users@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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Recursion of components
On Tue, 21 Aug 2007 12:54:05 -0300, César Les [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Recursion of components
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:[EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Recursion of components
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{
ListSection subSectionList;
ListField 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
Re: Recursion of components
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
Re: Recursion of components
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{
ListSection subSectionList;
ListField 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
Re: Recursion of components
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{
ListSection subSectionList;
ListField 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
Re: Recursion of components
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{
ListSection subSectionList;
ListField 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]
Re: Recursion of components
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{
ListSection subSectionList;
ListField 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]
Recursion of components
Hi all.
In my project I need to generate edit form for a class like this:
class Section{
ListSection subSectionList;
ListField fieldList;
}
I tried to implement SectionEditComponent with following html template:
table cellspacing=10
tr jwcid=@For source=ognl:subsectionsList
value=ognl:subsection element=tr
tdspan jwcid=@SectionEditComponent
section=ognl:subsection//td
/tr
tr jwcid=@For source=ognl:fieldList value=ognl:field
element=tr
tdspan jwcid=@Insert value=ognl:field.name//td
tdspan jwcid=@TextField value=ognl:field.value//td
/tr
/table
But Tapestry 4.1 says that I have recursive components references and
throws an exception.
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?
Best regards,
Dmitry.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Recursion of components
Dmitry Sidorenko wrote:
Hi all.
Hi,
In my project I need to generate edit form for a class like this:
class Section{
ListSection subSectionList;
ListField 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]
