|
From: Justin F. <je...@ey...> - 2001-06-29 07:26:52
|
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
|