11 Replies Latest reply on Aug 8, 2007 5:13 AM by pmuir

    convertEntity with non-Id key?

    nickarls

      Hello,

      Is it possible to have convertEntity insert something other than the ID into a selectbox? I have an entity that is basically

      @Id
      Integer id
      String key
      String value;

      and would like map it to the <key,value> instead of <id, value>

      or have I misunderstood the usage of the converter completely?

        • 1. Re: convertEntity with non-Id key?
          pmuir

          No, it inserts the ID (in Seam 1.2.1.GA) or a string used to lookup the id in the page context (in Seam2).

          • 2. Re: convertEntity with non-Id key?
            nickarls

            Could it be considered a useful feature? Some sort of optional insertedValue property for s:selectItems? One would think that convertEntity would probably still have to do the same things...

            • 3. Re: convertEntity with non-Id key?
              pmuir

              I guess you want this to be able to manipulate the dom from JS?

              In Seam2 this is obfuscated completely by using a sequence to map values written to the page to the relevent id (which also allows for the use of composite ids). The problem with using something other than ID is then doing the lookup from the database.

              You can add a feature request to JIRA for this, we can probably provide a way of doing this.

              • 4. Re: convertEntity with non-Id key?
                starascendant

                I'd call this a fairly necessary feature as well. It's a pretty common design in many databases that I've had to work with, particularly where the database is originally from a legacy system.

                • 5. Re: convertEntity with non-Id key?
                  nickarls

                  I raised

                  http://jira.jboss.com/jira/browse/JBSEAM-1768

                  for it. Besides legacy databases it is useful for us when some entities goes between systems where the ID has no meaning and the relation has to be "denormalized" to something that the recieving end understands.

                  Sure, you could probably do a converter function in the backing bean that would convert a list of entities to a list of SelectItem:s with reflection based on a property name but adding full EL support to it could be a little hairy. Of course, there are probably utility classes for it in Seam but if it goes into the jsf tag it would probably be cleaner.

                  • 6. Re: convertEntity with non-Id key?
                    pmuir

                    I don't understand how this relates to legacy databases. The property you mark @Id is always the ID. Sure, the ID can have no meaning, but unless you want to do stuff using the dom, it doesn't really matter.

                    • 7. Re: convertEntity with non-Id key?
                      nickarls

                      I can think of cases where a table has some String-type field that could technically work as an @Id, but the table has had an new Integer @Id added later on.

                      • 8. Re: convertEntity with non-Id key?
                        pmuir

                        So, I don't get *why* that affects the EntityConverter. The integer ID is the one to use...

                        • 9. Re: convertEntity with non-Id key?
                          starascendant

                           

                          "pete.muir@jboss.org" wrote:
                          I don't understand how this relates to legacy databases. The property you mark @Id is always the ID. Sure, the ID can have no meaning, but unless you want to do stuff using the dom, it doesn't really matter.


                          Because a database may have a relationship (enforced or not) to something other than the Id. I've run across more than one legacy app that has an autonumbering Id on a table, but stores the name or something else in a related table rather than the Id value. While it's not good practice it's not something you always have the option to remediate, which means that being able to accomodate it ends up being useful.

                          Perhaps the entityConverter itself isn't an appropriate place for this, but it really does need to be accomodated somehow.

                          It looks like I'm not the only one thinking this either. In doing some further searches, I found another JIRA that I think relates to the issue. It seems that one of your fellow developers is attempting to address this in http://jira.jboss.com/jira/browse/JBSEAM-1589.

                          • 10. Re: convertEntity with non-Id key?
                            nickarls

                             

                            "pete.muir@jboss.org" wrote:
                            So, I don't get *why* that affects the EntityConverter. The integer ID is the one to use...


                            The key stays the same of course and thats why I said in post #3 that the change would probably be to SelectItems and not to convertEntity

                            "me, myself and I" wrote:

                            Could it be considered a useful feature? Some sort of optional insertedValue property for s:selectItems? One would think that convertEntity would probably still have to do the same things...


                            But JBSEAM-1589 seem to be just what I'm looking for. What is the status of that one? Will it be automagically included in the next beta or?

                            • 11. Re: convertEntity with non-Id key?
                              pmuir

                              Vote for it if you want it done ;)