What about something like this... In our current Struts app we have a class called LookupBean. Its basically a simple Java object with properties for id and description. Whenever we call a method to get data for a table (like you're describing) or a select list or whatever, we can return a list of these beans. (So the DAO populates the bean with both the id and the description.)
Then when you are rendering you can use whatever you need. For a table we would use a custom tag that would basically check for instanceof LookupBean and use the description method, otherwise it would call toString() on the object and display the normal string value. In faces you could do something similar. In fact, you could probably tweak the renderer to check for this type of bean. Otherwise maybe you could customize the dataTable but I don't think that would be necessary. Would that work? sean On Mon, 17 Jan 2005 22:01:23 -0600, Aaron Bartell <[EMAIL PROTECTED]> wrote: > >Now tens or hundreds of thousands of elements might be a different > thing, but even then it's mostly just a memory consumption issue rather > than a performance issue. > > Exactly. When you have 500 to 2000 users on a system at any given time, > memory per job is quite important. > > I can see where you are coming from and your point is noted. Thanks Kalle. > > Aaron Bartell > > Korhonen, Kalle wrote: > > >>-----Original Message----- > >>From: Aaron Bartell [mailto:[EMAIL PROTECTED] > >>Subject: Re: Convert/Lookup Suggestions > >>I don't think loading a Map of descriptions is the way to go. > >> That is not something that will scale well. What happens > >>when you have thousands of product codes? And product codes > >>aren't the only thing I am needing descriptions for. > >> > >> > > > >The implementation of a Map is completely up to you so I don't think you can > >claim that it won't scale well. You could make your Map backing bean a > >fa�ade for your lookup table, implement caching or do whatever else you want > >- certainly, you can make it just as scalable as you need. But even a simple > >HashMap-based implementation should be able to deal with thousands of > >elements just fine. Now tens or hundreds of thousands of elements might be a > >different thing, but even then it's mostly just a memory consumption issue > >rather than a performance issue. > > > >Kalle > > > > > > > >>Korhonen, Kalle wrote: > >> > >> > >> > >>>Since you asked... > >>> > >>>First, I really would recommend against using any > >>> > >>> > >>abbreviations in your > >> > >> > >>>code. In the end, it just makes it harder to understand > >>> > >>> > >>without giving > >> > >> > >>>you any benefits. I wouldn't let any developer here to use > >>>abbreviations especially when naming public properties. > >>> > >>>Then, maybe you don't need to care about localization, but > >>> > >>> > >>generally, > >> > >> > >>>it's a bad idea to store non-localizable string into the db. In your > >>>case though, description looks clearly like it should be > >>> > >>> > >>part of order > >> > >> > >>>object, even if it's stored in a different table. I would just add > >>>getDescription method in the Order object, or create a new > >>> > >>> > >>model object > >> > >> > >>>that inherits from Order and put the method there. > >>> > >>>If you still don't want to take that route, you could create > >>> > >>> > >>a Map of > >> > >> > >>>descriptions, with product codes as keys and make it a managed bean, > >>>e.g. name your Map bean as ProductDescriptions, and in the code you > >>>could simply get the description using > >>>#{productDescriptions[<productCode>]}. Using a converter for that > >>>sounds like you are trying to use it in a way it's not intended for. > >>> > >>>Just my 2 cents, > >>>Kalle > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: Aaron Bartell [mailto:[EMAIL PROTECTED] > >>>>Sent: Saturday, January 15, 2005 2:18 PM > >>>>To: MyFaces Discussion > >>>>Subject: Convert/Lookup Suggestions > >>>> > >>>>Just curious as to how others would implement this example. > >>>> > >>>>Let's say I have an Order object that has a field called prdCde > >>>>(product code). The value for product code that I store in > >>>> > >>>> > >>the Order > >> > >> > >>>>object is it's unique id. That unique id is associated with a > >>>>Description in the PRDCDELUP (Product Code Lookup) table. > >>>> > >>>>I am displaying a list of Order objects using <h:datatable> > >>>> > >>>> > >>and when I > >> > >> > >>>>get to the "Product Code" column I want to display the > >>>> > >>>> > >>description of > >> > >> > >>>>the product code rather than it's unique id, because the unique id > >>>>will mean nothing to the user. My thought is to build a custom > >>>>converter to do this but am wondering if that is the right > >>>> > >>>> > >>direction > >> > >> > >>>>to go or not. > >>>> > >>>>I know I could do it other ways, but it seems I would always be > >>>>messing with my model objects, making them provide lookups > >>>> > >>>> > >>that they > >> > >> > >>>>should not have to do (i.e. having the Order object provide > >>>> > >>>> > >>a method > >> > >> > >>>>called > >>>>getPrdCdeDescr() just isn't the way I want to go) > >>>> > >>>>Thoughts? > >>>>Aaron Bartell > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>> > >>> > >>> > >>> > >> > >> > > > > > > >
