Hi Pazu,
thanks for your interesting mail and your kind remarks!
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.
There are several ways to achieve similar things and they probably
aren't obvious enough, I'll just go over some of the possibilities.
* You can configure elements through properties during the
declaration, also when these elements are embedded. Since RIFE's
property system fetches the object instance 'late', you can make the
values dynamic.
* Each embedded element has access to the content inside its tag. So
when you do: <!--V 'ELEMENT:.id'-->somestuff<!--/V-->, the
getEmbedValue() will return "somestuff" in the embedded element.
You can update this value dynamically and make it different for each
embedded element instance that's processed.
http://rifers.org/docs/api/com/uwyn/rife/engine/
ElementSupport.html#getEmbedValue()
* Now, since property files are often used for configuring things is
Java, you can use a property format as the value content and easy
obtain those properties through getEmbedProperties():
http://rifers.org/docs/api/com/uwyn/rife/engine/
ElementSupport.html#getEmbedProperties()
* However, using the embed value is a one-shot static configuration,
to make this more dynamic you can access the embedding element's
template with the getEmbeddingTemplate() method. This will give you
full access to that template.
* If you want even more power, you can use the getEmbeddingElement()
method, this will give you the instance of the embedding element that
contains the current embedded element. I typical way to transfer data
is to declare an interface and communicate through it, for example:
public interface NewsProvider
{
public NewsItem getNewsItem();
}
Now the embedding element implements it and provides the data
whenever the method is called. The embedded element can then do this:
NewsItem newsitem = ((NewsProvider)getEmbeddingElement()).getNewsItem();
You can see this at work in our SimpleBlog tutorial and example:
http://rifers.org/rife_indepth_simple_blog
* Last, this makes it easy to communicate amongst specific elements,
however sometimes you want to provide data to a whole lot of
elements. We haven't decided yet if it would make sense to create or
extend the object model to allow this. Declaring all the interactions
seems like an unnecessary overhead. Imho it only makes sense for the
public API of your site (the site structure) and the minimum required
data that RIFE needs to be able to function. Currently, we've simply
been using setRequestAttribute and getRequestAttribute. These methods
give you access to a map where you can aggregate data, but it will
only live as long as the request.
I've been toying with a number of additional ideas and they might or
might not be implemented soon:
* allow the embed value to easily become the template of the embedded
element on-the-fly, this makes it easy to mark up lay-outs and
augment them with behavior.
* support for 'widgets' that don't need to be declared inside the
site-structure, this still need to be extensively designed and
investigated. We've talked about it in the past on this list: http://
thread.gmane.org/gmane.comp.java.rife.user/1104
I hope this clears things up for you and provides what you need. Feel
free to give ideas or remarks if you think that it can be improved
upon within the RIFE approach.
Best regards,
Geert
--
Geert Bevin Uwyn bvba
"Use what you need" Avenue de Scailmont 34
http://www.uwyn.com 7170 Manage, Belgium
gbevin[remove] at uwyn dot com Tel +32 64 84 80 03
PGP Fingerprint : 4E21 6399 CD9E A384 6619 719A C8F4 D40D 309F D6A9
Public PGP key : available at servers pgp.mit.edu, wwwkeys.pgp.net
_______________________________________________
Rife-users mailing list
[email protected]
http://lists.uwyn.com/mailman/listinfo/rife-users
