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

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

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

Or, you can use a path constant to find the root path for /resources/

I prefer just to ensure that my sites start at document root, so I don't
have to deal with that kind of crap :)

But, for portability, the best way to do it is with a path constant.

because, what if you have

/site_name/foo/page.php
that prints:

<img src="../resources/images/foo/moo.gif">

then you have a broken image ref.

whereas if the module prints:

<img src="/path/to/resources/from/doc_root/resources/images/foo/moo.gif">

than you're ok.

also, note that "resources" is not a mandated binarycloud thing - it's just
the way I like to organize me public resource files like images, js libs,
and css.

so you can have

/images/
/css/
etc
in your own modules.

I probably _will_ request that people keep images in separate folders within
/resources/ if they want to distribute modules with the binarycloud distro,
just for simplicity and clarity.

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

Right, pain in the ass.

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

That was my thinking, yes.

> 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

yes.

or I suppose you could have

resources/site_name/images/ css/ js/

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

I see the point.

Is there anything wrong with using a symlink in this case?

That's nice and clean, and allows you to have any other "you-specific"
image, css, etc directories within your own vhosts, however you like doing
it.

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

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

Again, I agree there.

The organization of resources/ is 100% ad-hoc at this point, I have put no
effort into standardization. It appears now would be a good time.

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

Which is not the case (intent to example-set)

So, I'll send a separate message to the list re: this with clear options.

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

Nope :)

_a




--
alex black, ceo
en...@tu...

the turing studio, inc.
http://www.turingstudio.com

vox+510.666.0074
fax+510.666.0093