Re: Modular: Fusebox & Classes/OOP

Michael > I don't think we're doing a 'pure' OOP approach. PHP doesn't allow > for 'pure > OOP' whatever that may be. When I said a pure OOP approach, I was really thinking of the fact that even your main index page is an object, with the content subclassing out from there. FreeTrade is purely procedural, which should make it fairly efficient, and so far as I can see this doesn't cause any major architectural problems. The gurus suggest that OOP in PHP4 is none too efficient, and as performance is more important to us than re-usability we are minded to go the procedural way at present. > I will say that reviewing the FreeEnergy system, it does seem a bit overly complex. Right now, our thinking is that the idea is strong, but the implementation could do with tidying up. I would like to see clearer modularisation of the functions, with a more structured API. Bit this is just a first impression and may be unfair. If Leon reads this, please feel free to put me right! For our own app, we are thinking of pulling together three different strands: 1) Tim Perdue's ideas about search engine friendly URLs (very important for us) 2) The FreeEnergy ideas about assembling complex pages recursively from presentation layer components using a single central "assembler" script 3) A fast and light template substitution parser to allow the separation of HTML and PHP in the content "screens", as the HTML components are called in FreeEnergy. So we end up with something very like your model, but without the objects: 1) Use mod_rewrite to redirect all incoming pages to index.php 2) Initialise the page and database, then parse out the URI using Tim's ideas. For page requests that have been generated by links rather than forms, the URI should contain all the info required to assemble the page. For example, if the URI is /shop/accessories/buckles/prod_100276 we know to pull out the "product detail" template and populate it with the data for the named product, adjusting the layout for the product subtype. This will involve a long control statement, so any ideas about the best way to do this would be welcome. One neat thing about Tim's approach is that if the customer edits the URI in the browser, back to shop/accessories for example, this will be a meaningful address and will pull up the department page. We also check for POSTed data, and set database actions depending on any content from a hidden "action_instruction" field. 3) Then we do the database stuff, and populate our variables. 4) At this stage we know which screen we need, and the screen knows which headers, footers, menus and Meta data is required. (Leon stores all this for each screen is a big multi-dimensional array. This seems to lead to a lot of repetition, as there are only a few configurations on any site. Our idea is to define these layouts just the once, and say - "set this screen up with layout #3". 5) So now we include() our screen templates, which have been set up with the usual {placeholders} for the dynamic_data, and the last step is to call the parser, substitute in the variables, and print() the results. 6) Meanwhile, we have been buffering the output. If we suffer any fatal errors, we abort the page and redirect to present the customer with a friendly apology and suggestions for how to continue. So what do you think? How does this approach square with your own experience, and have you any ideas for improvements? Geoff Caplan British Goldsmiths geoff@britishgoldsmiths.com