binarycloud-general

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

[James M. <foo...@ho...>]

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

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

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

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

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 would love to hear from other people that have gone though a full 
development cycle with BC.

Thanks,
-James-

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

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

[James M. <foo...@ho...>]

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

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.

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

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

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

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'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?

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?

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

>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 :)

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

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

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

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

James

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

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
>

[binarycloud-general] structure

[Alby L. <al...@th...>]

I've moved this from dev since its a "duh" question. I've seen this type of
structure all over r2 and can't seem to grasp the
logic:

>>>>
$modXSettings = array(
"foo" => array(
"name" => "Peter",
"other" => "Pan"
),
perms => "god"
);
>>>>

Would someone be willing to explain what's going on here and why? An array
within an array, I can see the usefulness in that I *think*, but a such a
complex matrix hardly seems ubiquitously useful as this structure is
referenced in r2.

Alby

Re: [binarycloud-general] structure

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

> I've moved this from dev since its a "duh" question. I've seen this type of
> structure all over r2 and can't seem to grasp the
> logic:
> 
>>>>> 
> $modXSettings = array(
> "foo" => array(
> "name" => "Peter",
> "other" => "Pan"
> ),
> perms => "god"
> );
>>>>> 
> 
> Would someone be willing to explain what's going on here and why? An array
> within an array, I can see the usefulness in that I *think*, but a such a
> complex matrix hardly seems ubiquitously useful as this structure is
> referenced in r2.

It's a nested hierarchy.

Think of it as xml:

<modXSettings>
    <foo>
        <name>Peter</name>
        <other>other</other>
    </foo>
    <perms>god</perms>
</modXSettings>

It is the most efficient way to store a set of data, i.e. in one variable
that has some defined structure.

You reference it with:

$modXSettings['foo']['name']
etc

best,

_alex

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