Announcement Announcement Module
Collapse
No announcement yet.
thoughts after using Roo Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • thoughts after using Roo

    I've been experimenting with ROO for a few weeks now and based on that experience here are the broad things I would like to see added to ROO:

    (This is not to say that ROO isn't awesome. It is awesome. Well done.)

    1. Support for setting order on collections and queries. Need a) support for lists (which can maintain arbitrarily ordered data) instead of just sets in domain objects, and b) some sort of "order by" option on entities, collection properties and finders. Of course we can implement comparable, but in many cases we want the db to order the result sets before returning them, and once we get them we want to keep them in the order the db gave them.

    (The "order by' on finders feature may be addressed here: http://jira.springframework.org/browse/ROO-241.)

    2. Stronger support for the common "user-driven" application archetype that relies heavily on relationships to a user account. To achieve this now, the controller methods have to be modified to obtain the user's id, and the entity methods have to be modified to pass the user's id in queries of associated objects. I expect to have to customize and maintain the forms, but it would be nice if Roo could manage the controllers and entities in such a typical case.

    It may not be feasible to do this kind of "archetype" support, but maybe some sort of extension that allows: a) a reference to the logged-in user to be added to each persistence method and b) the ability to add where and order clauses to the query (including with references to the user object). (Of course this might be easier if Roo also generated the user object as part of its Spring Security integration.)

    3. Ability to access my entire roo command history for a project. Helps to create scripts or just remind myself what steps were taken.

    ***

    Hope those make sense. (#2 is hard to explain, but I think you'd run into several issues if you tried developing any heavily user-driven application such as a personal music library or something like that where virtually all of the objects persisted are related to a user account.)

    My two cents. Overall, this has been a nice experience.

  • #2
    Thanks for you feedback. We certainly appreciate it!

    1. Support for setting order on collections and queries.
    http://jira.springframework.org/browse/ROO-241 will be actioned and solve this problem. I always recommend people vote on Jira issues so we can see what people are interested in.

    2. Stronger support for the common "user-driven" application archetype that relies heavily on relationships to a user account.
    Are you just wanting to access the currently-authenticated user? If so, Spring Security offers a SecurityContextHolder.getContext().getAuthenticati on() which can be used statically (it's a ThreadLocal).

    Also Spring 3's @MVC feature allows you to add the Principal object into the signature of any controller method, and it will be auto-populated correctly. This is perhaps the easiest way of finding out the authenticated user in a web controller method.

    3. Ability to access my entire roo command history for a project.
    This request keeps coming up and again and again, so I'll definitely have to do it! :-) https://jira.springsource.org/browse/ROO-274 is the related issue if you'd like to vote or monitor the issue.

    Thanks again for your feedback.

    Comment


    • #3
      Thanks for the responses, Ben. I voted for the "command history" issue (which somehow I hadn't latched onto before).

      http://jira.springframework.org/browse/ROO-241 will be actioned and solve this problem. I always recommend people vote on Jira issues so we can see what people are interested in.
      Yeah, but that's my issue, so I can't vote for it! I also wanted to bring up the notion of sort order in general, as this could apply not only to finders but to normal collections on domain objects.

      (Was the thinking is that most domain collections - e.g., person.relatives - are fairly small and can be sorted by the client? Is there a reason for not having a "field list relatives" command in addition to a "field set relatives" command?)

      Are you just wanting to access the currently-authenticated user?
      No, the issue is that I don't know how to prevent a user from accessing data associated with another user without pushing virtually every controller and/or entity method out of the aspect. I guess I'm asking for cheap object-level security!

      Let's say I'm using request paths like this (one path for members, one for admin):

      /myapp/member/task

      /myapp/admin/task

      I want "GET myapp/member/task/1" to load task 1 ONLY if task 1 is owned by the logged-in user. Similarly, I want "POST myapp/member/task" to save a task ONLY if the task is owned by the logged-in user.

      I think one way to accomplish this is to add "WHERE member=:member" to each query in TaskEntity and relevant finders. Another way is to try to validate at the controller method level (if an object is being requested or persisted, make sure the retrieved/provided object belongs to the current user).

      Either approach requires pushing lots of code out of Roo-managed aspects. (Maybe there's a way to do it with Aspectj, though. Hmmm....)

      Sorry for being wordy. I realize this may be beyond the scope of what Roo hopes to achieve. But in the spirit of trying to let Roo manage my boilerplate code, I thought this was an interesting case.

      (Btw, is it me, or is it the case that anyone showcasing Roo stops right before they run into the need to add object-level security?)

      Comment


      • #4
        I'd suggest you take a look at Spring Security's ACL features, which provide Java-side filtering based on object ACLs. For small collections this is OK, but for large collections you'd want to do it on the database side and that would involve adjusting the finders accordingly.

        Regarding sort order generally (as opposed to in finders), that would involve providing an automated implementation of Comparable. The problem with doing this is you must also provide a compatible equals() and hashCode(), and all of these require consideration of object associations. Consider Order and LineItem. If Order has a Set<LineItem> collection, by rights you'd need these methods to include the elements within the collection. In turn when these methods are invoked within the collection elements, they will be required to visit the "order" field and as such a circular reference will be created. Of course you can detect these things and code around it, but it makes it non-trivial. If people are willing to have equals/hashCode/Comparable without regard for collections we can do it more easily.

        Comment


        • #5
          Hi,

          Regarding the ordering issue there´s already a Jira Ticket open to allow data sort in the UI.

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


          P.D. Sorry for the spam, i really want that functionality in Roo

          Comment


          • #6
            Raul,

            I'd love for the scaffolding to provide column sorting etc., but I also want to set the sort order on the database side in many cases. There is an open jira issue to add db-side sort order to roo-generated finders, but apparently it still won't be possible to db-side sorting for, for example, myEntity.findAll() (which I guess I can simply not use).

            Ben,

            Regarding object-level security (e.g., making sure users can only see/edit their own persisted objects), something simpler than ACL should suffice, but this is still confounding. I think I could make excellent use of the @PreAuthorize annotations announced here:

            http://blog.springsource.com/2009/06...00m1-released/

            E.g.,
            Code:
            @PreAuthorize("#task.owner.name == principal.name or hasRole('ROLE_ADMIN')")
            Anyway, thanks again for your various bits of advice. I've read lots of your replies to users in this forum and I've learned a lot about the choices you've made for Roo.

            Mike

            Comment

            Working...
            X