binarycloud-dev — development list for binarycloud

Re: [binarycloud-dev] r2 /make

[Angel H. <an...@ho...>]

Angel, try setting the path to BCHOME before typing make. Don't you love it
when the obvious stares you in the face?

-- Me



on 6/28/01 6:39 PM, Angel Hernandez at an...@ho... wrote:

> 
> Urghhh... I feel lame asking this question. BUT what does one need to do in
> order to get a basic install. I tried going into the binarycloud dir and
> typing "make", but the errors seem to imply I need to do more than that ;-)
> 
> Also, does anyone have any good references to URLs, etc that explain
> Makefiles and how to use them - especially in a context as it may apply to
> r2.
> 
> As you can probably tell, I don't really understand r2 yet (or anything that
> deals with make), but I'm convinced it's really worth learning. So any help,
> pointers, etc would be most appreciated. Thanks!
> 
> -- Angel
>

Re: [binarycloud-dev] Er, am I still complaining???

[Alby L. <al...@th...>]

Justin Farnsworth:

First of all, you're not BC bashing by any means, and I think a bunch of us
on the list probably appreciate the example situations in which BC
will/does/or could operate. I agree that it is necessary that administration
services make our lives as web site developers easier when utilizing a
solution like BC that make redundant tasks unecessary.

Personally, I don't really like the idea of multiple instances of BC as they
will be duping the same utilities, however, I don't like the idea of complex
dir trees for simple sites either, with a template here and a module there
in seemingly unrelated directories. So, I thought it might be possible to
implement a more-user-friendly (or was it a more perfect union??) schema.
Whereas the dir tree for BC _as it stands_ has been engineered for various
reasons, it doesn't quite fit with a comfortable administration structure,
could a front end be built for administering the sites that hides the
complexities behind the scenes?

I could be fooling myself with this suggestion, but have always found that
even though many projects are mission critical, the future is so very
unforetold with software it helps to take the time and make administration
easier, even if it takes more time to code up.

I could volunteer to work on this type of thing, unfortunately I haven't
even come close to getting BC2 installed. I gave up my last linux box a
month ago to fun full speed on my current development, which I'll tell about
in my next email for its peculiar attributes with relation to BC2.

Alby Lash
al...@th...

[binarycloud-dev] New build error

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

Alex:

What is the meaning of this error?:

------------------------------------------------------
[root@localhost binarycloud]# pwd
/usr/local/binarycloud
[root@localhost binarycloud]# export BCHOME=/usr/local/binarycloud; make
Building en site
in user
in user/htdocs
in base
in core
in bldr
in init
make[2]: /usr/local/binarycloud/base/utils/processprepend.php: Command
not foundmake[2]: *** [installprepend] Error 127
in lib
in mgr
[root@localhost binarycloud]# 
--------------------------------------------

Are you requiring us to have a php binary all compiled up
and in /usr/local/php4/bin as dictated by the shebang
in processorprepend.php, viz

---------------------------------------
[root@localhost utils]# pwd
/usr/local/binarycloud/base/utils
[root@localhost utils]# head processprepend.php 
#!/usr/local/php4/bin/php -q
<?php
// {{{ Header 
/*
 * -File		$Id: processprepend.php,v 1.3 2001/06/25 17:01:32 odysseas Exp
$
 * -License		LGPL (http://www.gnu.org/copyleft/lesser.html)
 * -Copyright	2001, Intacct Corp.
 * -Author		odysseas tsatalos, ody...@ya...
 */
// }}}
[root@localhost utils]# 
----------------------------------------------

Now I run RedHat 7.1, and php is in /usr/bin, so I edited the
shebang to #!/usr/bin/php -q and got:

--------------------------------------------------------
[root@localhost binarycloud]# pwd
/usr/local/binarycloud
[root@localhost binarycloud]# export BCHOME=/usr/local/binarycloud; make
Building en site
in user
in user/htdocs
in base
in core
in bldr
in init
in lib
in mgr
[root@localhost binarycloud]# 
---------------------------------------

This might be useful for the people on the list that have
had problems.  I also suggest that, in the Makefile
you test for the existence of files that you are going to use
and either tell the user what is missing, or have the Makefile
go out and find what is needed.....

_jef

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

[binarycloud-dev] The obvious is always humbling...

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

Alex:

In my previous _long_ post about my administrative problems,
it just occurred to me that there seems to be a work-around
to organize the file tree, to do what I wanted.  I haven't
checked it out yet, but see no reason not to use

-/binarycloud/--+
                |-user--|-the_common_stuff_here
                |
                |-site1-|-mod---
                |       |       
                        |-tmpl--|-html--|-masters
                                        |-layouts
                |-site2-|-mod---
                |       |
                        |-tmpl--|-html--|-masters
                                        |-layouts
                |-site3-|-mod---
                |       |
                        |-tmpl--|-html--|-masters
                                        |-layouts

and then, in (as an example) index.php something
like the following stanza for templates

        'templates' => array(
                'def' => array(
                        'path'  =>
"../../site_name/tmpl/html/masters/main.3pane.tmpl",
                        'type'   => "html",
                        ),
                '3pane' => array(
                        'path'  =>
"../../site_name/tmpl/html/masters/main.3pane.tmpl",
                        'type'   => "html",
                        ),
                '4pane' => array(
                        'path'  =>
"../../site_name/tmpl/html/masters/main.4pane.tmpl",
                        'type'   => "html",
                        ),
                ),

and similarly, with layouts, do the old

	../../site_name/tmpl/html/layouts/main.layout

trick.

I donno.  It makes me wonder about the "cost" of PHP/Apache doing
all that directory work all up and down the line.  That is at least
six directory "searches" for each of those file includes.

Any comments?  As an aside, does anybody on this list (worry about)/havv
these administration concerns?  

Regards,

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

[binarycloud-dev] Er, am I still complaining???

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

Alex:

I have downloaded the latest r2 tarball with the "make system"
embedded, the slimmed-down Page, and the change in module
structure by making X->Init() into a constructor.

Now, I don't yet have my arms around this new thingy, but
I must express my happiness with make(1) being used, because
I can add my own targets for "administrative" matters.  FYI,
I love make, and probably have 30 targets in  typical
makefiles for our site(s) administration.

Still, and I don't claim that you intended to solve my
administrative problems with BC.  But, I think that this
email will be useful, again, to show what we, a small
developer with about 40 sites, are up against.
I suppose that there is a philosophical clash, as, to
me, BC is designed with a mindset of it being for
"one site", while youse guys say, "No, you make different
sites with different modules" or some such.

There is a wider context, and here it is.  The file layout
for us, is:

--HTTPD_ROOT--	+
		|-site_name0-
		|-site_name1-
		|-site_name2-

and so on, for each site, and with virtual servers pointing
to site_nameN

and for binarycloud:

/usr/local/binarycloud/-+
			|-user--|-mod---|-site_name-
				|
				|-tmpl--|-html--|-masters
						|-layouts


With this structure I have some issues:
1.  For the site-specific modules, it is OK because
	I can avoid name clashes with a subdirectory
	that is "accommodated" in BC.
2.  For the masters, I feel cheated, because I have
	to add another subdirectory for each site.
	I am going to have, at least, one "main.tmpl"
	for each site.  I DON'T WANT to name my
	templates main.acmecorp.tmpl, main.foobiz.tmpl
3.  For the layouts, the same problems exist as for
	the masters.  We are going to have a _lot_ of
	layouts (our company is run by artists) and
	to avoid name clashes, I don't want to have
	to have
		page1.acmecorp.layout
		page7.xyxbiz.layout
		page3.foocompany.layout
	in one directory, ergo the subdir "necessity".
4.  For the server root, it is as above, and there
	is "no problem"
5.  Now for any site, with BC, there are at least
	two trees (minimum) to deal with for those
	administrative matters such as backing up,
	archiving, and using CVS.  The minimum
	would be the HTTPD_ROOT/site_name and
	er, what the whole bloody BC user subtree.
6.  How do I work at home, or even at work, with
	CVS, for example.  With the present file
	layout, I have to have a module rooted at
	the webserver subdirectory site_name, this
	is OK.  But where do I CVS to work on
	site-specific modules, or site-specific
	layouts, or site-specific templates?
	Do I have to bring over the whole bloody
	sub-tree starting at BC_PATH/user?  I
	don't want all that.
7.  To solve the name clash problem, if I put site_name
	subdirectories under masters and layouts,
	I now have three sub-tree "units" for each
	site.  Sure, I can consider these three
	sub-trees as a "site" in my backup planning,
	my CVS planning, my development server to
	production planning.
8.  BUT, some sites will use the "common modules"
	that we wish to develop.  So, what do we
	do, I suppose establish a ./common subdir
	under ./user/mod, and make this a "node"
	for our administration needs.  That way,
	I could CVS this sub-tree, backup this
	subtree, copy to production this subtree
	et cetera.

I donno, I don't have a plan yet.  I may have to do
some silliness with establishing symbolic links to
reduce the complexity of administration, or something
else.

Can I take risks like overriding things like
BC_PATH_USER or BC_PATH_MOD.  I don't even want to
go there, because you may break me in a future
release.

I don't know if I am explaining my problems well.  Be
gentle, and try to understand that I want things
to be easy to administrate, it is a huge, flippin'
headache in everyday life.  So, although I have not
thought this out well, it seems that a way to
reduce my problems would be

-/binarycloud/--+
                |-user--|-the_common_stuff_here
		|
                |-site1-|-mod---
                |       |       
                        |-tmpl--|-html--|-masters
                                        |-layouts
                |-site2-|-mod---
                |       |
                        |-tmpl--|-html--|-masters
                                        |-layouts
                |-site3-|-mod---
                |       |
                        |-tmpl--|-html--|-masters
                                        |-layouts

Now,  I only have 2 trees to deal with for a site (unless I
want to work on the common_stuff, I can work at
home and checkout things like:
	site1-bc (site1 tree above)
	site1-docroot (site1 in the server DOC_ROOT)
	bcuser (the common stuff)
	site23-bc
	site19-docroot

or archive these, or delete these, or move these.
The above would require some ability of overiding
system_constants, or integrate some true
user (as in client, not BC user) definitions.
Right now, in any index.php for defining a layout
file, or a template file, I can't get above the
html directory.  For modules, I cannot get above
./user/mod.

This is not whining.  My estimation for BC remains
high.  It just seems like the anticipated great
payoff of using BC is somehow diminished by a
greater administrative load, besides the necessity
to cd a lot because relative cd'ing is "broken".


Regards,

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

Re: [binarycloud-dev] r2 /make

[TAO R. <ron...@ho...>]

alex,

is it ready in CVS...???
I can't get any update from CVS source tree....

ronald

>
>hi all,
>
>http://www.binarycloud.com/download/
>
>for your downloading pleasure.
>
>This is r2, with make and the second revision of Page.
>
>have at it :)
>
>
>--
>alex black, ceo
>en...@tu...
>
>the turing studio, inc.
>http://www.turingstudio.com
>
>vox+510.666.0074
>fax+510.666.0093
>
>
>
>_______________________________________________
>binarycloud-dev mailing list
>bin...@li...
>http://lists.sourceforge.net/lists/listinfo/binarycloud-dev

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Re: [binarycloud-dev] r2 /make

[Angel H. <an...@ho...>]

Urghhh... I feel lame asking this question. BUT what does one need to do in
order to get a basic install. I tried going into the binarycloud dir and
typing "make", but the errors seem to imply I need to do more than that ;-)

Also, does anyone have any good references to URLs, etc that explain
Makefiles and how to use them - especially in a context as it may apply to
r2.

As you can probably tell, I don't really understand r2 yet (or anything that
deals with make), but I'm convinced it's really worth learning. So any help,
pointers, etc would be most appreciated. Thanks!

-- Angel


on 6/28/01 5:25 PM, Alex Black at en...@tu... wrote:

> hi all,
> 
> http://www.binarycloud.com/download/
> 
> for your downloading pleasure.
> 
> This is r2, with make and the second revision of Page.
> 
> have at it :)
> 
> 
> --
> alex black, ceo
> en...@tu...
> 
> the turing studio, inc.
> http://www.turingstudio.com
> 
> vox+510.666.0074
> fax+510.666.0093
> 
> 
> 
> _______________________________________________
> binarycloud-dev mailing list
> bin...@li...
> http://lists.sourceforge.net/lists/listinfo/binarycloud-dev

[binarycloud-dev] r2 /make

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

hi all,

http://www.binarycloud.com/download/

for your downloading pleasure.

This is r2, with make and the second revision of Page.

have at it :)


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

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

vox+510.666.0074
fax+510.666.0093

Re: [binarycloud-dev] Can't wait

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

make will be out soon, everyone... doing some other misc foo, but I expect
to have that release mucho soon-o :)

_a

> I can't wait to see r2 released.... :)
> Come on alex !!! :)
> 
> 
> 
> _______________________________________________
> binarycloud-dev mailing list
> bin...@li...
> http://lists.sourceforge.net/lists/listinfo/binarycloud-dev
> 


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

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

vox+510.666.0074
fax+510.666.0093

[binarycloud-dev] Can't wait

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

I can't wait to see r2 released.... :)
Come on alex !!! :)

Re: [binarycloud-dev] A Request for "A Standard"

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

> heh i already had that dream like 2 years ago...now i'm just waiting for bc2
> to try and build it ;)
> 
> alex if you need help with that lemme know, i'd be glad to share ideas with
> you that i've had in the past.
> 
> //.seth b --> www.subimage.com

go! any and all... :)

_alex



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

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

vox+510.666.0074
fax+510.666.0093

RE: [binarycloud-dev] A Request for "A Standard"

[Seth B. <se...@su...>]

heh i already had that dream like 2 years ago...now i'm just waiting for bc2
to try and build it ;)

alex if you need help with that lemme know, i'd be glad to share ideas with
you that i've had in the past.

//.seth b --> www.subimage.com

> -----Original Message-----
> From: bin...@li...
> [mailto:bin...@li...]On Behalf Of Michael
> Kimsal
> Sent: Wednesday, June 27, 2001 5:23 PM
> To: bin...@li...
> Subject: Re: [binarycloud-dev] A Request for "A Standard"
>
>
>
> >
> > We fantisize a lot here about BC.  We were blue-sky-ing
> > the other day about a kind of "Module Browser", and
> > an application that could select modules and then
> > build a site.  We could put this on a laptop and
> > Marketing could prototype a site on the spot with
> > a customer.  The PROBLEM is, shall we say, is that
> > living here in the South, the customer would likely
> > say, "Sheeeat, I ain't a-gonna pay you XX thousand fer
> > that, ya jes built it in 5 minutes....".
> >
>
>
> Right on - that's the BIGGEST damn problem we face.  Levity aside,
> it's a real problem.  Almost makes you NOT want to bother creating
> cool tools to do stuff quickly, if you can't turn around projects
> quickly cause people think it's not 'worth it' if you can deliver
> something on time with no major show stopping bugs.
>
> But coming up with cool tools is still, well, so cool... :)
>
> Carry on.
>
>
>
>
>
> _______________________________________________
> binarycloud-dev mailing list
> bin...@li...
> http://lists.sourceforge.net/lists/listinfo/binarycloud-dev
>

Re: [binarycloud-dev] A Request for "A Standard"

[Michael K. <mi...@ta...>]

> 
> We fantisize a lot here about BC.  We were blue-sky-ing
> the other day about a kind of "Module Browser", and
> an application that could select modules and then
> build a site.  We could put this on a laptop and
> Marketing could prototype a site on the spot with
> a customer.  The PROBLEM is, shall we say, is that
> living here in the South, the customer would likely
> say, "Sheeeat, I ain't a-gonna pay you XX thousand fer
> that, ya jes built it in 5 minutes....".
> 


Right on - that's the BIGGEST damn problem we face.  Levity aside,
it's a real problem.  Almost makes you NOT want to bother creating
cool tools to do stuff quickly, if you can't turn around projects 
quickly cause people think it's not 'worth it' if you can deliver 
something on time with no major show stopping bugs.

But coming up with cool tools is still, well, so cool... :)

Carry on.

Re: [binarycloud-dev] A Request for "A Standard"

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

> Ummm, this discussion/interchange has been interesting for
> me.  Lordy, there are things I haven't thought about that
> BC is going to allow.  This bloody BC is as accommodating
> as a Bangkok cathouse.  I have to confess that I didn't
> even consider a 1st-loaded library class to serve for my,
> er, what shall I say, "global-but-not-global-scope" storage place.
> In a way, I have sinned by suggesting global scope,
> something that is a no-no in C.  Mea culpa.

I'm not entirely convinced yet that a core class isn't necessary, but so
_far_ I haven't been able to find any conditions in my head that would make
its existence necessary. We'll see.

> And, well, I am starting to think about the wonderful
> possibilities of calling $some_module->Init($options)
> from elsewhere (anywhere if loaded later) just to get
> different data from that module's Init(), that, with an
> option "directive", would store it in, say, a variable in a
> 1st-loaded library class variable.  Like you say,
> of course, these mothers can already talk globally
> and tete-a-tete.  I see now that I don't need a
> global BC_LUNCHBOX which now seems to appear to me as
> a kind of vulgar cut buffer. [NOW DEPRECATED]

hehe

Note that Init() no longer exists. it's the constructor now instead.

Also, you would probably want to do the "passing" with class variables in
the module:

$this->moo;
which would end up being something like

$Page->modules[x]->moo (or something, I didn't look)

> I can see/understand your "dilemma" about possibly
> establishing a kind of standard class/library that is
> loaded on initialization by BC.  What I hope is that
> the design will somehow be such that module writers
> all over the place will _tend_ to do data passing in
> a kind of "standard" way, that will allow a minimum
> of rewriting for local conditions.  This is the ultimate attractiviness
> of BC for someone, who, for example, needs some  M$Word guru
> somewhere, someplace, to contribute a WORD.DOC to
> HTML translation module.  I certainly could not do it,
> and therefore I am going to have to depend upon the
> kindness of strangers.

Word to html is pretty much covered, I have an applescript _now_ that cleans
xml+html+goober ms word html export.

That will become php, and part of something else, which will allow joe
schmoe to paste in a word doc html export and get clean code out the other
end.

It is doable! I can see the liiiiiiiiiiiiiight!

> Don't let me slow you down on unimportant matters right
> now, but, what is going to be the infrastructure
> or place for contributed modules?

I have considered a pear-ish infrastructure far into the future, but to be
honest it should be only a question of gathering developers to make
binarycloud more of a tool than brochureware. Installing modules would
really be like "tar -xzf foo.tgz ../binarycloud/user/mod/" and have a nice
day.

if you don't like the module:

rm -rf ../binarycloud/user/mod/foo/

there will be shell scripts for doing install/remove automatically (and
maybe even a browser interface or something)

For binarycloud, I imagine a directory of user/contributors, a cvs browser,
a bug tracker, and a module repository. probably forums, too.

> We fantisize a lot here about BC.  We were blue-sky-ing
> the other day about a kind of "Module Browser", and
> an application that could select modules and then
> build a site.  We could put this on a laptop and
> Marketing could prototype a site on the spot with
> a customer.  The PROBLEM is, shall we say, is that
> living here in the South, the customer would likely
> say, "Sheeeat, I ain't a-gonna pay you XX thousand fer
> that, ya jes built it in 5 minutes....".

Though, uh, you could actually do that :)

> That last paragraph was for levity only.

But, you could :)

_a


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

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

vox+510.666.0074
fax+510.666.0093

Re: [binarycloud-dev] A Request for "A Standard"

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

Alex:

Ummm, this discussion/interchange has been interesting for
me.  Lordy, there are things I haven't thought about that
BC is going to allow.  This bloody BC is as accommodating
as a Bangkok cathouse.  I have to confess that I didn't
even consider a 1st-loaded library class to serve for my,
er, what shall I say, "global-but-not-global-scope" storage place.
In a way, I have sinned by suggesting global scope,
something that is a no-no in C.  Mea culpa.

And, well, I am starting to think about the wonderful
possibilities of calling $some_module->Init($options)
from elsewhere (anywhere if loaded later) just to get
different data from that module's Init(), that, with an
option "directive", would store it in, say, a variable in a
1st-loaded library class variable.  Like you say,
of course, these mothers can already talk globally
and tete-a-tete.  I see now that I don't need a
global BC_LUNCHBOX which now seems to appear to me as
a kind of vulgar cut buffer. [NOW DEPRECATED]

I can see/understand your "dilemma" about possibly
establishing a kind of standard class/library that is
loaded on initialization by BC.  What I hope is that
the design will somehow be such that module writers
all over the place will _tend_ to do data passing in
a kind of "standard" way, that will allow a minimum
of rewriting for local conditions.  This is the ultimate attractiviness
of BC for someone, who, for example, needs some  M$Word guru
somewhere, someplace, to contribute a WORD.DOC to
HTML translation module.  I certainly could not do it,
and therefore I am going to have to depend upon the
kindness of strangers.

Don't let me slow you down on unimportant matters right
now, but, what is going to be the infrastructure
or place for contributed modules?

We fantisize a lot here about BC.  We were blue-sky-ing
the other day about a kind of "Module Browser", and
an application that could select modules and then
build a site.  We could put this on a laptop and
Marketing could prototype a site on the spot with
a customer.  The PROBLEM is, shall we say, is that
living here in the South, the customer would likely
say, "Sheeeat, I ain't a-gonna pay you XX thousand fer
that, ya jes built it in 5 minutes....".

That last paragraph was for levity only.

Regards,

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

Re: [binarycloud-dev] A Request for "A Standard"

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

> Now this is NOT the start of a polemic.  And, remember, the
> end result of this request is one line in Init establishing
> an array called, for example, BC_LUNCHBOX, in global scope.
> This would not, I allege, cause you to be injustly accused
> of forcing policy.

it would likely be a class, but I did a little more thinking with odysseas
about this one:

    -a) given that you control load order, you can just have the modules
talk to themselves.
    -b) yes, we could make a simple class, and yes, we may well end up doing
that. but at the moment I don't see the reason.

say you did exactly what you described in your earlier mail. all you would
need to do is get the property from page.

> And now, dah, dah, for the "complex example" that intersects
> with, shall we say, maintainability and administration of
> 500 web sites that need/use the great circle distance
> between two ZIP's.

cool!

> 1.  This site for bird lovers-in-detail has a computation
> ability to determine how long certain types of
> birds take to fly between cities.  The distance
> is computed, then a table is looked into for
> average MPH for a particular type of bird.

Holy crap that's esoteric! I love it!

> 2.  This site for bird lovers-in-extreme-detail has
> the same thing, but, but, they want the site
> to go to the US weather bureau and get the current
> prevailing wind, compensate for the flight direction,
> and give the time for flight.

Whee!

> 3.  This site for bird lovers-in-really-extreme-detail has
>       the same thing, but, but, they want the site
>       to go to the US weather bureau and get the current
>       prevailing wind, compensate for the flight direction,
> and THEN take into consideration the day of the year
> because the cuckolded titmouse is known to fly faster
> in the summer than the winter -- and give the time for flight.

Ok.

> 4.  This site for glider pilots wants the same-kind-of thing
> but wants a look-up table for glider types.
> 
> n-1.
> n.
> 500.
> 
> Yes, I know, I could do some libraries, and maybe I am thinking
> wrongly.  But, by simply loading in sequence a set of maybe
> 3-5 modules I could solve a _lot_ of problems by refining the
> granularity if I have data passing.

Wait, why?

Why would you not have a library class that you can send some params lik
wind speed, bird type, bird mph, etc and get a result back?

How about a simpler example:

    I have a map module. It displays a map of some address, say a defailt
address initially.
    On the same page, I have a "customer display" module. That contains some
address info.


Say I wanted to have the map module display the customer location based on
the customer being displayed in the other modules.

Why not have the customer modules make that variable available in itself?
Then we load the customer module first, and the map module looks at the
customer modules and displays that address.

What I'm trying to say is you don't need that global array, but you can have
the modules directly talk to one another. Eliminate the bureaucracy, as it
were.

> I sure as hell am not going to design 500 different modules.
> I will pay the price of the exposure of having to design 500
> different layouts.  I also, by module loading order, have the
> ability of dynamic "switching" by, say, loading different
> look-up tables, or even different methods of, say, Great
> Circle computations, something that may be necessary in
> Northern Canada where longitude convergence makes certain
> algorithms less accurate than others.

Right, but again I think that application belongs in a lib.

> Fantasy, you say?  Sure.  But I seem to believe that the
> correct "way" to use BC is to atomize down more than you.


I think so.
But the point about BC is you _can_ build your original structure. That's
not how I would do it but that's not the point.

You could build all those modules, and have them talk to each other by
getting variables from each module class. That would work fine.

> do.  BC is a Lego set for me, and I like to build to finer
> detail, therefore, my perception of BC is that it allows
> to build with small pieces, not large pieces that are
> "application size".

You can build both!

> NOW, I STILL DON'T know what these mystical "Managers" are
> going to look like.  Are they going to allow me to do
> generic queries for ZIP on potentially 500 databases of
> different names and ZIP imbedded in potentially 10
> different field names in potentially 10 different table
> names, AND STILL USE SOMETHING LIKE one generic, but
> configurable, module that solves all requirements from
> 500 customers?  I donno.  I certainly can imagine that

Yes.

> for some reason or other, I would wish to simply insert
> one extremely "thin" module in between module 3 and
> module 4 merely to use Init() (Output just returns)
> to go look something
> up in a database and deposit the data behind it
> for use, or for overriding data that the previous
> module computed, that succeeding modules _may_
> expect.

Right! and you can do that.

> And, I have not even addressed the great promise of BC that
> is important for me, namely the hope that I will be
> able to snarf BC modules from other developers, while
> contributing modules for public consumption, WHILE
> NOT having to, say, install 100 libraries that are
> necessary for these feriners-gewritten-Kode.  I think
> that a data-passing facility would allow greater
> compatability for exchange.

I completely agree!
But I don't see the need for a controlling class for this stuff. I think you
can just have the modules talk directly to each other. no reason to put in
an intermediary.

> I donno.  I have started thinking this way, I will
> keep thinking about it.  Maybe I don't need data
> passing to trailing modules...  It seems like it
> would be useful, right now.

You absolutely do need it. But, you can do it now :)

_a



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

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

vox+510.666.0074
fax+510.666.0093

Re: [binarycloud-dev] A Request for "A Standard"

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

Alex Black wrote:
> hi Justin,
> 
> that sounds like one module with a library to me.

Un, uh
 
> so, you have the library compute great circle,
> do a query for the store,
> spit it into a template,
> and output.
> I echo Odysseas' response re: a view on a set... though I will now try and
> create scenarios in my head for needing module communication. :)
	.......

> > I don't think this is a trivial request, because if
> > BC grows up to be big, and people "use" data dropping
> > and picking up from a built-in a standard place, the
> > ultimate interchange of code between developers would
> > become easier.
> 
> I think you may be right, though I need to come up with a complex example
> that would force me into it :)

----------------------------
Now this is NOT the start of a polemic.  And, remember, the
end result of this request is one line in Init establishing
an array called, for example, BC_LUNCHBOX, in global scope.
This would not, I allege, cause you to be injustly accused
of forcing policy.

And now, dah, dah, for the "complex example" that intersects
with, shall we say, maintainability and administration of
500 web sites that need/use the great circle distance
between two ZIP's.

1.  This site for bird lovers-in-detail has a computation
	ability to determine how long certain types of
	birds take to fly between cities.  The distance
	is computed, then a table is looked into for
	average MPH for a particular type of bird.
2.  This site for bird lovers-in-extreme-detail has
	the same thing, but, but, they want the site
	to go to the US weather bureau and get the current
	prevailing wind, compensate for the flight direction,
	and give the time for flight.
3.  This site for bird lovers-in-really-extreme-detail has
        the same thing, but, but, they want the site
        to go to the US weather bureau and get the current
        prevailing wind, compensate for the flight direction,
	and THEN take into consideration the day of the year
	because the cuckolded titmouse is known to fly faster
	in the summer than the winter -- and give the time for flight.
4.  This site for glider pilots wants the same-kind-of thing
	but wants a look-up table for glider types.

n-1.
n.
500.

Yes, I know, I could do some libraries, and maybe I am thinking
wrongly.  But, by simply loading in sequence a set of maybe
3-5 modules I could solve a _lot_ of problems by refining the
granularity if I have data passing.

I sure as hell am not going to design 500 different modules.
I will pay the price of the exposure of having to design 500
different layouts.  I also, by module loading order, have the
ability of dynamic "switching" by, say, loading different
look-up tables, or even different methods of, say, Great
Circle computations, something that may be necessary in
Northern Canada where longitude convergence makes certain
algorithms less accurate than others.

Fantasy, you say?  Sure.  But I seem to believe that the
correct "way" to use BC is to atomize down more than you.
do.  BC is a Lego set for me, and I like to build to finer
detail, therefore, my perception of BC is that it allows
to build with small pieces, not large pieces that are
"application size".

NOW, I STILL DON'T know what these mystical "Managers" are
going to look like.  Are they going to allow me to do
generic queries for ZIP on potentially 500 databases of
different names and ZIP imbedded in potentially 10
different field names in potentially 10 different table
names, AND STILL USE SOMETHING LIKE one generic, but
configurable, module that solves all requirements from
500 customers?  I donno.  I certainly can imagine that
for some reason or other, I would wish to simply insert
one extremely "thin" module in between module 3 and
module 4 merely to use Init() (Output just returns)
to go look something
up in a database and deposit the data behind it
for use, or for overriding data that the previous
module computed, that succeeding modules _may_
expect.

And, I have not even addressed the great promise of BC that
is important for me, namely the hope that I will be
able to snarf BC modules from other developers, while
contributing modules for public consumption, WHILE
NOT having to, say, install 100 libraries that are
necessary for these feriners-gewritten-Kode.  I think
that a data-passing facility would allow greater
compatability for exchange.

I donno.  I have started thinking this way, I will
keep thinking about it.  Maybe I don't need data
passing to trailing modules...  It seems like it
would be useful, right now.

Regards,

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

Re: [binarycloud-dev] A Request for "A Standard"

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

> Here is an example to illustrate.  Let us say that we are
> trying to give the location of the nearest ACME CORP store
> to the site user, based upon the entry of the site user's
> ZIP code.  Our module load order may be, after the round
> trip passing in the ZIP:
> 
> 1.  Module with some decoration output
> 2.  Module to merely compute great circle distance,
> no output
> 3.  Module to get the nearest store out of the
> database, no output
> 4.  Module with some decoration and output of result

hi Justin,

that sounds like one module with a library to me.

so, you have the library compute great circle,
do a query for the store,
spit it into a template,
and output.

I echo Odysseas' response re: a view on a set... though I will now try and
create scenarios in my head for needing module communication. :)

> For this example data has to be dropped into global
> scope, Hansel and Gretel style, by module 2 for module 3.
> Then data has to be put into global scope by module 3
> for module 4.
>
> THIS IS NO PROBLEM with the facility of BC.  But, in
> a production environment, when our business is going to
> create numerous modules that maybe do tasks that only
> differ slightly, and depend upon data "passed in" from
> a previous manipulation of an upstream module, we have
> to agree among ourself as to the place where this data
> will be picked up, and results dropped.  So, we may
> do something like, everything will be stuck in
> the EYE_LUNCHBOX array/data structure, and comments will be put in
> the module source as to where it expects things,
> and where it will drop things in the EYE_LUNCHBOX
> datastructure/array.

what do you think about the above?

> This is still no problem.  However, one of the advantages
> of BC will be the contribution or interchange with other
> developers of BC modules.  Probably every shop will have
> its "own conventions", and foreign modules may have to
> be tweaked slightly.

it is my hope that the tweaking is done with subclasses and custom templates
only, so everyone can keep pretty clean installs.

> As I said, this is no problem, but I think it would
> be a good idea to consider that BC supplies upon
> initialization a standard place for data passing.
> Sure, we could do it, and put "EYE_LUNCHBOX[]" into
> our copy of Init.  But, I would rather you supply the
> facility, and that this would be available for all
> BC users.  You are not going to dictate that data
> to be passed has to go there.  But, by you setting
> up this facility, at least everybody could start
> using it.
> 
> I don't think this is a trivial request, because if
> BC grows up to be big, and people "use" data dropping
> and picking up from a built-in standard place, the
> ultimate interchange of code between developers would
> become easier.

I think you may be right, though I need to come up with a complex example
that would force me into it :)

_a


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

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

vox+510.666.0074
fax+510.666.0093

Re: [binarycloud-dev] A Request for "A Standard"

[Odysseas T. <ody...@ya...>]

Justin,

Thats a good suggestion and we will look into 
creating a standard communication "bus", where
modules can talk to or listen in.

Keep in mind though that such a facility is 
more applicable when you have indendently created
modules as opposed to use it for the communication
between the "pieces" of your application.

To give an example: 
my.yahoo could use a similar "bus" architecture to
let the various modules in my.yahoo page be aware
of stock tickers that you are adding in your
portfolio.
For example the stock news module will prioritize high
news about companies whose ticker you are monitoring
in the
stock portfolio module.

However thats not how Yahoo did it.
It decided to see the two modules (portfolio, stock
news etc) as just viewports of one integrated
application. All these viewports are agreeing on
common structures that are either in the DB or in  
Session vars. 

There is no reason to argue which approach is good or
bad. Simply understand that there contexts where one
may be more applicable than the other.

odysseas

--- Justin F
arnsworth <je...@ey...> wrote:
> Alex:
> 
> We are still futzing along with development of
> modules that
> will ultimately be used in our production sites,
> with the
> r2 constraints.  Our enthusiasm for the BC model and
> the
> implications for the future, remains unabated.
> 
> Now, one of the things that we feel a "need" for is
> a way
> to pass data downstream from one module to another. 
> It
> may be that we are using BC in a way that is
> unanticipated,
> but our way, right now, is what we think best.
> 
> Here is an example to illustrate.  Let us say that
> we are
> trying to give the location of the nearest ACME CORP
> store
> to the site user, based upon the entry of the site
> user's
> ZIP code.  Our module load order may be, after the
> round
> trip passing in the ZIP:
> 
> 1.  Module with some decoration output
> 2.  Module to merely compute great circle distance,
> 	no output
> 3.  Module to get the nearest store out of the
> 	database, no output
> 4.  Module with some decoration and output of result
> 
> 
> For this example data has to be dropped into global
> scope, Hansel and Gretel style, by module 2 for
> module 3.
> Then data has to be put into global scope by module
> 3
> for module 4.
> 
> THIS IS NO PROBLEM with the facility of BC.  But, in
> a production environment, when our business is going
> to
> create numerous modules that maybe do tasks that
> only
> differ slightly, and depend upon data "passed in"
> from
> a previous manipulation of an upstream module, we
> have
> to agree among ourself as to the place where this
> data
> will be picked up, and results dropped.  So, we may
> do something like, everything will be stuck in
> the EYE_LUNCHBOX array/data structure, and comments
> will be put in
> the module source as to where it expects things,
> and where it will drop things in the EYE_LUNCHBOX
> datastructure/array.
> 
> This is still no problem.  However, one of the
> advantages
> of BC will be the contribution or interchange with
> other
> developers of BC modules.  Probably every shop will
> have
> its "own conventions", and foreign modules may have
> to
> be tweaked slightly.
> 
> As I said, this is no problem, but I think it would
> be a good idea to consider that BC supplies upon
> initialization a standard place for data passing.
> Sure, we could do it, and put "EYE_LUNCHBOX[]" into
> our copy of Init.  But, I would rather you supply
> the
> facility, and that this would be available for all
> BC users.  You are not going to dictate that data
> to be passed has to go there.  But, by you setting
> up this facility, at least everybody could start
> using it.
> 
> I don't think this is a trivial request, because if
> BC grows up to be big, and people "use" data
> dropping
> and picking up from a built-in standard place, the
> ultimate interchange of code between developers
> would
> become easier.
> 
> Regards,
> -- 
> Justin Farnsworth
> Eye Integrated Communications
> 321 South Evans - Suite 203
> Greenville, NC 27858 | Tel: (252) 353-0722
> 
> _______________________________________________
> binarycloud-dev mailing list
> bin...@li...
>
http://lists.sourceforge.net/lists/listinfo/binarycloud-dev


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/

[binarycloud-dev] A Request for "A Standard"

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

Alex:

We are still futzing along with development of modules that
will ultimately be used in our production sites, with the
r2 constraints.  Our enthusiasm for the BC model and the
implications for the future, remains unabated.

Now, one of the things that we feel a "need" for is a way
to pass data downstream from one module to another.  It
may be that we are using BC in a way that is unanticipated,
but our way, right now, is what we think best.

Here is an example to illustrate.  Let us say that we are
trying to give the location of the nearest ACME CORP store
to the site user, based upon the entry of the site user's
ZIP code.  Our module load order may be, after the round
trip passing in the ZIP:

1.  Module with some decoration output
2.  Module to merely compute great circle distance,
	no output
3.  Module to get the nearest store out of the
	database, no output
4.  Module with some decoration and output of result 

For this example data has to be dropped into global
scope, Hansel and Gretel style, by module 2 for module 3.
Then data has to be put into global scope by module 3
for module 4.

THIS IS NO PROBLEM with the facility of BC.  But, in
a production environment, when our business is going to
create numerous modules that maybe do tasks that only
differ slightly, and depend upon data "passed in" from
a previous manipulation of an upstream module, we have
to agree among ourself as to the place where this data
will be picked up, and results dropped.  So, we may
do something like, everything will be stuck in
the EYE_LUNCHBOX array/data structure, and comments will be put in
the module source as to where it expects things,
and where it will drop things in the EYE_LUNCHBOX
datastructure/array.

This is still no problem.  However, one of the advantages
of BC will be the contribution or interchange with other
developers of BC modules.  Probably every shop will have
its "own conventions", and foreign modules may have to
be tweaked slightly.

As I said, this is no problem, but I think it would
be a good idea to consider that BC supplies upon
initialization a standard place for data passing.
Sure, we could do it, and put "EYE_LUNCHBOX[]" into
our copy of Init.  But, I would rather you supply the
facility, and that this would be available for all
BC users.  You are not going to dictate that data
to be passed has to go there.  But, by you setting
up this facility, at least everybody could start
using it.

I don't think this is a trivial request, because if
BC grows up to be big, and people "use" data dropping
and picking up from a built-in standard place, the
ultimate interchange of code between developers would
become easier.

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

[binarycloud-dev] status, + an intro

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

hi all,

to give you all a quick rundown:
    -the make system is complete, and functional
    -the second revision of Page is done, it's now much smaller :)
    -new function called "import" which does the same thing in php that it
does in java, that's part of the reason why page is so much simpler...

I will be doing a cvs synch soon, probably tomorrow onto binarycloud.com, I
encourage you all to have a look.

also, I'd like to introduce Odysseas Tsatalos to you all, he and I have been
working together on the make system and much of the other basic structural
aspects of r2. He knows a lot about php, and system design; I think you'll
all find he knows his s*it in general :)

In future, he'll be playing a more active role on this list, and will play a
key role in r2 builds from now on.

best,

_alex






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

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

vox+510.666.0074
fax+510.666.0093

Re: [binarycloud-dev] Comparison function/sorting in $Page->_init_modules

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

> Perhaps this is a question proper for the PHP list, but since
> I have been scratching my head over something I found in Page.php,
> I am asking for edification.
>
> Now I am an old C programmer and I am familiar with Lvalues
> and Rvalues and memory layout and references.  And I have
> written many a comparison functions to sort data structures
> to pass as arguments into xxx_cmp() functions.
>
> BUT, I don't understand:
>
> uasort($this->modules[$group], array(&$this,'_ary_sort'));
>
> where the second argument is "normally" supposed to be the
> function to be used for the sorting, user supplied.  I just
> don't understand why this works.  The knee-jerk call would
> be:
>
> uasort($this->modules[$group],&$this->_ary_sort);
>
> which doesn't work, and messing about with it I got a
> facinating error message coughed up by PHP (probably from
> Zeev) that was in transliterated/ASCII'ized Hebrew.  It
> made me pause for a moment to think how marvelous open
> source is......

Yes, the second way was how I did it first. The second gives a reference to
the object, and a separate pointer to the method to use (which I think is
very strange).

> How is this idiom of using an array getting the Lvalue of
> the function???

It's a function of uasort, though there is some new, more elegant code in
the revision of Page.

_alex

> This is probably a waste of everybody's time.  I hope
> someone else wondered.
>
>
> --
> Justin Farnsworth
> Eye Integrated Communications
> 321 South Evans - Suite 203
> Greenville, NC 27858 | Tel: (252) 353-0722

[binarycloud-dev] Comparison function/sorting in $Page->_init_modules

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

Alex:

Perhaps this is a question proper for the PHP list, but since
I have been scratching my head over something I found in Page.php,
I am asking for edification.

Now I am an old C programmer and I am familiar with Lvalues
and Rvalues and memory layout and references.  And I have
written many a comparison functions to sort data structures
to pass as arguments into xxx_cmp() functions.

BUT, I don't understand:

	uasort($this->modules[$group], array(&$this,'_ary_sort'));

where the second argument is "normally" supposed to be the
function to be used for the sorting, user supplied.  I just
don't understand why this works.  The knee-jerk call would
be:

	 uasort($this->modules[$group],&$this->_ary_sort);

which doesn't work, and messing about with it I got a
facinating error message coughed up by PHP (probably from
Zeev) that was in transliterated/ASCII'ized Hebrew.  It
made me pause for a moment to think how marvelous open
source is......

How is this idiom of using an array getting the Lvalue of
the function???

This is probably a waste of everybody's time.  I hope
someone else wondered.


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

Re: [binarycloud-dev] BC File Layout, Production Environment

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

> We have taken our cajones in our hands and lept for BC for
> our future production.  It is scary, but so far so good.
>
> I have some issues.  This is nothing "serious" in a
> technical sense, but I have to enter the subjective realm
> here to give you our comments and experience so far.  This
> experience, and our requirements, which _may_ be typical
> for users of BC, may have some influence on you with
> respect to the next CVS.
>
> I will explain.  Let us say that we are a smaller web
> site developer, with, say, 40 sites.  Although this
> may be inaccurate, it _seems_ to us that you are in
> the mind set that BC is, more or less, for one site.

Sort of. (and let me explain that):

core and all of the utilities, libraries, etc aren't something that needs to
be put in with each installation. I haven't put in any work to think about
how to elegantly handle a central binarycloud core "repository" of files,
but to be honest it would be pretty trivial, whatever I decide.

As long as those files are accessible to the system, there's no reason you
can't run (x) sites on the same server with the same core files.

> So, if I use BC for 40 sites, I must do things like:
>
> 1.  under $BC/user/mod, establish a directory for
> each site such as
> a) acmecorp
> b) xyxcorp
> c) the other 38

I think that would probaby get annoying.

If I were doing that, I'd have 40 separate binarycloud/user/ directories,
one user install per site. Easier to configure, easier to test, and easier
to manage in general.

And there's no reason you can't do that and/or the "single monolithic
package" install, which is what I need for web farm installs + updates.

> to put the unique modules for that site
> 2.  under $BC/user/tmpl/html/masters, establish a
> directory for each site such as
> a) acmecorp
> b) xyzcorp
> c) the other 38
> 3.  under $BC/user/tmpl/html/layouts/, establish a
> directory for each site such as
> a) acmecorp
> b) xyzcorp
> c) the other 38

Again, for 2 or 3 sites, I think that would be fine, 40 and you probably
want to consider separating the installs.

> Now, so far, so good, except there is a hell of a
> lot of cd'ing going on during development changing
> from the site-specific DOCUMENT_ROOT, to the site-specific
> modules, to the site-specific layouts, to the site-specific
> masters.

Yeah, and that's a pain in the ass.

> Now, under the modules, yes Virginia, we anticipate to
> have some general things, but, unless I am missing something
> we are not able to "generalize" _all_ modules,
> and certainly not the master templates or layouts with their
> particular decoration.

Correcto

> This is OK.  We get by our wanderings around in the directory
> tree by sourcing site-specific cd-able variables into bash
> to make life easier.

erg.

> I only wonder, and I have certainly not thought this out like
> you have, to do something like have a "site" directory under
> (I donno, $BC/user???) where a small sub-tree exists that has
> the three things which will be in, er, constant edit, namely
> a) modules
> b) masters
> c) layouts

You can consider /user that "site" directory.
You would have no way of knowing this, but I have simplified the user/ tree
to contain fewer directories, as the make system is capable of some of the
build-time organization I want.

You will also be editing queries, and probably config, so again I think it's
quite safe to assume "user/ = site/".

Now, we could allow you to specify the path (and thus the name) of the user/
directory.

So you could have something like:

binarycloud/
    core/
    sites/
        foo_site/
        boo_site/
        moo_site/

in your source tree.

Again, this is probably trivial, but it still would require a little
thought. :)


> NEXT SUBJECT (BUT RELATED TO ABOVE)
> ===================================
> You have implimented what you call "User Constants" in Init.  Well,
> in this you set useful things like DEBUG flags, currency names,
> currency symbols, et cetera.  This is a very good idea.  But,
> what do I do with 40 sites?  What is the meaning of "user" in this
> case.  If I have a German customer, who wants prices in DM, I have
> to pay attention to overriding the so-called "User Constants".
> If I turn on debugging in "User Constants", suddenly all 40
> sites, in production, start displaying funky debugging information.

Again, the argument for separation of your installs. In my last email, I
mentioned config as a problem with having them all squished together.

Point at which you need to maintain different configs, you should have
separate user/ directories.

> WHAT I WOULD LIKE IS another "level" incorporated into binarycloud
> that would be "site specific".  I would like an environment handled
> for the site, called, say, "Site Constants" that Init would handle
> (by including a site-specific file established at a standard place)
> and which would be convenient to override the "User Constants", which
> for my thinking, are kinda only "system default constants".

I wouldn't make that implicitly part of the system, I'd make that an
optional "make structure" - which would effectively allow you to say "I have
three user directories at foo/ moo/ and boo/, please include them in the
make"

I probably wouldn't want to have another "layer" on top of "user" defaults,
is't much simpler to just maintain separate user/ trees for each project and
their corresponding config.

> Yes, yes, I know I can do workarounds by resetting "User Constants"
> in the $Mod->Init() all over the place, or some other artifice.
> But, I don't want to do that.  For a specific example, I certainly
> want to easily turn debugging on FOR ONE SITE ONLY.

Yes, doing it that way is kludgey and the whole point is to avoid
kludgeyness at all costs :)
Separate user/ trees also solves this problem.

> Therefore, my suggestion is include the abstraction, somehow, of
> a "site layer" in BC.  This could be handled in the 'init' array
> with a gizmo like
> 'site' => 'acmecorp'
> that would then let BC know where to look for some of the files
> it needs in, say, sub-directories of standard places, with the
> subdirectory named "acmecorp".

Which is sort of how it would work.
It would almost certainly be a function of our make-prepend, which would set
the site name in each rendered htdocs.

> All I am asking is for you to think about this, think about my
> problem in a production environment.

And this has been brought up by others, whom I am to have a conversation
with today. What you are asking for is both reasonable and "normal" - and I
see no reason not to allow for multiple user/ trees in the same build
context.

> LAST INSIGNIFICANT BITCH
> ========================
> This is completely subjective, but until I went through the
> code, I was derailed for a while by what I consider your
> excellent nomenclature/taxonomy.  I suggest a nomenclature change...
>
> I do not understand why you call "load_order" by that name,
> since is seems intuitive for me, it should be called
> "init_order" in the $bc_page structure.  For me, it has

That is a very good point. Note that Page has been rewritten (it's tiny,
now) - and I'll change that. Excellent point.

> nothing to do with "loading", but represents the order of
> "initializing" (very clever, BTW).  For a while I though
> this was a control that ordered the module DATA collection
> as the page content was built up from modules.  I thought,
> geez, great, if I wish to change the module content order,
> I change the load order instead of moving the arrays around
> in the $bc_page hash.

yep!
but, it is _VERY_ important to note that there is no "print" order: we
assume (I think reasonably so) that you want the modules printed in the
order they were specified, assuming you are not using a module layout.

> I also would not mind having modules being accessable by name
> in the layouts (am I driving you crazy yet?) instead of doing
> things like:
>
> <?php echo $Page->output['content'][1]; ?>
> HTML DECORATION HERE
> <?php echo $Page->output['content'][7]; ?>
> HTML DECORATION HERE

Agreed, and I believe this will happen.

> because I have to make sure I align the $bc_page hash
> with the layout by the order of the module in the hash.
> I would rather only have to remember the name of the
> piece that I had to put in the layout, viz:
>
> <?php echo $Page->output['content']['julie_bio']; ?>
> HTML DECORATION HERE
> <?php echo $Page->output['content']['julie_nude_pics']; ?>

there is a problem with that:
you can have the same module printed on the same page as many times as you
want.
actually, the current r2 test page does just that.

$Page->output['content']['module'];
is meaningless in that context, which _one_ should I output?

becuase you can pass in options, each of these modules with the same name
could out put vastly different markup.

another way to support that is to make you explicitly "name" each module in
a page definition array.

I did that for a while, and it annoyed me. So I killed it.

Part of the revisions of Page a bit later will include an abstraction of all
that stuff which will use an external class to do template application.

> I don't know if a "parallel" named hash could be built up
> in Page with these named keys in addition to the simple
> index array.  Making two arrays for the content is
> perhaps an expensive solution (although BC is not necessarily
> designed to be fleet-of-foot).

Doing a paralell thing would not work, because the class instances of the
modules is actually stored within $Page->modules.

and BC _is_ designed to be as fast as is possible given the services it
provides. I strive for .1-.4/second per page render.

> That is all for now.  Don't let this scolding discourage
> you, the child is still very much loved.

No bad news so far... :)

_a

[binarycloud-dev] BC File Layout, Production Environment

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

Alex:

We have taken our cajones in our hands and lept for BC for
our future production.  It is scary, but so far so good.

I have some issues.  This is nothing "serious" in a
technical sense, but I have to enter the subjective realm
here to give you our comments and experience so far.  This
experience, and our requirements, which _may_ be typical
for users of BC, may have some influence on you with
respect to the next CVS.

I will explain.  Let us say that we are a smaller web
site developer, with, say, 40 sites.  Although this
may be inaccurate, it _seems_ to us that you are in
the mind set that BC is, more or less, for one site.

So, if I use BC for 40 sites, I must do things like:

1.  under $BC/user/mod, establish a directory for
	each site such as
	a) acmecorp
	b) xyxcorp
	c) the other 38
	to put the unique modules for that site
2.  under $BC/user/tmpl/html/masters, establish a
	directory for each site such as
	a) acmecorp
	b) xyzcorp
	c) the other 38
3.  under $BC/user/tmpl/html/layouts/, establish a
	directory for each site such as
	a) acmecorp
	b) xyzcorp
	c) the other 38

Now, so far, so good, except there is a hell of a
lot of cd'ing going on during development changing
from the site-specific DOCUMENT_ROOT, to the site-specific
modules, to the site-specific layouts, to the site-specific
masters.

Now, under the modules, yes Virginia, we anticipate to
have some general things, but, unless I am missing something
we are not able to "generalize" _all_ modules,
and certainly not the master templates or layouts with their
particular decoration.

This is OK.  We get by our wanderings around in the directory
tree by sourcing site-specific cd-able variables into bash
to make life easier.

I only wonder, and I have certainly not thought this out like
you have, to do something like have a "site" directory under
(I donno, $BC/user???) where a small sub-tree exists that has
the three things which will be in, er, constant edit, namely
	a) modules
	b) masters
	c) layouts

NEXT SUBJECT (BUT RELATED TO ABOVE)
===================================
You have implimented what you call "User Constants" in Init.  Well,
in this you set useful things like DEBUG flags, currency names,
currency symbols, et cetera.  This is a very good idea.  But,
what do I do with 40 sites?  What is the meaning of "user" in this
case.  If I have a German customer, who wants prices in DM, I have
to pay attention to overriding the so-called "User Constants".
If I turn on debugging in "User Constants", suddenly all 40
sites, in production, start displaying funky debugging information.

WHAT I WOULD LIKE IS another "level" incorporated into binarycloud
that would be "site specific".  I would like an environment handled
for the site, called, say, "Site Constants" that Init would handle
(by including a site-specific file established at a standard place)
and which would be convenient to override the "User Constants", which
for my thinking, are kinda only "system default constants".

Yes, yes, I know I can do workarounds by resetting "User Constants"
in the $Mod->Init() all over the place, or some other artifice.
But, I don't want to do that.  For a specific example, I certainly
want to easily turn debugging on FOR ONE SITE ONLY.

Therefore, my suggestion is include the abstraction, somehow, of
a "site layer" in BC.  This could be handled in the 'init' array
with a gizmo like
	'site'	=> 'acmecorp'
that would then let BC know where to look for some of the files
it needs in, say, sub-directories of standard places, with the
subdirectory named "acmecorp".

All I am asking is for you to think about this, think about my
problem in a production environment.

LAST INSIGNIFICANT BITCH
========================
This is completely subjective, but until I went through the
code, I was derailed for a while by what I consider your
excellent nomenclature/taxonomy.  I suggest a nomenclature change...

I do not understand why you call "load_order" by that name,
since is seems intuitive for me, it should be called
"init_order" in the $bc_page structure.  For me, it has
nothing to do with "loading", but represents the order of
"initializing" (very clever, BTW).  For a while I though
this was a control that ordered the module DATA collection
as the page content was built up from modules.  I thought,
geez, great, if I wish to change the module content order,
I change the load order instead of moving the arrays around
in the $bc_page hash.

I also would not mind having modules being accessable by name
in the layouts (am I driving you crazy yet?) instead of doing
things like:

<?php echo $Page->output['content'][1]; ?>
HTML DECORATION HERE
<?php echo $Page->output['content'][7]; ?>
HTML DECORATION HERE
	.
	.
	.

because I have to make sure I align the $bc_page hash
with the layout by the order of the module in the hash.
I would rather only have to remember the name of the
piece that I had to put in the layout, viz:

<?php echo $Page->output['content']['julie_bio']; ?>
HTML DECORATION HERE
<?php echo $Page->output['content']['julie_nude_pics']; ?>
HTML DECORATION HERE
	.
	.

I don't know if a "parallel" named hash could be built up
in Page with these named keys in addition to the simple
index array.  Making two arrays for the content is
perhaps an expensive solution (although BC is not necessarily
designed to be fleet-of-foot).

--

That is all for now.  Don't let this scolding discourage
you, the child is still very much loved.

Regards,

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