Hi Steven,
I think this is a pretty good recommendation.
Flowlinks and datalinks need to refer to two elements at the same
time, so they go in the XML where both of the element names are
close at hand.
The nice thing about declaring them with annotations though is that
you can provide them with a destination class instead of a
destination id. This makes the links typed and allows things like
refactoring to work 'out of the box'.
Submissions seem like the biggest no-brainer for using annotations.
They are completely private to a particular element; no outside
element can get at them or needs to know anything about them. (As
far as I can tell, anyway -- is that correct?)
That is totally correct.
I ran into a big problem though with annotations and submissions,
pointed out to me by JR. The way it's currently setup is that
parameters, submission beans, files are added to the last submission
that was declared. This can either by through class-level @Submission
annotations, or by method-level @SubmissionHandler annotations. When
using property setter annotations for the parameters, submission
beans and files, using the @SubmissionHandler annotation is probably
much more convenient. Sadly though it turns out that Java reflection
isn't able to provide you with methods of a class in a predictable
order. Hence, the order of the methods in Class.getDeclaredMethods
can be different from your class layout, and it can even change from
JDK to JDK. This totally invalidates the usefulness of 'adding to
last declared submission' since you're never sure what the 'last
submission is'. When you work with one submission, you can still
declare it as a class level annotation, however when using multiple
submissions, there seems to be no way to easily use annotations on
property setters for the data structure of the submissions.
I don't really know what the 'best' solution is. Without resorting to
hacks, I can only come up with the introduction of the submission
name for each parameter, submission bean and file property setter. I
don't like that much though. When resorting to hacks, it should be
possible to make RIFE actually inspect the element class bytecode and
find all the methods names in the order that they were compiled. This
can then be used to iterate over them when processing the
annotations. However, I'm not sure what the contract is for the
method order in bytecode. It might not even be the same as the method
order in source.
Any thoughts on this?
The URL is in the XML because the element doesn't need to know
anything about it. On the other hand, neither do other elements, so
that one could easily go either way -- but to me it seemed more
like "site structure" than "element details."
Exits are in annotations even though other elements need them
because code needs them too,
Not sure I follow you here, what do you mean by "because code needs
them too". Exits are only related to a particular element, flowlinks
tie elements together though.
and the ability to use compiler-checked string constants for both
the element declaration and my exit() calls seems helpful to me.
Once I started using string constants as above,
I like that approach a lot, didn't think of it. I think I'll use it
too ;-)
I started wondering if it would eventually be possible to get rid
of the XML and use annotations and/or regular Java code to do the
entire site declaration. Just point RIFE at a bootstrap class and
it takes it from there. You'd get compile-time sanity checking and
IDE support from top to bottom. No more need to spell out your
fully-qualified class names in XML files -- just refer to the Class
objects. Not sure if I actually think that's a good idea, or for
that matter if it's even possible as things stand now, but the idea
of reducing repetition and pushing stuff into Java code seems very
RIFE-like in theory.
First, RIFE fully supports you declaring your elements and site
structure in Java only (without any XML). You can find more
information here: http://rifers.org/wiki/display/RIFE/Site+structure
+and+element+declaration+without+XML
These builders are actually exactly what is used behind the scenes by
the XML processor, they are also what I use in the hierarchical site
building experiment that I posted yesterday.
Your idea of pointing RIFE to one bootstrap class and following the
links is very interesting. I'm not sure about its usefulness in real
life though. Many of the sites I work on have a lot of 'isolated'
pages, without flowlinks or datalinks. Most of the time there are
globalexits though, but they are totally external from the elements
and declared on a site-structure level. I'm not sure if it would be
good to introduce a new way of pulling in elements, based on that. In
the end, it might become too complex and difficult to understand what
really goes on.
Take care,
Geert
--
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
Rife-users@uwyn.com
http://lists.uwyn.com/mailman/listinfo/rife-users
