Re: Convert/Lookup Suggestions

[Aaron Bartell]

>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