Hmm, from all your comments it seems you have pointed out that the best solution would be for types to have no knowledge whatsoever of refids. Of course this is not possible under the gaze of the BC monster. We could always start the mythological Ant 2 after 1.7 to apply the learning of the past several years. I'll keep thinking about this, though.
-Matt --- Dominique Devienne <[EMAIL PROTECTED]> wrote: > > From: Matt Benson [mailto:[EMAIL PROTECTED] > > > > Ever noticed that every Ant type that supports the > > id/refid pattern must include a load of custom > code? > > Why? Wouldn't it be possible in UE to check all > > DataType subclass elements for refid, validate no > > other attributes/elements/nested text, and > substitute > > the actual object? It doesn't appear that > DataType > > supports Locations so that wouldn't be an issue. > Who > > can point out any flaws in this approach? > > That's how it should have been in the first place > ;-) > > Would you change the data types' code to remove the > checks > and setRefid() methods? If not (for obvious BC > reasons), then > what should be the behavior between the old and new > way to > deal with refid? > > Also, the old "in code manual checks" of dealing > with refid > works even programmatically (like in <script>), when > the new > one works only thru the framework. For new DataType > without > a setRefid() method, that's not an issue, but for > older code > I don't know how to handle it. --DD > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
