binarycloud-dev

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

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

Alex/Guys:

Now I know it is usually too much to expect for others to
run a piece of code or search for a bug if it is not directly
affecting you.  This is not a complaint, only
an observation of reality  But, first, I
will ask a question to the group.

Are any of you building sites with BC and using inter-module
"communication", that is, fetching variables or calling
methods in another module with the construct:

$return = $Page->modules[group][idx]->foo();

	or
$some_var = $Page->modules[group][idx]->bar;

?????????

IF YOU ARE DOING THIS, DOES IT WORK FOR YOU?

Now, if you are concerned or interested, you can read
farther.  I have been having all kinds of strangeness
trying to make this "intermodule" communications work,
which should just be nothing more, except through
a couple more dereferences, than calling a method
in a class or fetching a var in a class in the
same namespace.

I have experienced all kinds of strangeness.  I have
posted before on this.  I have spent days looking for
the "problem", and and starting to be suspicious of
Zend as well as my own sanity.

Now I have a $bc_page with 4 groups.

1. top		has two modules, EyeLibrary
			and DataDictionary
2. main		has two modules, Lister and
			TestMain
3. left		has one module, TestNavLeft
4. bottom	has  two modules, Warning and
			Blank

SO, if in the TestMain module I put this
little bit of debugging code

global $Page;   
if(1) {
echo "<pre>";
$group  = "top";
$idx    = 0;
$item   =& $Page->modules[$group][$idx];
if (empty($item)) { printf("EMPTY reference in [%s][%d]",$group,$idx); }
print_r($item);
echo "</pre>";

What is rendered is fine, namely
eyelibrary Object
(
[options] => appears 1
)

which is expected, since EyeLibrary is the first in the group.

if I change group to main and idx remains at 0,
what I get is expected, namely the Lister

lister Object
(
[tableOptions] => Array
	snip

BUT IF I LOOK FOR group = "bottom", idx = 0,
I get:
EMPTY reference in [bottom][0]

This is same for the group 'left".  In other
words, I cannot "see" anything in groups 'left'
or 'bottom".

Any ideas?  I have some VERY WILD ones, like Zend
sees, somehow, the method of instantiation that
BC uses as a recursion, and Zend is throwing something
away after three levels.

_jef

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

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

[Jimmy H. <ji...@ha...>]

Justin,

I have tried only briefly to go beyond normal "wow the hello world
works" test on BC. I found it very hard to do what you just mentioned.
For example I wanted to use a 'database' module to perform the query but
you guessed it, it's hard to refer to the module without reverting to
using a global variable.

So I have decided to leave BC for now, and wait till Alex has sorted out
the "Manager" classes and integrated a more complete working system
before I shall spend my time looking at it again.

I particularly find that it ridiculous and tedious to have to write 4
different files to create one simple page. (the htdocs, the layout
template, the module, and module specific layout).

Regards,
Jimmy

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

[alex b. <en...@tu...>]

> Justin,
>
> I have tried only briefly to go beyond normal "wow the hello world
> works" test on BC. I found it very hard to do what you just mentioned.
> For example I wanted to use a 'database' module to perform the query but
> you guessed it, it's hard to refer to the module without reverting to
> using a global variable.

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.

Modules are _only_ for getting output to a page. Modules can include header
redirects, etc - but it's bad form to have a silent logic-only module.

And it will be a pain in the ass to work with :)

I don't have any "very" complex modules in any of my projects, including
large projects. There is never a reason to put that much code in a module.
Of course you can, if you want.

> So I have decided to leave BC for now, and wait till Alex has sorted out
> the "Manager" classes and integrated a more complete working system
> before I shall spend my time looking at it again.

I suggest you read the above. Modules are not the be-all-and-end-all.

> I particularly find that it ridiculous and tedious to have to write 4
> different files to create one simple page. (the htdocs, the layout
> template, the module, and module specific layout).

You don't need a layout template per page.

As opposed to?
How would you suggest cutting down that number, but retaining all the
abilities of the system?

Also, remember that doing page definitions will be made a hell of a lot
easier by a page editor, and by the fact that pages will be done in XML.
Each module will have a declaration file (probably similar to pear's package
declaration format) which will allow a page editor to provide the user with
a list of modules.

best,

_alex

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

[alex b. <en...@tu...>]

> Are any of you building sites with BC and using inter-module
> "communication", that is, fetching variables or calling
> methods in another module with the construct:
>
> $return = $Page->modules[group][idx]->foo();
>
> or
> $some_var = $Page->modules[group][idx]->bar;
>
> ?????????
>
> IF YOU ARE DOING THIS, DOES IT WORK FOR YOU?

I am not doing that. And of course it would not work very well, because it
is 100% relying on the load order, which is of course, page specific.

Why are you calling methods in one module from another module?

> Now, if you are concerned or interested, you can read
> farther.  I have been having all kinds of strangeness
> trying to make this "intermodule" communications work,
> which should just be nothing more, except through
> a couple more dereferences, than calling a method
> in a class or fetching a var in a class in the
> same namespace.

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"

----

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

Or, really for 90% of things, global variables.

> 1. top has two modules, EyeLibrary
> and DataDictionary
> 2. main has two modules, Lister and
> TestMain
> 3. left has one module, TestNavLeft
> 4. bottom has  two modules, Warning and
> Blank
>
> SO, if in the TestMain module I put this
> little bit of debugging code
>
> global $Page;
> if(1) {
> echo "<pre>";
> $group  = "top";
> $idx    = 0;
> $item   =& $Page->modules[$group][$idx];
> if (empty($item)) { printf("EMPTY reference in [%s][%d]",$group,$idx); }
> print_r($item);
> echo "</pre>";
>
> What is rendered is fine, namely
> eyelibrary Object
> (
> [options] => appears 1
> )
>
> which is expected, since EyeLibrary is the first in the group.
>
> if I change group to main and idx remains at 0,
> what I get is expected, namely the Lister
>
> lister Object
> (
> [tableOptions] => Array
> snip
>
> BUT IF I LOOK FOR group = "bottom", idx = 0,
> I get:
> EMPTY reference in [bottom][0]

Have you looked at a printf of the $Page object to see if the thing you are
making reference to exists?

> This is same for the group 'left".  In other
> words, I cannot "see" anything in groups 'left'
> or 'bottom".
>
> Any ideas?  I have some VERY WILD ones, like Zend
> sees, somehow, the method of instantiation that
> BC uses as a recursion, and Zend is throwing something
> away after three levels.

I really, really, _really_ doubt it has _anything_ to do with the zend
engine.

:)

_a

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

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

[binarycloud-dev] Example of Form_Builder

[Jimmy H. <ji...@ha...>]

Hi alex,
is there any examples on using FormBuilder?

Re: [binarycloud-dev] Example of Form_Builder

[alex b. <en...@tu...>]

hi Jimmy,

Yes, you can download the r1tarball and have a look at the knowledgebase
modules...
https://sourceforge.net/project/showfiles.php?group_id=16402&release_id=2667
8

Though, and I must stress this, that version of formbuilder is not entity
aware - it's there because we're probably going to rip some of the parts out
of it that we find useful.

It's good code, and it works, but it's definitely binarycloud r1 stuff. Same
with the current TableBuilder.

_alex


----- Original Message -----
From: "Jimmy Harlindong" <ji...@ha...>
To: <bin...@li...>
Sent: Monday, July 16, 2001 7:20 PM
Subject: [binarycloud-dev] Example of Form_Builder


> Hi alex,
> is there any examples on using FormBuilder?
>
>
>
> _______________________________________________
> binarycloud-dev mailing list
> bin...@li...
> http://lists.sourceforge.net/lists/listinfo/binarycloud-dev
>