Hi Steven,
I like the ideas that you present here and only have a minor comment.
Maybe you're not aware of this, but as for the declarations, you can
use a variety of languages to provide the implementations of your
elements, as long as they run on the JVM. So maybe we should use
another term instead of "package", but then again it does seem
totally appropriate to use it for this mechanism, guess I'm not sure
about it.
The implementation of this feature will take quite a long time
because the current site builder hasn't got the required capabilities
to do this. Sadly, I will not be able to dedicate time to this before
three months.
Best regards,
Geert
On 28 Jun 2006, at 21:09, Steven Grimm wrote:
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
--
Geert Bevin
Uwyn "Use what you need" - http://uwyn.com
RIFE Java application framework - http://rifers.org
Music and words - http://gbevin.com
_______________________________________________
Rife-users mailing list
[email protected]
http://lists.uwyn.com/mailman/listinfo/rife-users
