Hi Sim! Ok, Unfortunately I generally have an opposite opinion on some items you descri...
1st thing my opinion differs from yours in case of the tree - I think the tree should contain nearly everthing, for XML-files hava a tree structure - ever opend an .xml in MS Internet Exporer 5.x ? Do you know the netbeans IDE? Everything is in the tree, and people are used to it! It would be nice if Antidote look familiar ;-)! 2nd: You say that we need ACSElements for EVERY Task - IMHO This would be a mess for Antidote :-(. Nobody (or at least I don't ;-)) wants to implement an ACSElement everytime a new Task has been submitted! I'd propose to become MORE generic! Ok, tasks to not implement a FileSetUser interface OSTLT, but we can ask targets yia reflection if they have a "addFileset", "createInclude", "setIncludes", "createExclude", "setExcludes" method and we can find attributes by looking for set-methods... It'll be hard, but possible - and it is a chance! And of course for there are no conventions this will not cover EVERY case but 90%+, I hope! I'd like to hear what others say... :-)! Greetings, Chris Here is what Simeon wrote: > I had a side discussion what to implement next in Antidot; Sim pointed out > that filesets are still missing, so here is my proposal! > > 1st: I think we need at least one new ToolbarButton/ContextMenuItem: New > Fileset (or something like that, wich just is enabled when a node is > activated where fileset is a valid option. To make this possible we will have to start creating ACS classes with their associated BeanInfo classes for each of the tasks. Right now all tasks are covered by a generic ACSTaskElement class, which treats all tasks the same (as attribute containers; not very elaborate). It's probably time to start providing more sophisticated editing of each of the tasks. This, unfortunately, is where Antidote would have benefited from a more consistent set of API conventions in the task implementations. Obviously we will run up against maintenance issues as tasks change and evolve over time. It's too bad that the tasks that use filesets don't implement a "FileSetUser" interface (or the like). > Do we need another > Button/MenuItem for "Add Include" or should this function should > be provided > by the PropertyEditor??? My current feeling is that it should be done via a property editor, requiring us to have a fileset type that is referenced in the appropriate BeanInfo classes. But I'm somewhat on the fence with this one. I certainly don't think you should be able to add filesets to things that shouldn't have them, and the best way I can think of right now to limit that is via the BeanInfo approach. > > 2nd: An extension of the project tree is needed: > > project > | > +-property > | | > | +-fileset > | | > | +-property/include > | > +-target > | > +-task > | > +-fileset > | > +-property/include If the fileset is represented as a class like "ACSFileSetElement", then this comes for free. But I'm also on the fence here as to whether that is just too much detail in the tree view. Already I think showing properties in the tree view is not a good idea (and some other mechanism is needed), and I feel that adding filesets will make it even more unmanageble. It all really depends on how good a fileset property editor ends up being. > > 3rd: The PropertyEditor can look like the task-propertyeditor. Version 1 yes (that's where a generic Object[] editor would help). I think later it would be nice to extend it to help with glob generation and path selection. > > BTW: Can one Task/Property contain multiple FileSets? It it can, should we allow it? > > Implementation: > New Ant Construction Set Elements: > ACSFilesetElement (similar to ACSTaskElement) > ACSIncludeElement (similar to ACSPropertyElement) > and the BeanInfoClasses belonging to the Elements > PropertyEditors: > IncludesPropertyEditor Probably FilesetPropertyEditor instead, which takes care of adding the includes/excludes to the fileset. > Command Classes: > NewFilesetCmd > NewIncludeCmd If adding these is done via a property editor, they probably aren't needed. > Events: > NewFilesetEvent > NewIncludeEvent Looks good to me, although I'd go ahead and add exclude as well. Thanks, sim --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
