Hmmm... Definitely has peaked my interest. I like the fact that there are only instance objects that go right to the database instead of loading a Map.
Thanks for the thought Sean, I will let you know if I implement this scenario and how well it works. Aaron Bartell On Mon, 17 Jan 2005 23:08:19 -0500, Sean Schofield <[EMAIL PROTECTED]> wrote: > 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 > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>> > > >>> > > >>> > > >>> > > >> > > >> > > > > > > > > > > > > -- Aaron Bartell
