Re: [binarycloud-dev] What we have is a failure to communicate....

[Justin F. <je...@ey...>]

Alex:

Hmm, some info/observations.

You asked:
1. Why are you calling methods in one module from another module?

It is interesting that my perception of BC, or what I see
as its advantages, and how it is used, seemingly is different
from yours.  I see BC as a kind of high-speed "class gatherer"
and the model in my mind is that I, sort of, have one big
virtual file with all the classes I need.  Therefore, I "call" other
methods in other classes (cross module).  As an example
if I go fetch from a database in several modules and there
are errors (presumedly non-fatal), I wish to have another
module (class) push these warnings on a stack in the
Warning module, and then when it is Output-time for
Warning, Warning->Output() displays them.  This functionality
is not unlike your $Debug->CaptureMessage() thingy,
(blessedly you can go to global scope!).
Therefore from any module, I want to call methods or
fetch vars from another module (Class).

You talk about importing/including libraries in the
module to do things.  This is certainly possible if
you just need methods that are "self-standing", manipulate
something, return something, and are independant of
any data/data structure/state somewhere else in the platform.

> I think this all depends on whether you need to maintain the state of the
> module you need to talk to - i.e. do you need to differentiate between
> individual instances of the same module, or can it just be "any instance"

Correct.  Sometimes I don't care what instance I talk to, but
when I need state, I have to have one instance somewhere that
I can talk to.

> If it's the former, I think in future we'll deal with that (a manager) - but
> you can do it now with module ids (your tag thing, I implemented it)...

Yes, I am doing that too, it works quite well "in parallel".

2.  Your statement:
> Remember that modules are _only_ intended for presentation - they _are_not_
> libraries.
> If you need general functionality for your applications, make libraries and
> put them in user/lib/, and include them in your modules as normal.

This, er, sort of facinates me.  I am willing in an eyeblink to
change my "method" of using BC.  But I am interested in why you
make that statement, _only_ intended for presentation.   Why?
I am trying to evaluate the advantages of that approach.

I see advantages of creating what I call "Drone Modules" that do
nothing but, say, collect a data set during Constructor-Time
and another instance that collects another data set during
Constructor-Time.  Then, following I have a a couple of "listers"
in the same group, each instance being told (through options, for
example) which Drone to use for its data set to present.  Like
this, I can put up 2 (or N) reports/lists on a page.  It is true
what you say that I could include a class in the module that could
then be used to collect a data set, then another from somewhere
else...  But why is this "better"?  It seems that such coding
diminishes the generality of the module.

I want to do
+---------------+       +---------------+
| Mod A:        |       | Mod B:        |
| Control       |------>| Data Collect  |
|               |       |               |
+---------------+       +---------------+
        |
        |
        |
        v
+---------------+
| Mod C:        |
| Lister        |
|               |
+---------------+

where module A controls things, gets data from module B
and passes it to module C for ultimate display.

The advantage of this is that I can load many instances
of module B and have each one get a different set of
data, and then maybe A shuffles these data sets around
and passes these data sets to module C, which can
_also_ be multiple, each Lister having been set
up (again by a cross module call) for a different
look and feel.

Now A _may_ not have Output(), B certainly does not
have output, and C _may_ do all the output, and if
there are many instances of B and C, I may then
have 23 reports presented on the page, each with
a different dataset and different look and feel.
And, to go blue-sky, what if I wish to use GD
and draw 23 different bar charts?

And, for this, I only have to generalize module B
and module C, they are, for me, my "library" in
functionality.  I keep the unique bits in module A.
And, I retain a kind of ability to change things
dynamically.  You may argue that you can make
conditional includes in module A, I am sure that
would work.  But I see advantages of how I wish
to do it right now, I will have to think a bit
on how you are suggesting that "modules should not
be used as libraries".  My "method" allows for
the possibility to retain state easier, I think.

MAYBE I AM APPROACHING THIS ALL WRONG.  I donno.
I am cutting the salami in a certain way, you are
suggesting another.  It just seems that to write
an "application" that is as complex as a dynamic
report generator, I would have to cut the salami
in my way....  I will give it a think.

And Jimmy, I hope that I was not the cause of
you bailing out.  Alex will be pissed off at me.
But don't go away.  It is a bit of a pain in the
ass to do things right now with this construction
site, but ultimately, it will pay off handsomely.

_jef
-- 
Justin Farnsworth
Eye Integrated Communications
321 South Evans - Suite 203
Greenville, NC 27858 | Tel: (252) 353-0722