Never thought there was an argument here :)
I see what you are getting at. Recursive would make it a more robust
function. There are a lot of variables that he has not told us about, thus I
was only commenting on the fact that a recursive function would do more than
what his question asked.
(I try not to do more than people ask for. It's easy to get sucked into
solving a larger problem than was asked)
"you would have to know how deep in order to change the variable"
- apparently he already knows how deep to go. his original post said
"switch (level) {"
On Thu, Aug 11, 2011 at 2:31 PM, Merrill, Jason <
[email protected]> wrote:
> >>" If the XML gets larger and deeper, that function would fail... "
> - why would it fail? (assuming that the level var could be whatever you
> want?
>
> (OK, I am not trying to argue with you here, I promise)
>
> Because that's exactly it, if the levels got deeper, you would have to know
> how deep in order to change the variable - human intervention. Otherwise, if
> you didn't manually keep the XML in synch with the variable value, it would
> fail. And how could you know that dynamically without doing a recursive
> function, which is what I suggested. It gets worse if a system produces the
> XML. So what would be advantage of your suggestion over mine? Yours would
> require a manual tweaking of the level variable. A recursive function would
> not that value to be set at all. And a recursive function could be set to
> only check down to a certain level if you wanted that, or only check certain
> specific levels.
>
> Jason Merrill
> Instructional Technology Architect II
> Bank of America Global Learning
>
>
>
>
>
> _______________________
>
>
> -----Original Message-----
> From: [email protected] [mailto:
> [email protected]] On Behalf Of Ktu
> Sent: Thursday, August 11, 2011 2:14 PM
> To: Flash Coders List
> Subject: Re: [Flashcoders] Simplify XML Call
>
> "that would be limited to you hard coding the number of levels to go down
> to"
> - he already had this level var created with whatever number he had
> intended, I was just giving an example value...
>
> " If the XML gets larger and deeper, that function would fail... "
> - why would it fail? (assuming that the level var could be whatever you
> want?
>
>
> "it would be a better idea to check the length of the array instead"
> - John didn't indicate that this was a problem of verifying the data, but
> instead wishing to write the same code in fewer lines. That is what I did. I
> do agree with you though, that error checking would be good to have.
>
>
>
>
> I've changed my code to test creating the string required. This is a TEST
> to prove that my code would indeed create the referencing desired.
>
>
> var level:int = 5;
> var str:String = "xml.menu"
> for (var i:int = 1; i < level; i++) {
> str += ".item[whichItem" + ((i == 1) ? "" : i) + "]"; } str +=
> ".item.length()";
>
>
> change level to whatever you want and it will produce the same lines of
> code John reference above. Clearly this doesn't work, but since such little
> information was given (especially about the 'whichItemX' variables, this was
> my shot at it.
>
>
>
>
> This here is an updated version of it that breaks out a piece to make it a
> bit cleaner to read:
>
> var level:int = "n";
> var xmlItem:* = xml.menu;
> for (var i:int = 1; i < level; i++) {
> var which:* = this["whichItem" + ((i == 1) ? "" : i)]
> xmlItem = xmlItem.item[which];
> }
> totalItems = xmlItem.item.length();
>
>
>
>
> John, I think if we are going to be able to help you further we would need
> more information about how this xml is truly setup, and wher some of these
> values come from (whichItem, whichItem2..., level)
>
>
>
>
>
> On Thu, Aug 11, 2011 at 12:58 PM, Henrik Andersson <[email protected]
> >wrote:
>
> > While you have the right spirit I think that it would be a better idea
> > to check the length of the array instead. That way you won't
> > accidentally step out of bounds there.
> >
> > ______________________________**_________________
> > Flashcoders mailing list
> > [email protected].**com
> > <[email protected]>
> > http://chattyfig.figleaf.com/**mailman/listinfo/flashcoders<http://cha
> > ttyfig.figleaf.com/mailman/listinfo/flashcoders>
> >
>
>
>
> --
> Ktu;
>
> The information contained in this message may or may not be privileged
> and/or confidential. If you are NOT the intended recipient, congratulations,
> you got mail!
> _______________________________________________
> Flashcoders mailing list
> [email protected]
> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
>
> ----------------------------------------------------------------------
> This message w/attachments (message) is intended solely for the use of the
> intended recipient(s) and may contain information that is privileged,
> confidential or proprietary. If you are not an intended recipient, please
> notify the sender, and then please delete and destroy all copies and
> attachments, and be advised that any review or dissemination of, or the
> taking of any action in reliance on, the information contained in or
> attached to this message is prohibited.
> Unless specifically indicated, this message is not an offer to sell or a
> solicitation of any investment products or other financial product or
> service, an official confirmation of any transaction, or an official
> statement of Sender. Subject to applicable law, Sender may intercept,
> monitor, review and retain e-communications (EC) traveling through its
> networks/systems and may produce any such EC to regulators, law enforcement,
> in litigation and as required by law.
> The laws of the country of each sender/recipient may impact the handling of
> EC, and EC may be archived, supervised and produced in countries other than
> the country in which you are located. This message cannot be guaranteed to
> be secure or free of errors or viruses.
>
> References to "Sender" are references to any subsidiary of Bank of America
> Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are
> Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a
> Condition to Any Banking Service or Activity * Are Not Insured by Any
> Federal Government Agency. Attachments that are part of this EC may have
> additional important disclosures and disclaimers, which you should read.
> This message is subject to terms available at the following link:
> http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you
> consent to the foregoing.
> _______________________________________________
> Flashcoders mailing list
> [email protected]
> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
>
--
Ktu;
The information contained in this message may or may not be privileged
and/or confidential. If you are NOT the intended recipient, congratulations,
you got mail!
_______________________________________________
Flashcoders mailing list
[email protected]
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
