On 08/08/2007 02:00 PM Derick Rethans wrote: > On Tue, 7 Aug 2007, Kore Nordmann wrote:
>> 1) Indication of supported mechanism in backend handlers. > If you mean the capabilities with this, I think the interface parts are > not going to work here - and making empty interfaces just sounds > strange. So I would go for option 3: bitfield. Yes, that was my intention, too. If we define the bit values in the derived classes, we also have easy extensibility given. >> 2) Selection of best transport handler for requesting client. > In your example code I see that the user has to register the transports > - just like with the Document design I don't think users should > generally be bothered with this. So for the default supported clients we > should pre-register them. As for the canParse() bit - I think that would > be better then just a regular expression. The Feed (hehe) component does > do something similar. As with Document, I disagree with you on the transport registration issue. We don't force people to use our autoload mechanism, but they may do so and if they want to, we provide them with a bootstrap file they can include. Why not go the same way in both components? Provide the handlers, provide the registration methods, allow the user to register them manually (e.g. in case he only needs some of them or wants to use own instead of ours) and offer a boostrap mechanism for adding all shipped ones (e.g. a static method). Kore and me actually agreed that to have all shipped handlers registered by default and to offer manual register()/unregister() methods can be a sufficient way to go, AFAIK. What about that? Regards, Toby -- Mit freundlichen Grüßen / Med vennlig hilsen / With kind regards Tobias Schlitt (GPG: 0xC462BC14) eZ Components Developer [EMAIL PROTECTED] | eZ Systems AS | ez.no -- Components mailing list [email protected] http://lists.ez.no/mailman/listinfo/components
