php-general Digest 24 Sep 2006 00:05:39 -0000 Issue 4364
Topics (messages 242144 through 242162):
Re: PHP5 object construct
242144 by: Chris Boget
Re: libcurl (cookies across cURL session). . .?
242145 by: Michael Williams
Object to array conversion oddity
242146 by: Marcus Bointon
242147 by: Ray Hauge
242149 by: Marcus Bointon
242150 by: Marcus Bointon
242151 by: Ray Hauge
242152 by: Marcus Bointon
242153 by: Robert Cummings
242154 by: Robert Cummings
242155 by: Marcus Bointon
242156 by: Ray Hauge
242157 by: Jon Anderson
242159 by: Marcus Bointon
242160 by: Marcus Bointon
242162 by: Robert Cummings
Re: File Upload Security and chmod
242148 by: tedd
Re: php/css and .htaccess [SOLVED]
242158 by: J?rgen Wind
Re: symlink
242161 by: Tom Rogers
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[email protected]
----------------------------------------------------------------------
--- Begin Message ---
ok, so if we were talking Java, perhaps you are looking for
information that allows you to build 'accessor' and 'mutator' methods?
If so, then your example should work (syntax aside). Here's another
'test' example that I just whipped up and tested that shows you can
use any method name you wish.
As I said previously, accessor/mutator methods are exactly what I am looking
for. I do like the idea of having a public 'interface' (for the lack of a
better word) to a private property. I don't particularly care for using
just the __set() and __get() methods because they are too arbitrary. If I
needed to do any specific checking or formatting for a property, either in
defining or returning the value, I'd have to have a big giant switch()
statement. So here is a roundabout solution that I got the idea/code for
while researching this issue:
class MyClass {
private $_bob;
// Private so all property access is done through the
// __set() and __get() methods
private function setBob( $bob ) {
$this->_bob = $bob;
}
private function getBob() {
return $this->_bob;
}
function __get( $var ) {
$methodName = 'get' . $var;
if( method_exists( $this, $methodName )) {
return call_user_func( array( $this, $methodName ));
} else {
throw new Exception( 'Method [' . $methodName . '] does not exist' );
}
// echo "In __get( $var )\n";
}
function __set( $key, $var ) {
$methodName = 'set' . $key;
if( method_exists( $this, $methodName )) {
call_user_func( array( $this, $methodName ), $var );
} else {
throw new Exception( 'Method [' . $methodName . '] does not exist' );
}
// echo "In __set( $key, $var )\n";
}
function __call( $method, $args ) {
// echo 'Calling [' . $method . '] with args: [' . print_r( $args, TRUE )
. ']';
}
}
try {
$myClass = new MyClass();
$myClass->Bob = 'JoeBobBriggs' ;
echo '$myClass: <pre>' . print_r( $myClass, TRUE ) . '</pre>';
echo $myClass->Bob . '';
} catch( Exception $e ) {
echo 'Caught exception: ', $e->getMessage(), "\n";
}
Now I can do whatever checking I need to do in the setBob() method and any
formatting in the getBob() method.
The above is not my original idea and I wish I could remember the name of
the person to thank for pointing me in this direction. :|
thnx,
Chris
--- End Message ---
--- Begin Message ---
Tom,
I tried writing to a local file(./cache/cookiejar), but to no avail.
I'll give /tmp a try to see if that location makes any difference.
Permissions aside, I should be able to write where I wish, correct?
Thanks,
Mike
On Sep 23, 2006, at 7:43 AM, [EMAIL PROTECTED]
wrote:
From: Tom Atkinson <[EMAIL PROTECTED]>
Date: September 23, 2006 7:42:32 AM EDT
To: [email protected]
Subject: Re: [PHP] libcurl (cookies across cURL session). . .?
Use cURL's own cookie handling features.
curl_setopt($ch, CURLOPT_COOKIEJAR, '/tmp/cookies.txt');
curl_setopt($ch, CURLOPT_COOKIEFILE, '/tmp/cookies.txt');
That will store the cookies in the file and read them from there
next time. /tmp may or may not be a suitable location.
--- End Message ---
--- Begin Message ---
A simple class like this:
class Myclass() {
public $field1 = '';
private $field2 = '';
public function __sleep() {
return array('field1', 'field2');
}
}
$myclass = new Myclass;
If I var_dump this, I get:
object(Myclass)#6 (2) {
["field1"]=>
string(0) ""
["field2:private"]=>
string(0) ""
}
If I coerce this to an array:
$arr = (array)$myclass;
the properties change names in a most unhelpful way:
array(2) {
["field1"]=>
string(0) ""
["Myclassfield2"]=>
string(0) ""
}
The docs (http://www.php.net/manual/en/language.types.array.php) say:
"If you convert an object to an array, you get the properties (member
variables) of that object as the array's elements. The keys are the
member variable names."
It seems that's not quite true.
How can I stop it doing this? Looks a bit buggy to me.
Marcus
--
Marcus Bointon
Synchromedia Limited: Creators of http://www.smartmessages.net/
[EMAIL PROTECTED] | http://www.synchromedia.co.uk/
--- End Message ---
--- Begin Message ---
On Saturday 23 September 2006 09:40, Marcus Bointon wrote:
> A simple class like this:
>
> class Myclass() {
> public $field1 = '';
> private $field2 = '';
> public function __sleep() {
> return array('field1', 'field2');
> }
> }
> $myclass = new Myclass;
>
> If I var_dump this, I get:
>
> object(Myclass)#6 (2) {
> ["field1"]=>
> string(0) ""
> ["field2:private"]=>
> string(0) ""
> }
>
> If I coerce this to an array:
>
> $arr = (array)$myclass;
>
> the properties change names in a most unhelpful way:
>
> array(2) {
> ["field1"]=>
> string(0) ""
> ["Myclassfield2"]=>
> string(0) ""
> }
>
> The docs (http://www.php.net/manual/en/language.types.array.php) say:
>
> "If you convert an object to an array, you get the properties (member
> variables) of that object as the array's elements. The keys are the
> member variable names."
>
> It seems that's not quite true.
>
> How can I stop it doing this? Looks a bit buggy to me.
>
> Marcus
> --
> Marcus Bointon
> Synchromedia Limited: Creators of http://www.smartmessages.net/
> [EMAIL PROTECTED] | http://www.synchromedia.co.uk/
To me it looks like they append the name of the class to any private
variables. I would guess that it does this to make sure you know what you're
doing and using the private variable like that. I'm just guessing at that
point though.
Try a test with multiple public and multiple private variables. If the format
of the array keys stays the same, then you should have your answer.
HTH
--
Ray Hauge
Programmer/Systems Administrator
American Student Loan Services
www.americanstudentloan.com
1.800.575.1099
--- End Message ---
--- Begin Message ---
On 23 Sep 2006, at 15:51, Ray Hauge wrote:
To me it looks like they append the name of the class to any private
variables. I would guess that it does this to make sure you know
what you're
doing and using the private variable like that. I'm just guessing
at that
point though.
Well, I realised that, but it's not very helpful as there's no
separator between class name and variable name it's impossible to
separate it correctly - if I had happened to have a property called
'myclassfield1', I would not be able to tell if the real property
name was 'myclassfield1' or a private property called 'field1'. If it
is going to stray from the documented behaviour, It would be far more
useful to retain the names that the var_dump on the object uses -
'field1:private'. That's safe as : is not a value char in a variable
name, but it's fine as an array index.
Try a test with multiple public and multiple private variables. If
the format
of the array keys stays the same, then you should have your answer.
In my real code I do have multiple fields all exhibiting this
behaviour. I'll report it.
Marcus
--
Marcus Bointon
Synchromedia Limited: Creators of http://www.smartmessages.net/
[EMAIL PROTECTED] | http://www.synchromedia.co.uk/
--- End Message ---
--- Begin Message ---
Here's a more accurate example:
<?php
class Myclass {
public $field1 = '';
private $field2 = '';
protected $field3 = '';
}
$myclass = new Myclass;
var_dump($myclass);
var_dump((array)$myclass);
?>
This produces:
object(Myclass)#1 (3) {
["field1"]=>
string(0) ""
["field2:private"]=>
string(0) ""
["field3:protected"]=>
string(0) ""
}
array(3) {
["field1"]=>
string(0) ""
["Myclassfield2"]=>
string(0) ""
["*field3"]=>
string(0) ""
}
So it seems protected fields behave differently too.
Marcus
--
Marcus Bointon
Synchromedia Limited: Creators of http://www.smartmessages.net/
[EMAIL PROTECTED] | http://www.synchromedia.co.uk/
--- End Message ---
--- Begin Message ---
On Saturday 23 September 2006 10:04, Marcus Bointon wrote:
> On 23 Sep 2006, at 15:51, Ray Hauge wrote:
> > To me it looks like they append the name of the class to any private
> > variables. I would guess that it does this to make sure you know
> > what you're
> > doing and using the private variable like that. I'm just guessing
> > at that
> > point though.
>
> Well, I realised that, but it's not very helpful as there's no
> separator between class name and variable name it's impossible to
> separate it correctly - if I had happened to have a property called
> 'myclassfield1', I would not be able to tell if the real property
> name was 'myclassfield1' or a private property called 'field1'. If it
> is going to stray from the documented behaviour, It would be far more
> useful to retain the names that the var_dump on the object uses -
> 'field1:private'. That's safe as : is not a value char in a variable
> name, but it's fine as an array index.
>
> > Try a test with multiple public and multiple private variables. If
> > the format
> > of the array keys stays the same, then you should have your answer.
>
> In my real code I do have multiple fields all exhibiting this
> behaviour. I'll report it.
>
> Marcus
> --
> Marcus Bointon
> Synchromedia Limited: Creators of http://www.smartmessages.net/
> [EMAIL PROTECTED] | http://www.synchromedia.co.uk/
Could you do something like this?
$private = "Myclass"
$protected = "*";
// public variable
echo $myclass["field1"];
// private variable
echo $myclass[$private."field2"];
// protected variable
echo $myclass[$protected."field3"];
Unless, of course, this behavior is not consistent. If it is a bug, then you
run the risk of it being fixed in the future. But if it is intended to be
that way, then this format should work regardless of what the member variable
names are.
--
Ray Hauge
Programmer/Systems Administrator
American Student Loan Services
www.americanstudentloan.com
1.800.575.1099
--- End Message ---
--- Begin Message ---
On 23 Sep 2006, at 16:37, Ray Hauge wrote:
Could you do something like this?
$private = "Myclass"
$protected = "*";
No, because if I have a property called 'Myclassfield1', after
casting to an array I can't tell if it's private property called
'field1' or a public property called 'Myclassfield1'.
I think it's just plain wrong. Arrays should not try to be objects.
You can find out protection level of a property via introspection of
the object that you have in hand. In the vast majority of cases,
you'll want it to act just like the docs say it does, and if you
don't, you should probably be using the object itself anyway.
Bug report is here: http://bugs.php.net/?id=38935
Marcus
--
Marcus Bointon
Synchromedia Limited: Creators of http://www.smartmessages.net/
[EMAIL PROTECTED] | http://www.synchromedia.co.uk/
--- End Message ---
--- Begin Message ---
On Sat, 2006-09-23 at 16:04 +0100, Marcus Bointon wrote:
> On 23 Sep 2006, at 15:51, Ray Hauge wrote:
>
> > To me it looks like they append the name of the class to any private
> > variables. I would guess that it does this to make sure you know
> > what you're
> > doing and using the private variable like that. I'm just guessing
> > at that
> > point though.
>
> Well, I realised that, but it's not very helpful as there's no
> separator between class name and variable name it's impossible to
> separate it correctly
<?php
class MyClass()
{
public $field1 = '';
private $field2 = '';
public function __sleep()
{
return array('field1', 'field2');
}
}
$myClass = new Myclass;
$prefix = get_class( $myClass );
$prefixL = strlen( $prefix );
$myArray = (array)$myClass;
foreach( $myArray as $name => $value )
{
if( substr( $name, 0, 1 ) === '*' )
{
$foo = &$myArray[$name];
unset( $myArray[$name] );
$myArray[substr( $name, 1 )] = &$foo;
}
else
if( ereg( "^$prefix", '', $name ) )
{
$foo = &$myArray[$name];
unset( $myArray[$name] );
$myArray[substr( $name, $prefixL )] = &$foo;
}
}
?>
> - if I had happened to have a property called
> 'myclassfield1', I would not be able to tell if the real property
> name was 'myclassfield1'
And the likelihood of you having a property called Myclassfield1 is?
Most developers start a class name with a capital, and a property name
with a lowercase. So the likelihood if you are adhering to convention is
slim to squat. That said, I think they should have put in a -> or a :
character :)
> or a private property called 'field1'. If it
> is going to stray from the documented behaviour, It would be far more
> useful to retain the names that the var_dump on the object uses -
> 'field1:private'. That's safe as : is not a value char in a variable
> name, but it's fine as an array index.
>
> > Try a test with multiple public and multiple private variables. If
> > the format
> > of the array keys stays the same, then you should have your answer.
>
> In my real code I do have multiple fields all exhibiting this
> behaviour. I'll report it.
It sounds like they've helped out by giving more data than was
necessary. This can be useful when working with the data to know it's
origin.
Cheers,
Rob.
--
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'
--- End Message ---
--- Begin Message ---
On Sat, 2006-09-23 at 11:46 -0400, Robert Cummings wrote:
> On Sat, 2006-09-23 at 16:04 +0100, Marcus Bointon wrote:
> > On 23 Sep 2006, at 15:51, Ray Hauge wrote:
> >
> > > To me it looks like they append the name of the class to any private
> > > variables. I would guess that it does this to make sure you know
> > > what you're
> > > doing and using the private variable like that. I'm just guessing
> > > at that
> > > point though.
> >
> > Well, I realised that, but it's not very helpful as there's no
> > separator between class name and variable name it's impossible to
> > separate it correctly
>
> <?php
>
> class MyClass()
> {
> public $field1 = '';
> private $field2 = '';
>
> public function __sleep()
> {
> return array('field1', 'field2');
> }
> }
>
> $myClass = new Myclass;
> $prefix = get_class( $myClass );
> $prefixL = strlen( $prefix );
>
> $myArray = (array)$myClass;
> foreach( $myArray as $name => $value )
> {
> if( substr( $name, 0, 1 ) === '*' )
> {
> $foo = &$myArray[$name];
> unset( $myArray[$name] );
> $myArray[substr( $name, 1 )] = &$foo;
> }
> else
> if( ereg( "^$prefix", '', $name ) )
That line should have been: if( ereg( "^$prefix", $name ) ). I was
originally doing a replace, but then I scrapped it :)
Cheers,
Rob.
--
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'
--- End Message ---
--- Begin Message ---
On 23 Sep 2006, at 16:46, Robert Cummings wrote:
And the likelihood of you having a property called Myclassfield1 is?
Sure, but don't you think that coding should at least try to be
driven by logic rather than luck? I'm also not denying that it's not
too hard to work around (with a function not dissimilar to what you
suggested), but I'd really prefer it if it just did what it says on
the tin. By its very nature, casting from object to array indicates
that you no longer want the constraints of property protection, which
an array can't preserve anyway, and it's not as if there are not
intentional, documented methods of obtaining this information.
It sounds like they've helped out by giving more data than was
necessary.
...and in doing so defaults to breaking code that expects it to
behave like the documentation says it does? I don't think I'd
classify that as helping out. Bear in mind that my code broke in
exactly this way. If you want to find out what the access level of a
property is, I doubt your first thought would be to convert it to an
array - and I bet you didn't know that this info was even there
because it's not documented, thus helping nobody. This is what
introspection is for. I don't have a problem with being provided with
extra information, just as long as it doesn't interfere with correct
operation, which is what it currently does. It could provide the
extra info in a marginally less destructive way, for example by
adding 'private' and 'protected' array properties containing field
names for each access level to the resulting array. OTOH, that would
break what you'd expect count() to deliver after the conversion. I
really think it should just do what's it's meant to, and no more.
Marcus
--
Marcus Bointon
Synchromedia Limited: Creators of http://www.smartmessages.net/
[EMAIL PROTECTED] | http://www.synchromedia.co.uk/
--- End Message ---
--- Begin Message ---
On Saturday 23 September 2006 11:41, Marcus Bointon wrote:
> On 23 Sep 2006, at 16:46, Robert Cummings wrote:
> > And the likelihood of you having a property called Myclassfield1 is?
>
> Sure, but don't you think that coding should at least try to be
> driven by logic rather than luck? I'm also not denying that it's not
> too hard to work around (with a function not dissimilar to what you
> suggested), but I'd really prefer it if it just did what it says on
> the tin. By its very nature, casting from object to array indicates
> that you no longer want the constraints of property protection, which
> an array can't preserve anyway, and it's not as if there are not
> intentional, documented methods of obtaining this information.
>
> > It sounds like they've helped out by giving more data than was
> > necessary.
>
> ...and in doing so defaults to breaking code that expects it to
> behave like the documentation says it does? I don't think I'd
> classify that as helping out. Bear in mind that my code broke in
> exactly this way. If you want to find out what the access level of a
> property is, I doubt your first thought would be to convert it to an
> array - and I bet you didn't know that this info was even there
> because it's not documented, thus helping nobody. This is what
> introspection is for. I don't have a problem with being provided with
> extra information, just as long as it doesn't interfere with correct
> operation, which is what it currently does. It could provide the
> extra info in a marginally less destructive way, for example by
> adding 'private' and 'protected' array properties containing field
> names for each access level to the resulting array. OTOH, that would
> break what you'd expect count() to deliver after the conversion. I
> really think it should just do what's it's meant to, and no more.
>
> Marcus
You're right about the undocumented feature that you ran into. It did not
behave the way the documentation pointed it out, and either the documentation
or the behavior needs to be modified.
I would guess that modification of the behavior might take a while to come
out, unless you were going to patch your install, but even then it might be a
while. So, to get around that you could create a function to "convert" the
array to what you expected. Here's a possible declaration:
function convertClassArray($array, $className)
That function would then create a new array and change the keys as necessary,
stripping off the class name from the private variables and stripping off the
* from the protected ones, to give you what you expected. Not exactly what
you're looking for, but it would probably help to keep the changes to your
existing code down while you're waiting for a patch/documentation change.
--
Ray Hauge
Programmer/Systems Administrator
American Student Loan Services
www.americanstudentloan.com
1.800.575.1099
--- End Message ---
--- Begin Message ---
Marcus Bointon wrote:
Sure, but don't you think that coding should at least try to be driven
by logic rather than luck? I'm also not denying that it's not too hard
to work around (with a function not dissimilar to what you suggested),
but I'd really prefer it if it just did what it says on the tin. By
its very nature, casting from object to array indicates that you no
longer want the constraints of property protection, which an array
can't preserve anyway, and it's not as if there are not intentional,
documented methods of obtaining this information.
Along those lines, I think that logically, if you were to cast an Object
to an array, it should only export the public properties. Since the
private/protected properties aren't visible outside the class, it would
be safe to assume that they're not for public consumption. After all,
they're intended (by design of the class) only to be accessed via
functions defined in the class. I think PHP's behavior is a bit odd, but
still somewhat logical.
If you just want an array of properties, add this to your class.
public function getPropertyArray() {
$refClass = new ReflectionClass(__CLASS__);
$properties = $refClass->getProperties();
$propArray = Array();
foreach ($properties as $property) {
if (!$property->isStatic()) {
$name = $property->getName();
$propArray[$name] = $this->$name;
}
}
return($propArray);
}
And that'll do essentially what you're asking for. You could just call
it toArray() too, and even check for isPublic/isPrivate/isProtected for
some additional granularity.
jon
--- End Message ---
--- Begin Message ---
On 23 Sep 2006, at 18:54, Jon Anderson wrote:
If you just want an array of properties, add this to your class...
That's exactly the kind of thing I was on about. Since reflection
gives access to all this information, why bother trying to squeeze
the same info into an array-shaped container that just can't hold all
the same info without corrupting it? I can see that there might be
some reason for converting the object with additional information in
some circumstances (much like serialization to strings does), but
here we're only talking about casting, which should be a 'best-fit'
data matter. The behaviour we've got would be better served with a
function like toArrayPreservingClassInfo() rather than the default
casting behaviour.
Since reporting the bug (which was immediately marked as bogus; go
figure), I've had something else brought to my attention: The
resulting array keys are not what they seem! Their actual structure is:
NULL<classname>NULL<propertyname>
So, here we have undocumented behaviour justified by yet more
undocumented behaviour! How behaviour so wildly different to what's
documented is not considered a bug I don't know. At least this format
can be dismantled reliably, rather than trying to string-match class
names. I think trying to preserve this information (as you said) is
entirely pointless - it's not as if you can cast back from an array
to an object, and I can't think of any circumstances in which it is
preferable to using reflection (unless it's a relic from PHP4?).
What's next - appending a creation time to integers when they're cast
into strings?
Marcus
--
Marcus Bointon
Synchromedia Limited: Creators of http://www.smartmessages.net/
[EMAIL PROTECTED] | http://www.synchromedia.co.uk/
--- End Message ---
--- Begin Message ---
I've written a function that does a conversion that matches the docs,
based on the other info I've mentioned:
/**
* Clean up the name munging that PHP applies while casting from
object to array
* The resulting array looks like what the documentation says that
(array)$object delivers, but actually doesn't
* @param object $object The object to convert
* @return array
*/
function object2array($object) {
$class = get_class($object);
$array = (array)$object;
$propArray = array();
$matches = array();
foreach ($array as $key => $value) {
if (preg_match('/^\0(([a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*)\0
([a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*)$/', $key, $matches)) {
//It's a private property
if ($matches[1] == $class) { //Ignore private props of
superclasses
$propArray[$matches[2]] = $value;
}
} elseif (preg_match('/^\0(\*)\0([a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-
\xff]*)$/', $key, $matches)) {
//It's a protected property
$propArray[$matches[2]] = $value;
} else {
//It's a public property
$propArray[$key] = $value;
}
}
return $propArray;
}
Works nicely for me.
Marcus
--
Marcus Bointon
Synchromedia Limited: Creators of http://www.smartmessages.net/
[EMAIL PROTECTED] | http://www.synchromedia.co.uk/
--- End Message ---
--- Begin Message ---
On Sat, 2006-09-23 at 17:41 +0100, Marcus Bointon wrote:
> On 23 Sep 2006, at 16:46, Robert Cummings wrote:
>
> > And the likelihood of you having a property called Myclassfield1 is?
>
> Sure, but don't you think that coding should at least try to be
> driven by logic rather than luck? I'm also not denying that it's not
> too hard to work around (with a function not dissimilar to what you
> suggested), but I'd really prefer it if it just did what it says on
> the tin. By its very nature, casting from object to array indicates
> that you no longer want the constraints of property protection, which
> an array can't preserve anyway, and it's not as if there are not
> intentional, documented methods of obtaining this information.
>
> > It sounds like they've helped out by giving more data than was
> > necessary.
>
> ...and in doing so defaults to breaking code that expects it to
> behave like the documentation says it does? I don't think I'd
> classify that as helping out. Bear in mind that my code broke in
> exactly this way. If you want to find out what the access level of a
> property is, I doubt your first thought would be to convert it to an
> array - and I bet you didn't know that this info was even there
> because it's not documented, thus helping nobody. This is what
> introspection is for. I don't have a problem with being provided with
> extra information, just as long as it doesn't interfere with correct
> operation, which is what it currently does. It could provide the
> extra info in a marginally less destructive way, for example by
> adding 'private' and 'protected' array properties containing field
> names for each access level to the resulting array. OTOH, that would
> break what you'd expect count() to deliver after the conversion. I
> really think it should just do what's it's meant to, and no more.
Blah, blah, blah. The documentation is probably out of date and applied
to PHP4. Feel free to get off your arse and volunteer if you don't like
it >:) You don't get have your cake and eat it *PTHTHTHTHTTHTHTH*
Cheers,
Rob.
--
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'
--- End Message ---
--- Begin Message ---
At 7:19 PM -0600 9/22/06, Andy Hultgren wrote:
For whatever reason when I ftp in using WinFtp I don't see public_html
(it's hidden, don't know why; if I make a directory called
".public_html" it gets created and then disappears), but I can see my
file structure from my host's website and so I know that when I ftp in
to myDomain.com this is what is "there":
index.htm
page1.htm
page2.htm
.public_html/
images/
etc. etc.
Andy:
Sorry, I didn't catch all of the thread, but this is my drift.
When you access your site (http://yourdomain.com) via a browser, do
you see the above index.htm?
If so, and you want to stay with that host, then leave the
.public_html/ folder alone, and build your site using WinFTP, or
whatever.
If you want to change permissions for a file from within a php
script, then ftp into your site (using ftp_login), change the parent
folder permissions, do your file thing (upload, delete, save, etc.),
and then change the parent folder permissions back and it's done.
At least that's the way I do it working on a shared host and it works for me.
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
--- End Message ---
--- Begin Message ---
tedd wrote:
>
> At 10:37 AM -0500 9/21/06, David Giragosian wrote:
>>On 9/21/06, tedd <<mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]> wrote:
>>-snip-
>>
>>Now, this header coupled with the above .htaccess allows php code to
>>be embedded within a css file AND work for all popular browsers,
>>including FireFox/Mozillia.
>>-snip-
>>
>>tedd,
>>
>>So with this approach you're able to tailor css styles for specific
>>browsers and their particular implementations of css, rather than
>>employ hacks directly in the css??
>
> David:
>
> Yes, plus much more. This is similar to getting php/html to play nice
> together.
>
> What I've discovered here (if no one has considered this before,
> which I would think is highly doubtful) is a way to embed php code
> within css (like html) to do anything you want.
>
> You see, my chief complaint with css over the years has been its lack
> of variables. Many in the css camp say that the lack of variables is
> a feature and not a drawback -- and I understand them not wanting the
> unclean masses to contaminate their pure language. But, not knowing
> any better, I've always wanted to use variables in css.
>
> A few years back, I published my limited version of how to use
> variables in css:
>
> http://www.sperling.com/examples/pcss/
>
> But for most, it was too problematic to implement and had limited scope.
>
> However, what I've discovered here is that by adding the proper
> .htaccess file and the addition of a header in the css file, you can
> do anything you want from within a css file -- which includes adding
> variables, adding "includes", performing computations, browser
> sniffing, and I think anything else you can do in php. The extent
> could be as unlimited as php/html -- I don't know the full extent.
>
> As far as I'm concerned, this is a significant discovery for me --
> I'm always trying to get different languages to work together.
> However, to others, perhaps this technique has been obvious or too
> trivial to mention. I don't know, but I haven't found any references
> that address this technique.
>
> To the gang -- is this something new, or am I getting excited over
> nothing?
>
> In any event, I'll be adding "how to do it" to my web site so I can
> lead others astray. :-)
>
> Thanks.
>
> tedd
>
> --
> -------
> http://sperling.com http://ancientstones.com http://earthstones.com
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>
full ack,
you only have to make sure that zlib.output_compression is off (at least in
that folder),
if you want IE6 users to be able to read the css content !
--
View this message in context:
http://www.nabble.com/php-css-and-.htaccess-tf2308435.html#a6465094
Sent from the PHP - General mailing list archive at Nabble.com.
--- End Message ---
--- Begin Message ---
Hi,
Saturday, September 23, 2006, 10:37:20 AM, you wrote:
RL> On Mon, September 18, 2006 4:53 pm, Ross wrote:
>> Can someone explain how and why you would use a symlink in php?
RL> A symlink is the Un*x version of a Windows "shortcut" or the Mac's
RL> "alias"
RL> The difference being that a symlink actually *works* and a Windows
RL> "shortcut" is useless for anything except their crappy desktop app...
in windows 2k and xp you can use fsutil to create hard links in the
same NTFS volume.
Usage : fsutil hardlink create <new filename> <existing filename>
fsutil hardlink create c:\foo.txt c:\bar.txt
But it probably has a few bugs of its own :) and it can't do your edit
trick as it only works on files not directories as far as I can tell.
--
regards,
Tom
--- End Message ---
