Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Invalid
    • Affects Version/s: 4.0
    • Fix Version/s: 4.1.2
    • Component/s: Framework
    • Labels:
      None

      Description

      I have a contrib:tableRows component that binds the EvenOdd class like this:

      <component id="tableRows" type="contrib:TableRows">
      <binding name="class" expression="beans.evenOdd.next"/>
      <binding name="row" expression="currentRow"/>
      </component>

      However the evenOdd class was never getting instantiated/processing on each row in the table.

      I looked into my .html page and noticed that I had something like this:

      <tr jwcid="tableRows" class="odd">

      but when I took the class attribute out of my html the evenOdd bean got instantiated and processing. So it looks like there is an issue of binding a bean to an attribute if it already exists in a .html page. This page is part of an app I am migrating from 3.0, in which the evenOdd bean processed properly with the class attribute in the .html page.

      Is this an issue with contrib:tableRows or bindings in general if you attempt to bind to an html attribute that is already set?

      scott

        Activity

        Hide
        Kent Tong added a comment -

        It is a bug with bindings in general. The problem should be in ComponentTemplateLoaderLogic. If a binding is specified in both the template and the specification, the validate() method should return false, but at the moment it is only checking conflicts between informal parameters in the template and formal/reserved parameters, so it is returning true.

        public class ComponentTemplateLoaderLogic
        {

        private boolean validate(IComponent component, IComponentSpecification spec, String name,
        IBinding binding)
        {
        // TODO: This is ugly! Need a better/smarter way, even if we have to extend BindingSource
        // to tell us.

        boolean literal = binding instanceof LiteralBinding;

        boolean isFormal = (spec.getParameter(name) != null);

        if (isFormal)
        {
        if (component.getBinding(name) != null)

        { // Literal bindings in the template that conflict with bound parameters // from the spec are silently ignored. if (literal) return false; throw new ApplicationRuntimeException(ImplMessages.dupeTemplateBinding( name, component, _loadComponent), component, binding.getLocation(), null); }

        return true;
        }

        if (!spec.getAllowInformalParameters())

        { // Again; if informal parameters are disallowed, ignore literal bindings, as they // are there as placeholders or for WYSIWYG. if (literal) return false; throw new ApplicationRuntimeException(ImplMessages.templateBindingForInformalParameter( _loadComponent, name, component), component, binding.getLocation(), null); }

        // If the name is reserved (matches a formal parameter
        // or reserved name, caselessly), then skip it.

        if (spec.isReservedParameterName(name))

        { // Final case for literals: if they conflict with a reserved name, they are ignored. // Again, there for WYSIWYG. if (literal) return false; throw new ApplicationRuntimeException(ImplMessages.templateBindingForReservedParameter( _loadComponent, name, component), component, binding.getLocation(), null); }

        return true;
        }
        }

        Show
        Kent Tong added a comment - It is a bug with bindings in general. The problem should be in ComponentTemplateLoaderLogic. If a binding is specified in both the template and the specification, the validate() method should return false, but at the moment it is only checking conflicts between informal parameters in the template and formal/reserved parameters, so it is returning true. public class ComponentTemplateLoaderLogic { private boolean validate(IComponent component, IComponentSpecification spec, String name, IBinding binding) { // TODO: This is ugly! Need a better/smarter way, even if we have to extend BindingSource // to tell us. boolean literal = binding instanceof LiteralBinding; boolean isFormal = (spec.getParameter(name) != null); if (isFormal) { if (component.getBinding(name) != null) { // Literal bindings in the template that conflict with bound parameters // from the spec are silently ignored. if (literal) return false; throw new ApplicationRuntimeException(ImplMessages.dupeTemplateBinding( name, component, _loadComponent), component, binding.getLocation(), null); } return true; } if (!spec.getAllowInformalParameters()) { // Again; if informal parameters are disallowed, ignore literal bindings, as they // are there as placeholders or for WYSIWYG. if (literal) return false; throw new ApplicationRuntimeException(ImplMessages.templateBindingForInformalParameter( _loadComponent, name, component), component, binding.getLocation(), null); } // If the name is reserved (matches a formal parameter // or reserved name, caselessly), then skip it. if (spec.isReservedParameterName(name)) { // Final case for literals: if they conflict with a reserved name, they are ignored. // Again, there for WYSIWYG. if (literal) return false; throw new ApplicationRuntimeException(ImplMessages.templateBindingForReservedParameter( _loadComponent, name, component), component, binding.getLocation(), null); } return true; } }
        Hide
        Jesse Kuhnert added a comment -

        I think this behavior is actually correct. That component probably has inherit-informal-parameters set to true, which is what you've done. Not allowing the informal parameter to be set would be an even bigger issue. I see no other way to do this.

        Show
        Jesse Kuhnert added a comment - I think this behavior is actually correct. That component probably has inherit-informal-parameters set to true, which is what you've done. Not allowing the informal parameter to be set would be an even bigger issue. I see no other way to do this.

          People

          • Assignee:
            Jesse Kuhnert
            Reporter:
            Scott Walter
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development