Re: [binarycloud-general] BC quick-start guide?

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

>> You're building pages, and modules to use in those pages. Have a look at
>> index.php, note that it's a definition of a series of modules, and
>> templates. you can find all of those files in user/mod/,
>> user/tmpl/html/layouts and user/tmpl/html/masters
> 
> Okay after rooting through things I've got it all working although the
> install process is a bit buggy. Im running against the current CVS BTW.

Can you define "a bit buggy?" - assuming you do a make it should be happy.

>> What's "missing":
>>     -A second generation authentication system. If you _really_ need one,
>> you could probably get R1 Auth/Perm (which are quite effective, and
>> production tested - but 'simple') working with R2.
> 
> Are you suggesting I use R1 or just cut out that piece and graft it to R2?

The latter, though I would encourage you to wait just a little, because the
new auth/perm stuff is a hell of a lot more advanced.

But, note that Auth.php and Perm.php are "classified" already from R1, so
you could probably get them running pretty fast.

>>     -Some miscellany: I haven't started using Andreas' Request Class
>> (that's
>> actually next on the list)
> 
> I was looking at writing something just like this myself.

Oh, it's in CVS and as far as I can tell it's extremely groovy code. We're
going to "enforce" the use of Request for all binarycloud-distro modules.

>>     -Some things are still moving targets - I'm sure we'll com across
>> things
>> we have to change, etc as development progresses.
>> 
>> _but_ and I canot stress this enough:
>>     -The module structure and method naming scheme is now written in
>> stone:
>>             Constructor called to 'init' the module, Output() called to
>> (you
>> guessed it) generate output.
>> 
> 
> So your advice is to start using R2? My group has set a loose deadline of
> the 31st to bring a beta of our site up and the missing auth and perm stuff
> is a show stopper. Is there a roadmap for these things on your TODO list?

If you're looking for the 31st, I suggest you use R1 Auth/Perm.
There is a TODO, but I don't have a project schedule outlined because it
would fluctuate as I have more and less time because of projects.

> Also, Im wondering if we need the fine grain abstraction that BC provides.
> We need some of BC's services but Im concerned that the overhead of the page
> abstraction is going to be too high to develop our pages rapidly.

I've built huge applications with it, and it speeds everything up. Because
you need to be organized about using modules, nothing gets "lost" in
include-land.

I'm working on something that will simplify page authoring for those that
don't need tight control over load order, etc. But authoring pages in XML
will be really easy anyway :)

Also, remember: the system is a set of tools, the only "requirements"
really are associated with Module method naming.

You can do all kinds of crazy things: if you don't like master templates use
includes in a prepend, or use a module to output header and footer, or
etc....

My point is that the system can be turned to do things very differently from
what you see in the "default" cvs version.

One of the things I will do later is build a series of "variant" pages and
applications to give users a feel for the flexibility of the system. Other
things first, though :)


> I would love to hear from other people that have gone though a full
> development cycle with BC.

I can give you my experience, biased though it is:

I lead two projects of similar size, one with bc and one without. The
project without bc was much harder to deal with because I didn't have a good
mechanism for controlling the condebase my contractors were generating. The
second project, with binarycloud r1, took ~half the time to complete, with
much higher quality code when the project was done.

I haven't done a production cycle with R2, but I can tell you that many of
the ideas in R1 have been refined based on experiences with the system, and
it will save you time if you're willing to be disciplined (i.e. maintaining
coding standards, phpDoc, etc etc.)

The page render pipeline in r2 is quite mature and powerful, building
modules is fast and efficient (and obviously serves to break up your
application into useable, easily debuggable components)

However, as you have pointed out, r2 isn't done. Though simple, the r1
auth/perm system is quite robust, I'm using it in production now. You could
probably get them working in a day.

The remaining tasks are related to EntityManager and the make system:

    -"multi site" make
    -Authentication system, PolicyManager
    -Pemissions
    -Managers: Entity, Query, Template, etc.
    -"default" module associations with master templates
    -Integrate PHPDoc into the make process
    -Test PEAR_Error further (note that pear error is up and running with
the current system, PEAR is imported as part of the init process for r2..
but we might extend it to do some stacking, etc.
    -Use the Request class throughout the system (this is relatively simple)
    -Get xml2php running for page definitions, language defs, datasources,
etc.
    -Get LanguageKeyer working with xml string repositories (language
selection and path setting works fine right now, but there's no language
keyer for abstracting "application" strings.

best,

_alex