Ariel Constenla-Haile wrote:
Hi Frank
Frank Schönheit - Sun Microsystems Germany escribió:
Hi Ariel,
I'd say the latter. I don't really see the need for calling from form A
into form B: If you have code needed in both forms, put it into the
database document. I think cross-document calling would a) make things a
lot more complex, b) make this inconsistent with the other apps (you
cannot call from text document A into text document B, can't you) and c)
open yet another can of worms by making well-defined concepts such as
"ThisComponent" meaningless.
and the other way around: calling from the parent a function within
its child?
I tend to say no. Again, if you have a macro which is *not* needed in
the form only, the put it into the database, where everybody can use it.
Which brings me to another idea I had: Just disallow macros in
forms/reports, only allow them in the database. This would solve most of
the problems :)
This would be a great idea!!! (though what about backwards
compatibility? will it be too much code to implement - not to destroy
the users old data?)
.......................
This was what I thought when I knew that ODB doc. will have macros:
bye bye macros in forms!!!
( forgive me here for thinking out loud.. )
Retain only locations of 'application' and 'document' and when the
document is a form within an odb file it refers to to the odb document,
not the form document.
First - legacy code embedded in forms..not a lot to worry about there
IMO, because of the macro security issue most folks using scripts with
forms already have them in external libraries.
From the stand point of implementing this with forms / reports in
folders, I suppose this makes life simpler. Use of folders is also
limited currently it seems - hopefully however, the idea of a muli-user
Base file ( whether that is with an embedded database or just a shared
container for forms / reports / queries ) is not totally dead and
buried. If so, then when that happens the use of folders becomes much
more important I think. ( should I enter the RFE for folders in the
Query section now or later...*smile* ) However, that alone is a non
issue for this choice I suppose.
Use of folders also makes the new location of 'container' a bit
awkward...unless we think of it as 'containing document', which then
reflects that a simple container is exempted and it is the odb file only
that is referred to.
Thinking of macros in forms as a way of attaching code directly to UI
controls one is quick to jump to the conclusion that this is a bad
thing. Poor design with too much coupling of UI to function.
So yes, why have script libraries at the form level at all then?
But now look at a form another way perhaps.
As a class -
It is an aggregate and parameterized class
It has public and private data interfaces
It has public and private methods.
In the implementation used by Base it does not support inheritance, but
that most definitely does not preclude re-use.
It is then an example of component based development, versus pure object
oriented development. The former being implemented by the latter.
Does the class gain anything from a re-use stand point by also carrying
some code? Maybe.
Does it lose anything or diminish its usability from this re-use
perspective by forcing the code to an external location? Again maybe.
Can we build a form that supports custom actions that could be applied
to differing result sets, without having to alter or only minimally
alter, the code implementing those actions? The answer is yes. In these
cases then does it make sense to bind the code to an external location?
I would say no. I also recognize that this is a much less frequent
activity then building one off, single use, forms.
The thoughts here are just what a "common"/"dummy" user would/could do
(let me tell you I've seen almost everything - mostly coming from
former MSAccess users without programming knowledge, and used to
VBasic's Me , DoCmd, etc.)
Ariel, I believe you are touching on principles of good design practices
versus bad ones, and don't really see how forcing the casual database
developer to place all their code in a library at the odb file addresses
this in the long run. It may help, perhaps, ( well, I would be stronger
on this - it would help ) but it will still come down to whether the
person takes the time to research and learn some new skills or not. They
could still write tremendously horrendous scripts, all stored together
in one shared library.
From the casual developers stand point I think taking a hard look at
what is meant by having an Integrated Development Environment for
scripts would render far greater returns. That and a equally hard look
at what functionality is available with the control library supplied.
How much of that could be done realistically both from a resource
standpoint and a institutional focus stand point is the question there, IMO,
Anyway - just some thoughts as I read the email.
Drew
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
