redbullmarky

i moved this as it has no use of classes/objects and isn't OOP. Please get yourself acquainted with the boards and pick a suitable place before posting. also - if you get errors, please post them as you see them and we'll probably be able to help better.

search engines (or bots in general) don't store cookies, so the session ID needs to be passed across the URL. What you're seeing is the session_id(). it's an automatic (unless switched off) feature of PHP allowing sessions to be maintained for users without cookies enabled.

please read the stickies and look around before opening a topic. if the site had a single £ for every time this question has been asked, we could buy facebook. http://www.phpfreaks.com/forums/index.php/topic,58799.0.html topic locked.

please make sure your next topic is posted in the correct section - this has nothing to do with OOP. Also, you might want to be a bit more clear about what problems you're getting with the code - errors, issues, unexpected behaviour, etc. we can't just guess

just because someone's budget is tight, doesn't mean necessarily you need to throw something clunky together. the fact that he's coming back for repeat work means he's probably a decent sort of guy, who you underestimated a bit. for me, writing a maintainable application versus a quick job involves nothing more than a pen and paper and a small amount of time versus just diving straight in without preperation. it might be worth asking him exactly where he sees the project going overall, to guage how much additional work needs putting into it. then you'd be in a better position as to whether it's worth your time refactoring. or even whether you can use any of the system's elements for future projects? word of mouth is the strongest form of advertising, so keeping everyone happy regardless of project size is so so important. i'd heavily recommend against getting in a similar situation for future projects.

Hmmm. John, when a class is written to pretty much act as a "wrapper" for data that's already available globally (sessions and request data being my first thoughts), is it still bad? If I had a single object do deal with, then passing it around doesn't seem an issue. But taking into account that most of my system will need access to the Request, Session, Config and DB objects, how is the best way to pass all of these around so they're readily accessible?

ahh looks handy. thanks! you say: as if you don't really do it this way at the mo, so how do you generally handle things like for your current stuff, with regards to passing around objects?

have a look here, as this question has already been asked a while back: http://www.phpfreaks.com/forums/index.php/topic,167238.0.html

i just did help you. not only did i help you though, but i helped anyone else in need of something similar that reads it, not just your private circle of friends. see how it works? Some keywords/phrases to try in Google to help yourself: - database model php - RowDataGateWay Some frameworks to look at to get "study material": - CakePHP - CodeIgniter - Django (not PHP, but easy enough to grasp) - Ruby on Rails (as above, not PHP)

if you want a personal response, please post in the freelance forum for paid help - otherwise, help/responses should be posted here publicly to help others that maybe in the same boat as you in response to your question, this might be a start: http://forums.devnetwork.net/viewtopic.php?p=263455 also having a look at some well established php frameworks (google is your friend here - take a look at the code of a good few of them) will help. CakePHP's Model works for me, but there are plenty of others.

yup that's it. i mean i know how i'd implement it, but just wondering the longer term effects. i cant think of any right now, but having said that, i never thought there was anything wrong with my original spaghetti code from my earlier days until i needed to do some serious restructure work. I suppose there's the temptation to overly use it, which could probably introduce all the problems associated with globals, but i'm just looking at pretty much using it for "wrapper" objects for stuff that's accessible globally anyway (or should/could be).

bright and a bit cheap. currently there's not much there either, so quite bland too, irrespective of the colours. pink is one of those colours notoriously tricky to get decent results from, at least for the web anyway. Unless you really know what you're doing, leave the pink to the experts and move to something a little safer.

Hi all I've been doing a bit of reading up on a few of the simpler patterns recently, especially those that handle object creation/storage for ease of access/use across my system. Not just any old objects, but moreso for those that are sort of global anyway - session, request (wrapper class for accessing GPC stuff), DB and config. So my question - are there any serious pitfalls (putting best-practice aside for a bit) of combining the registry with a factory, so i'd have factory methods such as getSession/getRequest (all under one factory roof), etc but where they actually store the instance for the next time they're required? Looking under the bonnet of Joomla, they do something sorta like this. From what I've gathered/understood so far from other sources, the normal Factory returns a new instance of a requested object, rather than a previously instantiated one. Other implementations have each class using their own factory - so instead of Factory::getSession(), it'd be more like Session::getInstance() - though wouldn't the latter mean that I've have lots of Singletons running all over the place rather than just the one? Is the way I explained still classed as the Factory pattern and i've just got my understanding muddled? Or is it really a dirty love child of both patterns? Any thoughts? Cheers Mark

says it all. dJtl, please search the forums before posting - there are huge topics to some of the questions you're asking, and they're not exactly hidden away and hard to find... edit: you were also asked kindly here to do exactly this - please do not double post topic locked.

http://www.phpfreaks.com/forums/index.php/topic,119433.0.html

i'm locking this for the reason stated by GingerRobot.

htmlspecialchars doesn't handle all the characters that can be used for SQL injections. htmlspecialchars is ideal for when outputting "unknown" data to the screen, which will help prevent XSS attacks. you might want to look at mysql_real_escape_string() instead, as it's designed for the job at hand. i have to be honest though and say that i'm not a huge fan of "blanket" operations like this, at least with not keeping an original copy at least. this makes it a pain in the ass for making comparisons, due to extra slashes. eg, an input of: Hello 'World' will produce something like: Hello \'World\' - meaning if you need to check the value of the necessary $_GET/$_POST var, you're gonna come unstuck: // example code, but in effect your filter stuff would go here $message = "Hello 'World'"; $_GET['message'] = mysql_real_escape_string($message); // produces Hello 'World' // rest of code here // now the check if ($_GET['message'] == "Hello 'World'") { echo 'match!'; } I tend to escape the raw data just before putting it in the DB (mysql_real_escape_string) and also escape the raw data just before putting it to the browser (htmlspecialchars). Writing a simple set of functions, or building an input class (to replace accessing $_GET/$_POST directly altogether), would be (and is) my personal preference here.

that's enough. topic locked.

kinda sidetracking your question, and without sounding rude, these types of buttons (at least the ones that i see on buttongenerator) are a little bit 'yesterday' and pretty ugly. a smidgeon of Photoshop (or Fireworks/The GIMP, or any other half-decent graphics package) coupled with some clever CSS, and thing's will start to look a little bit better with 100% control over the results, rather than having to worry about the limitations of button generators.

please can you post the code in question.

you may actually get similar results (from an educational point of view) downloading CakePHP, as it's similar in a huge way to CodeIgniter (just a little more complex ) you may find the following article useful to get stuck straight in to how things are working: http://www.thinkingphp.org/2006/09/25/learning-from-the-cakephp-source-code-part-i/ and Cake's manual isn't too shabby these days. However, CodeIgniter's manual is very good and easy to follow, yet alot of the stuff in there can very easily be translated to Cake. Good luck!

to "remember" the data across pages, $_SESSIONS are where it's at. take a read up here regarding serialising the object, which you'll need to do to store it in your session: http://uk2.php.net/manual/en/language.oop.serialization.php then sessions themselves: http://uk.php.net/sessions

Azu + GingerRobot - unless either of you have anything further to add that relates to the topic, do not post any further comments here. Azu - seems kinda funny you reporting the post considering it's your post that's the most offensive. KEEP A LID ON YOUR SWEARING. do you not remember being told last time?

haha it happens to the best of us

TheFilmGod spelt it Calander