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

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

> I don't wish to be a gadfly on the ass of progress, but I

heh, that's good :)

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

Makefile system is usable now, I'm sitting on it to make sure there isn't
anything that I don't like.

So, within ~1 week.

Managers: a little longer, I expect those to be fully functional in about a
month or so. Trying for less, but there you have it.

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

Yep.

> 2. Write HTML/PHP in the Module->Output() to display/do
> what the modules "purpose" is

Yep.

> 3. As Managers are released, rewrite, say, the Module->Init()
> to include the functionality of, say, Entity and
> Query.

Yep.

> 4. As Managers are released, rewrite, say, the Module->Output()
> to include the functionality of, say UI/Rule/Event.

Rule may well disappear.
Event will likely change and be a little more simple.
UI is used by the builders:
    ListBuilder
    FormBuilder
    etc.

You will probably not find it useful separate from them.


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

So far so good, le les artistes do their designs + html, and decide how much
you you would like to use XSLT in your projects. From there, either take
that html and php-ify it, or xslt-ifyit :)

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

Yes, pretty much.

I have one other comment: when you design your schemas, keep in mind that
you are trying to build entities: data structures which can be nested.

So, for example:

"user"
    user_name (string, no more than 40 chars, no special chars allowed)

    password (encrypted string, no more than 40 chars, no special chars
allowed)

    address (fkey/entity reference)
        street_address
        phone_number
        foo

    email   (string, must match a regex:
"^([a-z0-9_]|\\-|\\.)+@(([a-z0-9_]|\\-)+\\.)+[a-z]{2,3}\$"
    no more than 255 chars)

etc.

that will allow you to define entities fairly quickly once the system is
ready, and from them you'll be able to build queries automatically.

You might want to store a set of english "labels" for each of those fields,
too:

User name
Password
Address
    Street Address
    Phone Number
    Foo
Email

As entities include labels for the fields (so FormBuilder can make forms for
your automatically :)

> 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"

That is one way to do it. But only if you are running separate sites off the
same installation, which might have other problems (configuration, etc)

I like to keep mine just in masters, I've never had more than 5.

But that's all arbitrary, so if you like you can store them in

html/foo/bar/moo/bar/aliens/ate/my/lunch/and/it/had/chocolate/milk/too/

> 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"

Ditto above.

> 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"

No.

You're much better off structuring and perceiving modules as complete
applications:

knowledge_base
forum
etc.

instead of:
    my tables, my forms, etc.

because tables and forms will soon be extremely easy to generate.

Sometimes it also makes sense to cut out a "process" and make it a module:
"checkout" etc.

> 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"

That's an interesting point.
I have never considered doing it that way, but come to think of it that's
probably a good, simple way to deal with it.

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

Everything you have mentioned will not break.

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

Thanks.

Actually all that is going to get even more "lax" in the source tree,
because the makefile will take care of actually organizing the code for you.
(heheh)

So the next release of r2 will have fewer directories in user/, because
there's no reason to make an artificial separation in source. That will make
packaging and installing modules _really_ easy. (think all the files you
need in once place, instead of 5 places, but with none of the disadvantages
of having similar files distributed throughout a tree)

I have tried to structure everything so it's easy to find, etc, but I wanted
to specifically avoid enforcing "the way I do things" on people. Couldn't do
that 100%, but it seems pretty reasonable so far :)

_alex


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

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

vox+510.666.0074
fax+510.666.0093