Hi Steven,
Providing a warning is indeed a solution to indicate to people that
there is an ambiguity, but in general RIFE tries to log nothing
informational. Personally, I find it very annoying to have to wade
through a bunch of logs to discover the reason behind something.
Also, often this stays turned on during production and you get these
huge logs with informational messages that are not that useful at
all. However, I have doubts about the usefulness during development
also. Just imagine that you have a site with many elements that are
re-used across it. This means that you constantly keep seeing these
messages whoosh by. One additional message will most probably be
lost, instead of being noticed.
At one point I did think that it might be interesting to start from
the local scope and then extend outwards to find the element ID that
one might be referring to. However, I'm not sure that this is very
comfortable for the developer because this introduces the concepts of
one element being 'nearer' than the other. I think that this is
probably not the same for everybody and might even be different
according to the site structures that people adopt. It's potentially
very confusing and arcane to understand why a certain element was
chosen.
This is why I proposed to simply refer to the first element that's
declared in the site and then allow people to specify a specific one
or to point to a certain sub site when ambiguity needs to be
resolved. However, this potentially creates other problems. It might
be working in your own application, but when you package it up and
integrate it elsewhere or even pull in another package sub site in
the beginning of your declarations, you might have the same element
that's declared earlier than the one that was detected before. This
could cause your entire site to break.
So, I'm now more tempted to leave this functionality as is, and just
allow people to point to specific sub sites when the destination
class functionality is used. Actually, this makes a lot of sense
because when they have elements that are included in other sub sites,
they manually created those sub sites and gave them IDs. By default,
if they do nothing and just use the elements to build up a flat level
application, they will all be part of the same sub site, and the
destination class functionality will just work.
Examples of re-used elements are many, most of the elements that ship
with RIFE are actually reused by people in many places: like printing
templates, creating Web services, providing Ajax functionality,
authenticating against several roles, ... In sites that we develop,
we have for example flexible product pages or check out processes
that can be customized with properties. We include those all over the
site.
To summarize, I think I'll just settle on adding an additional
annotation attribute to specify the sub site ID.
Best regards,
Geert
On 02 Jul 2006, at 18:41, Steven Grimm wrote:
That would cover my use case, certainly. So far I am using each of
my elements exactly once.
Maybe there should be a warning logged if there's more than one
match for a given class, just in case people include the same
element in several places. I wouldn't mind having to use an ID if
there was ambiguity about which element I meant.
This is probably what you have in mind already, but it should use
the first element declared with the destination class in the
current subsite, *then* search other subsites. I bet most of the
time if you use the same element in multiple places you will want
to refer to the local one. Plus that makes the system keep working
as it does today if you're referring to local instances of elements.
What are some examples of places where you'd want to use an element
in multiple subsites? About the only case I can think of is if you
have an element that should be accessible only by two distinct sets
of users (so you'd put it in two different authentication-required
subsites.) In that case searching the local subsite first would
definitely be the desired behavior.
One other stray thought: To keep the benefit of referring to the
class object while still allowing you to disambiguate, maybe there
should be a way to specify which subsite you want without knowing
the ID of the element. E.g., if your destId points to a subsite
name rather than an element, and there's a destClass, RIFE tries to
search for that class in the given subsite. Or maybe a separate
destSite attribute would be better so as not to overload destId.
-Steve
Geert Bevin wrote:
Hi Steven,
at the moment this is intended behavior by lack of a better
solution. The problem is that for RIFE there is no way of knowing
which element ID you mean when you point it to a destClass. The
element can be included many times, with different IDs and in
different sub-sites.
A solution that I now think of is that instead of just assuming
that the element resides in the same sub-site, that logic could be
changed to selecting the first element declared with the
destination class as its implementation. What do you think? Would
that work? It seems that it would cover most of the things that
people expect when using it.
Best regards,
Geert
_______________________________________________
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
