Jump to content

redbullmarky

Staff Alumni
  • Posts

    2,863
  • Joined

  • Last visited

    Never

Everything posted by redbullmarky

  1. if you're on about eCommerce sites, then one of the better looking and more original ideas is here: http://www.panic.com/goods/ If that's not what you mean, ignore me
  2. i play the guitar. Have a Gibson Les Paul (for sale), an Ibanez and a Washburn acoustic which is just indispensible. have a keyboard too, but it's a cheap one (albeit full size and sounds nice) and lives in the loft.
  3. i think thorpe meant 'extract() which takes an associative array and creates variables of same name as key in the local scope. <?php $myarray = array( 'dog' => 'woof', 'cat' => 'miaw' ); extract($myarray); echo $dog; // outputs 'woof' echo $cat; // outputs 'miaw' ?>
  4. for me, the morning "getting into work" mode wouldnt be the same without a cup of tea, XKCD and Dilbert. Even got little OSX Widgets for them both at work
  5. ahhhh nice!!! thanks for the time and effort, dude. will report back when i get a chance.
  6. I'm not so sure. There are plenty of 'fancy' bits that could go on a site that ultimately aren't essential to the running of the site, but could be nice. For example - lets say ModuleA is part of a News section for the site. Now - when I'm displaying my site, it's not really much more than eye candy to have a nice pretty calendar with all my news items plotted on it next to my articles, based on the news article's date. So I decide to install the Calendar. Now somehow - the News module is now aware that there is something installed that it can manipulate. It doesnt know or care what it is, it just has some form of common interface that it can talk through. Then I decide to remove ModuleA and install ModuleB, which also uses the calendar. The calendar does not care that ModuleA is no longer there, as it's not dependent on it. But ModuleB now uses the calendar. Automagically. Ok - maybe i'm waffling a bit - but does that make sense?
  7. is there any way/techniques i can use to de-couple the modules though? i mean, a Calendar is pretty much personal taste, so may not be required - but say there was a way for ModuleA to use the calendar (or any other plugin for that matter) IF it's there? i'm guessing some form of hooking system would help, but implementing that ontop of all the other stuff i'm thinking of is prooving to be a mindjob. John - thanks for the example
  8. hmmm i'll have to do some more reading of that one. I have come across factories a fair bit recently but just probably need to read up a bit first so i can build a solid implementation. i suppose in many ways i don't want to jump the gun too much - I have a handful of sites i personally need to build (and will need to easily maintain long term) so pretty much need a solid foundation for my CMS that's unlikely to change much as it grows. On a side note - I actually had a look at the way EyeOS (the webtop) do it, and it's pretty slick IMO - tho again, not sure if it's the best way or not. Thanks for your help - anything else you come up with tho would be much appreciated. *off to do some reading*
  9. before i go on though, i'm sort of confused why you state you will use AJAX and OOP - do you know why? are they specifically required by your site, or are they just buzzwords or things you think you should be using? not being unnecessarily negative here, but your decisions on what technologies and the structure of your app can directly influence/help your decision of your site structure. a "conventional" structure would be to organise your folders based around your sitemap - ie, top level folders for stuff like 'about us', etc and have your pages within. a more complex approach, normally encouraging/encouraged by OOP, would be to follow an MVC structure. so as you can see - might be worth plotting out your exact requirements first, what you think you might need in the future, etc and then plot out a proper structure.
  10. Hi all This is probably going to seem like alot of ground to cover, but just wanted to juggle some thoughts. Lets say I wanted to build a CMS. Now - CMS's are very good for content, but if for example I wanted to create a part of my site as a dedicated jobs board/product catalogue, etc, a regular content page is obviously not going to work as it's more 'dynamic' than that. I have static content sites, I have job board sites, as well as newspaper sites, etc and I'm wanting to merge all the code into a very simple to use system that i can use over and over for building other sites. The key areas for me, I guess, is a very simple back-end admin system that I can plug in different modules (Content, Users Management, Calendar, etc) and an equally flexible front-end system that can react to whatever content I'm trying to spit out - ie, a job listing page, a contact page, a simple article, etc. Now my problem comes in terms of developing a nice, plugin-friendly structure that keeps components, etc as seperate as possible but also allows them to communicate if needs be. For example - if I write an article within the Content module, I'd probably like the Calendar to automatically put a summary on itself for that article. But if I was to remove the Content module altogether, then calendar should not break. I'm probably getting along the lines of some form of 'hooking' system as mentioned in another thread? Also - if I was to have a 'Reports' module that was able to summarise stuff going on in my whole system (number of articles, number of jobs, registered users today, etc) then how could I get this to automatically react to a new module being installed so their own stats would also appear in my reports module? sure, I could make the 'Reports' module a Core (required) class so that it's always there, but it's just an example of what i'm after - independence but interactive at the same time, I guess. On another note comes my 'Content' manager - I'm thinking of the idea of having ALL content driven by simple plugins. The idea I had for their structure was: <?php class MyPlugin extends Plugin { protected $params = array(); public function view() { // options here are: // 1, make amendments to the variables that would be passed to the view, based on $params // 2, return the output that gets appended to, for example, $body or $left } public function edit(GUI $gui) { // add extra fields, tabs, etc based on what this plugin needs, and return the newly modifed form object for Plugin's caller to render return $gui; } } ?> so when i set up the page, i add a 'content' plugin called 'title' with params that specifiy that it's a single line input field, a 'content' plugin called 'body' with params that specifiy it's a wysiwyg or textarea. one of the params would also say which variable to assign the plugin output to. so the 'body' one might output to a template variable called 'pagebody', but i might also then have a plugin called 'contact' which appends this pagebody variable with a contact form. then, when actually editing the page, all i do is set up an instance of 'GUI' (basically a container for HTML generating classes - eg, new TextInput(), new HtmlForm(), etc) and pass it through each of the page plugins' edit method, and it adds the parts to the editing interface that are required. the idea being that each 'page' in my site is build of plugins that hold particular parameters including one that says which variable in my template to prepend/append/overwrite to (eg, title, body, left, etc) - and once the 'page' has been loaded, it's passed through the view method of each plugin in order that it's been set up on the page, each of which 'manipulates' the page before the final variables are sent to the template. now - maybe i'm getting WAY too complex here with my thoughts and methods, and maybe i'm being too obsessed about plugins and stuff, but if anyone can share any nice, cleaner ways of achieving any of my above ramblings, that would be great apologies if some bits of that make no sense - just ask for clarification. Cheers edit ps, for the more literal, serious developer out there, please forgive my possibly incorrect use of words like 'components', 'plugins', 'modules', etc - all i mean by all of them is "chunk of system that can be thrown into the pot".
  11. i'll put this simply. DO NOT POST REQUESTS FOR SITES TO BE HACKED/CRACKED or whatever you want to call it. if it's YOUR OWN SITE, and you wish to test security, please post in the "Beta test your stuff" forum. Otherwise - don't even go there. topic locked
  12. yeah managed to find it once i had a proper name for what i was looking for thanks
  13. i may have posted a little quick for part of it. i managed to get apache set up with: UseCanonicalName Off VirtualDocumentRoot "D:/web/%1" at the end of my vhosts file. however, i still need to add these to my hosts file. is it possible to automatically have all *.localhost requests go to my local webserver?
  14. Hi all When working locally, I keep all my sites in a 'web' subdirectory, in a directory of their own. Each time I set up a new site, I have to add a line to my hosts.txt (eg, myproject.localhost) and also set up a vhost such as: <VirtualHost *:80> DocumentRoot "D:/web/projects/myproject" ServerName myproject.localhost </VirtualHost> before restarting the server. now, as I always follow the same pattern with naming, what i'm wondering - is it possible to wildcard the relevent places such that ALL requests to 'myproject.localhost' automatically know which correct DocumentRoot and ServerName to set up? Whilst it's not difficult to set up manually, it'd be much better for me if this was automated - apart from making it easier, it'd mean that any old sites wont require any tidying up of vhosts/hosts.txt file. Cheers Mark
  15. i couldnt agree with you more, only there's big business in domain names if you know what you're doing. if you think about it though, it's just like any other business - buy as cheap as possible, sell for as much as possible. the prices generally only reflect the traffic/keywords/demand for that particular name. if you see one parked, make an offer to the domain owner. i have a couple now that i've gotten for cheap (for what they are) just because the owner couldnt wait to get rid of them and couldnt afford keeping up with constant renewal costs for all the ones they owned.
  16. Trac is possibly one of the better project management tools for me. SVN integration, wiki, bug tracking, milestones, etc all rolled into one. Worth a look
  17. if the session id (that used to link you to your session) cannot be stored in a cookie (if they're switched off), then it's appended onto the URL. Often you'll see many pages indexed in search engines with this in the URL.
  18. 32 days, 7 hours and 56 minutes. i need to go to the pub more.
  19. sending the headers and file must be done before anything is sent to the browser - be it raw HTML or text sent by echo/print. post the code in question and we may be able to help you more.
  20. i got much better score on that one, for some reason...
  21. you can try google: http://www.google.co.uk/search?hl=en&q=link%3Awww.phpfreaks.com
  22. havent read the other two, but the first one got me started with more advanced stuff and give me the basic ability and understanding i needed to go finding my own answers via Google. off topic, the only other PHP book I own is PHP5 Objects, Patterns and Practices which IMO is a must have for OOP PHP, especially if you're writing a pretty big application/framework/CMS.
  23. *sigh* i got annoyed with it keep stopping me on the second attempt and gave up. first attempt was 65 wpm with about 5 mistakes. thing is, when i'm typing normally, i make tonnes of mistakes but i almost instinctively know when i've done it immediately, so automatically press backspace and correct myself without even thinking. makes things tricky when it just stops you in your tracks til you type the right letter without letting you backspace... i spose it also makes it tricky when 99% of my typing is coding so i'm used to certain keywords and symbols rather than proper English paragraphs. Most of my regular English is courtesy of pen and paper oh well.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.