Author Topic: Building a treeview with recursion  (Read 13267 times)

0 Members and 1 Guest are viewing this topic.

MP

  • Seagull
  • Posts: 17750
  • Have thousands of dwgs to process? Contact me.
Re: Building a treeview with recursion
« Reply #30 on: March 22, 2009, 02:10:09 AM »
It's a good point John. I perused the thread but I don't see if Keith spec'd how the files are being generated or where they're coming from. Nonetheless, going the xml route is likely the best route, so regardless where they originate, the main proggy should expect xml.

In other words the files would have to be pre-processed (cleaned/converted to xml) if they originate from a 3rd party, formatted as proper xml if they are generated from a seperate module within the app greater.
Engineering Technologist • CAD Automation Practitioner
Automation ▸ Design ▸ Drafting ▸ Document Control ▸ Client
cadanalyst@gmail.comhttp://cadanalyst.slack.comhttp://linkedin.com/in/cadanalyst

MikeTuersley

  • Guest
Re: Building a treeview with recursion
« Reply #31 on: March 22, 2009, 09:55:23 AM »
Exactly. The major point is how to build the treeview which is best accomplished by the route I've explained. Processing the text files, or changing them at output if it's Keith's program, then becomes the next step. We may be stepping backward but then moving forward with a stronger solution and a shift in the problem.

If it's Keith's program that outputs the information, then using the class object that xsd would spit out becomes a simple process - instantiate it, add the values where needed, then serialize it to the xml file. Again, there is no need to write custom code to populate an xml document.

If he has no control over the text files' generation, then he'd need some code to "wash" it as MP explained.

I came into this when R started explaining how to do it with xml and he was way off the mark on how to use xml to populate a treeview. While his approach may work, it was not the simplest or easiest approach. It's about working smarter, not harder.

If Keith comes back saying the files are not his and he needs help "washing" them, then I'll gladly pitch in with that question  :-)

tjr

  • Guest
Re: Building a treeview with recursion
« Reply #32 on: March 22, 2009, 11:44:34 AM »
I came into this when R started explaining how to do it with xml and he was way off the mark on how to use xml to populate a treeview. While his approach may work, it was not the simplest or easiest approach. It's about working smarter, not harder.
If your way is smarter then I'm glad I'm a dope. You're passing off nested for loops as recursion, which is just plain wrong. My xmlTreeClimber function will recursively build a TreeView regardless if it has 1 node or 10000, how will nested for loops do that? My xmlTreeBuilder function will generate the XML code in the exact same format recursively.

You can't just say, hey I'm going to "clean" my input into the way I want it as you don't know what the output will be used for. If he is pulling an XML file from a 3rd party app, changing some stuff and feeding it back in the same format the 3rd party expects cleaning input fails.

MikeTuersley

  • Guest
Re: Building a treeview with recursion
« Reply #33 on: March 22, 2009, 10:58:16 PM »
I'm not passing off for loops as recursion - I'm saying you don't need recursion especially in your scenario with an xml file. The simpler the code, the easier it is to maintain by you or whomever inherits it.

Quote
You can't just say, hey I'm going to "clean" my input into the way I want it as you don't know what the output will be used for. If he is pulling an XML file from a 3rd party app, changing some stuff and feeding it back in the same format the 3rd party expects cleaning input fails.

Sure I can! What do you think xslt is for? Here's where the smarter comes into play - if the data is formatted such that it's a pain to deal with, convert it to something that's easier to handle. If the file is to be consumed by some other 3rd party app downstream, then obviously you need to convert it back.

tjr

  • Guest
Re: Building a treeview with recursion
« Reply #34 on: March 22, 2009, 11:55:04 PM »
I see what you're saying, but I can't just bring myself to agree with it. Generated code is not maintainable, one off code compared to a generic function doesn't seem logical and converting data to a format that is simpler for a developer to understand just to modify it and convert it back seems like a recipe for failure. I'd rather take the extra 20 minutes or so and code up something myself for something as simple as this than deal with generated code.

MikeTuersley

  • Guest
Re: Building a treeview with recursion
« Reply #35 on: March 23, 2009, 02:14:53 AM »
Well, if you've never tried it, give it a shot once and see what you think. I suggested the use of xsd to generate the class just because it was faster than writing all the properties and a cool little tool a lot of people are unaware of. I agree with generated code being unmaintainable but not here - it's just property declarations for the most part. To serialize/deserialize is 4 or 5 lines of standard code where you just change the object you are serializing. This can all be done in about 2 minutes assuming you have the xml file completed and are comfortable with xsd. Then its just handling the For loops. For the average cad programmer, it's nice and simple.

As for the washing, I agree, it could be tedious and may not be the wisest choice. In this specific case, it appears he could use search and replace on the tabs or a regular expression. His focus would be on something simpler (manipulating strings) than the recursion of the treeview structure. A lot of times the programmers on my team (and even I) get too focused on trying to code around the data when the easiest solution is to adjust it and then the main app programming becomes easier. It is on a case by case basis and, if it's xml, xslts make it a fairly straightforward process.

BTW, I didn't mean to infer that you were not smart!

pkohut

  • Guest
Re: Building a treeview with recursion
« Reply #36 on: March 23, 2009, 03:23:46 AM »
I've been keeping my eye on this thread and Seven had it correct way back in the
beginning with counting tabs.  1) you can't infer any extra meaning from the sample
text file that's not already there.  2) The user provided the criteria of the input file.
3) I don't agree though that recursion is expensive.  If I had a concern I'd implement it
both as a recursive function and as a non-recursive function.  That's the only way to
know the true story.  4) Converting to XML and then using XSLT "IS WAY MORE EXPENSIVE"
then processing the data raw in the first place.  5) This function could probably be done in
10 to 15 lines of recursive code, without using any libraries.


Paul