[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