KevinM1
Moderators-
Posts
5,222 -
Joined
-
Last visited
-
Days Won
26
Everything posted by KevinM1
-
Or, better yet, combine the ability to reply with viewing a message. Most PM systems I've seen have a text editor right below the message to allow for replies without having to go to another page.
-
Unobtrusively? <!doctype html> <html> <!-- all markup until the button --> <button id="reply">Reply</button> <!-- all markup until just before the ending html tag --> <script type="text/javascript"> var button = document.getElementById('reply'); button.onclick = function() { location.href='http://local.debbie/account/reply_pm.php?msg=$msgID'; } </script> </html> Inline JavaScript is bad because it mixes markup with behavior. Yeah, unobtrusive JS requires more lines (at least, for something trivial like this), but it makes maintenance/editing/debugging a heck of a lot easier. Especially in Debbie's case, where she's using PHP to generate HTML and (potentially) JS. For the same reasons why we separate CSS and HTML, we should separate JS and HTML. Unobtrusive JS also allows one to write progressively enhanced code. Since you're writing an actual script instead of just bolting a line of code onto an element's event, you can feature detect (libraries like Modernizr help greatly with that), and subsequently write code that will present the user a more interactive experience if they're using a modern browser. @doubledee JavaScript isn't hard, and is absolutely something you should learn. It's the one common scripting language that is truly available everywhere, and with Flash support dwindling and HTML 5's improvements (canvas, SVG, web sockets, etc.), it's vital to at least have some understanding of it. And yes, <button> is HTML 4: http://www.w3.org/TR/html4/interact/forms.html#h-17.5
-
No, it's not HTML 5. It's a generic HTML button with inline (yuck) JavaScript attached to its (the button's) click event that would bring the user to the URL provided. You don't need anything special to use it. It's very basic/vanilla/old HTML and JavaScript.
-
There's nothing amateurish about procedural programming. Period. Full stop. You continuing to assert it does not make it true. Indeed, all you're showing is your own inexperience. Again, you don't know what you're talking about. OO has been around, in terms of languages, since the 1970's. Its theoretical underpinnings since the 1950's. OO isn't some new discovery which is self-evidently better than everything else. There are very real reasons why OO isn't used in every situation. Off the top of my head: Code bloat Memory overhead Memory management No great way to handle true decimal math (reliance on floating point) --- Since you keep asserting that OOP is what true professionals use (even though that's wrong), what is it that OOP does that's different/better than everything else in your eyes?
-
Why don't you want to put the month number as the first argument to your function? What do you mean by wanting to make it more automatic than that?
-
This topic has been moved to Miscellaneous. http://www.phpfreaks.com/forums/index.php?topic=360017.0
-
Yup. Once again, OOP is merely one methodology among several, all of which have their pros and cons. And to label procedural programming as amateurish is laughable. There's a reason why C is still widely used. It's what the linux kernel is written in and what PHP itself is written in, just to name a couple examples.
-
1. There's no such thing as a perfect script. 2. OOP isn't the objective pinnacle of programming methodologies. 3. PHP will never go full OO. It would require a complete overhaul of the underlying C code, and would break a lot of existing apps. 4. Design patterns aren't just something tied to OOP. 5. Anyone who knows what they're doing doesn't use globals outside of the superglobal arrays. Further, globals are very possible with objects. That's what a singleton is. That's what static methods do. I'm not trying to be Captain Buzzkill, but you seem stuck on the idea that OOP = perfection, which is ridiculous. OOP is certainly a good methodology that is very useful when done well. I use it in all my projects. But it's not the answer to every problem. It requires a fair amount of overhead. It also doesn't fit certain scenarios. I wouldn't use it for the guts of a financial system, for example. Look up functional programming if you want to broaden your horizons. --- As far as features I'd like to see, either Ruby or C# style properties. Writing boilerplate get/set code sucks. I'd also like to have the ability to label data members as read only.
-
Yeah, your code is all over the place. For starters, it's not a good idea to have your Contact class derive from your Database class. Ask yourself this question: "Is a contact a database?" The answer is no. Inheritance creates what are known as is-a relationships, meaning that whatever you have for a child class is, in the eyes of PHP, also an object of the parent class. If something isn't considered something else (like a contact isn't considered to be a database) in real life, it shouldn't in your code, either. Inheritance should only be used if you want to create a family of similar classes. You should NOT use inheritance because you merely want one object to access another. There are far better ways to do that. Let's look at Contact itself: is a contact a validator? Again, no. You should have a standalone validation object that you can pass a contact into, like so: $validator = new Validator(); $validator->validate($contact); if ($validator->hasErrors()) { // handle the errors } Every class should have a single responsibility. Beyond that, you have a lot of logical oddities. You make two contact objects for one set of data. You call showErrors before anything is actually done with a contact. You treat the isValidData method as a boolean, but then never return anything from it. My best advice is to drop the OOP and just try to get it working procedurally. You can always refactor it back into OOP after that. And since you want to learn OOP, you should get a good resource. The following book is the best resource for OOP in PHP available: http://www.amazon.com/Objects-Patterns-Practice-Experts-Source/dp/143022925X/ref=sr_1_1?ie=UTF8&qid=1337892781&sr=8-1
-
Can you show your class code and how you're using it?
-
Of course it's possible. That's what AJAX is - JavaScript sending a request to some server code, and then handling the results. That server code can be just about anything: PHP, Ruby, Python, Perl, C#, VB, C++, etc. In your case, you're sending data via POST, but, according to the code you have above, don't touch $_POST. AJAX works just like synchronous requests. If you send something via GET in your JavaScript, you need something in your PHP that can handle the corresponding $_GET values. The same thing goes with POST. You'd be wise to step back and make small test scripts to see how it all works. Trying to get a live component to work when you haven't even played with AJAX before is just asking for heartbreak.
-
It's more common to save images in a directory and store their paths in the db. It saves you from needing to mess with headers when displaying them.
-
Have you tried installing WAMP yet? Regardless of what packaged software you use (if any), if you're going to write/use PHP, you need an environment to run it on. WAMP is the simplest way to get started. Since you want to make something custom, you're likely going to need to write some code on your own. The best resource is the online PHP manual: http://www.php.net/manual/en/ You can skip past the part that describes installing PHP if you've installed WAMP.
-
Like thorpe said above, if you want to use PHP on Windows, the easiest way to get started is to install WAMP - Windows Apache MySQL PHP. Here's a link: http://www.wampserver.com/en/ It will install the AMP on your W. Since you mentioned/hinted at hiring someone, if you get too frustrated to want to do it on your own, feel free to post in our freelancing section: http://www.phpfreaks.com/forums/index.php?board=8.0 Beyond that, I'm not sure what else we can do to help you.
-
You need a more professional picture of yourself on the front page. Red eyes, with a loosened tie, while looking a bit tipsy at a prom/wedding/graduation/whatever isn't exactly the image you want to portray. Also, I agree with Adam. You shouldn't rank yourself 5 stars at anything right now. Your portfolio really only shows that you can edit Prestashop themes. That's akin to someone who only knows WordPress trying to sell themselves as a PHP guru. It's a gross exaggeration. Your portfolio site itself suffers from 'more is less'. Too many boxes, animations, etc. that distract from the information you want to convey. A portfolio site shouldn't be filled to the brim with all the techniques you know. Edit yourself, and recognize that potential clients want to know a few things: 1. You're qualified. 2. You're talented. 3. You're honest. You do this by simply explaining who you are, showcasing what you do, and by generally explaining how you interact with clients during the process. Going overboard with credentials (your CV), jargon (your research), and your experience (your own front page rankings) makes you come across as desperate, and perhaps not entirely truthful. There's no reason that, if you're truly as capable as you want to make your clients believe, you can't let your work stand on its own, and explain yourself in clear, concise, jargon free language. So, get rid of the "Look at me! I'm still only a student, but want so desperately to impress everyone!" cruft, and focus on highlighting your work. You can sell yourself while remaining honest.
-
accessing methods of outer class from methods in inner class...
KevinM1 replied to Hall of Famer's topic in PHP Coding Help
There are a few ways you could approach this. The easiest would be inheritance. Child classes have access to all of their parent's public and protected members. You could also try the Decorator pattern (look it up), since a UserProfile is really something that wraps a User. -
What do you mean by perfection? Programming is a balancing act between such things as in-process efficiency, readability, maintainability, scalability, etc. The best programs do a lot of those things well, but never excel at everything. There's always a tradeoff.
-
There's also no such thing as a 'perfect' script/program. And, invariably, at some point, it all gets converted into machine readable instructions. EDIT: OOP is a design paradigm largely aimed at making things easier for people. Consider that while thinking about perfection.
-
The main problem is that there's no layout to speak of. There's no real indication on how to use the site, and, even worse, why someone would want to. And, no, the miniscule 'About' link isn't good enough. The conspicuous Facebook stuff (why is it placed in the middle of the form?) makes it look like the site is built to simply grab user info. It's a form in a box. That's it. Good design isn't about rounded corners and mouse hover effects (some of which - the radio buttons - look hideous). It's about conveying information in a clean, visual appealing way. Like I said in my first critique, it looks like you spent 5 minutes on it. All of the problems remain. Shunting your term paper outline-esque instructions to a separate page isn't a fix. Changing colors without knowing how to use them isn't a fix. 'Media Shindig' in an ugly font isn't edgy, or cool, and memorable for all the wrong reasons. Stop rearranging the deck chairs and, instead, try to steer away from the iceberg. Shuffling around components that don't work individually won't suddenly click into a well-designed site. Look at professional sites for inspiration. Look here, too: http://www.smashingmagazine.com/ http://designmodo.com/ http://designfestival.com/
-
All capital letters, at least in the West, = shouting. Plus, it makes code hard to read as every letter has a uniformity in size when capitalized. Since code is as much for humans to read (as we're trying to do here) as it is for computers to process, it makes sense to write code that's readable. That means stop using all caps.
-
OOP's theoretical underpinnings can be traced to the 1950s. Smalltalk (it's a language) was released in 1972. In terms of widespread use, one can assume that the adoption of C++ over C by many developers in the 80s/90s played a major role. In any case, implying that OOP is somehow new is incorrect. There's nothing bad/wrong with procedural programming. Like xyph said, the idea of creating abstractions that can be used in a variety of situations is a key component of programming in a general sense. OOP and procedural programming are merely different ways of creating those abstractions. OOP is the dominant paradigm for application programming because it allows us to model things in an intuitive way. It's not a good fit in all situations because of the overhead it requires. For a somewhat relevant example, you won't see objects in the linux kernel for that very reason.
-
For me, the main problem is that the site is very unattractive. First impressions count for a lot, and a bright pee yellow site likely isn't conveying what you want it to convey. More detailed critique: 1. Your content has no room to breathe. You're almost flush to the left of the screen. Your rounded rectangle almost intersects with your headline. Your use of an ordered list looks is cramped (no vertical spacing between items), and looks like a term paper outline. There's also no real break between the description of the site or the actual search form, and the Facebook profile bit is completely out of place. Don't just cram everything into one box and call it a day. Think about logically grouping your content, and separating each part. Borders, boxes, the <hr /> tag, etc. can all reign the eye in. 2. I don't mean to be harsh, but the header is just embarrassing. It looks like it took about 5 minutes to make, at most. Some text and a couple stock photos jammed together isn't going to entice anyone. You need to do more. Create some branding - a logo/icon and core colors that represent this site/your business. 3. Like I said above, the color is very off-putting. Yellow on yellow is just loud, and not enticing. 4. Why do your buttons change shape? You do realize that changes the height of your rounded rectangle, right? It's unnecessarily gimmicky. There's more, but start there.
-
Debbie, with the exception of objects (and that's only in PHP 5+), arguments are passed into functions by value. That means that if you have an external variable named $gender, and you pass it into a function, $gender's value is COPIED into the function. What happens to that copied value within the function has no effect on the $gender variable outside the function. Example; $test1 = "Forrest Gump"; $test2 = "Bubba"; function prestoChangeo($x) { $x = "Lt. Dan"; return $x; } prestoChangeo($test1); $test2 = prestoChangeo($test2); echo "$test1<br />$test2"; Regarding parameters vs. arguments: parameters are simply named placeholders.
-
That's backwards. The ring chooses someone worthy and you are automatically a part of the Green Lantern Corps. Speaking of rings.. that darn hobbit still has mine! Ah, well I was always a Marvel Comics guy. Angsty teenage mutant drama FTW!
-
Welcome to the Green Lantern Corps. I presume you've received your power ring?