[binarycloud-dev] Uh, A Gadfly's Problem

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

Alex:

I don't wish to be a gadfly on the ass of progress, but I
would like to discuss my/our problem vis-a-vis using bc
r2 in our not untypical small web development business.

As I have previously stated, I am impressed with the
elegant qualities of bc r2, and have decided on these
perceived merits to have our company "commit" to using
bc in the future.  I have no real problem in waiting for
the core completion, and I think there is a way to develop in the
interim by using (as you did in Hello World) the artifice
of putting "raw" PHP/HTML in the SomeModule->Init() and
SomeModule->Output() methods.  (I will ask you about this
later.)

But, I am in the midst of writing a justification position
of going to bc for our partners/management, and I simply
would like a best guess on your part as to when the Makefile
system will be usuable "enough", when some of the Managers
will be usuable "enough".  This is not meant to be pressure,
but we would like to have a feeling for this, simply for
our planning.

I would like for you to comment on what you consider the
best way to work in the interim.  From our study, it
seems that to allow writing code today should allow
easy "upgrading" as bc matures, would be the following, all
of which assumes a typical dynamic site using PHP/MySQL:

FOR MODULES
-----------
1. Write PHP code in the Module->Init() that gets the data
	from the database or whatever.
2. Write HTML/PHP in the Module->Output() to display/do
	what the modules "purpose" is
3. As Managers are released, rewrite, say, the Module->Init()
	to include the functionality of, say, Entity and
	Query.
4. As Managers are released, rewrite, say, the Module->Output()
	to include the functionality of, say UI/Rule/Event.

This is how I see how to "start now" and preserve the layer
and abstraction, and allow us to get "Les Artistes" (what I
call the design/Mac people) up to speed on using this wonderful
touchstone/Holy Grail of separating-layout-from-content.

Is this approach what you would do?  I would like your
comments.

One other more mundane question.  How would you (maybe
this answer is already implicit) organize your directory
structure under the BC_PATH for, say, a website.  I
am thinking:

FOR TEMPLATES
1.  Under BC_PATH_TMPL/masters/ create a directory site_name.
2.  In the XML or bc_page structure, make the paths
	==> "html/masters/site_name/template_to_use"

FOR MODULE LAYOUT
1.  Under BC_PATH_MOD/html/layouts/ create a directory site_name
2.  In the XML or bc_page structure, make the paths
	==> "html/layouts/site_name/layout_to_use"

FOR MODULES THAT ARE GENERAL, Reusable
1.  Under BC_PATH_MOD establish a set of directories that
	reflect "category of module" such as
	./forms
	./locators
	./tables
	./pagers
	./gizmos
2.  In the XML or bc_page structure, make the paths
	==> "forms/magic_form.php" or
	==> "tables/super_table1.php"

FOR MODULES THAT ARE SITE-SPECIFIC, one-offs
1.  Under BC_PATH_MOD create a directory site_name
2.  In the XML or bc_page structure, make the paths
	==> "site_name/whatever_specific_mod.php"

It is likely you will comment "whatever organization that
suits you".  I just wish to make certain that CVS updates
will not mangle this system in the future.

As an observation, one of the most appealing features of bc
for me is this perception that such organization can
be made, and the repository "method" for modules is
intuitive and natural.  You may think that this great
administration advantage is self-evident, but you
should toot your horn more about this concept as it
is something of value that transcends the code itself.

Regards,

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