> -----Original Message----- > From: Scott Barnes [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 31, 2005 7:31 AM > To: CF-Talk > Subject: Re: What's wrong with the Javascript? > > Ditto, > > A simple listener/queue system would be suitable here vs looping over > every element.
True - one of the brilliant things about JS is that it's so flexible. However "looping over every element" is actually simple as well (and can be simpler than managing a queue). > Personally i'd rather write a listener that waits for an onChange > event and adds the id of that element to a queue (marking it as > dirty), then when i need to process that information, it iterates over > that queue and carrys out taskXYZ accordingly, each time slicing the > currentItem from the queue (in the event more items get added...which > is pretty damn rare). Personally - so would I. But then again that wouldn't help describe JavaScript capability of extending any object on the fly. ;^) Another example would be better. Let's say you're building a system to construct a pizza. You present three select lists: "Crusts", "Sauces" and "Toppings". People can select what they want from these lists - the items selected are removed from the original list and placed on the "Your Pie" list. The value for all of these elements is a Unique Database ID. Perfectly understandable to the back-end system (which would never confuse a crust with a topping) but not easily parsable in JS. In addition people may only add one "Crust" - if another is selected the new select replaces the old one and the one returns to the "Crusts" list. However they can mix sauces and toppings. So you're moving option objects around from list to list but you want them to "remember" their source lists for when they get removed. You also need a fast way to interrogate the options for their source so you can ensure only one type of crust. The "traditional" way I've seen this done (over and over) is to create compound values. Something like "Source_ID" and then, every time you need it parsing out the source. This works, but it's clumsy and creates extra work. Instead just create an ad hoc property on each Option field called "Source". You can easily access the original list source anytime as a simple property call. You could also add more properties. For example each option might have a "Cost" property (which could be totaled later by looping through the "My Pie Options"). Another possibility might be a "delay" flag which would indicate that some options might take longer to cook than others. All of this information is related directly to the options at hand. You could keep them in lookup objects or arrays but that's not very contextual. The back-end system doesn't need any of it (it knows already) so it's only used by the front end to improve user experience. In general once I've embraced this kind of thinking I've seen my code get smaller and simpler while losing no capability. Jim Davis ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:200990 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
