Hi, Mario, Happy New Year!
I certainly did think about your suggestions. And I am not the least surprised that you immediately want to implement a composite. You do seem to be in love with the Composite pattern! :-)
But here is where I drew the line. I think we are talking about entirely different use cases.
My use case is a user who has to talk to a particular non-"standard" FTP server. He already knows or can easily discover its properties. He wants to write a program (or Ant Script, once Ant supports the new FTPClientConfig way of doing things) and that is that. Runtime discovery of the properties of the server he is working with are not the point for such a user and will only slow his application down. Such a user doesn't even need the system-type autodetection, let alone a composite. Configuration via calls to a few String setters fits within this scenario. Configuration via passing objects around does not. ike Ant should not have to create parser objects in order to use commons-net for its ftp task.
I presume that your use case is the use case of VFS, although I must admit that I really don't understand its utility. I'm not sure what problems this vastly self-configuring parser solves. But that is really beside the point.
In any case, the autodetection mechanism you need could be built outside of commons-net as well as within it. There is the method FTPClientConfig.getSupportedLanguageCodes() to help you query the capabilities of the system. You could use it to build an array of SimpleDateFormats and build some sort of scheme to iterate through the whole bunch, trying each one in order, or whatever you want to do.
That is the approach I would recommend to you. The point is that your use case and my use case are different, and I can't implement yours without making the FTPClient more unwieldy and more confusing for the user than I want it to be.
But there is also a second possibility. There is nothing preventing you from building your system as an alternative WITHIN the commons-net package structure, if working through the default FTPClientConfig mechanism is too prosaic for your tastes:
First, note that FTPClient itself now implements the new Configurable interface. You could define a composite version of FTPClientConfig as an extension of FTPClientConfig and define alternative factory class other to DefaultFTPEntryParserFactory, and specify this in the FTPClient.configure() method itself.
if (config instanceof SuperDuperFTPClientConfig) {
__parserFactory =
Class.forName(((SuperDuperFTPClientConfig)config).getFactoryClass()).
newInstance();
}Then initiateListParsing() would invoke your factory instead of the default one which could do whatever you need it to do. Actually, you don't even need and FTPClientConfig in order to do that, you could just call FTPClient.setParserFactory().
My logic is simple, and works for my use case. The composite pattern previously introduced made developing the Configurable setup harder than it needed to be. It wasn't until I realized that users in my use case neither needed nor wanted any autodetection, that I was able to cut the cord. Take a look at the changes I had to make to DefaultFTPFileEntryParserFactory to accomodate your Composite patterns and the new ones. That's as far as I want to go in that direction. If you want different functionality, you should develop your own factory. That's what the FTPFileEntryParserFactory interface is for.
So to reiterate, I see two options. 1) work within the current setup from the outside, passing in FTPClientConfigs and build your composite detection scheme outside of Net or 2) write your own Parser Factory and possibly FTPClientConfig subclass and then, with just a small change to the current system, you could hook your factory in with the logic you need, unencumbered by the restrictions of the old system.
If I still don't have enough hooks for you, I can consider ways of building them in. And some further refactoring - extracting interfaces, if that buys you anything. Try either approach and let me know where the bottlenecks are. We can certainly make changes.
But I won't be willing to change the default FTPClientConfig to pass objects more complicated than strings around. It confuses the issue of my use case and violates the simple and clear design of the class which is a simple container of configuration strings.
Mario Ivankovits wrote:
Hi Steve!
Lot of work!
But there is one thing is miss. After a first look at your checkins it seems it is not possible to replace the FTPTimestampParserImpl by a custom implementation.
It would be nice to have this to build a CompositeFTPTimestampParser which is able to hold multiple FTPTimestampParserImpls configured for a couple of languages one has to deal with. You know ;-) I would like to "guess" the right one.
I know you are against this strategy ...
Said that I would like to suggest to change the FTPClientConfig to not to hold the configuration of the TimestampParser but to hold a already configured TimestampParser.
Lets speak in meta-code:
TimestampParser europeTimestamps = new SimpleDateTimestampParser(); europeTimestamps.setRecentDate(lsjgklsjgdkl); . . FTPClientConfig conf = new FTPClientConfig(NT); conf.setTimestampParser(europeTimestamps);
That way any parser could be written without having to "ignore" the default configration strategy.
Just an idea!
--- Mario
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
