>> Ok, sounds reasonable. So you want to have hard-coded, pre-
>> compilation values, is that it?
>
> Well, we are not abandoning the runtime aspects at all. Everything
> can still
> be changed in runtime, for instance Assume that you have three
> menus, "m1", "m2" and "m3" defined as ContentAggregators. Now, if
> you create
> a MenuItem (which is a ContentSource) as "Logout" and originally
> has the
> Destination array being { "m1.Logout", "m3.Logout" }, then the Logout
> menuitem will be wired to "m1" and "m3". Configuration Admin allows
> for
> arrays, so by changing the "Destination" array to
> { "m1.Logout", "m2.Logout" } you will remove the menu item from
> "m3" and add
> it to "m2".
Ok, makes sense.
>> Then an array as you suggested would work. Or, if you want to be even
>> more explicit, you could maybe use a hashmap so that the user can
>> also add a small description or something. I guess a full-blown class
>> would be overkill in this case.
>
> Are you suggesting that the "wire" contains additional description,
> or is it
> enough if we add localized description support for the ContentSource
> instances?
Nah, I'm not "suggesting" anything, as somebody once told me. ;-)
I was just saying that if there is a possibility that a developer (or
better yet a developer taking over somebody else's code) can be
confused by an entry for an aggregation point (and I can see a strong
possibility of such confusion happening), then one possibility could
be to add a description, probably closer to a comment than anything
seen by a user, that could accompany each wire entry so that it's
easier to figure out what the intention was.
The problem I foresee is that since there is no strong typing (and
hence no IDE tools for the foreseeable future) this new developer may
have a difficult time tracking down the Aggregator that accepts this
wiring, or figuring out the intent of the original developer. This
was one of the problems I encountered when trying to get used to
using pax-wicket. I couldn't easily figure out what was wired to what
even in existing, working code. This is compounded when similar IDs
are used in different places.
So, the intent of this suggestion is probably good... but then again,
maybe this is completely the wrong place to hold such comments...
Or maybe, as we discussed at one point, it would just be more
appropriate to use a full-blown object, since an object is much more
descriptive, allowing the developer to understand more easily what's
going on, IMHO.
Cheers,
Dave
_______________________________________________
general mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/general
