Jump to content

trq

Staff Alumni
  • Posts

    30,999
  • Joined

  • Last visited

  • Days Won

    26

Posts posted by trq

  1. I know that you and I are in agreement that we avoid the old pre-5.0 frameworks like Cake and CI, and I never cease to be amazed by the fact that we seem to get more questions about them then we do about any of the frameworks we actually like and use.

    I know right... I'm not sure how these projects are kept alive.

     

    Just for shits and giggles I have just had a quick look at CakePHP's upcoming 3.0. Starting at the composer file - the first sign that things aren't good. The framework isn't built from loosely coupled components. I've then browsed the "Core" namespace just for fun. My eyes hurt.

  2. As long as this registry is injected via __constructs I don't see it as such a bad thing. It is basically a IoC container in that case.

     

    Just make sure that you are type hinting to a well defined interface for this Registry.

     

    The registry pattern has the potential to cause issue when you make it a singleton that has a static getInstance() method or similar.

    • Like 1
  3. The first question I have is, these "websites", are they all going to be hosted on a single machine? If so, why is the admin panel going to be hosted separately?

     

    I would be possible to create a CMS that could handle multiple websites which is essentially what you're asking. Not a simple task, but its very doable given the right timeframe and resources.

     

    Should I make the admin panel audit the website selected by sending commands through api, crud, rest or simply by direct db access?

    Rest is a "type" of api, while crud is basically an interface to the database. I would be tempted to go down the api route but it would be a lot more work than creating a cms allowing crud.

     

    What is the most secure way of doing this central admin (bare in mind the admin panel will have a minimum of 10 different admin levels/permission sets)?

    Really? I'm not sure that is a question that can be answered in a simple post.

     

    How should I have the database layout/hierarchy for this (3 completely separate site - again this will grow + a central admin site)?

    A single database will suffice.

     

    Last question (that I can think of) - how much of a mammoth task really is this?

    Completely depends on your skillset and the tools that you are comfortable using. I just finished a project where I created a completely custom, fairly feature rich CMS for a client in around 5 weeks from scratch. With the right tools, anything is possible.

  4. You have a bunch of errors in your code.

     

    1) Your "or die()" error message relates to a database connection failing, if mysql_query returns false it has nothing to do with your connection here.

    2) mysql_* has been deprecated and should no longer be used.

    3) Numeric string need to be quoted in php. eg; $record[jaaIndex] should be $record['jaaIndex']

     

    Now as for your issue. Have you taken any notice at all of the warning that is being produced? What does is the value of $result?

  5. Can you be specific regarding why you had never or would never consider using CI?

    Not really, it was a long time ago and I have never given it a second look.

     

    The first thing I remember though was simply it's coding standards, its ugly, I remember that. I also remember it going against a lot of the design principles I had learnt through working with Python. God like "core" objects, static methods scattered throughout, zero testing and an Active Record based ORM. Better frameworks already existed for PHP at the time, Codeignitor was not doing anything ground breaking or improving on this.

     

    How and why was that decision made?

    See above.

     

    What kind of developer uses CI, and how is that different than you?

    People with little experience with OOP and good design principles

     

    Also, in what way do you think CI has done harm to the php landscape?

    Because it has since taught a lot of its users bad design. You can still see some of these tendencies in other popular frameworks. A lot of CI people have been drawn to Laravel for instance because they see the Facades as providing them with the same Static interface they've grown to love (all be it a lot better implemented under the hood).

     

    I'm looking for specific facts regarding CI's deficiencies, problems, etc.

    I'm sure you can find plenty of articles on the subject.

     

    Could it be that it's just popular to hate CI?

    I've never liked CI. Those that use it may be in a bit of a bubble but it's always been that way from my view.

     

     

    You mentioned that CI may fill a need for some developers. Can you elaborate?

    I understand that people who can simply ignore the bad design or people who are blissfully unaware of it "can get shit done". Much like how a lot of people can "get shit done" with platforms such as Wordpress. Truth be known, there is a lot of bad PHP code around that enables people to "get shit done", still, this doesn't change the fact that it is crap code.

  6. I'm not sure how many valid opinions you're going to get around here. I for one have never and would have never even considered using CI. As far as I am concerned the project can't die soon enough.

     

    I understand it was popular amongst a certain crowd of developers, and I understand that for a lot of instances it has filled a need. I also believe however that overall it has probably done more harm than good to the php landscape.

     

    An "Abomination" is the latest term I've been using to describe it. The sooner it is gone, the better IMO.

    • Like 1
×
×
  • 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.