(This might be a little too long. I have no thing to do at work, I'm bored, and this usually leads to large chunks of incomprehensible text)
First, some background: I'm current developing an application with a common backend accessed by both a RIFE and a Tapestry front layers. The IDEA here is to make a direct comparision of the effort and development experience of the two frameworks. I've been using Tapestry for some time now, and I love it, but it has some shortcomings. First, abstract classes: while every tapestry developer says you get used to this after some time, I have quite the contrary experience: after some time, all this abstract coding really pisses me off. Second, URL's: you don't have much of a control over Tapestry URL's, making the development of RESTful services very hard to impossible. There are other problems, but this message isn't about bashing Tapestry, so let's move on. I've been led to RIFE by occasional messages from Keith Lea on JetBrains' newsgroups. Now I'm making a sincere effort to learn it, but it seems there's still some road ahead before I can grok RIFE. Before delving into the problem at hand, let's take a short course over my learning experience, and the good points about it. The first good point about RIFE is the template language. It's ingenuously simple, and surprisingly powerful after you get used to it. Granted, it's not easy to get used to a template language without *any* logic, after almost a decade of JSP's, but after I did, I really started liking it. The second point about RIFE is how everything in your application is well laid out, with a site map declaring all elements, and the flow of links and data between them. In the RIFE way, data in your application is well compartimentalized, with each element having access to the data it needs, and and the data it needs only. Now (finally), the problem: the flat element list. You see, I'm used to creating components to represent every reusable part of a web application with Tapestry: buttons, links, and any other portions of a web page that must have a uniform look and behaviour are componentized. Sometimes these components are heavily parameterized. To make things more palatable, let's take as example a built-in Tapestry component: the contrib:Table. This component takes as input a collection of objects, and some info on how to render them. To use it, you declare it inside another component's (or page -- Tapestry treats them slightly different) template. The table component takes as input a collection of objects, and some info on how to render them. Part of this info may actually be blocks declared in the container's template. That's my problem with RIFE. While I can declare components (elements), the container/contained relationship between them isn't quite as clear as in Tapestry -- you can't declare an element inside another element in RIFE. Also, a component in Tapestry has much greater control over it's embedded components than in RIFE, or should I say, a contained element in RIFE is *too* independent -- it's too hard to capture info about the element it's contained in. Now in practical terms: I'd love to see a way to declare real embedded elements in RIFE: an element that's contained inside another element, rendered as part of it's parent template, and able to access the parent's template blocks and values, and to have it's input somehow linked to it's parent inputs. The parent would be able to set it's child inputs and read their outputs. Maybe there's a non-obvious way to do this today, and maybe I'm missing some "a-ha!" thing that would make everything crystal clear. And maybe you can help me find that thing. Alright, this message is now *way* too large even for my boring text standards. Let's see of I can get some replies, and I'll pick up from them. Congratulations if you had the patience to get this far, and many thanks in advance, -- Marcus Brito _______________________________________________ Rife-users mailing list [email protected] http://lists.uwyn.com/mailman/listinfo/rife-users
