Sitting at mobile phone so just a short opinion - starting on wiring
descriptions, possibly introducing xml to hold it would get us very
close to eclipse extension points except that we are using the service
registry directly, and are more flexible through a real whiteboard
pattern. something to consider?
On 2/15/07, David Leangen <[EMAIL PROTECTED]> wrote:
> >> 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
>
_______________________________________________
general mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/general
