binarycloud-dev Mailing List for binarycloud (Page 37)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

> 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

2001	Jan	Feb	Mar	Apr (57)	May (287)	Jun (166)	Jul (286)	Aug (273)	Sep (254)	Oct (144)	Nov	Dec
2002	Jan	Feb	Mar	Apr	May (1)	Jun	Jul	Aug	Sep	Oct	Nov	Dec

binarycloud-dev Mailing List for binarycloud (Page 37)

binarycloud-dev — development list for binarycloud