[binarycloud-dev] Generalizing Modules To Use ??/resources

[Justin F. <je...@ey...>]

Alex:

I am still in the process of writing a bunch of small modules,
as well as some complex ones, and creating several "toy" sites
using these modules from different "packages".  This is to
get used to, and/or discover module inter-communication
issues, resource issues, naming convention requirements, et cetera.

There is one issue that I have come across that is not
a technical problem at all, meaning, we can establish
our own conventions here at Eye integrated.  However, I am so
keen for binarycloud and its potential and the anticipated
exchange of modules, that I am always thinking of the
implied conventions necessary for the "module exchange bazaar".

This has to do with general modules that must access
someplace/resources in the DOCUMENT_ROOT for a nice,
say, standard button image.

So, for site-specific, never-to-be-used-anywhere-else
modules, these are put in the "package" 
./user/mod/sitemame.

For general, can-be-used-anywhere modules, these are
put in the "package"
./user/mod/lib

Now, up in the document root, one way of organization
is:

DOC_ROOT
	/site-one
		/resources
	/site-two
		/resources
	/site-three
		/resources
	/resources

This allows references to resources that are site-specific
to be, say, "./resources/images/some-image.gif".

For general modules, references to resources are then,
say,  "../resources/js/my_js_lib.js".  This allows a
general module to be used in any site, and that general
module to find its resources IN ONE PLACE.  Otherwise,
any general module that required resources would have
to have a copy of the resource IN EACH of the sites
resources sub-directory.

I think that you agree that if you have a set of general
modules, you do not want to have to put their resources
in each of the site resources.  There would be filename
clashes, if you changed a general javascript library, you
would have to copy it to each site's resources.

OK, so with this generalization in mind, and considering
our previous discussions about having site modules live
at the same level as ./user/ in binarycloud tree, I
looked to what you had done in the latest CVS/tarball.

For your images, you have:

./r2/binarycloud/build/en/htdocs/resources/images/binarycloud/.
under which you have subdirectories for buttons, titles,
templates, et cetera.  Thus, I notice that you have this
distinction of "site-name" UNDERNEATH images to isolate
site-specific images.  Although you did not do it for
the ./js/* resources or the ./css/* resources, I glean
that you are thinking to have ONLY ONE resources directory
up in the document root, and to isolate site-specific from
general resources, make subdirectorys down in the single
instance of the ./resources directory.

Technically, there is nothing at all wrong with this,  I
could adapt to this way for my use-anywhere modules by
establishing a sub-directory under images called "general".
But, this means that any general module would have to refer
to an image as:

../resources/images/general/image-name.gif

and any site-specific-module would use:

../resources/images/site-name/image-name.gif

I realize you cannot enforce this policy, I can merely
change the resources to the way I like it, which seems
cleaner, has the site-specific resources under that
site's virtual host root. BUT I think this is a bit
of wrong-headedness to have site-specific modules
to have to go traverse OUTSIDE its virtual host
root.

So, after all this long-windedness, my motive is to
endeavor to establish some conventions that are agreed
upon, apriori, for exchange of general modules and
do not necessarily require editing, or putting those
general modules required resources in different
places than what the contributing author did.

I find it ironic that you distinguished site-specific
resources DOWNSTREAM and site-specific modules
UPSTREAM, if you get what I mean.

In any case, I wish to bring this to everybody's
attention.  I am so enthusiastic about binarycloud
that I hope that the exchange of modules will be
such that I don't even have to edit contributions
because things are always found in "standard places".
I would entertain any comments this group has that
are a result of their experience.

So, Alex, although you cannot enforce policy on this
issue, you are still setting an example (perhaps
unintended) of distinguishing site-specific resources
in a single resources tree DOWNSTREAM, and outside
of a site's virtual host root.

Do you have a reason for this in the overall scheme
of things that I am unaware of?

Regards,
-- 
Justin Farnsworth
Eye Integrated Communications
321 South Evans - Suite 203
Greenville, NC 27858 | Tel: (252) 353-0722