Click
  1. Click
  2. CLK-373

Control properties are not automatically solved!

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 1.5 M1, 1.4.2
    • Fix Version/s: 1.5 M2
    • Component/s: None
    • Labels:
      None

      Description

      It looks like properties (i18n ones) are not autmatically solved for
      (custom)Controls, the same way as for Pages:
      E.g. for CustomForm.java
      -----------
      public class CustomForm extends Form {
      public CustomForm(String name)

      { super(name); buildForm(); }

      private void buildForm()

      { TextField snfld = new TextField("snfld"); this.add(snfld); }


      }
      -----------

      and CustomForm.properties :
      -----------
      snfld.label=Special Name
      snfld.title=Enter the special name!
      -----------

      When using this control from a page, those properties are not automatically
      solved. It's done only when not using that Control but a standard Form with
      the fields added there(in the page code), and the properties in a file with
      the same name as the page.

      This makes very hard to reuse i18n Form code (e.g. reuse the same Form in
      view-xxx.htm in readonly mode, in edit-xxx.htm, in add-xxx.htm, of in other
      special-cases-xxxx.htm) and I think this is critical.

      Thank you,

      Demetrios.

        Activity

        Hide
        Demetrios Kyriakis added a comment -

        Attached is a complete example:
        From the index.html you can see the two cases (forms): one that works and one
        that doesn't (but it should, since only so the Click Controls are "self contained", "re-distributable", and most important: "reusable").

        Issue created on request in this discussion:
        http://thread.gmane.org/gmane.comp.web.click.user/2183

        Show
        Demetrios Kyriakis added a comment - Attached is a complete example: From the index.html you can see the two cases (forms): one that works and one that doesn't (but it should, since only so the Click Controls are "self contained", "re-distributable", and most important: "reusable"). Issue created on request in this discussion: http://thread.gmane.org/gmane.comp.web.click.user/2183
        Hide
        Bob Schellink added a comment -

        Thanks for the detailed sample Demetrios.

        The main limitation is ClickUtils#getParentMessages which only returns the top parent messages. So if you have Page -> Form -> Field, getParentMessages will return the Page messages, ignoring Form messages. To improve this we could grab the Form messages on our way to the top. However this does impact performance and memory.

        Alternatively we can introduce a new method getParentMessage(control, name) which checks each control in the hierarchy if it contains the name. When found it keep scanning up the hierarchy and higher level controls and Page override the lower level messages. Example impl:

        public static String getParentMessage(Control control, String name) {
        if (control == null)

        { throw new IllegalArgumentException("Null control parameter"); }

        if (name == null)

        { throw new IllegalArgumentException("Null name parameter"); }

        Object parent = control.getParent();
        if (parent == null)

        { return null; }

        else {
        String message = null;
        while (parent != null) {
        if (parent instanceof Control) {
        control = (Control) parent;
        if (control != null) {
        if (control.getMessages().containsKey(name))

        { message = (String) control.getMessages().get(name); }

        }
        parent = control.getParent();

        if (parent == null)

        { return message; }

        } else if (parent instanceof Page) {
        Page page = (Page) parent;
        if (page.getMessages().containsKey(name))

        { message = (String) page.getMessages().get(name); }

        return message;

        } else if (parent != null)

        { // Unknown parent class return null; }

        }
        }
        return null;
        }

        Show
        Bob Schellink added a comment - Thanks for the detailed sample Demetrios. The main limitation is ClickUtils#getParentMessages which only returns the top parent messages. So if you have Page -> Form -> Field, getParentMessages will return the Page messages, ignoring Form messages. To improve this we could grab the Form messages on our way to the top. However this does impact performance and memory. Alternatively we can introduce a new method getParentMessage(control, name) which checks each control in the hierarchy if it contains the name. When found it keep scanning up the hierarchy and higher level controls and Page override the lower level messages. Example impl: public static String getParentMessage(Control control, String name) { if (control == null) { throw new IllegalArgumentException("Null control parameter"); } if (name == null) { throw new IllegalArgumentException("Null name parameter"); } Object parent = control.getParent(); if (parent == null) { return null; } else { String message = null; while (parent != null) { if (parent instanceof Control) { control = (Control) parent; if (control != null) { if (control.getMessages().containsKey(name)) { message = (String) control.getMessages().get(name); } } parent = control.getParent(); if (parent == null) { return message; } } else if (parent instanceof Page) { Page page = (Page) parent; if (page.getMessages().containsKey(name)) { message = (String) page.getMessages().get(name); } return message; } else if (parent != null) { // Unknown parent class return null; } } } return null; }
        Hide
        Demetrios Kyriakis added a comment -

        > Thanks for the detailed sample Demetrios.
        You are welcome. I wish it would be faster to "generate" click applications - to be able to send usable test cases for other problems aswell (right now it seems to take too much, and the quick-start template is not very usable due to the roles mess).

        > The main limitation is ...
        > ...
        > Alternatively we can introduce ....
        > ...
        I don't know how to implement or what are the internals of Click but, I know that the desired behavior is very very important - it is critical:

        • without it the users has to write up to 4 or 5 times more code (mostly duplicated and prone to copy and paste errors). For i18n intensive applications this is even worse.

        Please solve this issue to be able to have fully reusable i18n controls.

        Thank you,

        Demetrios.

        Show
        Demetrios Kyriakis added a comment - > Thanks for the detailed sample Demetrios. You are welcome. I wish it would be faster to "generate" click applications - to be able to send usable test cases for other problems aswell (right now it seems to take too much, and the quick-start template is not very usable due to the roles mess). > The main limitation is ... > ... > Alternatively we can introduce .... > ... I don't know how to implement or what are the internals of Click but, I know that the desired behavior is very very important - it is critical: without it the users has to write up to 4 or 5 times more code (mostly duplicated and prone to copy and paste errors). For i18n intensive applications this is even worse. Please solve this issue to be able to have fully reusable i18n controls. Thank you, Demetrios.
        Hide
        Bob Schellink added a comment -

        fix checked into trunk

        Show
        Bob Schellink added a comment - fix checked into trunk

          People

          • Assignee:
            Bob Schellink
            Reporter:
            Demetrios Kyriakis
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development