binarycloud-dev — development list for binarycloud

RE: [binarycloud-dev] RE: r2 /make

[Andreas A. <a.a...@th...>]

Hi Alex,

>> How is this handled within the build-tree. I only want the htdocs
>> directory accessible by the user. The directories above should be out ouf
user
>> scope.
> And that's coming a bit later, we will very likely abstract the entire
> htdocs/ tree (except resources/) so it is within the user directory.

Ah ok, now it's clear to me. Tnx

Andi

RE: [binarycloud-dev] Another kneejerk suggestion for import()

[Andreas A. <a.a...@th...>]

> Hey, I can live with that.  It makes the distinction
> that I was wanting, would have sufficient information
> in it for import() to allow me to have "dots" in
> my file names, I think.

Yepp, but it alianates import(). On the other hand it might be an option to
unify include operations. So you do only need to know import() and forget
about include, include_once....

What the naming concerns. I think this will change with ongoing bc
deveopment. The extension .php should only be used for code, not for layout.
I think this will change wenn the managers are introduced.

Andi

Re: [binarycloud-dev] Re: r2 make system win32 step by step

[TAO R. <ron...@ho...>]

hi,

this is probably not the problem of make system.

>Hello,
>   All's well with make on win... EXCEPT an error when running 
'xslt_example.php'
>:
>Warning: Failed opening 
'c:/cygwin/home/wds/r2/binarycloud/build/en/binarycloud/Init.php'
>for inclusion (include_path='.;') in ./prepend.php on line 33
>
>Fatal error: Cannot instantiate non-existent class: init in 
c:/cygwin/home/wds/r2/binarycloud/build/en/htdocs/xslt_example.php
>on line 50
>***********
>apparently path problem, not looking in Init for Init.php
>o.k. so the line in xslt_example.php:
>import('binarycloud.Init');
>changed to: import('binarycloud.init.Init');
>
you fixed the first one bug

>then got this error:
>Warning: Failed opening 
'c:/cygwin/home/wds/r2/binarycloud/build/en/user/mod//.php'
>for inclusion (include_path='.;') in ./prepend.php on line 33
>
>Fatal error: Cannot instantiate non-existent class: in 
c:/cygwin/home/wds/r2/binarycloud/build/en/binarycloud/core/Page.php
>on line 129
>************
>Now i'm clueless :(
try to change the following things in htdocs/xslt_example.php
in $bc_page array
sprit the path to name and package, u can follow the way in index.php,
then it will work....

have fun :)

ronald
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Re: [binarycloud-dev] Permissions?

[Benjamin D. S. <be...@be...>]

I guess what I'm looking for is like *nix rwx - only for program PORTIONS as 
well as programs themselves. 

X permissions to a program file lets the user "see" that page. 
(object_perms.php) However, that page (object_perms.php) might deal with 
different types of users differently. 

How is this not a permissions issue? Would you suggest that the module needs 
to keep its own ACL (or equiv) rather than have that provided by a similarly 
functioning set of code? 

-Ben 

On Saturday 30 June 2001 16:26, you wrote:
> > Users can create directories if they want, from within the browser.
> >
> > We have different kinds of users - administrators, and users, for
> > example.
> >
> > Everybody can see the "object permissions" page, and see what the
>
> permissions
>
> > are for an object they'd like to download.
> >
> > But, the owner of the object (who uploaded it) and administrators get
> > additional functionality on this "object permissions" page - they can
>
> modify
>
> > the permission set as well as view it. (so an extra button automagically
> > appears, and instead of listing the permissions, checkboxes are
> > displayed)
>
> Right, but wouldn't that mean you would want to have a module on that page
> that only displays if the user owns the file?
>
> That isn't a function of perm.
>
> > Additionally, the administrator should have a UI whereby he/she can grant
> > administrative priveledges to the "object permissions" page.
>
> So far, so good.
>
> > So, we have:
> > 1) permissions to the page ("object permissions")
> > 2) permissions to portions of the page (set permissions vs view
>
> permissions)
>
> Sort of, I think this is a function of the module, not the perms system.
>
> Though I can imagine a module permissions system.
>
> > 3) permissions to the managed object (the things the site manages)
> > 4) of at least two distinct types (files uploaded, directories)
> > 5) A means for administrators to grant permissions to other users to the
> >    "object permissions" page. (and presumably other pages as well)
> >
> > Does this paint a scenario that makes the needs clear? I can think of
>
> several
>
> > potential applications where this type of fairly advanced permissions
> > structure might apply.
>
> _______________________________________________
> binarycloud-dev mailing list
> bin...@li...
> http://lists.sourceforge.net/lists/listinfo/binarycloud-dev

-- 
"Life is short. Live it!"

Re: [binarycloud-dev] list of make issues

[alex b. <en...@tu...>]

> >     -Justin would like to see the package delimiter in import statements
> > change from . to something else that no one would ever think of using in
a
> > filename: : or :: or # or whatever.
> > I am not really opposed to changing binarycloud.core.Perm to
> > binarycloud:core:Perm, actualy - though I would like Odysseas' opinion
on
> > that one.
> #-- above item 2 --
> Actually, I have become agnostic on this.  You will have to
> understand my initial confusion on this facility. Alex is
> correct that I should use include_once().  For a while, I
> was hung up in my mind that Alex wished to "register" all
> er, includes for some reason that I did not understand,
> but PHP is going to do that for the work ot the user/module level
> within the include_once() facility, AND NOW I UNDERSTAND
> that Alex didn't want, or care about, what got done within
> modules, unless import() was used within the module.

Yes, cool.

> So, what I think is that the dot is probably the best
> separator here, simply because that this is the way
> Java does it, and it is considered the "standard way".

Correct, I far prefer (and am used to) package.subpackage.Class

> I certainly won't confuse it with a file name because
> these are pulling in classes, and BC requires that the
> file basename be the name of the class, so I ain't gonna
> ever be able to scatter dots around in module names unless
> BC finds another way to derive the class name from the
> file name which for MyClass.secondtry.php would mean that
> BC would have to go _inside the file_ to get the class
> name.  I wouldn't even do that to my enemies.

Correct.
I waswilling to entertain : because that's how perl does it (actually,
Foo::Boo)

> >     -Justin would also like to have the ability to name his files with
> > whatever extensions he likes. However, I just thought of something:
> #-- above item 3 --
> See below
>
>
> >     Justin, are you only interested in having that ability within the
tmpl/
> > directory in user?. We have to establish a standard for entity naming,
> > because they will be interpreted by the make system and moved around at
> > build time, for example - but we may be able to just "assume" that
> > everything under tmpl will be a template, and thus only need language
> > keying.
> #-- above item 4 --
> Yea, I find it more important to have it for masters and layouts
> than for modules.  I would certainly rather have it operative
> for templates to have *.masters and *.layouts, and I would
> willingly forego any wish for *.mod for modules, because,
> er, modules _are_, er, "php" in my head.

That is a possibility.

> > Putting the above aside, the only way I see to allow for
developer-defined
> > extensions is to create a file with extension -> type mappings that make
> > uses to determine file type at build time.
> >
> > for example:
> >
> > ".master" = 'php'
> > ".layout" = 'php'
> > ".phtml" = 'php'
> >
> > etc.
> >
> > Again, I don't necessarily object to that, but Odysseas is the make
expert
> > among us, and I would like his opinion.
> #-- above item 5 --
> This would be cool, that mapping.  On some rainy day, I will
> start analyzing the Makefile system, see if I could come up
> with what I want as a superset of the present system, and if
> it is truly easy, I'll give you my ideas.  From my previous
> postings, you probably realize that I love to fiddle with make(1).

That _might_ be the case, but to be honest my experience with make is quite
limited.
I wouldn't mind that, either... actually, I sort of like it. I.e. if for
whatever reason you need to have a certain extension treated a certain way,
there would be a means of doing it without hacking the makefiles.

> #-- not above item 6 --
> You have been silent on dots scattered in file names (templates).
> Look, I can live with, get used to, stop complaining, if I just
> do my templates, for my convenience, for my admin scripts like:
>
> sitename-layout-page1.php [if we get no *.layout accommodation]
> or
> sitename-page1.layout [if we get *.layout accommmodation]
> or
> sitename-master-page1.php [if we get no *.master ability]
> or
> sitename-page1.master [if we get a *.master accommodation]
>
> This means, I would rather have the extension capability than the
> dot-in-a-filename capability.  Heck, I can parse on the hyphen or
> underscore instead of this dot that is causing problems in filenames.

I believe we can add the extension capability to import with relative ease.
Integration into make is a more complex issue.


> I really mean it, I am not just being nice.


heh :)

_alex

[binarycloud-dev] Re: r2 make system win32 step by step

[W.D.Sumilang <wa...@on...>]

Hello,
  All's well with make on win... EXCEPT an error when running 'xslt_example.php'
:
Warning: Failed opening 'c:/cygwin/home/wds/r2/binarycloud/build/en/binarycloud/Init.php'
for inclusion (include_path='.;') in ./prepend.php on line 33

Fatal error: Cannot instantiate non-existent class: init in c:/cygwin/home/wds/r2/binarycloud/build/en/htdocs/xslt_example.php
on line 50
***********
apparently path problem, not looking in Init for Init.php
o.k. so the line in xslt_example.php:
import('binarycloud.Init');
changed to: import('binarycloud.init.Init');

then got this error:
Warning: Failed opening 'c:/cygwin/home/wds/r2/binarycloud/build/en/user/mod//.php'
for inclusion (include_path='.;') in ./prepend.php on line 33

Fatal error: Cannot instantiate non-existent class: in c:/cygwin/home/wds/r2/binarycloud/build/en/binarycloud/core/Page.php
on line 129
************
Now i'm clueless :( 


__________________________________________________
FREE voicemail, email, and fax...all in one place.
Sign Up Now! http://www.onebox.com

[binarycloud-dev] Porting experience to new r2

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

Guys:

A previous poster inquired about the nuisance of following
along, or developing modules now for r2, prior to the
Mythical Managers, and the current quicksand platform
changes.

Well, for what it is worth, I have a small application
a-goin' that has

	7 php pages ($bc_page[]) in the DOCUMEN_ROOT
	9 modules
	2 layouts
	2 masters

and it was "ported" in less than two hours.  Most of the
time was just dog-work editing and changing file names,
and that changing file names was a self-inflicted thing.

_jef

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

Re: [binarycloud-dev] Permissions?

[alex b. <en...@tu...>]

> Users can create directories if they want, from within the browser.
>
> We have different kinds of users - administrators, and users, for example.
>
> Everybody can see the "object permissions" page, and see what the
permissions
> are for an object they'd like to download.
>
> But, the owner of the object (who uploaded it) and administrators get
> additional functionality on this "object permissions" page - they can
modify
> the permission set as well as view it. (so an extra button automagically
> appears, and instead of listing the permissions, checkboxes are displayed)

Right, but wouldn't that mean you would want to have a module on that page
that only displays if the user owns the file?

That isn't a function of perm.

> Additionally, the administrator should have a UI whereby he/she can grant
> administrative priveledges to the "object permissions" page.

So far, so good.

>
> So, we have:
> 1) permissions to the page ("object permissions")
> 2) permissions to portions of the page (set permissions vs view
permissions)

Sort of, I think this is a function of the module, not the perms system.

Though I can imagine a module permissions system.

> 3) permissions to the managed object (the things the site manages)
> 4) of at least two distinct types (files uploaded, directories)
> 5) A means for administrators to grant permissions to other users to the
>    "object permissions" page. (and presumably other pages as well)
>
> Does this paint a scenario that makes the needs clear? I can think of
several
> potential applications where this type of fairly advanced permissions
> structure might apply.

Re: [binarycloud-dev] list of make issues

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

alex black wrote:
> 
> If I am correct, here's the list of issues:
> 
>     -we need to be able to deal with multiple "named" user directories that
> use the same binarycloud/ package tree. (I 100% agree, this will be done)
OK, I want this the most.
#-- above item 1 --
	I want this the most, to have "site-name" sub-trees at the /user
	level.


>     -Justin would like to see the package delimiter in import statements
> change from . to something else that no one would ever think of using in a
> filename: : or :: or # or whatever.
> I am not really opposed to changing binarycloud.core.Perm to
> binarycloud:core:Perm, actualy - though I would like Odysseas' opinion on
> that one.
#-- above item 2 -- 
	Actually, I have become agnostic on this.  You will have to
	understand my initial confusion on this facility. Alex is
	correct that I should use include_once().  For a while, I
	was hung up in my mind that Alex wished to "register" all
	er, includes for some reason that I did not understand,
	but PHP is going to do that for the work ot the user/module level
	within the include_once() facility, AND NOW I UNDERSTAND
	that Alex didn't want, or care about, what got done within
	modules, unless import() was used within the module.

	So, what I think is that the dot is probably the best
	separator here, simply because that this is the way
	Java does it, and it is considered the "standard way".
	I certainly won't confuse it with a file name because
	these are pulling in classes, and BC requires that the
	file basename be the name of the class, so I ain't gonna
	ever be able to scatter dots around in module names unless
	BC finds another way to derive the class name from the
	file name which for MyClass.secondtry.php would mean that
	BC would have to go _inside the file_ to get the class
	name.  I wouldn't even do that to my enemies.
 

>     -Justin would also like to have the ability to name his files with
> whatever extensions he likes. However, I just thought of something:
#-- above item 3 --
	See below


>     Justin, are you only interested in having that ability within the tmpl/
> directory in user?. We have to establish a standard for entity naming,
> because they will be interpreted by the make system and moved around at
> build time, for example - but we may be able to just "assume" that
> everything under tmpl will be a template, and thus only need language
> keying.
#-- above item 4 --
	Yea, I find it more important to have it for masters and layouts
	than for modules.  I would certainly rather have it operative
	for templates to have *.masters and *.layouts, and I would
	willingly forego any wish for *.mod for modules, because,
	er, modules _are_, er, "php" in my head.


> Putting the above aside, the only way I see to allow for developer-defined
> extensions is to create a file with extension -> type mappings that make
> uses to determine file type at build time.
> 
> for example:
> 
> ".master" = 'php'
> ".layout" = 'php'
> ".phtml" = 'php'
> 
> etc.
> 
> Again, I don't necessarily object to that, but Odysseas is the make expert
> among us, and I would like his opinion.
#-- above item 5 --
	This would be cool, that mapping.  On some rainy day, I will
	start analyzing the Makefile system, see if I could come up
	with what I want as a superset of the present system, and if
	it is truly easy, I'll give you my ideas.  From my previous
	postings, you probably realize that I love to fiddle with make(1).


#-- not above item 6 --
	You have been silent on dots scattered in file names (templates).
	Look, I can live with, get used to, stop complaining, if I just
	do my templates, for my convenience, for my admin scripts like:

	sitename-layout-page1.php	[if we get no *.layout accommodation]
	or
	sitename-page1.layout		[if we get *.layout accommmodation]
	or
	sitename-master-page1.php	[if we get no *.master ability]
	or
	sitename-page1.master		[if we get a *.master accommodation]

	This means, I would rather have the extension capability than the
	dot-in-a-filename capability.  Heck, I can parse on the hyphen or
	underscore instead of this dot that is causing problems in filenames.

	I really mean it, I am not just being nice.


> --------
> 
> If I missed anything, let me know.
> 
> _alex
> 
> _______________________________________________
> binarycloud-dev mailing list
> bin...@li...
> http://lists.sourceforge.net/lists/listinfo/binarycloud-dev

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

Re: [binarycloud-dev] list of make issues

[Peter B. <re...@f2...>]

At 10:48 AM 6/30/01 -0700, you wrote:
>     -Justin would like to see the package delimiter in import statements
>change from . to something else that no one would ever think of using in a
>filename: : or :: or # or whatever.
>I am not really opposed to changing binarycloud.core.Perm to
>binarycloud:core:Perm, actualy - though I would like Odysseas' opinion on
>that one.

I have to say I would also like to see it changed.  To me, a dot represents 
a file extension or similar.  Using, for instance, binarycloud:core:Perm 
shows me that it is a path to a module (or whatever) rather than a file 
with lots of extensions tacked on :-)

Hope that's clear!
Peter.


-oOo-
Maple Design - web design, hosting, domain names
http://www.mapledesign.co.uk
-oOo-

RE: [binarycloud-dev] Another kneejerk suggestion for import()

[Andreas A. <a.a...@th...>]

Hi Alex,

> I will play with the "." -> ":" or "::" change.

vote for the "." It's comfortable. Java uses this and why break with a
standard.

Andi

Re: [binarycloud-dev] Obsession, file extensions, and video tapes...

[alex b. <en...@tu...>]

> -- quote --
> Makefiles need standard extensions so as there
> are standard rules that can do one thing for one type
> of a file and a different thing for another type of a
> file. That's why if you write your C application
> -- unquote --
> SO:  Odysseas needs, er, uniform file extensions to
> do his bit in his nascent Makefile system and populate
> his
> SUFFIXES:
> SUFFIXES: .php .xml
> stanzas in his Makefiles and make his life easier.

Not to make his life easy, to make it possible.
It's not necessarily uniformity, it's declaration. We need to explicitly
tell make about everything.

> -- quote --
> Re: different extensions, I'm willing to entertain them but I prefer to
> use
> directory structure rather than file extension wherever possible.
> -- unquote --

These are not contradictory statements.

> SO:  Alex wants/needs "information" to be implicit in directory
> structure so he can make his life easier with his (still fully unknown)
> "package" concept.

That is only after build-time, at which point you shouldn't care about
directory structure because it's taken care of for you.

> But, I want my cake and eat it too!  There has to be a way
> to accommodate this.  I like Adreas' last suggestion to solve
> the warty import() "problem".  And, waaall, surely Odysseas
> can be careful in his Makefiles by doing
>
> SUFFIXES:
> SUFFIXES: .php .xml .mod .layout .master

But that doesn't solve the problem effectively.
Yes, we could build a huge list, but if we're going to tackle that at all we
should do it right, and make it extensible.

As far as I can tell that's a type/extension map.

> while considering .layout as a .php, for example.  Now if
> that is accommodated, some other spoiled brat like me
> would want .LYT for layout files, .MST for master files.
> He could just add them if he correctly edits the Makefile.

Again, I would prefer to do that correctly - i.e. have a file which is
specifically for that purpose, instead of having variant makes all over the
place, so if we make a change all those variant people have to spend a huge
amount of time patching, etc.

_alex

Re: [binarycloud-dev] Permissions?

[Benjamin D. S. <be...@be...>]

Let's say that we have an application that handles files uploaded/downloaded 
from a web site. 

Users can create directories if they want, from within the browser. 

We have different kinds of users - administrators, and users, for example. 

Everybody can see the "object permissions" page, and see what the permissions 
are for an object they'd like to download. 

But, the owner of the object (who uploaded it) and administrators get 
additional functionality on this "object permissions" page - they can modify 
the permission set as well as view it. (so an extra button automagically 
appears, and instead of listing the permissions, checkboxes are displayed) 

Additionally, the administrator should have a UI whereby he/she can grant 
administrative priveledges to the "object permissions" page. 

So, we have: 
	1) permissions to the page ("object permissions") 
	2) permissions to portions of the page (set permissions vs view permissions) 
	3) permissions to the managed object (the things the site manages) 
	4) of at least two distinct types (files uploaded, directories)  
	5) A means for administrators to grant permissions to other users to the 				
	   "object permissions" page. (and presumably other pages as well)

Does this paint a scenario that makes the needs clear? I can think of several 
potential applications where this type of fairly advanced permissions 
structure might apply. 

-Ben 

On Friday 29 June 2001 18:42, you wrote:
> > I need something that can handle:
> > 1) Permission to view the page;
>
> got it.
>
> > 2) permission to view part of a page;
>
> do you mean module?
> we have permissions for entity operations, but not modules. that is
> intentional because modules can both be aware of the permission context,
> and if you use entitymanager, are governed by Entity Operations.
>
> > 3) permission to view target items handled by a page;
>
> I need a more detailed explanation of this.
>
> > 4) of multiple types (files, directories, messages, etc)
>
> perms only controls access to pages processed by php in htdocs - but does
> it globally for that.
>
> > 5) that can be assigned on the fly and re-assigned as needed without
> > making the user get a PHD in how to use the system.
>
> We'll most likely have an editor for it, and all the files are xml and
> pretty simple.
>
> > Something I've ben struggling with for a while now.
>
> If you can describe the couple up there that I'm not clear on, I'll give
> you a complete picture.
>
>
> _alex
>
> > -Ben
> >
> > On Friday 29 June 2001 17:43, you wrote:
> >>> I have a rather large, complicated project, and am waiting for the
> >>> permissions information for r2. Doesn't appear that this has been
> >>> updated in the spec - What is the final goal for this stuff?
> >>
> >> it's getting there, that's the secon major piece of core to be done.
> >>
> >> I can tell you that unless you're doing something _really_ esoteric, the
> >> infrastructure we'll have will ddo what you need :)
> >>
> >> Can you give me an idea of some specific requirements that I can speak
> >> to?
> >>
> >> _alex
> >>
> >>> -Ben
> >>
> >> --
> >> alex black, ceo
> >> en...@tu...
> >>
> >> the turing studio, inc.
> >> http://www.turingstudio.com
> >>
> >> vox+510.666.0074
> >> fax+510.666.0093
> >>
> >>
> >>
> >> _______________________________________________
> >> binarycloud-dev mailing list
> >> bin...@li...
> >> http://lists.sourceforge.net/lists/listinfo/binarycloud-dev
>
> --
> alex black, ceo
> en...@tu...
>
> the turing studio, inc.
> http://www.turingstudio.com
>
> vox+510.666.0074
> fax+510.666.0093
>
>
>
> _______________________________________________
> binarycloud-dev mailing list
> bin...@li...
> http://lists.sourceforge.net/lists/listinfo/binarycloud-dev

-- 
"Life is short. Live it!"

RE: [binarycloud-dev] Stripping comments in build

[Andreas A. <a.a...@th...>]

> I think I did some tests once, it was some unbelieveably small amount of
> time..
hmm. you're a speed-freak allright! ;-)

> but yes, that is certainly a possibility :)
a switch, or better:

make strip


> we will also provide the option to run the make through zend encoder
> automatically.
groovy!!

.andi

[binarycloud-dev] list of make issues

[alex b. <en...@tu...>]

If I am correct, here's the list of issues:

    -we need to be able to deal with multiple "named" user directories that
use the same binarycloud/ package tree. (I 100% agree, this will be done)

    -Justin would like to see the package delimiter in import statements
change from . to something else that no one would ever think of using in a
filename: : or :: or # or whatever.
I am not really opposed to changing binarycloud.core.Perm to
binarycloud:core:Perm, actualy - though I would like Odysseas' opinion on
that one.

    -Justin would also like to have the ability to name his files with
whatever extensions he likes. However, I just thought of something:

    Justin, are you only interested in having that ability within the tmpl/
directory in user?. We have to establish a standard for entity naming,
because they will be interpreted by the make system and moved around at
build time, for example - but we may be able to just "assume" that
everything under tmpl will be a template, and thus only need language
keying.

Putting the above aside, the only way I see to allow for developer-defined
extensions is to create a file with extension -> type mappings that make
uses to determine file type at build time.

for example:

".master" = 'php'
".layout" = 'php'
".phtml" = 'php'

etc.

Again, I don't necessarily object to that, but Odysseas is the make expert
among us, and I would like his opinion.

--------

If I missed anything, let me know.

_alex

Re: [binarycloud-dev] Another kneejerk suggestion for import()

[alex b. <en...@tu...>]

> Hey, I can live with that.  It makes the distinction
> that I was wanting, would have sufficient information
> in it for import() to allow me to have "dots" in
> my file names, I think.

That would only be true if we change the delimiter. I'd like to have a
conversation with Odysseas about this one.

> And, of course, you are correct about the economy
> of a single call to "load a package" without
> have to worry about that package's inventory/names
> changing from underneath you.  Yes, I like that.
>
> Right now, I am a bit confused, because I don't know
> what the intentions of Alex are, and if this would
> fit in the grand schems.  It seems to me, however,
> that your idea is good, and aligns itself with what
> Alex is thinking.  I also like your syntax better
> than what I suggested as a kneejerk, that is, your
> syntax only requires one argument to import().
> That is better.

If you are talking about Andreas file: resource handler, I don't see the
point.

Why not just use include_once in that case?

That is a separate issue from the import package delimiter, which would
still prevent you from doing an import on My.File.With.Lots.Of.Dots.php

> It still won't allow me, I think, to name my
> layout files *.layout, my masters *.master, and
> so forth.  Somehow, I still would like to retain
> that possibility.  I also still feel that within
> the system, for the only example that Alex/Odysseas
> gave where *.php is "necessary", like using
> the filter xml2php, there could be a solution.

That is only for the moment.

Soon, we will be filtering _all_ php code for language strings, maybe
comments, and I'm sure other stuff I haven't thought of yet - and that will
require us to have a mechanism for distinguishing php from xml and html fro
php, etc.

From a cursory discussion I had with odysseas, that would be possible
through a make-make system, but we're getting into esoterica at that point
:)

> That solution would be to put a "wrapping environment"
> around those operations by, say, appending ".php"
> before the operation, and stripping ".php" after
> the operation.

Can you qualify this a little more? What do you mean?

> Sure, this adds some overhead, but it is trivial.
> Right now, you cannot even have your files named
> *.PHP, or *.phtml, which is functionally identical
> to *.php, but gives my "need" a bit more force.
> Lordy, I hate the idea that, right now, I cannot
> name my files
>
> *.layout
>
> or as a partial compromise
>
> *.layout.php
>
> because it throws away the ability of easily
> constructing find(1) scripts or globbed
> arguments to any argument to any of the
> standard UNIX/Linux utilities needed for
> easy administration.  If I had to do things
> like name my files:
>
> file01Layout.php
> file07Master.php
> file09Module.php

How do you suggest we handle the fact that make must have implicit knowedge
about file extensions at build-time?

I'd like to hear what you think before responding.

> and the go sed(1) everywhere in my scripts,
> I would get very tired and irascable.  Er,
> I am already tired and irascable...
>
> Again, I like your suggestion.

Re: [binarycloud-dev] Another kneejerk suggestion for import()

[alex b. <en...@tu...>]

> Another one could be:
>
> Leave import for packages as is:
> import('binarycloud.core');
> import('binarycloud.core.Init);
> etc.
>
> add resource handler for true files:
>
> import('file:a_file_name');

why would one not then just use include_once?

i.e. we'd be replicating (unnecessarily, unless your suggestion would do
something different than when I have in mind) functionaliy that php already
takes care of.

_alex

Re: [binarycloud-dev] Warts on import() - bis

[alex b. <en...@tu...>]

> I think import() is not meant to handle path/fileinformation directly.
What
> you described is a side effect of import caus dots are translatet to / and
> this way the import contains a meta info. But this might not be
neccessarily
> a path. (this should be fixed, disallow "/", "\" and .+).

The delimiter is "." at the moment, I think Justin wants to see that
changed.

> The idea of import is a system to simplify including, I think (correct me
if
> I'm wrong):
>
> E.g.: import('binarycloud.pear');
>
> instead of:
> include_once(BC_PATH."/ext/pear/PEAR.php");
> include_once(BC_PATH."/ext/pear/cache.php");
> include_once(BC_PATH."/ext/pear/whatever.php");
> include_once(BC_PATH."/ext/pear/stuff.php");

Correct.

actually:

import('pear.foo') - we're going to store pear and metabase (and anything
else) in the ext/ source dir.

> The import() includes all neccessary files related to pear (or alle
> neccesary files of pear you need to include by calling import(bc.pear), or
> all files in the ext/pear/ directory or....). Imagine you have to include
> all by hand and then some filenames change within pear, you have to edit
all
> your code where you include pear. With import, nothing changes.

Exactly.

> Ok, you could do it the common way. But with a growing codebase the
package
> thing is more flexible, clear and intuitive, in my opinion.
> And imagine it's required that individual tasks have to be perfomed by
> including a specific package. If so you dont have to care about this, just
> import package and thats it.

Again, exactly.

Re: [binarycloud-dev] Another kneejerk suggestion for import()

[alex b. <en...@tu...>]

> What about this syntax to ship enough information to
> import() in order to distinguish "package" from "file":
>
> import('a_file_name')
>
> for importing a "true file object", and
>
> import('package_name:object')
>
> for importing an "object" from a "package"????

Again, how do I know where to get my file from, _without_ having a map?

and the latter is exactly what we do, minus the ":"

> See, this would suit me.  Maybe not everybody.  I NEVER
> USE A COLON in file names.  Somebody might.  But, I
> would argue that in the great corpus of UNIX conventions,
> using dots in file names probably prevails over using
> colons in file names by at least 100 to 1.  Hell, I
> don't really know that, but I bet you agree...

I suppose we could switch to
binarycloud::core::Perm or something, but I would prefer not to.
this notation:
binarycloud.core.Perm is clean, simple, and easy to write.

> Boff.  I am stopping now with this struggling with
> this problem for the time being and go make my modules
> work on the new r2, and wait for you to get out of
> bed and respond.  Maybe you have already fixed the
> problem in your dreams out there in PST.

I think I'd like odysseas' opinion on the "dots or colons or some other
character as package delimiter" thing.

This is one of the rare cases where I think I am comfortable saying, we need
to have a standard - not a complex one - just, "can't use multiple "." in
filenames" - because we must be able to have some implicit knowledge about
files going through make.

I will play with the "." -> ":" or "::" change.

_alex

Re: [binarycloud-dev] Warts on import() - bis

[alex b. <en...@tu...>]

> import('../../../bullshit');
> exit;

But that is not an import. You're trying to use it like include, which is
specifically what we're trying to avoid.

imports like:

binarycloud.core.Perm

are translated into paths:

binarycloud/core/Perm.php

for inclusion - and the paths adhere to our package structure (the paths in
source don't necessarily need to adhere to the package structure)

> Now Alex, you don't want THAT, do you?  You are not going to
> force policy of NEVER using relative directories, are you?
> Of course not, I hope.

If you want to use import, which uses _packages_ yes of course.
If you want to use a relative directory, do this:
include_once('../../moo/boo/whatever')
but I don't know where (or why) you would want to do that when you can do
user.mod.moo.Boo

> OK, I am not afraid of being laughed at for thinking out loud,
> so I have been thinking about "what you want to do" with this
> "package" idea, and the conventions you need to use for this,
> and how import() can be smarter.

I don't want to make it too smart, otherwise it sort of defeats the purpose:
a simple, clean bit of package infrastructure to help everyone deal with the
amount of code we have.

this import is about as standard as they come :)

> If import() is supposed to handle the abstraction of working
> for importing files, and/or "packages", and/or certain files
> from certain packages, ya gotta give import() more information.
>
> I think you should think about trying something like:
>
> import($_arg,$package=null)
>
> and then, cumbersome as it first appears, have the calling
> syntax require, if it is an "abstraction" from a package,
> call it thus:
>
> import("something_that_is_a_standalone_file")

There is no such thing. Import commands correspond to paths. So you can't
say "give me some file floating in space" - how would I know where to go and
get the actual thing in the filesystem?

> for a true file, and:
>
> import("something_related_to_package","package_name")
>
> for a "file" that is in the abstraction "package_name".

Again, I think you're trying to use import like include, and it doesn't work
that way :)

> You would have enough information available to import() to then
> be able to parse things and come out with the ultimate correct
> file to include_once().
>
> You might even wish to establish another global map to have
> tuples of "package" and "filename" held.  I don't know where
> you are going to go with those maps, I _do_ see their utility
> and efficiency of cutting down on useless calls to PHP that
> you know in advance are going to fail and burn up CPU time.

_exactly_ -> which is why we did not build an import that relies on a map,
which is a terrible waste of CPU cycles.

so, instead, we made the make process package our files for us, before
runtime, so we don't have to do inefficient lookups and other stuff like
that.

instead, import takes a package name:
binarycloud.core
and makes it a path:
binarycloud/core

> This is _only_ a quickie suggestion.  I have no inkling if this
> would fit in with your ideas.

all above :

_alex

Re: [binarycloud-dev] Stripping comments in build

[alex b. <en...@tu...>]

I think I did some tests once, it was some unbelieveably small amount of
time..

but yes, that is certainly a possibility :)

we will also provide the option to run the make through zend encoder
automatically.

_alex



----- Original Message -----
From: "Andreas Aderhold" <a.a...@th...>
To: <bin...@li...>
Sent: Saturday, June 30, 2001 6:11 AM
Subject: [binarycloud-dev] Stripping comments in build


> Hi,
>
> is it planned to strip comments from the .php files within the build tree?
I
> think that should be done to reduce parsing time.
>
> .andi
>
>
> _______________________________________________
> binarycloud-dev mailing list
> bin...@li...
> http://lists.sourceforge.net/lists/listinfo/binarycloud-dev
>

Re: [binarycloud-dev] RE: r2 /make

[alex b. <en...@tu...>]

> > if you look in build/en/binarycloud/* you'll notice that the
organization
> is
> > different.
> Yepp. But I don't get it right now how the build arch is handled with the
> webserver config.
>
> If I understand right the language rips are completly standalone systems.
> Thats good and no problem if you have different docroots/vhosts vor each
> language. e.g.
>
> foo.com points to build/htdocs/  -> determines language and switches to
> en.foo.com points to build/en/htdocs or
> de.foo.com points to build/en/htdocs
> etc.
>
> but what if you want to have language switching capabilities within one
site
> e.g. foo.com and foo.de points to the same docroot:

2 ways of dealing with that:
    -a script at docroot that abstracts the (x) 'build' htdocs for each
language
    -use a subdir:
        http://www.example.com/en/
    etc


> foo.com -> derminte language and set internally
> user switches foo.com?.lang=de
>
> or another organization:
> foo.com/de/
> foo.com/en/

right.

> How is this handled within the build-tree. I only want the htdocs
directory
> accessible by the user. The directories above should be out ouf user
scope.

And that's coming a bit later, we will very likely abstract the entire
htdocs/ tree (except resources/) so it is within the user directory.

> Maybe this is a stupid question and I'm missing something obvious. But I
> don't get it right now :-(

Make works, but the system isn't done - so there is behavior that doesn't
reflect the final state of everything.

_a

Re: [binarycloud-dev] FW: GroupIT Engine

[alex b. <en...@tu...>]

> Jason says that BC is (potentially) better for speeding up
> development, code reuse, administration, Lego-izing the
> world -- than GroupIT.  Maybe the way to describe this is
> that GroupIT _may_ allow a secretary construct a slick
> site, but it leaves everything a mess underneath.

Correct, though what I am potentially interested in pulling is
caching/php2html makes. A lot of the other stuff is probably not good, but
we won't use that :)

> Like I said, I have not looked personally at GroupIT.
> From what I did see, and Jason's perusal, the vision
> and concept of BC is far more attractive than GroupIT
> for those people that want to be able to construct
> _many_ sites reliably and quickly and have what is left
> underneath reusable and easy to administrate.

And, also, groupIT is an application, where binarycloud is a platform - but
it is nonetheless interesting as an application to pull pieces from.

_alex

[binarycloud-dev] Obsession, file extensions, and video tapes...

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

Guys:

OK, I'll get of this list, maybe, for the rest of the day.

BUT, I would like to point out the nub, the source of this
"problem" which, being greatly unfair, and self-servingly
taken out of context, is the inconsistency of Odysseas saying:

-- quote --
Makefiles need standard extensions so as there
are standard rules that can do one thing for one type
of a file and a different thing for another type of a
file. That's why if you write your C application
-- unquote --
SO:  Odysseas needs, er, uniform file extensions to
do his bit in his nascent Makefile system and populate
his
SUFFIXES:
SUFFIXES: .php .xml
stanzas in his Makefiles and make his life easier.

and Alex saying:

-- quote --
Re: different extensions, I'm willing to entertain them but I prefer to
use
directory structure rather than file extension wherever possible.
-- unquote --
SO:  Alex wants/needs "information" to be implicit in directory
structure so he can make his life easier with his (still fully unknown)
"package" concept.


But, I want my cake and eat it too!  There has to be a way
to accommodate this.  I like Adreas' last suggestion to solve
the warty import() "problem".  And, waaall, surely Odysseas
can be careful in his Makefiles by doing

SUFFIXES:
SUFFIXES: .php .xml .mod .layout .master

while considering .layout as a .php, for example.  Now if
that is accommodated, some other spoiled brat like me
would want .LYT for layout files, .MST for master files.

He could just add them if he correctly edits the Makefile.

Besides, you always need to consider that it is always possible
to turn a disadvantage into an advantage.  I would suggest that
later on, when BC is a bloomin' success and the M$ kiddies are
clamoring for it, you might have to accommodate 8.3 files,
upper-cased, like *.PHP.  YOU WILL BE READY FER 'EM. 

Yes, Virginia, I am obsessed...  Let's watch a video.

_jef

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

Re: [binarycloud-dev] FW: GroupIT Engine

[jason <ja...@gr...>]

Andreas Aderhold wrote:
> BC is the best designed and coded php "app" I've seen so far.



This is true.  It all seems to start with extensive idea sharing prior
to any hacking.  Most new applications seems to be initiated by one
person for a specific need.  Coding begins, and that need is acquired
immediately.  Then as it grows, it becomes simply bloated and robust. 
As it's popularity increases, the more beastly it becomes to maintain. 
At least, this has been my experience with past projects of my own.

Speaking of good/bad code, take a look at Drupal some time
(www.drupal.org).  It's a PHP content management app with "beautiful"
design structure and modularity.  I learned quite a bit from this
project, namely "Less is More".

Jason