php-general Digest 11 Jan 2009 13:24:52 -0000 Issue 5895
Topics (messages 285999 through 286012):
Re: Unique Object Instance ID..?
285999 by: Nathan Nobbe
286006 by: Ross McKay
286008 by: Micah Gersten
286010 by: Robert Cummings
Re: Editing in a text area field
286000 by: Murray
286001 by: Ashley Sheridan
286002 by: Murray
286003 by: Eric Butera
286004 by: Murray
286005 by: Ross McKay
286012 by: tedd
Re: Referencing variable in calling class?
286007 by: Paul M Foster
Re: hello
286009 by: Robert Cummings
Re: Couple of beginner questions
286011 by: tedd
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 ---
On Sat, Jan 10, 2009 at 4:31 PM, Nathan Rixham <[email protected]> wrote:
> Evening All,
>
> Not too often I ask a question here, but here goes;
>
> I'm making an "Object" class which all of my other classes extend, and I
> need each instance to have it's own unique id, seemed simple but it's harder
> than I thought (the difficulty is when it comes to deciding the syntax).
checkout spl_object_hash()
http://php.net/function.spl_object_hash
-nathan
--- End Message ---
--- Begin Message ---
On Sat, 10 Jan 2009 18:42:01 -0700, Nathan Nobbe wrote:
>checkout spl_object_hash()
>
>http://php.net/function.spl_object_hash
NB: only guarantees uniqueness for objects instantiated and in memory at
the same time. See the comments on that page for an example of creating
identical object hashes for two separate and distinct instances.
--
Ross McKay, Toronto, NSW Australia
"Let the laddie play wi the knife - he'll learn"
- The Wee Book of Calvin
--- End Message ---
--- Begin Message ---
Can you use something like APC to cache the instance variable so that
it's persistent across different sessions?
Thank you,
Micah Gersten
onShore Networks
Internal Developer
http://www.onshore.com
Nathan Rixham wrote:
> Colin Guthrie wrote:
>> 'Twas brillig, and Nathan Rixham at 10/01/09 23:31 did gyre and gimble:
>>> all I need is a completely unique id for each object instance that
>>> can never be repeated at any time, even in a multiserver environment
>>> (and without using any kind of incremented value from a db table or
>>> third party app)
>>>
>>> thoughts, ideas, recommendations?
>>
>> While it's not guaranteed to be unique the general technique used in
>> these situations is to use a UUID. The chances of a clash are slim
>> (2x10^38 ish combinations).
>>
>> You can generate a uuid via mysql "SELECT UUID()" or via the PHP Pecl
>> extension php-uuid.
>>
>> The other way of doing it would be to insert a row into a database
>> row with an auto-increment field and use the value of that
>> auto-incrment field as your identifier (SELECT LAST_INSERT_ID() in
>> mysql or via the db layers API).
>>
>> HTHs
>>
>> Col
>>
>>
>
> cheers for the input; uuid it has to be I guess; don't want it reliant
> on any third party software or db so pecl is out, as is mysql - looks
> like I'm going to have to (and probably enjoy) making a uuid function
> to generate type 4 random uuids.
>
> only other thought is to combine all the instance variables, hash the
> combination of them and save that together with a timestamp..
>
> considering
>
--- End Message ---
--- Begin Message ---
On Sun, 2009-01-11 at 00:07 +0000, Nathan Rixham wrote:
> Colin Guthrie wrote:
> > 'Twas brillig, and Nathan Rixham at 10/01/09 23:31 did gyre and gimble:
> >> all I need is a completely unique id for each object instance that can
> >> never be repeated at any time, even in a multiserver environment (and
> >> without using any kind of incremented value from a db table or third
> >> party app)
> >>
> >> thoughts, ideas, recommendations?
> >
> > While it's not guaranteed to be unique the general technique used in
> > these situations is to use a UUID. The chances of a clash are slim
> > (2x10^38 ish combinations).
> >
> > You can generate a uuid via mysql "SELECT UUID()" or via the PHP Pecl
> > extension php-uuid.
> >
> > The other way of doing it would be to insert a row into a database row
> > with an auto-increment field and use the value of that auto-incrment
> > field as your identifier (SELECT LAST_INSERT_ID() in mysql or via the db
> > layers API).
> >
> > HTHs
> >
> > Col
> >
> >
>
> cheers for the input; uuid it has to be I guess; don't want it reliant
> on any third party software or db so pecl is out, as is mysql - looks
> like I'm going to have to (and probably enjoy) making a uuid function to
> generate type 4 random uuids.
>
> only other thought is to combine all the instance variables, hash the
> combination of them and save that together with a timestamp..
Use microtime for your timestamp... much less likely to have a collision
than using seconds.
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
--- End Message ---
--- Begin Message ---
I don't know why, but I always baulk when I see HTML and, for example, XML
etc described as a 'language'.
I may well be wrong, but these always seem to be more appropriately
described as a 'syntax' rather than a 'language', at least in the computer
science sense. Of course, maybe these are essentially synonymous, but
'language' has always implied to me a more active role, so that PHP would be
a language, while HTML would be a syntax.
Just thinking out loud.
M is for Murray
On Sun, Jan 11, 2009 at 2:04 AM, Nathan Rixham <[email protected]> wrote:
> HTML is a markup language used to describe the structure of a document;
> presentation of HTML is controlled by either a client, with optional
> instructions via attributes (bad) or css (good)
--- End Message ---
--- Begin Message ---
On Sun, 2009-01-11 at 11:44 +1000, Murray wrote:
> I don't know why, but I always baulk when I see HTML and, for example, XML
> etc described as a 'language'.
>
> I may well be wrong, but these always seem to be more appropriately
> described as a 'syntax' rather than a 'language', at least in the computer
> science sense. Of course, maybe these are essentially synonymous, but
> 'language' has always implied to me a more active role, so that PHP would be
> a language, while HTML would be a syntax.
>
> Just thinking out loud.
>
> M is for Murray
>
>
> On Sun, Jan 11, 2009 at 2:04 AM, Nathan Rixham <[email protected]> wrote:
>
> > HTML is a markup language used to describe the structure of a document;
> > presentation of HTML is controlled by either a client, with optional
> > instructions via attributes (bad) or css (good)
I think you are thinking of language being synonymous with programming
language, which HTML isn't really. What it is, is a computer language.
Subtle difference, but difference, I believe, there is. Also, the name
kind of gives it away ;)
Ash
www.ashleysheridan.co.uk
--- End Message ---
--- Begin Message ---
Interesting, I've never seen this presented as an issue of ethics before. I
think I can see your point, but I'd suggest that there's an interplay of
ethical obligations between a user and the host / creator of an application
in which perhaps the user should or in many cases has to accept a
de-prioritised ethical consideration.
For example, I would guess that a user doesn't have the right to expect an
application to perform exactly to his or her expectations, regardless of
what they might be. So, I wouldn't consider myself ethically obligated to
work out how to accept 3gb of text from a POSTed form without truncating /
modifying that text due to practical limitations of my application. (not
suggesting this is a possible real-world example).
But still, an interesting observation!
M is for Murray
On Sat, Jan 10, 2009 at 6:36 AM, Daniel Brown <[email protected]> wrote:
> Well, of course you have the _right_ to do it --- as long as it's
> legal, and it's not something that *requires* the data to remain
> unaltered, you have the right to do manipulate it however you want.
> The question comes down to ethics and in predicting the preferences of
> the user.
>
--- End Message ---
--- Begin Message ---
On Sat, Jan 10, 2009 at 8:51 PM, Murray <[email protected]> wrote:
> Interesting, I've never seen this presented as an issue of ethics before. I
> think I can see your point, but I'd suggest that there's an interplay of
> ethical obligations between a user and the host / creator of an application
> in which perhaps the user should or in many cases has to accept a
> de-prioritised ethical consideration.
>
> For example, I would guess that a user doesn't have the right to expect an
> application to perform exactly to his or her expectations, regardless of
> what they might be. So, I wouldn't consider myself ethically obligated to
> work out how to accept 3gb of text from a POSTed form without truncating /
> modifying that text due to practical limitations of my application. (not
> suggesting this is a possible real-world example).
>
> But still, an interesting observation!
>
> M is for Murray
>
>
> On Sat, Jan 10, 2009 at 6:36 AM, Daniel Brown <[email protected]> wrote:
>
>> Well, of course you have the _right_ to do it --- as long as it's
>> legal, and it's not something that *requires* the data to remain
>> unaltered, you have the right to do manipulate it however you want.
>> The question comes down to ethics and in predicting the preferences of
>> the user.
>>
>
I don't see any problem with accepting html/xhtml/xml in an input
area. I do it all the time with FCKEditor. You can argue that it is
nice because you can use things like htmlpurifier to keep it sane
while also not having to invent weird things to give the input
structure/looks. Also being able to parse it with
simplexml/domdocument is useful too in a lot of cases.
One easy way to get around the problem with "modifying" the user
input, just give the user a preview of what you've done. They can
then decide whether or not it is acceptable.
--- End Message ---
--- Begin Message ---
I agree with others that in most cases you should be storing input as it is
presented to you once POSTed (with the usual caveats of escaping etc to make
INSERTing / UPDATEing possible).
This is exactly what you are doing when accepting input from FCKEditor etc.
Your input contains markup, and that's what you store.
My issue with modifying content after being POSTed, prior to storing in my
db is that for all of the careful considerations that I might put into
making only 'good' modifications, I might inadvertently make 'bad'
modifications instead or as well.
The same is true if I store the text and modify on the fly on the way to
presentation, but the important difference is that my stored version has
remained true to input, and if I correct whatever I might have done wrong
during display processing, I have not permanently changed or damaged my
stored data.
M is for Murray
On Sun, Jan 11, 2009 at 11:57 AM, Eric Butera <[email protected]> wrote:
> I don't see any problem with accepting html/xhtml/xml in an input
> area. I do it all the time with FCKEditor.
>
--- End Message ---
--- Begin Message ---
Ashley Sheridan wrote:
>FCKEditor is a good editor (although poorly named!) that allows you to
>set it not to use <b> and <i> tags and force it to convert them to
><strong> and <em> instead. Couple this with a decent regex and you can
>strip out the extra style tags which result from a pasted MSWord
>selection.
Likewise with TinyMCE (and I suspect many of the others). Given the
abundance of good rich text editors, I don't see any good reason for
making clients enter HTML tags directly - it only confuses them.
--
Ross McKay, Toronto, NSW Australia
"The lawn could stand another mowing; funny, I don't even care"
- Elvis Costello
--- End Message ---
--- Begin Message ---
At 7:02 PM -0500 1/10/09, Phpster wrote:
That can and should be done with a simple str_replace() on the
display portion of the code.
Bastien
Really?
Then how do you handle these examples of client input?
This is <b<what</b> I have to say.
This is <i><b>what</i></b> I have to say.
This is <b>what<b> I have to say.
This is <b>what /> I have to say.
This is what</b> I have to say.
And I could go on with even more examples. The point is that when you
allow the client to inject style elements into data, then things can
go wrong on several fronts.
One, of course is that the client can inject malformed code, which
can screw up the page.
Two, by allowing the client to do inject styling elements, then you
are not keeping style and date elements separate. That is counter to
"best practices".
For example, what happens at some later date when the client wants to
change how the data looks? The client says "You told me that you were
using css -- I thought it was easy to change things. Why can't you
remove all these bold statements?"
Of course, you could go to the css file and make bold not bold but
then what happens when you need bold? This problem not as simple as
using str_replace().
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
--- End Message ---
--- Begin Message ---
On Sun, Jan 11, 2009 at 10:33:30AM +1000, Murray wrote:
> Hi All,
>
> I'd like to reference the value of a variable in a class that called the
> current piece of code via a require_once.
>
> In essence, I have a 'front controller' class that builds the page to be
> displayed depending on several criteria.
>
> One issue I'm having is that when a user logs out of my application, I
> destroy the cookie that indicated the user was logged in during my preRender
> process, and then go onto display the 'logged out' page. Unfortunately, I
> have a page element that indicates whether the user is logged in or not, and
> I assume because the cookie destruction is being sent down in that page
> request, when that page renders it still appears as if the user is logged
> in, because the cookie still exists until after that page is rendered.
>
> So, I thought perhaps as part of my logout routine, I could set a variable
> that my 'are you logged in or out' code could check and use to override
> whether or not it displays the 'login' url or the 'logout' url.
>
> I thought that in that code I should be able to check the value of a public
> variable that is in my front controller class, but it appears I can't?
>
> So, pseudo chain of processing would be something like this:
>
> - call index.php
> - instantiate front loader class
> - perform pre-render processing, if logging out, set public variable in
> class to true
> - call actual page to be rendered via require_once
> - in page being rendered, call function from separate file that displays
> 'login / logout' url
> - in that function test public variable in front controller class to see if
> true
> - if true, regardless of whether or not the cookie still 'appears' to exist,
> display 'login' url because user has logged out
>
> However, am I right in thinking that the function that displays the login /
> logout url is actually unaware of the existence of the front controller
> class at the point at which it is being called?
>
> M is for Murray
I'm not quite sure why you don't force the login/logout page to use the
front controller. Here's how I do it: I set various variables, and check
the login status (I use $_SESSION variables to hold user ID and
encrypted password). If the user is not logged in, I force the
controller to be the login controller, regardless of whatever page the
user *wants* to display. Then I go ahead with instantiating the
controller, in this case, the login controller. So essentially, if the
user is logged in, I go ahead and instantiate whatever controller they
specify. But if they're not logged in, I force the login controller to
be the one which is instantiated. (In my case, the "front controller"
isn't really a class as other controllers are. It's just a bunch of
routines and function calls in index.php.)
Does that make sense?
Paul
--
Paul M. Foster
--- End Message ---
--- Begin Message ---
On Sat, 2009-01-10 at 23:58 +0100, Björn Bartels wrote:
> *rofl*
>
> damn... i love this list... so much for on- ehmmm off-list posts :p ...
It's not just a list... it's a community :)
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
--- End Message ---
--- Begin Message ---
At 4:16 PM -0500 1/10/09, Paul M Foster wrote:
And let me present an alternative perspective. Never do something like:
<?php echo 'Hellow world'; ?>
Let Apache (or whatever) interpret HTML as HTML, and don't make it
interpret PHP code as HTML.
Instead, do:
<h1>Hello world</h1>
If you're going to use PHP in the middle of a bunch of HTML, then only
use it where it's needed:
<h1>Hello <?php echo $name; ?></h1>
The contents of the PHP $name variable can't be seen by the HTML, which
is why you need to enclose it in a little PHP "island". Naturally, if
you're going to put PHP code in the middle of a HTML page, make the
extension PHP. Otherwise, Apache will not interpret the PHP code as PHP
(unless you do some messing with .htaccess or whatever). It's just
simplest to call a file something.php if it has PHP in it.
Paul
--
Paul M. Foster
Paul:
I agree with you. My example was not well thought out. My point was
not to mix style elements with data. I should have said:
I would consider the following"bad practice":
<?php echo("<h1>$whatever</h1>"); ?>
Whereas, the following I would consider "good practice".
<h1><?php echo("$whatever"); ?></h1>
Thanks for keeping me honest.
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
--- End Message ---
