Evan,
Developing a framework is a complex and time consuming endeavor. Usually they tend to evolve over time. Build this part as you need it, wait on that part because you don't need it just now, always with an eye on making things generic.
A couple of recommendations when developing objects.
1) Use memory variables only within a method. If the value you're storing will be needed outside the immediate method, it's a property not a memvar.
2) Don't hardcode values. (See example immediately following)
*/ Establish a connection to the SQL Server ...
lnSQLHandle = SQLCONNECT('BIGDAGGONESERVER','imauser','password')
If lnSQLHandle <= 0 && Connection failed
Return 0
Endif
The problem illustrated here is that the hardcoded values for the Server Name, the User ID and the Password will change when you go to a different app.
*/ Establish a connection to the SQL Server ...
lnSQLHandle = SQLCONNECT(This.SQLServerName, This.SQLUserID, This.SQLPWd)
If lnSQLHandle <= 0 && Connection Failed
Return 0
Endif
With the values now represented by properties of the connection object, you have a portable tool that can be used between applications. It may sound elementary, but this is the single most important thing to help you develop a portable object library.
Try to think in terms of building tools, elemental, portable tools. The tools may have interdependencies on each other, but the whole library should be portable to a new application.
Create your toolbox in a common folder where not only you, but all of your development team (if any) can reach them.
There are commercial frameworks available to take some of the grunt work out of what your planning. (Visual MaxFrame, and VFP6.0 has one built in)
Regards,
Jason Tryon
Jason Tryon
Senior Systems Analyst / Technical Lead
eBusiness / iPage