So at the moment I'm essentially working 3 jobs. My main job is that of an ASP.NET developer, which is taking up 90% of my time. So tonight, I spent a few hours trying to fix a Domino database for a customer. I've simply had no time to look at this problem during work hours, and I suspect I'd be better off looking at this from home.
What that means is that I can drink Bourbon while I code, and thankfully I had some Jim Beam Gold Label left (note the past tense here people).
Essentially the problem was, that the original developer had designed the code around 2 computed text fields. These fields loaded their values via @DbColumn. The values were then loaded into arrays via some dodgy JavaScript functions, as well as one of the fields being referenced as the data source for a drop down list. The idea was that you selected a product via the drop down list which contained descriptive text, and it then inserted the product code into the other box. All fine and well, except for when customers lists got "too big", and Domino spits the dummy over 32k of text.
When this first happened, I thought up some other ways around the problem. Mainly because the customer was on R5 and I really didn't want to go 'there'. However, I've just sold them R7, and upgraded the server, so it was time to fix things.
My initial plan was to use multiple embedded views, because, you can have multiple embedded views in R6.5 forwards right? Well no, they simply don't work. It'll let you put them in the form, but they simply don't render on the web. I didn't bother reading more into that one - that shit simply don't work yo'. So I was forced to dig around a bit, and ironically, in the end it was some of my recent ASP.NET development which made the answer pretty simple to come by (well, after the 3rd straight bourbon it was easy anyway).
I got hung up on needing multiple embedded views, because the original developer had created multiple fields (4 actually - 2 which were computed with the values, and 2 which were being displayed for the user) to solve the problem. I was really trying to change as little as possible, because there were some weird cross dependancies across the rest of the form. In reality, I only needed 2 fields and one embedded view to sort things out fairly nicely.
The original solution had 2 lists, and relied on the fact that it knew that both of those lists were in the same order. It worked. Given that it was written a long time ago it's fair enough. However, there was no need for the 2 lists to be seperated in the first place. I modified my embedded view to combine the text and the value for my select options, and implemented it as follows:
select name="options" onchange="document.forms[0].product.value = document.forms[0].options.value;"
and
option value="MYPRODUCTCODE">My Product Description
option value="MYPRODUCTCODE"2>My Other Product Description
..etc..
Which works quite nicely, using less messing about. However, the funny part for me - although a bit of thinking about JavaScript and reading the W3 forms page could have helped me, it was some recent development in ASP.NET which made me realise how incredibly simple it was all going to be. I'd recently done some work on a few pages using Dropdown lists, and the fact that Visual Studio has awareness of a display value VS an actual value VS an index made me realise that if it understood these things, then I could probably trick Domino into doing something similar.
Sometimes an overly helpful IDE can prevent you from fully understanding certain things. However sometimes, it can promote thought and actually help you to get it.
(For the somewhat slow, I'm referring to Visual Studio as the helpful IDE here)