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