Menu
▾
▴
binarycloud-dev — development list for binarycloud
You can subscribe to this list here.
| 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
|
|
From: Alex B. <en...@tu...> - 2001-10-03 22:33:42
|
hi all,
anyone have an opinion about file permissions?
I just wrote this to standardize the perms of the source tree:
find . -type f -exec chmod u+rw,g+rw,a+r {} \;
find . -type f -exec chmod u-Xx,g-Xx,a-Xx {} \;
find . -type f -name '*.sh' -exec chmod u+x,g+x {} \;
find . -type f -name '*.pl' -exec chmod u+x,g+x {} \;
find . -type d -exec chmod u+rwx,g+rwx,a+rx {} \;
find . -type d -name 'CVS' -exec chmod -R u+rwx,g+rw,a+rx {} \;
find . -type f -path '*CVS*' -prune -exec chmod u+rw,g+rw,a+r {} \;
It makes all normal files user/rw, group/rw, all/r - but makes .sh and .pl
files executable. (No .php files need to be executable)
I was thinking of adding a
<fsperms>
<sourcefile>
<user>rw</user>
<group>rw</group>
<all>r</all>
</sourcefile>
<sourcedir>
<user>rwx</user>
<group>rwx</group>
<all>rx</all>
</sourcedir>
<htdocs>
<user>r</user>
<group>r</group>
<all>r</all>
</htdocs>
</fsperms>
anyone like that idea? :)
_a
|
|
From: alex b. <en...@tu...> - 2001-10-03 07:05:01
|
did a clean sync all, please do: cvs update -dP :) _a |
|
From: alex b. <en...@tu...> - 2001-10-03 06:38:50
|
> There are several references to base_lib.js, yet the filename is > BaseLib.js. Why this crashed my Netscape(s), I have no idea. Sorry, I must laugh. Only Netscape. yep, changed that name and didn't change the template... I'll commit it tonight and do a sync tomorrow morning. :) _a |
|
From: Jason H. <jc...@ey...> - 2001-10-02 20:32:58
|
Well, after this latest cvs sync and a fresh build, the hello_world page crashes Netscape. I haven't tracked it down, but it crashes Netscape 4.78 on both Windows and Linux. IE works fine. jason |
|
From: Andreas A. <a.a...@th...> - 2001-10-02 17:43:37
|
Hi Alex, >> we have different xml files, translated to php and used only during make >> (i.e. the language or image repository). These files are >compiled to php and >> stored in the build tree (regarding to the docs). > > First, because I can see the need potentially for admin > tools that would need access to those arrays. Hmm, thats a good point. >Second, because I don't want to incur the overhead of >re-parsing a set of _big_ xml files on every make - >reading native php structures is _much_ >faster and I want make to be as fast as possible. A even better point :-) >> Ok, it's not pain in the a** to have them there and the only >>advantage I see is for debugging purposes. > >How would there be an advantage for debugging if those >files we not in the tree? I meant the other way around. They can be used for debugging (i.e. look if keys were translated right etc.) if they are there. Ok, I learned it's better to have 'em :-) Andi |
|
From: Alex B. <en...@tu...> - 2001-10-02 17:39:26
|
> we have different xml files, translated to php and used only during make > (i.e. the language or image repository). These files are compiled to php and > stored in the build tree (regarding to the docs). First, because I can see the need potentially for admin tools that would need access to those arrays. Second, because I don't want to incur the overhead of re-parsing a set of _big_ xml files on every make - reading native php structures is _much_ faster and I want make to be as fast as possible. The first reason is a bit tenuous, but the second is solid :) > We use them only during make and the php structures are not used on runtime > (or are they?). So why creating them as files? Isn't it enough to parse the > xml files and build the array internally, doing the replacement work and > write the outputfiles? Why mess up the build tree with those files? > > Ok, it's not pain in the a** to have them there and the only advantage I see > is for debugging purposes. How would there be an advantage for debugging if those files we not in the tree? You could be 100% certain that they were not being accessed, unless you specifically wrote a module to access them :) _a |
|
From: Alex B. <en...@tu...> - 2001-10-02 17:39:14
|
> <?global $Page; echo $Page->output['content'][0];?> I think I prefer this method... it's clean and it doesn't force users to add additional declarative tags. _a |
|
From: Alex B. <en...@tu...> - 2001-10-02 17:39:08
|
Correct. the .sh is an artifact of my editor: to get syntax highlighting, I named the files .sh :) _a > > Again, looks good. But this is only "pseudocode" we'll use make for this not > sh, do we? > > Andi > >> Jason: (if I'm correct in assuming that you're working on >> multi-site make) - >> attached is a very basic set of shell Makefiles which contain the correct >> targets and some useful comments. >> >> All: Have a look at this stuff, as it will obviously affect the Make system >> :) >> > > |
|
From: Andreas A. <a.a...@th...> - 2001-10-02 17:33:44
|
Hi Alex ok, I think so too, even the if global-declarations may be redundant. The users do not have to worry about adding extra tags to get it working. andi >> <?global $Page; echo $Page->output['content'][0];?> > >I think I prefer this method... it's clean and it doesn't force >users to add >additional declarative tags. > |
|
From: Andreas A. <a.a...@th...> - 2001-10-02 14:38:01
|
Hi Alex, we have different xml files, translated to php and used only during make (i.e. the language or image repository). These files are compiled to php and stored in the build tree (regarding to the docs). Why? We use them only during make and the php structures are not used on runtime (or are they?). So why creating them as files? Isn't it enough to parse the xml files and build the array internally, doing the replacement work and write the outputfiles? Why mess up the build tree with those files? Ok, it's not pain in the a** to have them there and the only advantage I see is for debugging purposes. Andi |
|
From: Andreas A. <a.a...@th...> - 2001-10-02 12:39:14
|
Hi All, what do you think of this system tag for the usage in templates: <bc:global> <page>true</age> <querymanager>true</querymanager> ... </bc:global> Will be translated to <? global $Page ?> <? global $QueryManager ?> ... The alternative is to add "global $Page" to every tag translated by bcc that uses globals i.e.: <?global $Page; echo $Page->output['content'][0];?> Andi |
|
From: Andreas A. <a.a...@th...> - 2001-10-02 11:41:46
|
Hi Alex, >The idea is to move nearly all of the interesting logic out >to php scripts instead of meking logic-heavy Makefiles. Agreed. We then can consider using php only for the make process at a later point. So we are more independent - users don't need gnutools. This is especially interesting for the windows world. BTW: Does anyone have experience with Ant? The Java Make Tool? Is this of any use for us? Looks good, Alex. Andi >Install.php >------------------------------------- > -Checks the path to see where the file came from. if it's in > resources/images, marks it as an image. > > -Checks to see if the file needs preprocessing > (does it have a special name?) > > -If so, registers it as such and assignes a 'name handler' > to deal with that file. > > -Runs install -Dp on the source file with the proper destination. > For source, the destination is determined by one of two factors: > -Package declaration in the file > -Location in the source tree. > (be careful here.. this is ok only for modules, config files, > and a few other dirs. Try and put package declarations on > everything but markup source. > For images, can only ever be in > htdocs/resources/images/* or mod/module_name/resources/images/* > The latter is handled as a 'mask' on the build htdocs. > For example, a source of >mod/module_name/resources/images/project_name/Image.gif > will end up at >build/site_name/lang_code/htdocs/resources/images/project_name/Image.gif. > > -If the file has a handler assigned, that handler is run > and does its job (which may be renaming the file > after processing it, etc.) > > -Checks the build file against the source file, > matches the modification dates if necessary. > > >PHPDoc.php >------------------------------------- > -Takes the path of the _build_ tree, and target directory. > (not the source, as these can contain string keys and other ick) > -Builds documentation for that tree, and writes html into > target directory. > (This dir should be a build dir, but you can modify it > however you like) > >BCC.php >------------------------------------- > -Takes the path of the file to be processed in the build tree > -Runs bcc on that file > -Always writes output to same file |
|
From: Andreas A. <a.a...@th...> - 2001-10-02 11:30:54
|
Hi Alex, looks fine to me. Andi >take it back, this is complete... >I'll publish a spec on the Make process with these conventions.. >Opinions? > >Naming 'special' files for processing by make: >--------------------- >-Something.ent.xml >Entity xml definition. Target build/site_name/lang_code/user/ent/ > >-Something.qry.xml >Query xml definition. Target build/site_name/lang_code/user/qry/ > >-Something.form.xml >Form xml definition. Target is host module directory. > >-Something.list.xml >List xml definition. Target is host module directory. > >-Something.wiz.xml >Wizard xml definition. Target is host module directory. > >-Something.cal.xml >Calendar xml definition. Target is host module directory. > >-Something.email.xml >Email xml definition. Target is host module directory. > >-Something.fax.xml >Fax xml definition. Target is host module directory. > >-Something.role.xml >Role xml definition. Target build/site_name/lang_code/user/role/ >Usually located in user/site_name/role/ in source tree. > >-Something.lang.xml >XML String Repository. Target build/site_name/lang_code/user/lang/ > >-Something.php.xml = this file will be processed from xml to php using >default xml2php rules and written out in the same location in the >build tree >with the extension .php. > >-Something.lang_code.php (i.e. Something.de.php or Something.en.php) means >the file will replace Something.php in same directory when the >language code >is the same as lang_code. Useful for writing the same module that has >different logic based on the location/language. > > >_______________________________________________ >binarycloud-dev mailing list >bin...@li... >https://lists.sourceforge.net/lists/listinfo/binarycloud-dev > |
|
From: Andreas A. <a.a...@th...> - 2001-10-02 11:30:49
|
Hi Alex, nono, don't assume everything I talk about is right - this could be catastrophic :) Andi >ohohoho > >ok, yes, of course that makes sense. > >:) > >in which case what you were talking about makes perfect sense... maybe I >should assume that in the future :) > |
|
From: Alex B. <en...@tu...> - 2001-10-02 00:44:55
|
hi all, cvs sync is done. please update. best, _alex |
|
From: Alex B. <en...@tu...> - 2001-10-01 23:36:02
|
hi all, Jason: (if I'm correct in assuming that you're working on multi-site make) - attached is a very basic set of shell Makefiles which contain the correct targets and some useful comments. All: Have a look at this stuff, as it will obviously affect the Make system :) best, _alex |
|
From: Alex B. <en...@tu...> - 2001-10-01 22:26:44
|
If you've had a look at the Makefile.html doc in that bc_todo zip I sent
out, this will start to make sense.
The idea is to move nearly all of the interesting logic out to php scripts
instead of meking logic-heavy Makefiles.
So, for example, each file within the source tree of a given site would be
run through Install.php if its modification date was newer than the copy in
the build tree.
PHPDoc would be used in make phpdoc, or make all if <autodoc> was true in
conf/MakeConf.php.xml.
BCC would be used on every source file unless it was explicitly turned off
in MakeConf.php.xml.
'ave a look... (anyone see anything missing?)
_a
Install.php
-------------------------------------
-Checks the path to see where the file came from. if it's in
resources/images, marks it as an image.
-Checks to see if the file needs preprocessing
(does it have a special name?)
-If so, registers it as such and assignes a 'name handler'
to deal with that file.
-Runs install -Dp on the source file with the proper destination.
For source, the destination is determined by one of two factors:
-Package declaration in the file
-Location in the source tree.
(be careful here.. this is ok only for modules, config files,
and a few other dirs. Try and put package declarations on
everything but markup source.
For images, can only ever be in
htdocs/resources/images/* or mod/module_name/resources/images/*
The latter is handled as a 'mask' on the build htdocs.
For example, a source of
mod/module_name/resources/images/project_name/Image.gif
will end up at
build/site_name/lang_code/htdocs/resources/images/project_name/Image.gif.
-If the file has a handler assigned, that handler is run
and does its job (which may be renaming the file
after processing it, etc.)
-Checks the build file against the source file,
matches the modification dates if necessary.
PHPDoc.php
-------------------------------------
-Takes the path of the _build_ tree, and target directory.
(not the source, as these can contain string keys and other ick)
-Builds documentation for that tree, and writes html into
target directory.
(This dir should be a build dir, but you can modify it
however you like)
BCC.php
-------------------------------------
-Takes the path of the file to be processed in the build tree
-Runs bcc on that file
-Always writes output to same file
|
|
From: Alex B. <en...@tu...> - 2001-10-01 21:31:02
|
heh, take it back, this is complete... I'll publish a spec on the Make process with these conventions.. Opinions? Naming 'special' files for processing by make: --------------------- -Something.ent.xml Entity xml definition. Target build/site_name/lang_code/user/ent/ -Something.qry.xml Query xml definition. Target build/site_name/lang_code/user/qry/ -Something.form.xml Form xml definition. Target is host module directory. -Something.list.xml List xml definition. Target is host module directory. -Something.wiz.xml Wizard xml definition. Target is host module directory. -Something.cal.xml Calendar xml definition. Target is host module directory. -Something.email.xml Email xml definition. Target is host module directory. -Something.fax.xml Fax xml definition. Target is host module directory. -Something.role.xml Role xml definition. Target build/site_name/lang_code/user/role/ Usually located in user/site_name/role/ in source tree. -Something.lang.xml XML String Repository. Target build/site_name/lang_code/user/lang/ -Something.php.xml = this file will be processed from xml to php using default xml2php rules and written out in the same location in the build tree with the extension .php. -Something.lang_code.php (i.e. Something.de.php or Something.en.php) means the file will replace Something.php in same directory when the language code is the same as lang_code. Useful for writing the same module that has different logic based on the location/language. |
|
From: Alex B. <en...@tu...> - 2001-10-01 21:20:11
|
hi all,
I was writing the big long-winded thing below when I realized the first
option has all the advantages, so decision made (unless someone can make a
_really_good_ counter argument :)
We're going to use special extensions in the source tree to simplify the
structure of the source tree and allow developers to make file types easily
so make and configure can process them appropriately.
I've got a partial spec in the R2Classes.txt file, which I'll re-publish in
a (somewhat) complete form in the next message.
After that I'll put out a spec on the 'make process'
best,
_alex
-------------
Wanted some opinions on the use of filenames (as opposed to locations) to
determine build location (and processing) outside of packages...
For example, If you have a strings file in
user/site_name/lang/StringFile.php.xml, we know that it will be made into
php and put in build/site_name/lang/user/lang/StringFile.php.
That was easy, right? What about a String file that's specific to a module?
Do we allow:
user/mod/hello_world/HelloWorldStrings.lang.xml
and assign meaning to the filename, so we know that
HelloWorldStrings.lang.xml should end up as HelloWorldStrings.lang (a php
file) in build/site_name/lang/user/lang/HelloWorldStrings.lang?
Or do we force users (and installations) to put all langs files in
user/site_name/lang/FileName.php.xml?
There are advantages and disadvantages to both.
The advantages of using filenames:
-We already use filenames for other purposes (.php.xml, and
.lang_code.ext for language-specific file substitution)
-It makes the source tree simple, and clean
-It makes installation and removal of modules clean and easy
-It forces some standards on file names so we can all at leasy figure
out what the hell is going on :)
The disadvantages to it:
-It forces us to either 1) add complexity to the makefile system to
allow for the proprocessing of 'special' files required by make like Strings
files and Configs, or 2) Force the user to separately re-make in areas
containing files that make needs in order to see the changes propagate
through the system.
I prefer the latter by far, because is puts the 'power' into the hands
of the user/developer, not us.
The advantages of fixed file locations:
Oop, no. Above is better.
|
|
From: Andreas A. <a.a...@th...> - 2001-10-01 19:52:45
|
Hi Alex, very groovy! >how abut the attached... > >it's more flexible because it lets you make symlinks wherever you want :) > >_a > >> Hi jason, >> >>> How about this.. You can define the path to your >>> Apache docroot in the >>> MakeConf, and add a target such as 'make install' to not >>> only build your tree, but to also install it to your >>> document root. (Could be symlink, >>> or a copy (??)) >> >> That's very cool... >> >> <deploy>/var/www/mysite</deploy> >> |
|
From: Alex B. <en...@tu...> - 2001-10-01 19:23:23
|
how abut the attached... it's more flexible because it lets you make symlinks wherever you want :) _a > Hi jason, > >> How about this.. You can define the path to your >> Apache docroot in the >> MakeConf, and add a target such as 'make install' to not >> only build your tree, but to also install it to your >> document root. (Could be symlink, >> or a copy (??)) > > That's very cool... > > <deploy>/var/www/mysite</deploy> > > Andi > > _______________________________________________ > binarycloud-dev mailing list > bin...@li... > https://lists.sourceforge.net/lists/listinfo/binarycloud-dev > |
|
From: Alex B. <en...@tu...> - 2001-10-01 19:04:44
|
ohohoho ok, yes, of course that makes sense. :) in which case what you were talking about makes perfect sense... maybe I should assume that in the future :) -a > Hi Alex, > > Yes, mybe you misunderstood my question. I was thinking of people that want > to use the load_ordered modules, define them in their page def and echo the > output in the master/layout template. Of course one can do it with pure PHP > "echo $Page->output[..][..]" but it would be nice to have bc:tags in the > source for that. > > Andi > > > >> Static modules won't support load order (at least initially) - the >> StaticModule() method in page runs the module and sends the output all in >> one go. >> >> I like the 'group' tag, it's a nice alias... but I don't see how we can >> elegantly support full load-ordered module arrays that are defined in the >> markup they will be presented in :) > >> >>> I thought of this: >>> >>> <bc:module> >>> <group>content</group> >>> <index>0</index> >>> </bc:module> >>> >>> short one: >>> <bc:module group="content" index="0" /> >>> >>> Will be transformed to: $Page->output['content'][0] >>> >>> or for the whole group: >>> >>> <bc:module group="content" /> = $Page->output['content']; >>> >>> Andi >>> >>> >>> _______________________________________________ >>> binarycloud-dev mailing list >>> bin...@li... >>> https://lists.sourceforge.net/lists/listinfo/binarycloud-dev >>> >> >> >> _______________________________________________ >> binarycloud-dev mailing list >> bin...@li... >> https://lists.sourceforge.net/lists/listinfo/binarycloud-dev >> > > > _______________________________________________ > binarycloud-dev mailing list > bin...@li... > https://lists.sourceforge.net/lists/listinfo/binarycloud-dev > |
|
From: Andreas A. <a.a...@th...> - 2001-10-01 18:27:32
|
Hi Alex, Yes, mybe you misunderstood my question. I was thinking of people that want to use the load_ordered modules, define them in their page def and echo the output in the master/layout template. Of course one can do it with pure PHP "echo $Page->output[..][..]" but it would be nice to have bc:tags in the source for that. Andi >Static modules won't support load order (at least initially) - the >StaticModule() method in page runs the module and sends the output all in >one go. > >I like the 'group' tag, it's a nice alias... but I don't see how we can >elegantly support full load-ordered module arrays that are defined in the >markup they will be presented in :) > >> I thought of this: >> >> <bc:module> >> <group>content</group> >> <index>0</index> >> </bc:module> >> >> short one: >> <bc:module group="content" index="0" /> >> >> Will be transformed to: $Page->output['content'][0] >> >> or for the whole group: >> >> <bc:module group="content" /> = $Page->output['content']; >> >> Andi >> >> >> _______________________________________________ >> binarycloud-dev mailing list >> bin...@li... >> https://lists.sourceforge.net/lists/listinfo/binarycloud-dev >> > > >_______________________________________________ >binarycloud-dev mailing list >bin...@li... >https://lists.sourceforge.net/lists/listinfo/binarycloud-dev > |
|
From: Andreas A. <a.a...@th...> - 2001-10-01 18:24:52
|
Hi Alex, >I far prefer symlink, because it means we don't have to add any additional >complexity to the already complex make system :) Good point. so <deploy> could make a symlink :-) Andi |
|
From: Andreas A. <a.a...@th...> - 2001-10-01 18:21:34
|
Hi jason, >How about this.. You can define the path to your >Apache docroot in the >MakeConf, and add a target such as 'make install' to not >only build your tree, but to also install it to your >document root. (Could be symlink, >or a copy (??)) That's very cool... <deploy>/var/www/mysite</deploy> Andi |
5 messages has been excluded from this view by a project administrator.
