Spring Roo
  1. Spring Roo
  2. ROO-345

support for embedded in Web scaffolding

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 1.0.0.RC2
    • Fix Version/s: None
    • Component/s: WEB MVC
    • Labels:
      None

      Description

      Fields with @Embedded annotation could have better form generation in Web scaffolding.

      for example when we have :

      @Entity
      @RooJavaBean
      @RooEntity
      public class User {
      ...
      @Embedded
      private Address address;
      ...
      }

      @Embeddable
      @RooJavaBean
      public class Address {
      private String city;
      ...
      }

      Then generated jspx form in User be something like :

      <form:input path="address.city" .../>

        Activity

        Hide
        Ken Rimple added a comment -

        I also have a similar request. It turns out that if you use the same embedded twice, ala shipping and billing address, you only get one scaffolded set of fields, with the property name rather than Roo digging into the mapped property name. Example :

        @RooJavaBean
        @RooToString
        @RooEntity
        public class Student extends Person {
        	
        @Embedded
          @AttributeOverrides({
            @AttributeOverride(name = "addressLine1", 
                column = @Column(name = "billing_address_line_1")),
            @AttributeOverride(name = "addressLine2",
                column = @Column(name = "billing_address_line2")),
            @AttributeOverride(name = "city", 
                column = @Column(name = "billing_city")),
            ... 
            })
            private Address billingAddress;
        	
            @Embedded
            @AttributeOverrides(value = {
                @AttributeOverride(name = "addressLine1", 
                    column = @Column(name = "shipping_address_line_1")),
                @AttributeOverride(name = "addressLine2",
                    column = @Column(name = "shipping_address_line2")),
         	...
            })
            private Address shippingAddress;
        	
        ...
        }
        

        The resulting scaffold treats the objects as single fields...

        <field:input field="billingAddress" 
           id="c_org_rooina_coursemanager_model_Student_billingAddress" 
           z="UR5h0XlNcD12TAH2KJ2uqdSWNqg="/>
        <field:input field="shippingAddress" 
           id="c_org_rooina_coursemanager_model_Student_shippingAddress" 
           z="nPedkI9sdZUa4C0S8a2qxKWFv/E="/>
        

        It would be great if the scaffolding wound out the embeddeds into actual fields, and used the attribute overrides to introspect what the actual field names will be. I guess the on-screen field names could be prefixed by the attribute logical name? billing_address_address_line_1?

        Show
        Ken Rimple added a comment - I also have a similar request. It turns out that if you use the same embedded twice, ala shipping and billing address, you only get one scaffolded set of fields, with the property name rather than Roo digging into the mapped property name. Example : @RooJavaBean @RooToString @RooEntity public class Student extends Person { @Embedded @AttributeOverrides({ @AttributeOverride(name = "addressLine1" , column = @Column(name = "billing_address_line_1" )), @AttributeOverride(name = "addressLine2" , column = @Column(name = "billing_address_line2" )), @AttributeOverride(name = "city" , column = @Column(name = "billing_city" )), ... }) private Address billingAddress; @Embedded @AttributeOverrides(value = { @AttributeOverride(name = "addressLine1" , column = @Column(name = "shipping_address_line_1" )), @AttributeOverride(name = "addressLine2" , column = @Column(name = "shipping_address_line2" )), ... }) private Address shippingAddress; ... } The resulting scaffold treats the objects as single fields... <field:input field= "billingAddress" id= "c_org_rooina_coursemanager_model_Student_billingAddress" z= "UR5h0XlNcD12TAH2KJ2uqdSWNqg=" /> <field:input field= "shippingAddress" id= "c_org_rooina_coursemanager_model_Student_shippingAddress" z= "nPedkI9sdZUa4C0S8a2qxKWFv/E=" /> It would be great if the scaffolding wound out the embeddeds into actual fields, and used the attribute overrides to introspect what the actual field names will be. I guess the on-screen field names could be prefixed by the attribute logical name? billing_address_address_line_1?
        Hide
        Ken Rimple added a comment -

        My original paragraph was slightly wrong (I hate not being able to edit these things) - I meant to say that you only get a single field per embedded, and that we end up with two fields that don't work properly because their datatype is the embedded component, and so they turn into one field each... The code example makes it clear. Thanks, Ken.

        Show
        Ken Rimple added a comment - My original paragraph was slightly wrong (I hate not being able to edit these things) - I meant to say that you only get a single field per embedded, and that we end up with two fields that don't work properly because their datatype is the embedded component, and so they turn into one field each... The code example makes it clear. Thanks, Ken.
        Hide
        Stefan Ocke added a comment -

        Maybe there should be a tag file generated fpr each Embeddable class. This tag file would contain the form fields (f.e. city, street, ... for an @Embeddable Address). This tag could then be reused in all forms for entities that contain the Embeddable.

        Show
        Stefan Ocke added a comment - Maybe there should be a tag file generated fpr each Embeddable class. This tag file would contain the form fields (f.e. city, street, ... for an @Embeddable Address). This tag could then be reused in all forms for entities that contain the Embeddable.

          People

          • Assignee:
            Unassigned
            Reporter:
            Sid
          • Votes:
            36 Vote for this issue
            Watchers:
            22 Start watching this issue

            Dates

            • Created:
              Updated: