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

[alex b. <en...@tu...>]

> Well, the BC_PATH and BUILD_PATH that live in build/en/htdocs/prepend.php
> were set to /u02/home/odysseas/r2/binarycloud after running make even
though
> I had $BCHOME set. Once I set them by hand things worked okay. Also having
> the php short tag '<?' turned off causes pretty much everything to break
but
> thats not really a bug I guess.

If you did a make, that shouldn't be the case. I'll look into it.

I'll add the short tag warning in install.

>
> But if I do go down that path I run the risk of having to retool
everything
> down road anyway right?

Yes. _but_ if you have a functioning system (which r1 auth/perm is) you can
choose when to do that re-write or if you'd like to do it at all.

> What's the nature of the applications that are being built with BC? The
site
> Im working on will be used to manage some *very* large catalogs of data.
> Interface-wise there won't be much to it in the beginning.

I've built mostly complex web applications, not dealing with huge amounts of
data, but I have no reason to believe that metabase isn't up to it.

Nothing in binarycloud will present you any with any problems, that I can
think of. It's all up to you re: how you write modules.

> >
> >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 :)
>
> But doesn't that work against me if Im relying on another person who only
> groks html to do the page layouts?

Not really. They can write the layouts and you can insert the module calls.
Or you can pass them html-only templates, which they work on, and pass back
to you.

> That's another question I have. When does the conversion from xml to php
> take place? When I run make? Will I have to 'remake' my whole site when I
> change just one xml file?

No, there's a makefile in nearly every directory, and we're probably going
do add automake to insetr makefiles down to every dir in the source tree, so

if you modify 2 files in a dir, you can do a make in 3 seconds.

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

:_)

> >
> >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 :)
>
> This would make things much clearer and lower the learning curve quite a
> bit.

Agreed. Because the system isn't cmoplete yet, I want to avoid spending time
on that stuff and get it working, but believe me when I say I have every
intention of documenting the s*it out of this system, and making very clear
how it can be used.

As always I'm happy to answer any questions.

> >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.
>
> Did the problems arise because the first team was having to implement alot
> of features already present in R1? Given that, I would expect the code
from
> team 2 to be better because the could spend more time on the core instead
of
> the support services. But that is just what you said :)

Correct, and binarycloud _does_ enforce a _little_ structure on your code,
and provides you with a great system for maintaining code and comment
standards.

> >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.)
>
> I've already documented my classes using PHPDoc. After having been
immersed
> in JavaDoc I understand the power of systems like it.

Yes, I love it. It keeps system documentation in context, instead of in some
other stupid file that you always forget to edit :)

> >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)
>
> This is an approach Ive already started using so migrating my current code
> to BC won't be terribly painful. But once I start down that path I don't
> want to have to revert so it's that first leap of faith that Im having
> trouble with at the moment.

Ok, so first:
if you have a functioning system _now_ you can only gain by converting to
bc. If you want to use some of the new tools down the road, then feel free
to do rewrites as needed. But BC doesn't force a thing on you, so if you
don't like metabase, don't use it.

I will ask that any conributed modules that would be distributsed with the
system adhere to certain standards, but there is _nothing_ in the system
that will enforce those rules.

> >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.
>
> So hypothetically if I decide to just go with R1 and wait for R2 to bake a
> little longer what's the migration path? Should I even bother? Pros and
> Cons?

Don't bother.
I strongly encourage you to get r1 auth/perm working with r1 instead of
using r1. R1 is Procedural code (well, 90% of it anyway) and it does work
well, but for obvious reasons a pure OO system is far more maintanable and
architecturally clean.

by all means use R1 as a reference, but don't use it in production: r2 even
at this stage is more mature.

> >
> >The remaining tasks are related to EntityManager and the make system:
>
> I happen to have written an EntityManager class for my stuff. This will
> cause problems no?

Nope. Just put it in user/lib and run a make, you'll have access to it with
import('user.lib.YourEntityManagername');

:)

_alex


> James
>
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
>
>
> _______________________________________________
> binarycloud-general mailing list
> bin...@li...
> http://lists.sourceforge.net/lists/listinfo/binarycloud-general
>