I filed this in JIRA (bug 285) and Geert suggested I send it to the
mailing list to get others' comments.
This is sort of a followon to bug 269 (about implementing the <autolink>
tag). You could just about eliminate the need for site configuration if
RIFE would automatically discover elements. You would pretty much only
need to declare each entry point of the site in the XML configuration.
Here's one way it could work.
<site>
<element id="home" implementation="com.foo.element.Home" />
<subsite ...> (if you want subsites)
<element ...> (if you want to, you can still explicitly declare
stuff as before)
... other <site> stuff ...
</site>
RIFE scans com.foo.element.Home and finds a couple of "autolink"
annotations, e.g.
@Autolink(srcexit="register")
There is no known element by that name yet, so RIFE searches for a class
with that name in the same package as the linking class, in this case
com.foo.element.Register. If it finds such a class and the class has an
@Elem annotation, the class gets added as an element (and its exits are
evaluated similarly).
That gets you all the elements that are connected via exits from each of
the declared elements. You could take that one step further:
<site package="com.foo.element">
<arrival destid="home" />
<subsite id="members" inherits="AuthMember" />
<subsite id="admin" inherits="AuthAdmin"
package="com.foo.element.admin" arrival="adminMenu" urlprefix="admin" />
<element id="AuthAdmin" ...> (same as the usual auth element) </element>
<element id="otherEntryPoint" />
...
</site>
The home page of this site is the element com.foo.element.Home (it is a
configuration error if that class doesn't exist or isn't annotated as an
element.) It has an authenticated members-only subsite whose elements
are in com.foo.element (they will be discovered by the algorithm above
since there are presumably exits leading from the public site to the
members-only sections). It has another subsite whose elements are in
com.foo.element.admin and whose arrival element is ID "admin.adminMenu"
implemented by class com.foo.element.admin.AdminMenu.
It also has a second entry point whose class is
com.foo.element.OtherEntryPoint. That class will be scanned for
connected peers just like the Home class. This would be needed for parts
of sites that aren't reachable by exits from the arrival pages. (In
practice I'd think that would be pretty rare, but the ability is there.)
This leaves just one class of elements that need to be declared, namely
embedded elements that are never pointed to by an exit. I assume it's
not really an option to have those elements be discovered and added to
the configuration on the fly as they're referenced by elements (though
if it *is* possible, that's the ideal approach). So maybe allow embedded
elements to be listed in the annotations of the classes that use them:
@EmbeddedElement
public static final String ELEM_COMMENT_FORM = "commentForm";
or, in the class's @Elem annotation,
embeds = { @EmbeddedElement(name="commentForm") }
or, if needed, with an implementation class declared (as a class object
so IDE refactoring finds it easily, or as a string):
@EmbeddedElement(implementationClass=com.foo.forms.CommentForm.class)
public static final String ELEM_COMMENT_FORM = "commentForm";
@EmbeddedElement(implementation="com.foo.forms.LoginForm")
public static final String ELEM_LOGIN_FORM = "myCrazyLoginForm";
This proposal does not remove any of the expressive power of RIFE's
configuration. You can still explicitly specify anything you need to,
either in XML or in annotations. (And you still have to configure the
elements themselves via annotations, though with bug 269 that
configuration would get a lot less complex.) It is simply a change in
the way RIFE acquires the same underlying configuration data.
Something like this would mean that for a lot of sites, you can set up a
small configuration once at the start of the development effort and
never touch the central config again as the site expands, while still
getting the advantages of RIFE's loosely-coupled element architecture. A
small config file would be able to describe an arbitrarily complex site.
This would be an especially big win for new developers, who wouldn't
have to muck with unfamiliar config files until they were ready to do
something unusual. ("Get productive right away.")
_______________________________________________
Rife-users mailing list
[email protected]
http://lists.uwyn.com/mailman/listinfo/rife-users
