David--
>>Is there a scoping architecture in PHP?
Yes there is scoping within PHP.
Example:
Users action 1:
1. index.php is loaded -- ($index_check exists in session)
2. dsp_main.php is included by index.php -- (if statement returns
false)
3. user happily can see what he requested
User action 2 (Naughty boy):
1. dsp_main.php is called by URL (no session is called, therefore
$index_check DNE)
2. the user now reads a nasty message telling him to write 100 times
that "he shall fudge URLS for self indulgence". The user then writes
an iteration that assists him in writing "he shall fudge URLS for
self indulgence" 100 times.
3. the teacher gets mad and tells the boy to leave the computer
science lab immediately
I do have to add that we should write and discuss the database
abstraction layer and the use of session management before we resolve
the application.php issue. I believe in doing so the issue no longer
will exist because everyone will see the power of php variables and
session management.
Chad
> > Why would number 2 need to set permissions for lots of file
> extensions?
>
> No enlightment here... and only one extension. You do not need to
> define your .inc extension for php to parse the file when it is
> included. You can include any ascii base file no matter what it is
> named...
And besides, if we're already screwing with server settings, we may as well
just add the php_auto_preprend_file to .htaccess!!
Silly.
David Huyck
b@...
Alright! Chad has been named!
I'm just about with you on the file persmissions thing, but that is what
folder (subdirectory) permissions are for, right? Only stick 1 file
(index.php) in each circuit's main directory, put the open-type permissions
on that folder, and all other files go in secured subdirectories.
Eh? Can I possible be correct even though I don't know a lick o' PHP?
Nat Papovich
ICQ 32676414
"If it was hard to write,"
says the Real Programmer,
"it should be hard to understand."
-----Original Message-----
From: Chad Albertson [mailto:dependapal@...]
Sent: Friday, October 06, 2000 2:57 PM
To: PHP-fusebox@egroups.com
Subject: Re: application.cfm
--- In PHP-fusebox@egroups.com, Nat Papovich <natp@g...> wrote:
> Hey Buddy (dependapal's new name)-
>
> Why is number 1 no good?
> You don't have to track any variable. You don't have to know where
it came
> from. It's value never changes, but it could, for all I care. I'd
only check
> to see if it exists at all. I like this solution a lot.
>
Ok... 1 works and 2 works, but we are talking about the same amount
of work for both.
Sample:
1. In every file that is not an index file.
Index check is global stored persistently in our session management
feature (we do not have one yet).
if( empty($index_check) )
{
// The fudger is relocated to the homepage with a badfile error
messages
header("Location: index.php?fuseaction=badfile");
}
2. Take for example the fusebox.org site with over 800 files. Each
files permissions must be set. Changing the extension to inc (or
anything else) will just make the php parser not parse the file. The
user can still fudge a URL to load
somedomain.com/blocks/dsp_footer.inc if its permission is set for web
viewing.
> Why would number 2 need to set permissions for lots of file
extensions?
No enlightment here... and only one extension. You do not need to
define your .inc extension for php to parse the file when it is
included. You can include any ascii base file no matter what it is
named...
To unsubscribe from this group, send an email to:
PHP-fusebox-unsubscribe@egroups.com
--- In PHP-fusebox@egroups.com, Nat Papovich <natp@g...> wrote:
> Hey Buddy (dependapal's new name)-
>
> Why is number 1 no good?
> You don't have to track any variable. You don't have to know where
it came
> from. It's value never changes, but it could, for all I care. I'd
only check
> to see if it exists at all. I like this solution a lot.
>
Ok... 1 works and 2 works, but we are talking about the same amount
of work for both.
Sample:
1. In every file that is not an index file.
Index check is global stored persistently in our session management
feature (we do not have one yet).
if( empty($index_check) )
{
// The fudger is relocated to the homepage with a badfile error
messages
header("Location: index.php?fuseaction=badfile");
}
2. Take for example the fusebox.org site with over 800 files. Each
files permissions must be set. Changing the extension to inc (or
anything else) will just make the php parser not parse the file. The
user can still fudge a URL to load
somedomain.com/blocks/dsp_footer.inc if its permission is set for web
viewing.
> Why would number 2 need to set permissions for lots of file
extensions?
No enlightment here... and only one extension. You do not need to
define your .inc extension for php to parse the file when it is
included. You can include any ascii base file no matter what it is
named...
Nat--
> Why is number 1 no good?
> You don't have to track any variable. You don't have to know where it came
> from. It's value never changes, but it could, for all I care. I'd only
check
> to see if it exists at all. I like this solution a lot.
problem here is scoping. In CF we can put a var in the session scope and
you'd have to reference it there, but a URL var wouldn't change that. In
PHP, if you set $golly in the index, even if it is scoped as a session var,
a user could set their own version of $golly in the url string. The scoping
thing is something I don't get yet. Is there a scoping architecture in PHP?
Buddy Boy?
David Huyck
b@...
Hey Buddy (dependapal's new name)-
Why is number 1 no good?
You don't have to track any variable. You don't have to know where it came
from. It's value never changes, but it could, for all I care. I'd only check
to see if it exists at all. I like this solution a lot.
Why would number 2 need to set permissions for lots of file extensions? Are
you going to some enlightened land where me and my no-PHP brain can't
follow?
Here's a mix-up of number 2, speaking in IIS terms, but I bet APache has an
equivalent if not better implementation:
The account that CF runs under (in IIS) can have access to files with
extensions .inc, while the account that the anonymous user uses in IIS only
can execute .cfm file extensions. That's the permissions thing you
mentioned?
Nat Papovich
ICQ 32676414
"If it was hard to write,"
says the Real Programmer,
"it should be hard to understand."
-----Original Message-----
From: dependapal@... [mailto:dependapal@...]
Sent: Friday, October 06, 2000 2:34 PM
To: PHP-fusebox@egroups.com
Subject: Re: application.cfm
--- In PHP-fusebox@egroups.com, Nat Papovich <natp@g...> wrote:
> Ya know, we don't HAVE to find another way around application.cfm's
built-in
> security. Alhough it could be a major security hole, if you code
everything
> perfectly, it'll work fine.
>
> I know absolutley no PHP, but have 2 ideas about how to make it
work:
> 1. Set a variable in index.cfm and have every other file in the
site ask (at
> the top of it) whether or not this varibale has been initialized.
If not,
> take the necessary steps to remedy the situation.
> 2. Map 2 different file extensions to the PHP compiler, so they get
> processed, but only set up the webserver to allow the web user to
have
> browser access to the index file's extension. Like name it
index.php (.php
> can be requested by the internet user) and name the includes
filename.inc.
1. bad idea, to hard to tract what the variable is and where it is
going... However I would love to be proved wrong? :)
2. this works and we will be setting permissions for lots and lots of
files :)
To unsubscribe from this group, send an email to:
PHP-fusebox-unsubscribe@egroups.com
> P.S. <emotion name="giddy">YES!!! We are actually getting people
talking
> PHP-Fusebox over here! I love the internet!</emotion> ...must be
Friday...
I definately agree on the relaxed friday atmosphere!! Plus, Fusebox
logic is very appealing common sense approach to designing web apps
with any language that fits.
As for application.cfm time and responses will tell. We individually
do not know all but as a group (internet) we can conquer anything....
PS... Names Chad... but I enjoy the pal sillyness
--- In PHP-fusebox@egroups.com, Nat Papovich <natp@g...> wrote:
> Ya know, we don't HAVE to find another way around application.cfm's
built-in
> security. Alhough it could be a major security hole, if you code
everything
> perfectly, it'll work fine.
>
> I know absolutley no PHP, but have 2 ideas about how to make it
work:
> 1. Set a variable in index.cfm and have every other file in the
site ask (at
> the top of it) whether or not this varibale has been initialized.
If not,
> take the necessary steps to remedy the situation.
> 2. Map 2 different file extensions to the PHP compiler, so they get
> processed, but only set up the webserver to allow the web user to
have
> browser access to the index file's extension. Like name it
index.php (.php
> can be requested by the internet user) and name the includes
filename.inc.
1. bad idea, to hard to tract what the variable is and where it is
going... However I would love to be proved wrong? :)
2. this works and we will be setting permissions for lots and lots of
files :)
Hey, Pal-- (that was fun to say... do you have a different name?)
> You can include these lines in either .htaccess files on a per
> directory basis or in your apache configuration files
>
> php_auto_prepend_file /path/to/include/prepend.php
> php_auto_append_file /path/to/include/append.php
>
> To keep things portable I believe we need to find another way. The
> only other way I know of is to check if index.php has been called
> (referrer) or included in each of the fuse files. That would mean an
> extra line of code for each fuse... yuck...
I knew there was an auto-prepend/append thing somewhere... I see what you
are saying about the portability issue, but perhaps we can work with that:
we can say, as a part of the spec, that in order to secure your application
you have to either set your .htaccess file up or you have to do something
like you and Nat said about checking for a variable everytime on every
template. There is probably a way to do this in IIS too (and some other web
servers), but I dunno.
David Huyck
b@...
P.S. <emotion name="giddy">YES!!! We are actually getting people talking
PHP-Fusebox over here! I love the internet!</emotion> ...must be Friday...
Ya know, we don't HAVE to find another way around application.cfm's built-in
security. Alhough it could be a major security hole, if you code everything
perfectly, it'll work fine.
I know absolutley no PHP, but have 2 ideas about how to make it work:
1. Set a variable in index.cfm and have every other file in the site ask (at
the top of it) whether or not this varibale has been initialized. If not,
take the necessary steps to remedy the situation.
2. Map 2 different file extensions to the PHP compiler, so they get
processed, but only set up the webserver to allow the web user to have
browser access to the index file's extension. Like name it index.php (.php
can be requested by the internet user) and name the includes filename.inc.
Hey, wait - did I just repeat someone else's ideas? Humble apologies if so.
I don't understand the PHP lingo and don't read the emails too closely.
Nat Papovich
ICQ 32676414
"If it was hard to write,"
says the Real Programmer,
"it should be hard to understand."
-----Original Message-----
From: dependapal@... [mailto:dependapal@...]
Sent: Friday, October 06, 2000 2:13 PM
To: PHP-fusebox@egroups.com
Subject: Re: application.cfm
--- In PHP-fusebox@egroups.com, "David Huyck" <b@b...> wrote:
> Close, but not quite-- the security purpose of application.cfm is
that it
> checks to see if the template being called is index.cfm (or
index.php), to
> make sure a user isn't fudging the url to access act_deleteFiles.cfm
> (.php...) directly. If the user types in
> http://www.server/act_deletefiles.cfm, the application.cfm would
holler
> "NO!!" and smack them on the wrist before forwarding the user to
> index.cfm?fuseaction=badfile. (wouldn't that be cool?)
>
> Does that make sense?
>
Ok reading you loud and clear... I was hesitating bringing this up
since it is Apache specific.
You can include these lines in either .htaccess files on a per
directory basis or in your apache configuration files
php_auto_prepend_file /path/to/include/prepend.php
php_auto_append_file /path/to/include/append.php
To keep things portable I believe we need to find another way. The
only other way I know of is to check if index.php has been called
(referrer) or included in each of the fuse files. That would mean an
extra line of code for each fuse... yuck...
To unsubscribe from this group, send an email to:
PHP-fusebox-unsubscribe@egroups.com
--- In PHP-fusebox@egroups.com, "craig girard" <craig@n...> wrote:
> A win32 version of PHP???? sweeeeeeeet, this is news to me, can
anyone send
> me a link?
>
> Thanks,
>
> Craig
Not that hard to find, but I would be happy to
http://www.zend.com/zend/download-php.php
It works great for minor debugging when individuals have a modem to
access the internet.
A win32 version of PHP???? sweeeeeeeet, this is news to me, can anyone send
me a link?
Thanks,
Craig
-----Original Message-----
From: David Huyck [mailto:b@...]
Sent: Friday, October 06, 2000 5:04 PM
To: PHP-fusebox@egroups.com
Subject: Re: Include.. Include.. Include....Nested
> <<So I have a question then: can one file include a file that
> <<includes another file? Or is that just a limitation of PHP on win32?
>
> Im going to have to take your word on the Win 32 limitation... I also
> think nested includes are new to PHP4.
>
> On your UNIX flavor it works however if you dont use output buffering
> your includes will be included in the reverse order they were called.
Cool! But dang! Now I have to go get myself a Unix box to test on...
poopy.
David Huyck
b@...
To unsubscribe from this group, send an email to:
PHP-fusebox-unsubscribe@egroups.com
--- In PHP-fusebox@egroups.com, "David Huyck" <b@b...> wrote:
> Close, but not quite-- the security purpose of application.cfm is
that it
> checks to see if the template being called is index.cfm (or
index.php), to
> make sure a user isn't fudging the url to access act_deleteFiles.cfm
> (.php...) directly. If the user types in
> http://www.server/act_deletefiles.cfm, the application.cfm would
holler
> "NO!!" and smack them on the wrist before forwarding the user to
> index.cfm?fuseaction=badfile. (wouldn't that be cool?)
>
> Does that make sense?
>
Ok reading you loud and clear... I was hesitating bringing this up
since it is Apache specific.
You can include these lines in either .htaccess files on a per
directory basis or in your apache configuration files
php_auto_prepend_file /path/to/include/prepend.php
php_auto_append_file /path/to/include/append.php
To keep things portable I believe we need to find another way. The
only other way I know of is to check if index.php has been called
(referrer) or included in each of the fuse files. That would mean an
extra line of code for each fuse... yuck...
> <<So I have a question then: can one file include a file that
> <<includes another file? Or is that just a limitation of PHP on win32?
>
> Im going to have to take your word on the Win 32 limitation... I also
> think nested includes are new to PHP4.
>
> On your UNIX flavor it works however if you dont use output buffering
> your includes will be included in the reverse order they were called.
Cool! But dang! Now I have to go get myself a Unix box to test on...
poopy.
David Huyck
b@...
<<So I have a question then: can one file include a file that
<<includes another file? Or is that just a limitation of PHP on win32?
Im going to have to take your word on the Win 32 limitation... I also
think nested includes are new to PHP4.
On your UNIX flavor it works however if you dont use output buffering
your includes will be included in the reverse order they were called.
For example:
<?PHP // nested.php
include("nested1.php");
echo "This is nested.php<br>";
?>
<?PHP
include("nested2.php");
echo "This is nested1.php<br>";
?>
<?PHP
echo "This is nested2.php<br>";
?>
A call to nested.php would produce.
This is nested2.php
This is nested1.php
This is nested.php
http://www.zend.com/manual/function.include-once.phphttp://www.zend.com/manual/function.include.php
Close, but not quite-- the security purpose of application.cfm is that it
checks to see if the template being called is index.cfm (or index.php), to
make sure a user isn't fudging the url to access act_deleteFiles.cfm
(.php...) directly. If the user types in
http://www.server/act_deletefiles.cfm, the application.cfm would holler
"NO!!" and smack them on the wrist before forwarding the user to
index.cfm?fuseaction=badfile. (wouldn't that be cool?)
Does that make sense?
David Huyck
b@...
> >> Im not quite sure what the benefit of application.cfm is. The
> nesting of app.cfm does not exist in the code from fusebox.org ?!
> Correct me if I'm wrong, but isn't this code just saying if it does
> not match a case within the called index.cfm that it will execute
> cflocation url="index.cfm?badfile=yes. Wouldn't this same execution
> be possible by putting a default fuseaction in each index.cfm? Sorry
> if I'm not understanding the benefit. Kind of hard to grasp due to
> my lack of Cold Fusion experience.
>
> Sample taken from fusebox.org
> <cfif findnocase("cfm",cgi.CF_TEMPLATE_PATH) and not findnocase
> ("index.cfm",cgi.CF_TEMPLATE_PATH)>
> <cflocation url="index.cfm?badfile=yes">
> </cfif>
So what is your understanding of application.cfm? In CF if you put an
application.cfm template in a directory, that file will get run
before any
other code in the directory; if there is no app.cfm in that dir, CF
looks in
the parent directory, and runs that app.cfm (if it is there, and so
on...)
How would that work in PHP?
>> Im not quite sure what the benefit of application.cfm is. The
nesting of app.cfm does not exist in the code from fusebox.org ?!
Correct me if I'm wrong, but isn't this code just saying if it does
not match a case within the called index.cfm that it will execute
cflocation url="index.cfm?badfile=yes. Wouldn't this same execution
be possible by putting a default fuseaction in each index.cfm? Sorry
if I'm not understanding the benefit. Kind of hard to grasp due to
my lack of Cold Fusion experience.
Sample taken from fusebox.org
<cfif findnocase("cfm",cgi.CF_TEMPLATE_PATH) and not findnocase
("index.cfm",cgi.CF_TEMPLATE_PATH)>
<cflocation url="index.cfm?badfile=yes">
</cfif>
David Huyck wrote:
"
> Correct me if I am wrong but doesn't app_layout.php break the rules.
> This should be dsp_layout.php due to its call to echo (print).
Perhaps strictly speaking that is true, but in reality this is an
application-level template. The only thing that echo is doing is printing
the collected output buffer (BodyContent) from the index. The idea here is
that you can set a variable called $page_title somewhere in your app before
you call app_layout, and then in dsp_header, you print that variable out in
the <title> tag. In reality it doesn't matter what you name stuff, but I am
familiar with using app_layout, and so I will probably name it that way
instead of dsp_layout."
Get with it! App_layout does THE EXACT same thing whether in CF Fusebox or
PHP Fusebox. If you open up app_layout.cfm you'll notice that it outputs the
display. It's named app_layout for a reason - it "lays out the application
output"
Nat Papovich
ICQ 32676414
"If it was hard to write,"
says the Real Programmer,
"it should be hard to understand."
-----Original Message-----
From: David Huyck [mailto:b@...]
Sent: Friday, October 06, 2000 9:03 AM
To: PHP-fusebox@egroups.com
Subject: Re: CF -> PHP translation
> model. It might be best to first start by rewriting the
> specifications written by Steve Nelson.
I'll have to disagree there... I would like to have a working model before
we start writing the PHP-fusebox specs. There are a lot of similarities and
a lot of differences between the two languages, so we need to be sure our
implementation works.
> Correct me if I am wrong but doesn't app_layout.php break the rules.
> This should be dsp_layout.php due to its call to echo (print).
Perhaps strictly speaking that is true, but in reality this is an
application-level template. The only thing that echo is doing is printing
the collected output buffer (BodyContent) from the index. The idea here is
that you can set a variable called $page_title somewhere in your app before
you call app_layout, and then in dsp_header, you print that variable out in
the <title> tag. In reality it doesn't matter what you name stuff, but I am
familiar with using app_layout, and so I will probably name it that way
instead of dsp_layout.
> > > client variables - i know PHP supports session management, but
> does it allow for the variables to be stored in a database for
> clustering purposes?
>
> Take a look at the serialize() and unserialize() functions. They
> convert arrays (and other PHP objects and variables) into PHP
> bytecode that can be stored and retrieved from database TEXT fields.
>
> A combination of the session management functions, serialize,
> unserialize, and a database abstraction layer would allow clustering.
Cool!
> > > application.cfm - this is necessary for security purposes
> >
>
> This is also necessary in PHP and should be rewritten to include DB,
> Session, and Authentication support.
So what is your understanding of application.cfm? In CF if you put an
application.cfm template in a directory, that file will get run before any
other code in the directory; if there is no app.cfm in that dir, CF looks in
the parent directory, and runs that app.cfm (if it is there, and so on...)
How would that work in PHP?
> > > Let's get some more PHP people on this list, i don't know any,
> tell your friends!
>
>
> Thats me and I too agree.....
Thanks for joining us! So I have a question then: can one file include a
file that includes another file? Or is that just a limitation of PHP on
win32?
Thanks...
David Huyck
b@...
To unsubscribe from this group, send an email to:
PHP-fusebox-unsubscribe@egroups.com
> model. It might be best to first start by rewriting the
> specifications written by Steve Nelson.
I'll have to disagree there... I would like to have a working model before
we start writing the PHP-fusebox specs. There are a lot of similarities and
a lot of differences between the two languages, so we need to be sure our
implementation works.
> Correct me if I am wrong but doesn't app_layout.php break the rules.
> This should be dsp_layout.php due to its call to echo (print).
Perhaps strictly speaking that is true, but in reality this is an
application-level template. The only thing that echo is doing is printing
the collected output buffer (BodyContent) from the index. The idea here is
that you can set a variable called $page_title somewhere in your app before
you call app_layout, and then in dsp_header, you print that variable out in
the <title> tag. In reality it doesn't matter what you name stuff, but I am
familiar with using app_layout, and so I will probably name it that way
instead of dsp_layout.
> > > client variables - i know PHP supports session management, but
> does it allow for the variables to be stored in a database for
> clustering purposes?
>
> Take a look at the serialize() and unserialize() functions. They
> convert arrays (and other PHP objects and variables) into PHP
> bytecode that can be stored and retrieved from database TEXT fields.
>
> A combination of the session management functions, serialize,
> unserialize, and a database abstraction layer would allow clustering.
Cool!
> > > application.cfm - this is necessary for security purposes
> >
>
> This is also necessary in PHP and should be rewritten to include DB,
> Session, and Authentication support.
So what is your understanding of application.cfm? In CF if you put an
application.cfm template in a directory, that file will get run before any
other code in the directory; if there is no app.cfm in that dir, CF looks in
the parent directory, and runs that app.cfm (if it is there, and so on...)
How would that work in PHP?
> > > Let's get some more PHP people on this list, i don't know any,
> tell your friends!
>
>
> Thats me and I too agree.....
Thanks for joining us! So I have a question then: can one file include a
file that includes another file? Or is that just a limitation of PHP on
win32?
Thanks...
David Huyck
b@...
Hello All,
Bare with me as I am not a cold fusion programmer, however have
interest in implementing the Fusebox methedology in PHP. From first
glance there is alot of fat that can be trimmed from the Cold Fusion
model. It might be best to first start by rewriting the
specifications written by Steve Nelson.
http://fusebox.org/specifications/largescale/index.cfm?
fuseaction=onelongpage&CFID=42867&CFTOKEN=5073401
Correct me if I am wrong but doesn't app_layout.php break the rules.
This should be dsp_layout.php due to its call to echo (print).
I also think that both app_globals.php and app_locals.php should
include calls to actions that will populate session variables based
on the users authentication. A rewrite of application.cfm to php
would also assist in the population of these variables away from
their defaults found in the flat files. Of course there should be
some logic to set defaults based on special circumstances of a new
user or first time user of the specific circuit application within
the home application.
> > custom tags - is there anything similar to custom tags in PHP?
http://www.zend.com/manual/phpdevel.php
> > <cf_formurl2attributes> - if there are no custom tags, is this
> > necessary or not?
I also agree that this "is not" necessary.
> > <cf_reuseform> - this is also a very powerful tag, shouldn't be
hard to translate
This would have to use PHP4's session management function to store an
array from page to page during the users session. Packaging this into
a class would be the most effective way of implementing this tool.
> > client variables - i know PHP supports session management, but
does it allow for the variables to be stored in a database for
clustering purposes?
Take a look at the serialize() and unserialize() functions. They
convert arrays (and other PHP objects and variables) into PHP
bytecode that can be stored and retrieved from database TEXT fields.
A combination of the session management functions, serialize,
unserialize, and a database abstraction layer would allow clustering.
> > application.cfm - this is necessary for security purposes
>
This is also necessary in PHP and should be rewritten to include DB,
Session, and Authentication support.
> > application variables - these are very important for scaling
purposes, how does that translate over?
as long as you have called a session within php and have set values
to variables, objects, and arrays you will have access to them within
the environment
> > Let's get some more PHP people on this list, i don't know any,
tell your friends!
Thats me and I too agree.....
Steve--
> My question is which of these CF-Fusebox tools translates over to PHP?
>
> --------------------------------------------------------
> custom tags - is there anything similar to custom tags in PHP? Maybe
> user defined functions?
There are definately user-defined functions. There are even user-defined
object classes so you can group a bunch of related functions into a class
and call them through an object-handler. I'm still not clear on the
benefits fo packaging things in an object (anyone?) as I am really new to
object-oriented programming. The first thing that comes to mind, though, is
that it protects from function naming overlaps and variable cross-overs,
i.e., if you want to use a variable defined outside the function, you have
to declare it a global var.
> <cf_formurl2attributes> - if there are no custom tags, is this
> necessary or not?
I am not yet clear on scoping and stuff, but I agree that this may not be
necessary. Anything passed through a form or a URL is available by name
(i.e., index.php?fuseaction=main... you just have to refer to $fuseaction to
get the value-- no scoping necessary)
> <cf_returnfuseaction> - This is a very powerful tag, I'd love to see
> this get translated, all it takes is session management
There is built-in session mgmt in PHP4. I am not sure how it works yet, but
it is there. This should be do-able, and may already be done (there is an
equivalent to Allaire's tag gallery on many sites, Zend.com being one of the
many).
> <cf_reuseform> - this is also a very powerful tag, shouldn't be hard to
> translate
I'm not sure, again being new to this language, but I think there might be
some built-in functionality here. I'll definitely look into that sometime
soon.
> client variables - i know PHP supports session management, but does it
> allow for the variables to be stored in a database for
> clustering purposes? If not, maybe we should come up with a standard
> way to do this.
There is a way to tell PHP where to store your session vars. I'm not yet
clear on whether you have to have control over the server settings or not,
though. DB is one of the options, if I remember correctly.
> application.cfm - this is necessary for security purposes
Again, there is a question about whether you need access to the server
settings to use this correctly, but there is an auto-prepend setting, where
you can force the system to read a file first before executing anything
else.
> structures - does PHP have something like structures? Gabe's new
> concept of the app_model.cfm file is incredibly powerful, uses
> structures in CF
I haven't seen app_model yet (I'll be looking at that shortly-- on
Fusebox.org?), but PHP variables are easily used as arrays and associative
arrays (much like structures, I think, though I don't know about storing an
array as the value of one of the assoc. array keys...). I'll look at that,
too.
> application variables - these are very important for scaling purposes,
> how does that translate over?
Excellent question. I think you can scope stuff as an environmental
variable, but I don't know if that persists between connections or not.
> Let's get some more PHP people on this list, i don't know any, tell your
> friends!
YES, YES, YES!!!! I am guessing a lot because I just don't know yet! I'm
learning, but not very fast-- I try to learn a little in the mornings here,
but then I spend most of my day coding in CF... A little retention issue
with the PHP stuff. So, if you know some good PHP folks (or are one
yourself), I'd love to hear them (you) chime in a LOT!!
Viva la Fusebox!
David Huyck
b@...
Erki--
Unfortunately I can't do that-- it is a built in function, not user-defined.
On second thought, I can see the usefulness of descriptive names, though--
maybe we can reuse the built-in functions by making a user-defined function
that does just that? i.e.:
function BodyContentStart() {
ob_start();
}
function BodyContentEnd($name = "BodyContent") {
$$name = ob_get_contents();
ob_end_clean();
}
Good idea... I think that this will end up being a part of a library of
functions we will have to include/require, perhaps in app_globals. I'm not
sure there is an equivalent to a custom tags directory that is always
available to any page (but I'd love to be proven wrong).
David Huyck
b@...
----- Original Message -----
From: "Erki Esken" <erki.esken@...>
To: <PHP-fusebox@egroups.com>
Sent: Wednesday, October 04, 2000 3:32 PM
Subject: Re: [PHP-fusebox] Welcome!!
> > I used PHP4 commands, ob_start(), ob_get_contents(), and ob_end_clean()
as
> a
> > form of <cf_BodyContent> (ob stands for output buffering), as well as a
> few
> > other tricks. So bring on the suggestions! I look forward to making my
> > first PHP-fusebox app soon!
>
> hmmm.. IMHO we should use more descriptive and 'FuseBox like' names, so i
> suggest we use something like this insted of the ob_ stuff:
>
> bodyContentStart()
> bodyContentGet()
> bodyContentEnd()
>
>
> erki
>
>
> To unsubscribe from this group, send an email to:
> PHP-fusebox-unsubscribe@egroups.com
>
>
>
>
> I used PHP4 commands, ob_start(), ob_get_contents(), and ob_end_clean() as
a
> form of <cf_BodyContent> (ob stands for output buffering), as well as a
few
> other tricks. So bring on the suggestions! I look forward to making my
> first PHP-fusebox app soon!
hmmm.. IMHO we should use more descriptive and 'FuseBox like' names, so i
suggest we use something like this insted of the ob_ stuff:
bodyContentStart()
bodyContentGet()
bodyContentEnd()
erki
I've yet to program in PHP, i've fallen in love with tag based syntax,
so I'm not too found of PHP's syntax. But it is such a powerful
language and free so I'd like to see Fusebox work with it.
My question is which of these CF-Fusebox tools translates over to PHP?
--------------------------------------------------------
custom tags - is there anything similar to custom tags in PHP? Maybe
user defined functions?
<cf_formurl2attributes> - if there are no custom tags, is this
necessary or not?
<cf_returnfuseaction> - This is a very powerful tag, I'd love to see
this get translated, all it takes is session management
<cf_reuseform> - this is also a very powerful tag, shouldn't be hard to
translate
client variables - i know PHP supports session management, but does it
allow for the variables to be stored in a database for
clustering purposes? If not, maybe we should come up with a standard
way to do this.
application.cfm - this is necessary for security purposes
structures - does PHP have something like structures? Gabe's new
concept of the app_model.cfm file is incredibly powerful, uses
structures in CF
application variables - these are very important for scaling purposes,
how does that translate over?
--------------------------------------------------------
Let's get some more PHP people on this list, i don't know any, tell your
friends!
Steve
Hello, all!
So we've had a few polls start, but no actual posts to the list yet, soI
thought I'd kick things off with an explanation for my reasons behind
starting this list. Here we go:
1) Fusebox rules!! -- I started programming ColdFusion in January, coming
from a strictly Perl environment. What a change!! All the commands are
human-readable and still really powerful! However, I had just spent the
past nine months figuring out how to lay out my Perl cdoe's architecture,
and now here I was in a new language with someone else's architecture in
place... Fusebox to the rescue! It was a Fusebox site already, and the
ramp I had to climb was virtually non-existent!
2) PHP is cool!! -- I like free. Free good. I download Apache, Perl, PHP,
MySQL, and throw them onto my machine, and I am set-- not a penny spent, and
I've got a development environment! Plus it is a robust, evolving language
with things familiar to me from CF (like session mgmt in PHP4) and things
familiar from Perl (like foreach loops and REAL regular expressions!!).
Gotta love that...
3) I don't know PHP! -- But I know Fusebox pretty well. I've been looking
for a list to help me get into PHP, but I haven't found one. And I have
been wanting to learn it, but not without my Fusebox with me! (btw, if
anyone had any good strictly PHP lists to suggest, I wouldn't mind)
So I started a list where I hope to gather some PHP insight while I build
applications in the familiar world of Fusebox. (Not to mention the fact
that one of Fusebox's aims is to become a cross-language methodology,
including CF, ASP, JSP, PHP, etc...) I'm excited by the initial response
from the FB list!
So now for the first question on the list:
I was hoping to have a functional set of base Fusebox templates in the files
section of this list, but instead what I have is a non-functional set of
templates on my dev box that look like a duck, and walk like a duck, but
they just won't quack! I think my initial problem is figuring out how to do
nested includes. I think I may have read somewhere that PHP4 on a PC
doesn't like to nest includes for some reason... Did I read right? Maybe
I'll need to set up a linux (FREE) box to test on, so my includes will
work-- I feel like that is so essential to FB. Otherwise what am I doing
wrong?
Tell you what I'll do-- I'll post my templates to the files section anyway,
and then we can hash this out. Okay, the files are here (you may have to
log in to get to them):
http://www.egroups.com/files/PHP-fusebox/FB+template+files/David+Huyck/
I used PHP4 commands, ob_start(), ob_get_contents(), and ob_end_clean() as a
form of <cf_BodyContent> (ob stands for output buffering), as well as a few
other tricks. So bring on the suggestions! I look forward to making my
first PHP-fusebox app soon!
Thanks...
David Huyck, moderator
PHP-fusebox@egroups.com
Enter your vote today! Check out the new poll for the PHP-fusebox
group:
What is your background?
o I know Fusebox
o I know PHP
o I know ColdFusion
o I know ASP
o I know JSP
To vote, please visit the following web page:
http://www.egroups.com/polls/PHP-fusebox
Note: Please do not reply to this message. Poll votes are
not collected via email. To vote, you must go to the eGroups
web site listed above.
Thanks!
Enter your vote today! Check out the new poll for the PHP-fusebox
group:
Do you think Allaire's going belly up
and you'll be glad you know PHP?
o Yes - they're doomed!
o No - ColdFusion will stick it out
To vote, please visit the following web page:
http://www.egroups.com/polls/PHP-fusebox
Note: Please do not reply to this message. Poll votes are
not collected via email. To vote, you must go to the eGroups
web site listed above.
Thanks!
Enter your vote today! Check out the new poll for the PHP-fusebox
group:
Is FuseBox COOL? :)
o Yes
o No
To vote, please visit the following web page:
http://www.egroups.com/polls/PHP-fusebox
Note: Please do not reply to this message. Poll votes are
not collected via email. To vote, you must go to the eGroups
web site listed above.
Thanks!