Fluid Infusion

Justin Obara added a comment - 14/May/09 10:29 AM Bug Parade 1.1 release

Justin Obara added a comment - 20/May/09 12:15 PM It appears that a class was added during the refactoring before 1.1 "fl-inlineEdit-edit". This has been changed in the themes as well. The only thing left is to make sure that it is included in the styles block in fluid.defaults and programatically added in to the necessary elements. At the moment it appears also that the default template has the selectors hard coded, instead of using the options.

Antranig Basman added a comment - 20/May/09 1:53 PM I have added the "fl-inlineEdit-text" style to the default options. We have looked at the further changes - that is, in feeding through any changes in these styles to the template used for rendering, which currently reads, for example -         var editModeTemplate = "<span><input type='text' class='flc-inlineEdit-edit fl-inlineEdit-edit'/></span>"; The other option, would be to add code to programmatically alter the styles, once rendering was complete. Either option, would, however, represent a big change in policy for this component. As it stands, the "implicit policy" is that the default markup produced, reflects the effect of the default selectors - if any changes are made to the selectors, the renderer should be changed to reflect this, and vice versa.

Anastasia Cheetham added a comment - 20/May/09 3:41 PM I'm re-opening this one, because I think that the style name should not be hard-coded into the default editModeTemplate. Given that it's in the options structure and could be overridden by the user to be a different class name, the class name should be extracted from the option structure and injected into the template. Come to think of it, the same should be true of the flc- class in the same template...

Antranig Basman added a comment - 20/May/09 8:12 PM I believe that the behaviour is now correct as it stands, since to change it would result in a breakage of the component's (implicit) contract up till now - which should not occur without at least one release of announcement/deprecation etc. if possible. This is actually the contract that all components that we have follow, that generate their markup internally - it looks more egregious here since the class is written in a string rather than being generated by the renderer. To be clear - the entire purpose behind allowing selectors to be configurable in components, is to be able to adapt their behaviour to the specific form of the markup which they are supplied. In this case where *no* markup is supplied, that is, the user allows the default renderer to operate, clearly the selectors as they stand are correct! We have *never* advertised that the point of control operates the other way round - that is, that the customisation of components by selectors, can cause an alteration in the markup which they produce. If we start to produce components which operate control in the reverse direction, the direction of control flow amongst the "community" of users using a component becomes unclear, and they could not be given a consistent set of instructions about what to expect from a Fluid component - these would change according to whether it was capable of generating markup or not. So - I argue that the behaviour as it stands now is correct - the ultimate "point of control" rests with the component user who customises the markup it operates on. Only in the case that this markup is changed, should the selectors that the component is configured with change. For this component, the markup may be changed either i) literally, by writing markup in the HTML file, or ii) by customising the "edit mode renderer" - in both of these cases, the hard-coded markup written inside the component is bypassed. The correctness of this reasoning, at least in the case of the "flc" selectors, is also reflected by a logical impossibility - these selectors are "free", in that the user may customise them to any value. However, it is not possible to write a closed-form implementation of the edit mode renderer which is capable of matching all user choices. This verifies that the "flow of control" properly passes from markup customisers to component customisers, and not the other way round.

Anastasia Cheetham added a comment - 21/May/09 9:17 AM Antranig's explanation of this makes complete sense to me (I'm easily convinced by good arguments). I will stress that this needs to be documented clearly, but I agree that the current behaviour is correct.

Justin Obara added a comment - 21/May/09 10:30 AM Verified fix using: FF2, FF3, Opera 9.6, Safari 3.1 (Mac OS 10.5) IE 7, IE 8, FF3 (Win Vista)