Page 3 of 3 FirstFirst 123
Results 21 to 26 of 26
  1. #21
    Join Date
    Apr 2004
    Location
    Nr London, UK
    Posts
    831
    Yea - naturally the two are not serial - but parallel, i mean waiting for the entire site to be done doesn't really work

    Make parts of the Site, then parts of the CMS, natural progression really

  2. #22
    Join Date
    Mar 2006
    Location
    South Australia
    Posts
    4,521
    MartinCo, we're going to rack up 100 posts in this thread just by agreeing with each other, so this is my last post until someone else has something to say..

    Yes I agree. In early design/concept meetings I am constantly thinking about how things will work, while the designer is thinking about how it will look pretty. Then things start to evolve; it is a very parallel process.

  3. #23
    Join Date
    Mar 2004
    Posts
    0
    Quote Originally Posted by martinco View Post
    Before people come on here, and just reply because its Nelson:

    You raise a fair few valid points.

    Modularity IS GOOD!

    monolithic coding is a thing of the past, even BSD even went to a modular kernel. Kill one module, dont kill the kernel. Result Far easier maintainability
    Well, I think the analogy between a OS and a stateless scripting language is a bit sewed. I agree with your point - but I don't think it applies to PHP.

    In any server side scripting language you have less then a second to Create, Run and Tear down each module, relationship, piece of logic, and data that your action uses. That all amounts to overhead. In C++ you can spend time allocating an object for each entity in your game; because that only happens once per level load. In PHP you don't have that luxury.

    The Code for the modules still needs to be read, i'm not talking on the fly code generation (as in php code, rather than html). Its not much of a loss compared with the restrictions.

    As you say, Fragmentation Penalty does occur, but this occurs naturally, i mean, why on earth doesn't everyone just use a single php file, go though and optimise for speed and efficiency?

    I mean, it cuts out include files, cuts out extra code, cuts out soo mcuh stuff - WHY!

    Probably because we are humans, coding by nature of includes/requires is modular, so why not make the most by extracting those parts which do the front end, and leave those at the back end do their own thing?

    Header, Title bar areas should be contained, page layouts = modules, the content of the modules in the DB (nothing sounds different to being hard coded to a single layout here!).
    I completely agree with this; I was not suggesting having it all in one file. But think long and hard about every way possible to reduce the amount of classes, files and object allocations in your code. Do we _really_ need a custom widget layer that takes an array of form element types and prints it for us? Or can your DBA object handle being loaded from a query that returns multiple results? Or can it just be loaded from an ID?

    OsCommerce by its nature would be sluggish(emphasis on the ish) - (tis a view rather than experiance), the fact it is an online shop, which there is not a one size fits all approach and yet a single application to fit "All your shopping needs". That tells you something about it.
    I don't buy it at all. I think that it is possible to make a commerce platform that is fast enough for humans to use comfortably.

    Quote Originally Posted by mr_charisma View Post
    OK, Everything you said about those particular frameworks/cms/software I agree with completely. I have done enough hacking on LiteCommerce to realise that too much of the time you spend is working out how to do things the 'LiteCommerce' way. Amazingly though once you figure it out it is really easy. It's a frustrating paradox, everything is too hard until you figure out how, then it is easy.

    What you have said is precisely the reason I wrote my own CMS for our clients from scratch. It was easier than trying to mold something like Joomla to do what we wanted (allow 'stupid' customers to manage their website with minimal fuss).
    I agree with that. Once I figured out the relationship between Zend's View, Zend's Form, the KT's MVC, KT's widget layer, KT's translation code and actually found the file that the action corresponded to - it was pretty easy

    My general Philosophy for CMSs is that you design/make the site, when its finalised (if ever) you make the CMS to cater for thats sites needs.
    That is true; but if you do it right you can make it portable to other sites. My point is that you can make portable code without making a monster - it's just I have not seen it and by the looks of it people would rather use the big "industry standard" CMSs then go out and make a custom one.

    One time I wrote a simple image gallery where the customer could add new images. I made it where the management center was contained in an AJAX-driven dialog box who's logic depended on a small (very lightweight) MVC that handled the uploading/listing/ordering. It was fast, small, had no dependencies and I could drop in any site without dealing with links/sections and whatnot. That is close to being the code I am most proud of - it did what it needed to do very easily and is stupidly portable. All you needed was a little login link somewhere on the page that would simply launch the dialog.

  4. #24
    Join Date
    Dec 2003
    Location
    Tananger, Norway
    Posts
    1,461
    If you ever want to take a look at a horrible CMS..... Try getting Sharepoint to do something it's not originally made for. That will have you crying yourself to sleep for weeks to come. :-)

    And my point conserning the drupal videos was that it would give you some background as to what a CMS would normally consist of and the ammount of work that is required to even try to video tape something like actually creating this.

    Also a question that I think is important here:
    What kind of earlier knowledge would you presume the viewer of the videos would have?
    - Programmed a little before
    - Written their own little web page
    - Customized a finished framework

    I mean, do you stop to explain what you are doing or do you assume that the user knows most of it and all you really show is the implementation of the code and the thoughts behind it all.
    Last edited by styx-; 11-09-2008 at 07:43 PM.

  5. #25
    Join Date
    Apr 2004
    Location
    Nr London, UK
    Posts
    831
    Styx-, All valid points and that have already been considered;

    Quote Originally Posted by styx-
    Programmed a little before
    Yes, At least the PHP/WebDesign II VTMs

    Quote Originally Posted by styx-
    Written their own little web page
    Well, the first answers this one

    Quote Originally Posted by styx-
    Customized a finished framework
    Not sure about this one, not sure its necessary - I think using pre-existing scripts etc. (thinking JS libs here) is a good thing. Working with other peoples code is also good. Using an entire framework? I guess that moves things on a bit.

    Quote Originally Posted by styx-
    do you stop to explain what you are doing or do you assume that the user knows most of it
    I think stopping to explain is a requirement, as to the simple things, this would not happen. FOR loops need no explanation!

    I think the main aim would be to try and help the viewers mental thinking and problem/workaround skills and not so much the code, but to use the code as a reasoning tool.

  6. #26
    Join Date
    Mar 2004
    Posts
    0
    Quote Originally Posted by martinco View Post
    I think the main aim would be to try and help the viewers mental thinking and problem/workaround skills and not so much the code, but to use the code as a reasoning tool.
    Exactly. I think beginner level stuff has been beaten to death and requires no more explanation. The biggest things beginners struggle with is not the syntax itself; but how to apply the syntax to solve a problem.


Page 3 of 3 FirstFirst 123

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •