> Anyway, as you can see, the correct behavior in this case is to replace > the `address' mixin-view-field with the `address' scaffold field, > because the latter is true-inline (see test > `get-object-view-fields.direct-shadow-proper-mixin'). At the moment FOF > does the wrong thing when presented when a non-true-inline of a name > appears after a true-inline of a name, but the real question is how do > we maintain the primacy of true-inline fields versus mixins
Looking at get-object-view-fields.direct-shadow-proper-mixin -- the test case seems a bit contrived. What's the use case for specifying a mixin directly followed by an inline of the same name? Does this test something non-obvious? > while also allowing mixin-parameterization of inherited true-inlines? What do you mean by mixin-parameterization? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "weblocks" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/weblocks?hl=en -~----------~----~----~----~------~----~------~--~---
