Hi, I am in the process of making changes in the CVS and one of the things that I am adding are the If, Else, and For components (as on www.t-deli.com).
All of these combine existing components, but while If and Else are fairly non-contentious, For is a bit problematic. The reasons are following: - IPrimaryKeyConvertor instead of ListEditMap Both For and ListEdit provide mechanisms to override the default 'squeezing'. The difference is that IPrimaryKeyConvertor is a relatively simple interface providing getPrimaryKey/getValue, while ListEditMap is a full-fledged map. I am assuming in the discussion below that the objects are big enough or simply non-serializable and render squeezing impractical. If I am not mistaken, ListEditMap needs to be initialized with all relevant objects in order to work well. This is often necessary anyway as the data comes from a database and it is often (but not always) better to load the data with just one query, rather than have a query for each primary key requested. IPrimaryKeyConvertor instead allows you to load only specific primary keys rather than the full collection. It can however be backed by a Map with the full collection, ant it will behave like ListEditMap. The choice is up to the developer. In addition, a number of people have indicated that IPrimaryKeyConvertor is simpler to understand as well. Unfortunately, there isn't a standard implementation for the latter because of the possible variations, but perhaps this needs to be rectified. In short, are there any comments/objections to using IPrimaryKeyConvertor for For? - Simplified primary key conversion Apparently, even IPrimaryKeyConvertor is too complex for some people and a simpler mechanism should be provided. In addition, a lot of people do not implement equals() and hashCode() on their data objects and/or use == rather than equals() and then wonder why things are not working. Here is a possible approach: The getPrimaryKey() portion of the interface can be easily implemented in a simpler way using an OGNL parameter that extracts the primary key from the iterated object (it will by just 'id' in the general case). The getValue() portion is a bit tricky, however, as it is unclear where to get the full values from. One way is to take the list provided in 'source', the provided OGNL expression can be used to extract the primary keys and a map 'primary key -> value' can be built. It will then be used to perform getValue(). This will work in most cases, and will even take care of the == problem above. The problem is that it is entirely possible for a value with that primary key to exist, but not to be in source -- e.g. if the rendered part of the list has shifted between requests. Depending on the use case, that may be problematic. My gut feeling is to have both the OGNL primary key expression and IPrimaryKeyConvertor. Which of the two mechanisms the developer will choose is up to him, but the possible dangers need to explained in the documentation. (of course, the third one -- squeezing is probably best if it is possible) Two more questions: - About rewind: Is there a need for people to be able to get the list of primary keys before the iteration begins? (probably via a binding) Some people have expressed such a desire in other contexts, and it makes a certain sense as it will allow you to know exactly what values should be loaded in your map. - Is there a need to have an ActionListener in For? If I understand correctly, it was provided in ListEdit mostly to support ListEditMap. Best regards, -mb --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
