Message:
A couple thoughts
Posted by Bill Venners on September 21, 1999 at 8:46 PM
createUI() is OK by me rather than getUI(). I'll check to see
if that's an idiom in the Java APIs. I don't remember offhand. > It might also be nice to require all UIs to fit a certain interface instead of relying entirely on the Entries to describe their purpose.
>
I'm not sure I understand what you mean here. The function
String in the Entry is to facilitate selection of a UI based
on its intended use. This allows you to discover something
about a prospective UI before you create it with the factory
method. I would think the interface would state how you use a UI, not
what it's intended use is for, unless you come up with tag
interfaces that indicate uses. But then you'd have to create the UI
object before you could see what tag interfaces it implements,
which isn't very useful for searching for UIs. Perhaps I'm
missing your point. > Also, should it be required that all Entries go into a package under org.jini.ui? Could they just be registered at runtime in some way instead? (Or maybe I'm just not familiar enough with the requirements. I'm not a Jini buff.)
>
This is a good point. I think you may be right here. We were
trying to avoid naming conflicts, but I think (taking the
IBM example from the article) that IBM should be able to
come up with a unique name for their entries that they advertise.
Such as plain old com.ibm.ui.vng.VoiceAndGraphicsFactoryEntry,
and it won't conflict with any other names. On third thought, what if IBM doesn't create that entry? What if
some third party wants to use the com.ibm.ui.vng.VoiceAndGraphics
class in making a UI for their Jini service in the absence
of any Entry defined by IBM? The third party can't just decide
on com.ibm.ui.vng.VoiceAndGraphicsFactoryEntry, because they
aren't IBM. But if we say what the proposal currently says,
then any party could make a FactoryEntry for any
UI class and stick in in a package where clients will be
expecting to find it. I guess I could update the proposal to
reflect this scenario, which seems to better justify the approach
described in the proposal. Also, if a client knows they would like to look for an entry
for a UI for some class, say com.fred.flintstone.CaveArt class,
they would know what the fully qualified name of the factory
entry would be without having to call fred.com and ask. They'd
just prepend the com.fred.flintstone.CaveArt with the
appropriate prefix, and append "FactoryEntry". This would seem
to make it easier for clients to use. > Serviceui sounds good, though, based on the info in JavaWorld. I'm impressed. I like decent standards. Thanks for your feedback. Thoughts? bv
Replies:
|
