On Fri, Mar 28, 2008 at 10:31 AM, Xavier Hanin <[EMAIL PROTECTED]> wrote: > On Fri, Mar 28, 2008 at 4:08 PM, Dominique Devienne <[EMAIL PROTECTED]> > > For the record, I think it's bad Ant style to use ids in tasks. [...] > > I think we use that bad pattern. We've been wondering about the best form > settings should take for a while. It used to be a datatype in 2.0 alpha, but > we were running into trouble because a datatype has no lifecycle. Hence in a > discussion Peter suggested to make it a task, using the id as we did before > for the datatype but with a default value: > http://markmail.org/message/52hqry734myzopts
Well, reading Gilles original issue, I agree with your answer Xavier. The "Ant way"(tm) is to have both an id for the <settings> and a settingsRef in <retrieve>. The only reason you'd not have a settingsRef in <retrieve> was to be BC with the deprecated <config> task, and only in this case would you attempt to use a default id to lookup the settings type. If <config> was never executed, i.e. you're not in BC mode, lacking a settingsRef in <retrieve> should be an error right away, and you shouldn't even try to lookup the "default" id. If Ivy was designed like most Ant tasks, all 3 forms below would be equivalent: <retrieve settingsRef="foo" /> <retrieve> <settings ... > ... </settings> </retrieve> <retrieve> <settings refid="foo" /> </retrieve> Where the nested settings is equivalent to the "foo" settings type not shown. The original issue of not being able to error out right away when a <settings> doesn't have an id is not really an issue IMHO. I'd be OK with changing Ant to allow a method to be called on types so that they can self-validate themselves (I also wished for such a method a long time ago), to enable the failure right at the point of definition of the type rather than at the point it's used (well, not used in fact, if you remove the use of a "default" id...). > This works pretty well from a user point of view who don't really know if > it's a task or datatype and don't really care. Except that we run into this > bug, and this bad pattern. So, what would you suggest? Is there something we > could do better while still preserving the behaviour we have now? Well, I don't quite agree here. Even though tasks and types are now much closer in the core code, they still remain different concepts, and are documented in separate sections of the manual. Types are data containers, while tasks are "doers" or actions or verbs. You affect the behavior of a task using inline stuff (attributes, nested elements) which can be types, sometimes defined outside the task itself and simply referenced by id, and the task shouldn't even be aware whether the types are defined "locally" in the task, or outside. In fact, you can even id a type defined "inside" a task, and reference it later by id in another task. Keeping task ids force the core Ant code to jump thru quite a few hoops, which we'd better remove in fact... (but we don't for BC...) So for new code like Ivy, an Ant sub-project even, to be using task ids is not a good thing in my opinion. So I suggest you put back settings as a type, only lookup a default id when you know you are in BC mode (i.e. <config> was used), and otherwise depend on normal uses and rules for ids and types, allowing inline-nested definition of settings. Ant users are used to have to id types they want to refer to in several tasks. Document it as such. Error out in retrieve when so settings are specified, either inline or by ref id. My $0.02. --DD --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
