On 1/24/11 6:45 PM, Alex Karasulu wrote:
On Monday, January 24, 2011, Emmanuel Lecharny<elecha...@gmail.com> wrote:
On 1/24/11 4:20 PM, Alex Karasulu wrote:
I've moved all the classes that compose the model into a model sub
package while removing codec dependencies. Next steps:
(5) Apply Decorator to ldap-codec.
I can handle this.
Thanks but I have already begun with files I have yet to commit. Also
with my refactoring it will create many conflicts. So it's probably
best that I handle it at least until some things stabilize.
Thinking again about those decorators :
if you encapsulate all the API objects into decorator, which adds the
internal methods the codec engine needs, then in order to use them you
will have to add a big if ( xxx instance of XXX) then new XXXDecorator(
xxx) else ..., arent you ?
At this point, I think there is another approach that is cleaner. In the
API, we have removed all the computeLength() etc methods from the base
messages, and we are using a dedicated class (LdapEncoder) that acts as
a kind of transformer.
I think we should just implement the missing encodeLength() et all
methods for controls in this LdapEncoder class.
Please give it a look and tell me if it's ok before starting to write
many decorators that might be spurious.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com