Re: [binarycloud-dev] sync is done

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

> 
> While this makes sense in theory, let me try and approach this from a
> different angle.
> 
> My train of thought is blocked by a lingering question on how modules
> will be distributed once BC is mainlined.

Tarballs with a simple installer.
There will be a distribution-packing utility that tars files assuming
binarycloud/ as the root of the tar.

> Are page definition (bcp.xml) files to be included with the module
> package?  While the easy answer may be "yes, why not",
> it also makes sense to allow for modules to be dropped in the module
> directory by themselves, so that the site-owners can add the new module
> to their _already existing_ page definitions where they see fit.

Yes, the pages will be included in the modules distro tarballs. You _should_
have a functional installation of a module that you can run in a browser
right after installation (including db setup + make)

And if you want to delete, move, etc htdocs (or module files) you can.

> The problem I see with replacing the $gPageDef declaration in the page
> definition is:
> 
> (begin scenerio)
> Let's say, my forum app uses this new PageDefBuilder to parse incoming
> URI's.  So this would mean that my forum app module package would
> contain a 'uri definition file' like you described.
> 
> Now, on my _already existing_ page definition where I have a navigation
> module, content management, whatever, I want a forum to appear at the
> bottom.  I would have to lose my existing $gPageDef array to make room
> for the new module which uses the PageDefBuilder.  Something just
> doesn't make sense here.
>
> My first idea/proposal here would be to create a new public method in
> $Page that gets passed the necessary info to handle the incoming URI and
> load up the right module.
> 
> I think this was a bit wordy, but it took some writing before my
> thoughts were clear.

That's effectively the same thing as PageDefBuilder. You could have
PageDefBuilder build only _part_ of your page definition (say, the 'forum'
group). :)

> To sum.. instead of a PageDefBuilder to replace the $gPageDef array, we
> add a $Page->BuildDynamicModule which acts as a gateway to launch a
> multi-module application, and the appropriate module is determined by
> comparing the incoming URI to an XML definition file in the module
> directory.

I still prefer the idea of PageDefBuilder, because page definitions to not
have to be built 100% - you can run it simply to _add_ some modules to a
page definition....

So, let's consider the possibilities:

    1) you want to run the forum 'alone' in its own location:
        forums/index.php
        -you create an apache alias for forum/* to forum/index.php
        -you create a 'request uri' class which is used by PageDefBuilder to
parse the request uri and build an array in $gPageDef.
        -You run $gPageDef through Page and get output.

    2) You want to have a forum for every single page on your site (hey,
possible right? :)

        -you create a normal page def for each page, but include
PageDefBuilder.
        -it uses the request_uri class to determine the forum name, and puts
the ForumList module into the page def.
        -user clicks 'post' or soemthing, and gets sent to the 'normal forum
post page elsewhere in htdocs.


I don't see a reason why that wouldn't work...

best,

-alex