Jump to content

devbanana

Members
  • Posts

    18
  • Joined

  • Last visited

    Never

About devbanana

  • Birthday 09/21/1988

Contact Methods

  • AIM
    devbanana
  • MSN
    brandon@devbanana.com
  • ICQ
    214125052
  • Yahoo
    devbanana

Profile Information

  • Gender
    Male
  • Location
    I don't know, but all I can see is this computer...

devbanana's Achievements

Newbie

Newbie (1/5)

0

Reputation

  1. [quote author=steelmanronald06 link=topic=105698.msg423288#msg423288 date=1156768849] SMARTY [/quote] Hi, Thanks for the reply. However, as I mentioned in my first post, I'm not looking for existing templating systems, but what features you would look for in a templating system. I don't like Smarty, because the logic is too imparative. If you're going to use Smarty, you may as well just use PHP for presentation logic, because they're both just as imparative.
  2. Great to see this is generating such an enthusiastic response. ::) Well, in spite the fear of talking to myself... I have been checking out XSLT, and it seems like it'd be a very nice tool to use for templating. A bit complicated, but at least it is a standard, and it can output various formats, so it doesn't necessarily need to be bound to outputting HTML/XHTML.
  3. Kind of depends how fast you learn things. It can be anywhere from fairly simple to magnificently comjplicated, depending on what you need to do. XPath really isn't all that hard; it is XSLT that gets difficult.
  4. This is a classic case for XSL. All I can suggest is to parse it in XSL to get the desired output, then assign the string to Smarty. Here is a starting resource on XSLT: http://www.w3schools.com/xsl/
  5. What results do you want to display? What do you want to parse the XML for? Why not simply use an XSL stylesheet to do your transformation, if that is indeed what you are doing? That's more standard than Smarty, anyway. :)
  6. Hello, I am creating a framework, and for the templating, I decided to use XML and XSLT. The thing is, I've heard that XSLT can be a bit intensive for larger documents, and it might hurt performance. So, I was thinking of detecting if the user's browser supported XSLT, and if so, just have the browser do the transform. Otherwise, PHP could do the transform. Here's the question: [list] [*]Is XSL an accepted standard so much so that it would be safe to assume the browser has XSLT support? it has been around since 1999, anyway. [*]If not, then how would you detect this in PHP? I'm thinking if I just check the HTTP_USER_AGENT, I might then be able to compare that to known user agents that do support it. [/list] Thanks, Brandon
  7. [quote author=thorpe link=topic=105694.msg422309#msg422309 date=1156591296] Im no OOP wizard but Im quite sure the application contoller sits further down in your application layer. Your front controller should not have direct access to business logic, rather it delegates to the application controller which would then envoke your commands and views. I cant really point you to any guides on the subject as Im reading most of my OOP stuff from a book (PHP% Objects, Patterns and Practice), however, [url=http://www.corej2eepatterns.com/Patterns2ndEd/ApplicationController.htm]this[/url] may help describe it better. [/quote] Thanks for the link; I've read that page a couple of times already, plus other pages, like the [url=http://www.martinfowler.com/eaaCatalog/index.html]catalog of P of EAA[/url]. So, it seems that the front controller would receive the request, and would perhaps parse it into some other form the application controller would understand, to map to a handler and view(s)? So something like: [code=php:0]<?php class FrontController { public function run() { $page = 'Home'; // Provide default // Would normally take the default out of a configuration file if (array_key_exists('page', $_REQUEST)) { $page = $_REQUEST['page']; // Do other processing to make sure it maps to a valid page } $appController = new ApplicationController($page); $appController->execute(); } }[/code] There are only a few things I wonder about with this. [list] [*]If I wanted to implement intercepting filters, would this be in the front, or application, controller? [*]I'm trying to think of a way to allow parameters to be passed as well. I was going to use pathinfo so that it could be like index.php/page/param1/param2, but IIS seems not to support pathinfo, and I am trying to make it work with both Apache and IIS. The only other thing I could think of is that after the page is retrieved and validated from $_REQUEST, delete $_REQUEST['page'], and pass what's left of $_REQUEST to the constructor of ApplicationController so it can get all the parameters that might be needed. I don't think it'd be a good idea for ApplicationController to use $_REQUEST specifically, unless it is passed $_REQUEST in the constructor, because I'm trying to limit access to $_REQUEST and the like to the front controller, which should handle the HTTP request. [/list]
  8. What, in your opinion, would the perfect templating system be like? I'm not looking for systems that have been already made, but features that you would want to see in a good templating system. Please be realistic. :) I know some people just like to have PHP intermingled with HTML, such as: [code]Hello <?php echo $user?>.[/code] But I don't really like this. It would be too tempting to do some processing in the presentation layer that does not belong in the presentation layer, plus I think it is too messy, as far as syntax is concerned. I'm thinking of, perhaps, a declarative syntax, that would mostly look like regular HTML, but would be parsed by the template system and replaced.
  9. Hi, There seem to be several different types of controllers when it comes to the MVC pattern. I've been reading a bit about both the front controller and the application controller, but I'm failing to see what the difference is. I know the role of the front controller, but am unsure of where the application controller, if used, would play into this. Found absolutely nothing when doing a search around these forums. :(
  10. Not bad ideas, though they seem a little too generic. Also, the names with "studio" in it, makes me think of an IDE instead of a framework. The dev library idea isn't bad, but to me, anyway, it is a true framework, not just a library of tools which that name might suggest. [me=devbanana]is confused[/me] I kinda think it should be fairly unique, and catchy. Thanks again. :)
  11. True. So what kind of name would you suggest then? Thanks for the suggestions. :D
  12. Well, if you subtract them, the difference will be in seconds. If you divide by 3600, you should have the difference in hours. [code=php:0]$diff = $date2 - $date1; $hours = floor($diff / 3600);[/code]
  13. Use [url=http://php.net/strtotime]strtotime()[/url] on both dates, then compare the resulting timestamps.
  14. Oh oh oh...I could name it bananaphp, spinning off the name devbanana, which will one of these days be my programming community type web site... [me=devbanana]ponders[/me]
  15. You need a way for each page to specify what kind of permissions a user requires to access that page. If it is the same for the entire application, you could have a central authentication/authorization class, which would be called for every page, to check if the user is logged in or not. I think you could use a front controller for this type of thing. After the user is authenticated, you could have a principal object with their username and role(s). If they aren't authenticated, just assign a principal object specifying a role of anonymous. The authorization component then could check that they have sufficient privileges to access the system. Role definitions: [code=php:0]define('ROLE_ANONYMOUS', 0); define('ROLE_EMPLOYEE', 1); define('ROLE_MANAGER', 2);[/code] Authorization could do something like: [code=php:0]// Ensure user is at least an employee or manager if ($principal->Role & (ROLE_EMPLOYEE | ROLE_MANAGER)) {     // Allow access } else {     // Disallow access }[/code]
×
×
  • 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.