Wiki Home

Vfe Ilibs


Namespace: VFP
Should the I level classes contain all the C level classes?

Author: Ron Cavil (rcavil@dct.com)

I have been working with the Cquery class. In the Iquery class, there is no equivilant Iquerycontainer or Iqueryvaluecombo classes. Is there a reason for this or should there be a Iquerycontainer and Iqueryvaluecombo classes?

Author: Mike Feltman

For the most part, only classes that we thought you were likely to subclass were included in the ilayer.

Mike Feltman
F1 Technologies

Date: October 05, 1999 03:15 PM
Author: Bob Archer (barcher@geac.com)

I think that was a miscue... I feel that an iClass should exist for every cClass and they should be layered the way they are in CodeBook 6.0.

For example, if I want to modify cBaseForm, I would change iBaseForm... then cPresObjForm would be a subclass of iBaseForm an inheriet the new functionality.

BOb

Author: Toni M. Feltman

Hi Bob,

For example, if I want to modify cBaseForm, I would change iBaseForm... then cPresObjForm would be a subclass of iBaseForm an inheriet the new functionality.

Didn't we talk about this before...? :-) The thought is great in theory however it will not work in practice. One of the reasons for the iLibs was to give a developer a place to put application specific framework changes. This is why the iLibs folder can be specified when the project is created. If cPresObjForm inherited from iBaseForm and someone created an application specific iLibs folder we would have to go and redefine cPresObjForm to come from the new iLibs class. This is no big deal for us, but what happens when the developer later creates a project using the standard iLibs folder? We have to set it back. Now, what happens if he/she is working on two projects at the same time. One with a specific iLibs folder and one with the standard iLibs folder? That is way too much mucking with the .vcx file for my taste. :-)

Toni-
Date: October 05, 1999 09:43 PM
Author: Bob Archer (barcher@geac.com)

Ah... well, if you are thinking of the iLib specific to an application, then the way it is works.

But, I think of the i-Layer as a way to globally modify/customize the framework. Perhaps that is why you feel it is 'way to much mucking with'. We are looking at the i-Layer as providing different layer of abstraction to the devloper.

For application level classes that all is based on can/should be developed by the devloper for each specific ap as it is called for.

If the iLibs are supposed to be application specific, why isn't an iLibs directory built in each application structure? Or is it? I haven't created an ap with the shipped version.

BOb
---
Author: Toni M. Feltman

Hi Bob,

For application level classes that all is based on can/should be developed by the devloper for each specific ap as it is called for.

So if you have one client that is slightly sight impared you would create a custom textbox with larger text and pick that textbox for each field through DBCX Explorer? Wouldn't it be easier to modify iTextBox and do nothing else?

If the iLibs are supposed to be application specific, why isn't an iLibs directory built in each application structure? Or is it? I haven't created an ap with the shipped version.

It is not that they are supposed to be app specific. It is that they "can" be app specific if the need arises. This need may arise in the example I mentioned above.

When you create a new project with VFE, iLibs is one of the directories that you can specify. If you specify an iLibs folder different from the default, all of the iLibs classes are copied to that new folder and updated appropriately. From that point on, VFE will look at this new iLibs folder for all of the components for the application, but just for this one application.

Toni-

Author: Bob Archer (barcher@geac.com)

> So if you have one client that is
> slightly sight impared you would create a custom
> textbox with larger text and pick that textbox
> for each field through DBCX Explorer? Wouldn't it
> be easier to modify iTextBox and do nothing
> else?


No... I would go to the VFE Preferences and change the class used for Character fields to my aTextBox subclass of iTextBox which has the larger font setting. (Which is another reason I think some of those preferences settings should be application (project) level and not global.)

If I wanted ALL the forms in Every Application I built to use Arial... I would want to go to iBaseForm and change it... But, then if I had ONE ap that I wanted to form font to be Times Roman Bold Italics, I could do that too. (without duplicating my iLibs directory.)

The way it is now, we have to duplicate code if we want global modifications AND ap specific modifications. Which works, it just takes more time to keep in sync, which I guess is fine if you are a consultant and bill every hour.

>
> It is not that they are supposed
> to be app specific. It is that they "can" be app
> specific if the need arises. This need may arise
> in the example I mentioned above.
>


Right, as I said though this is cut-and-paste reuse.

I still feel though, even if the iLibs work as they are, each cClass should have a i subclass... but, I do see the problem with having cClasses subclass from iClasses if you are moving around or using different iLib directory for each ap.

> the directories that you can specify. If you
> specify an iLibs folder different from the
> default, all of the iLibs classes are copied to
> that new folder and updated appropriately. From


Ah.. I didn't know that. It's a short day when you don't learn something new!

But, I would see the best of both worlds as having a single set of iClasses that are layered into the cClasses, then have an aLib (a = application) layer which are the only Concrete classes... In other words cClasses and iClasses would only be abstract and usually not instantiated. The ap is built with aClasses... Simmilar to the aApp lib.

We don't have to agree, just wanted you to understand where I was coming from.

BOb

Author: Mike Feltman



Hi Bob,

I thought about this pretty hard when we implemented the i-layer. I looked at the i-layer in CB6 and basically found it to be a mess. I thought the class hierarchies were confusing and because some of the stuff in the c-layer is also based on stuff in the i-layer it was unclear exactly what classes changes would impact unless you studied the class hierarchies in great detail. The pathing issues that Toni mentioned also factored into my decision.

Toni and I talked about this last night and I came up with another idea that should give you what you want and also avoid confusion. What about a g-layer? The g-layer would contain a single class library, named gBase, which would contain empty subclasses of all of the VFP base classes. The c layer would then inherit from the g-layer. This would basically give you one VCX that you could change that would impact the entire framework as well as the ilibs. The only code I would put in the g-layer is code to prevent classes in it from being instantiated directly. Does this sound like it would do the trick without introducing the other issues we've raised? (BTW, g would stand for global.)

Mike Feltman
F1 Technologies
Author: Toni M. Feltman

Hi Bob,

We don't have to agree, just wanted you to understand where I was coming from.

So we agree to disagree... :-) I do see where you are coming from. I guess we could leave the i-layer alone and allow for a specific a-layer in it's place when an application is created. Mike and I would have to dicuss it more before we could decide. This is a pretty major change that we would probably have to put on the plate for VFE 6.1.

Like Mike mentioned, having the i-layer inherit from the c-layer could cause a lot of confusion in a user's mind. The i-layer was already confusing enough for a lot of people. Many times when we make a decision on how to do something, we weigh the benefits against the ease of use as well as technical support costs. That is why there are some areas where things may not be done correct from a pure OOP standpoint.

Toni-
Don't forget that Toni gave you guys a wizard step at VFE DevCon that you can plug into each wizard that allows you to change the parent class.

Mike Feltman
You could tell VFE to create an Application Specific ILibs for this app and change the properties in the new iLibs classes. The wizards will automatically use this new set of iLibs for the project.

Toni-

> I
> come from the DOS world where I never started a
> new program, I merely copied the latest greatest
> program and enhanced it to do what I needed the
> new program to do.

> I am sure this is
> conceptually the same but it certainly is harder
> to get a "handle" on.


The reason you copied everyting was because you didn't want to recode all of the generic stuff that is not specific to a perticular app. Now that you have a framework, you really don't need to do that. The framework /vfe75/vfeframe stays in one place, and all of your projects use it.

> I got to looking and
> find that all the classes in the new cloned
> project point to
> VFE75\ILIBS\variousclasslibs

The ILibs is up for debate what the 'right' way to do it is. Some of us feel that each project should have it's own iLibs, some feel that all projects should share a common ilibs, some feel that each of our clients should have an ilibs, some feel that we shoudl be able to have as many layers of ilibs as we want. dosn't matter who is right, what matters is A) what F1 gives us and B) what you want to do with it. The 'easy' way is to just work with what F1 gives us, but then you are 'limited'. If you 'need' the extra flexability of seperate ilibs, then you need to put in the extra effort and set it up. I would sugest starting with what F1 gives you and don't mess with that like I did, cuz now I regret it.

> So if
> you "clone" a project all the classes in that
> project are the same as in the original project.
> If you changed a class in the cloned project you
> would be changing the class in all the projects
> that contain that class. That is a wonderful
> thing BUT it sure makes it hard to clone a
> project.

The problem here is that what you are cloning (the project dir) is probably everything you don't want in the new project. The project dir should contain the stuff revelent to the project, not the common stuff. F1's common stuff is in the framework dir, and your common stuff is in the iLibs dir.

> I guess you could take the new cloned
> project and save all the classes that will have
> changes specific to this project as different
> classes.

huh? I'm guessing the above will help you with this one.

> If I could just get someone to say
> "Yes, John you are correct" that would
> help.

You are asking the correct questions. ;)

>
> Perhaps someone can help me by
> explaining this piece: I create a FBC. Call it
> FBC_v_xxx_fieldx. Properties shows me it is in
> classlibrary vfe75\ilibs\idata.vcx
>
> Now I hook
> this FBC to a field on a view. The behavior tab
> says the classlibrary is
> vfe75\dev\itf\libs\abhavior.vcx
>
> Does abhavior
> just contain a reference to
> vfe75\ilibs\idata\FBC_v_xxx_fieldx

No. It's the other way around: FBC_v_xxx_fieldx contains a reference to abhavior. Subclasses know who their parent is, parent classes (aka super classes) have no idea if and who the subclasses are.

Category Visual FoxExpress Faq
( Topic last updated: 2003.10.17 07:24:56 PM )