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

[Alex B. <en...@tu...>]

> 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).

I think you're stepping over a bit into the domain of libraries, which is
why you aren't getting quite what you want.

I agree that module communications are important, and I will create
mechanisms to facilitate that communication, but it is certainly not a
requirement I have encountered even in building complex applications.

> 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.

That's not true: you can create as many instances of a class as you like and
have each of those class instances carry a context.

I do that all the time.

>> 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.

And that will always be difficult to do. You'll have to know something about
the page if you're going to do that.

That's ok - but keep that in mind.
 
> 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.

Precisely because of your problems.

It doesn't work well to embed all of your logic in "one place" that is also
responsible for presentation.

If you allow the use of libraries, (i.e. you build your applications that
way) a lot of your problems in that regard go away.

For example, I have a module which lists something, but part of that list
has some data that's derived from the result set of a SQL query. I abstract
the "figure-outer" code that makes that derivative data to a library.

Your error stack stuff is actually a prime example of something that will be
taken care of by the core classes (hopefully PEAR_Error).

Modules should hold what context they need to get presentation out the door
- they are in a sense responsible for assembling your application from its
components (libraries, templates, queries, etc)

modules are where all of the tools should be assembled, and their i/o
coordinated.

> 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.

Why? i.e. why have separate modules for each of those operations? I think
you're thinking of grains of sand, where I'm thinking about gravel :)

Modules are only significant as presentation components - otherwise you're
going through much too much trouble for each module.

> 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.

And, yes, you can do that.
But you'll need to do that 'passing' with global variables for the moment,
because other things need to come first before I dive into this issue.

As far as I am concerned, the lister should be a libaray, and so should the
data collector. That way you have Mod A 'control' which  is exactly what
they are for.

> 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.

There is no advantage over using a library, just use a different named
instance of that library. You can make as many instances of a class as you
like, just use a different variable name.

So you gain nothing by using a modules (except some pain in the a** trying
to get them talking to each other)

> 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?

then have one module responsible for the output, and have 'graph profiles'
which are loaded by the module at runtime.

> 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.

I want to make sure this is 100% clear: you are gaining nothing by using a
module in place of a library.

> MAYBE I AM APPROACHING THIS ALL WRONG.  I donno.

You aren't.

And I intend to 'support' what you are doing: however, you'll have to wait
for a while if you want it to be elegant.

For now, use global variables to do your passing, and you'll be fine.

> 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.

You wouldn't, but I am not in the business of dictating.

I'm not saying "modules can't be used as libraries" I'm saying "the way I
orginally thought about this is that modules would not be libraries... which
is why you aren't finding toold to support what you're doing"

but I _do_ see the value of that you are trying to do. so I'll make it
happen... but not yet.

> 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.

:)

_a


--
alex black, ceo
en...@tu...

the turing studio, inc.
http://www.turingstudio.com

vox+510.666.0074
fax+510.666.0093