Nicola Ken Barozzi wrote: > Robert Mouat wrote: > > > This work is given to the assembler: who now has control of both giving > > the transformer it's name (transformer:xslt) *and* telling the component > > what name to lookup (transformer:xslt). > > Ahhhhh :-) > > *Now* I get it more. > > The "telling the component what name to lookup (transformer:xslt)." part > I missed before.
I wasn't sure if having a client component expect this was going to break reusuability (i.e. container independance) -- which is why I was seeking assurances on the role of the assembler yesterday. > Thanks. :-D your welcome. > Could an alternative solution be that the lookup is don on a > TransformerManager that has a lookup(transformername) in it? > (akin to the SocketManager example of Berin) > > Or is this just a recreation of a Selector? It would be a recreation of Selector, but the selector would only need to be used in cases that the assembler couldn't handle -- also the Selector could be a component itself (and hence have arbitrary logic -- by which I mean you could put *any* logic in it, not that the selection would be arbitrary :) I was thinking that you could create a Selector component that received in it's configuration a set of role names and rules for when to use them. e.g. (to borrow from a previous example) selecting a mail server based on email address: a MailServerSelector component could be written to take in a email address and return a MailServar based on the address. You could use it by: MailServerSelector mss = (MailServerSelector) cm.looup( "mail-server-selector" ); MailServer ms = mss.select( emailAddress ); the configuration for the MailServerSelector might look like: mailserver1.roleName=apache-mail-server mailserver1.addressRegex=*.apache.org mailserver2.roleName=default-mail-server mailserver2.addressRegex=* and all the MSS would need to do is read the in rolenames and the corresponding rules from the configuration - then when select() is called it applies the rules until it finds one that works, then looks up the corresponding role name from it's own CM and returns the result. this basically takes Selector out of the framework and makes it something that can be implemented as a component as needed. The above example feels a little contrived -- are there any real use-cases when this might be needed? And will it always be obvious to the component that it will need a selector? Robert. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
