Announcement Announcement Module
Collapse
No announcement yet.
How to make Roo UI more usable for this kind of model Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • How to make Roo UI more usable for this kind of model

    My first post. I have been using spring for a few years, its been great. The docs are clear and code is enough to get you around. I am trying Roo right now as a potential candidate for a stop gap solution. We are looking for a RAD to do some CRUD for us, with minimal coding. As this would be a throw away solution. Roo seems to fit the bill as it will be similar to the current stack we use Java/Scala, spring, jpa/hibernate. This way it would not be a big change for the other developers.

    Our typical domain model follows the color model pattern. Something like this Archetypal Domain Shape

    So I gave Roo a try after going through the pizza tutorial.

    The model is a contrived one, but represents what we have. There is a Person entity, which can have a Owner role. As some point in time it would have an Ownership to a Thing entity.

    Here is the commands I put in.
    Code:
    project --topLevelPackage rootest
    jpa setup --provider HIBERNATE --database H2_IN_MEMORY
    
    entity jpa --class ~.domain.model.Thing
    
    entity jpa --class ~.domain.model.Ownership
    
    entity jpa --class ~.domain.model.Owner
    
    entity jpa --class ~.domain.model.Person
    
    focus --class ~.domain.model.Thing
    field string --fieldName name --notnull
    field set --fieldName ownerships --type ~.domain.model.Ownership
    
    focus --class ~.domain.model.Ownership
    field date --fieldName effectiveFrom --type java.util.Date
    field date --fieldName effectiveTo --type java.util.Date
    field reference --fieldName owner --type ~.domain.model.Owner
    field reference --fieldName thing --type ~.domain.model.Thing
    
    focus --class ~.domain.model.Owner
    field reference --fieldName party --type Person
    field set --fieldName ownerships --type ~.domain.model.Ownership
    
    focus --class ~.domain.model.Person
    field string --fieldName firstName --notnull
    field string --fieldName surname --notnull
    
    web mvc setup
    web mvc all --package ~.web
    This produces a functional, but not usable app. Some problems are:

    1. Drop downs are blank, can easily be fixed by editing the jsp and traverse the object graph like itemLabel="person.firstName"

    2. The list view are not that usable. This uses table:column tag which the property attribute does not seem to traverse the object graph. There seems to be a ticket for it.

    https://jira.springsource.org/browse/ROO-1709

    Is there another alternative to get a better list of objects? If this was hand coded. I guess the typical approach to is create a finder, create a list of DTO and then display on JSP. It would be possible to lift the code out from aj files and put them into java files. Although that pretty much defeats the purpose of why we are trying out Roo. I also tried to implement the toString and remote the root to string annotation, did not give me my desired results.

    3. Is it possible to let Roo do the bi-directional cascade on the model. As the above is logically bi-directional however there is no cascades. So the user would still need to edit 2 objects to create the bidirectional link. Just asking this if there is a way w/o again lifting the code from aj to java.

    Thank very much. Would appreciate some help. We are looking also at other alternatives such as Django, Grails. However we are trying to keep the solution even if its a stop gap to be w/ JVM eco system.

  • #2
    The reason the "Owner" drop-down appears blank (or more correctly, contains one blank item) is that org.springframework.core.convert.ConversionService .convert(Object, TypeDescriptor, TypeDescriptor) is returning an empty String when asked to convert an Owner to a String. This in turn is because Roo generates the following converter in ApplicationConversionServiceFactoryBean_Roo_Conver sionService.aj:
    Code:
    public Converter ApplicationConversionServiceFactoryBean.getOwnerToStringConverter() {
             return new org.springframework.core.convert.converter.Converter() {
                     public String convert(Owner owner) {
                             return new StringBuilder().toString();
                     }
             };
     }
    The above code is generated by these two classes in o.s.r.addon.web.mvc.controller.converter:
    • ConversionServiceMetadataProviderImpl
    • ConversionServiceMetadata

    The converter they generate concatenates the results of all getter methods except those that return:
    • the ID
    • the version
    • a collection or array
    • a domain type (e.g. Owner or Thing)
    • a boolean or Boolean
    • a type annotated with javax.persistence.Embedded

    So if your domain type contains only those types of fields, you end up with an empty String. The workaround is to push in the above method and customise it as required, for example:

    Code:
    @RooConversionService
    public class ApplicationConversionServiceFactoryBean extends FormattingConversionServiceFactoryBean {
    
        @Override
        protected void installFormatters(FormatterRegistry registry) {
            super.installFormatters(registry);
            // Register application converters and formatters
        }
    
        // This method has been pushed in from the ITD
        public Converter<Owner, String> getOwnerToStringConverter() {
            return new org.springframework.core.convert.converter.Converter<rootest.domain.model.Owner, java.lang.String>() {
                public String convert(Owner owner) {
                    Person party = owner.getParty();
                    return party.getFirstName() + " " + party.getSurname();
                }
            };
        }
    }
    This is preferable to editing your JSPX files, as you only have to do it once (not for every JSPX file).

    We're looking at how we might fix Roo to handle this scenario better; clearly an empty String is not very useful.
    Last edited by Andrew Swan; Feb 28th, 2012, 09:51 PM. Reason: Added link to JIRA ticket

    Comment


    • #3
      Re your question 2:

      The list view are not that usable. This uses table:column tag which the property attribute does not seem to traverse the object graph. There seems to be a ticket for it.

      https://jira.springsource.org/browse/ROO-1709
      There's another two similar tickets that I've now linked to that one. Please vote for some or all of them as appropriate, although the roadmap is pretty full for the 1.3.0 release.

      Is there another alternative to get a better list of objects? If this was hand coded. I guess the typical approach to is create a finder, create a list of DTO and then display on JSP. It would be possible to lift the code out from aj files and put them into java files. Although that pretty much defeats the purpose of why we are trying out Roo.
      Roo doesn't (and can't) know your application's use cases or therefore what object graphs to retrieve and display. If you have any suggestions about ways in which Roo could be more helpful in this regard, by all means put them forward (or log them as a new feature if sufficiently complete). This could take the form of new shell commands, new Roo annotations, or some combination thereof. Maybe a new "dto" command that generates a class annotated with a new @RooDataTransferObject annotation, which in turn triggers Roo to generate the DTO and the code that populates/retrieves it. The annotation would need one or more attributes that specify the parts of the object graph to be retrieved. Maybe an array of these annotations could go directly onto the entity class? In any case, this type of change would have a big impact on other parts of Roo such as finders, repositories, services, MVC/JSF/JSON/etc.

      I also tried to implement the toString and remote (remove?) the root (Roo?) to string annotation, did not give me my desired results.
      To replace the toString() method generated by Roo, you only need to implement your own version of it within the entity's Java class; next time you run the Roo shell, Roo will see your version and delete its own. You can and should leave the annotation in place, so that if you delete your toString() method, Roo will re-create the default one. If this doesn't work for you, please log a bug report with enough information for us to replicate the problem.

      I'll look into question 3 when time permits.
      Last edited by Andrew Swan; Feb 29th, 2012, 12:21 AM.

      Comment


      • #4
        Thanks Andrew. Being a Roo newbie, the info above is useful and does makes sense. We really appreciate your reply.

        Comment


        • #5
          Is there another alternative to get a better list of objects? If this was hand coded. I guess the typical approach to is create a finder, create a list of DTO and then display on JSP. It would be possible to lift the code out from aj files and put them into java files. Although that pretty much defeats the purpose of why we are trying out Roo.
          At the risk of teaching you how to suck eggs, if you're happy to use domain objects instead of DTOs, then you can always use the "finder" commands to generate JPA-based finder methods and their associated MVC artifacts (views and controller methods).

          Comment

          Working...
          X