Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
.Net 2.0 Slower than Foxpro
Message
De
03/01/2006 11:26:02
 
Information générale
Forum:
Visual FoxPro
Catégorie:
Visual FoxPro et .NET
Versions des environnements
Visual FoxPro:
VFP 9
OS:
Windows XP
Network:
Windows 2003 Server
Database:
MS SQL Server
Divers
Thread ID:
01080435
Message ID:
01082653
Vues:
17
>>Ok, I'll bite. What is Node Scripting?
>
>Navigating a node collection - like document ids in HTML or JS - like nodes on treeview and listview - like node and xpathing with DOMDocument.
>

Ok, this make sense. I have imploying tree structure not only in data repersentation, but in the application architecture. My latest (next) version of LifeCycle - Build heavily use tree architecture in it construction to isolate the various individual parts. It make the navigation (and readability) easier, and helps in the reusability (using a factory style of design patterns.)

>As opposed to "binded" data controls where some macro in the "class" connects (or binds) to a DBF - node scripting requires that the property values of a node collection be addressed distinctly and individually (iterative?).
>
>Understanding and experience with Node objects - since they transcend "tools" or "programming languages" (you address the DOM the same in JavaScript, NET and VFP) may be a better route than formally learning this or that language - especially since we have VFP. The VFP command window is one of the best tools available to instanciate - tear apart - review and build node collections. The success (or lack there of) of a particular action is immediate. A "?" mark before the node path in the cammand window will echo it to the _VF_ console. With other languages you would have to write a program - compile it - and theuse a combination of alert boxes or debugger options to see what is inside the node collection - learn why a request of the collection is not working.

I totally agree that the VFP Command Window and desktop has help speed up the development and debugging of my VFP applications. Simulating this feature in other development environment (not the language) is difficult if not impossible.

As for the TV, it has its place. There are times when it is missing a needed feature whwn I need it (multiple columns, and multiple images on a item, to name few.)

>
>Knowing a little bit - or a little bit more about a particular language is just surface scratching - the beef is in understanding - IMO - the "carrier" objects - thats where all the business happens - and not a partcular syntax to set a font forecolor in this or that language. To me success is not a language skill - is is an architecture skill - and those skills depend on our understanding of nodes and their containers. TV is but the first step - if that is too tricky Combos - employing "additem" rather than a bind, is a good place to start. Beside - with a listbox and a "None" recordsource - the developer can do things with it (the ListBox) that cannot be done with a bound data source.

I agree in full.
Greg Reichert
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform