SitePoint Sponsor

User Tag List

Page 12 of 16 FirstFirst ... 28910111213141516 LastLast
Results 276 to 300 of 397
  1. #276
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    What do you mean ? Like sticking a constant in front of all paths in the require_once statements ? I personally prefer to tamper with the include_path through ini_set()
    I ususally do this, but I recently came across a host where this didn't work, and had to resort to creating a constant and using that. Something to keep in mind...


    Regarding the following block of code:

    PHP Code:
    // Switch on the page GET variable
    $file $_GET['page'];

    require_once (
    modules/$file); 
    This code doesn't exist anywhere in the script being developed, so I don't know what the issue is? In any case, access to the request should always be done through the request object, which would be in charge of validating input in some way.

  2. #277
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by pixelsoul
    I dont know basically this is what the skeleton script does correct?
    at least with example_serverpage.php.

    With the other ones it also seem to run a class with the same name.
    As you said, the ServerPageMapper does essentially the same thing that your code snippet does. There is probably not much benefit to using the skeleton as is for that. However as you expanded your site the FrontController might give you some benefits by formalizing the structure of your code, redirects, centralized functions like access control, etc.

    Also it should be noted that there is and untaint() method in the mappers to (attempt to) prevent malicious action parameter values.
    Christopher

  3. #278
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Interesting to see people's reaction to the Dai & Knight presentation. It doesn't get interesting until the end as they go through several designs each improving on the previous one to show the "why" of what they are presenting.

    As I said when I posted it, I think this represents a full-blown system and that many people would only use parts of it. I do think breaking it into parts makes it useful to more people. I also don't think the parts they specify would be done in the same way in PHP. I understand when Ezku says, " but Context objects and such didn't seem like anything I'd want to do. Feel free to convince me otherwise, though." for example. In PHP there is still the need for the Context to be communicated, but it probably as simple a single var in PHP as opposed to some big class.
    Quote Originally Posted by kyberfabrikken
    Anyway - the purpose of the ApplicationController as explained by Dai&Knight, is simply to group Handlers together in a common namespace. The aim seems primarily to be a reduction of classes. I can't really see the great benifit of this, but I recon that some would. Then again - I love heaps of tiny classes, and looking at the available php-code (PEAR?) that's not the mainstream of the php-community.
    I think the Application Controller is different than the Mapper/Handler configuration of the Front Controller. It is really a state machine that reponds to events. I think a general purpose implementation will enable many types of configurations (such as RoR style).

    Ezku posted code that shows a way to do validation. However I think one of the real positives on an Input Controller is that it encourages a key best practice which is to filter and validate all data from the request. I'll see it I can come up with some Input Controller classes as an example.

    I do like the challenge of convincing Ezku otherwise.
    Christopher

  4. #279
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by 33degrees
    I ususally do this, but I recently came across a host where this didn't work, and had to resort to creating a constant and using that. Something to keep in mind...
    It doesn't matter if ini_set is disabled, since set_include_path should work in any case. Unless the version of PHP is < 4.3.0.

  5. #280
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    Interesting to see people's reaction to the Dai & Knight presentation. It doesn't get interesting until the end as they go through several designs each improving on the previous one to show the "why" of what they are presenting.
    It was rather hard to extract any "real world" implications out of the presentation, it being strictly Java. Most points just lack meaning when I'm looking more at "how on earth do they intend to actually achieve that?" than what is tried to be communicated.
    In PHP there is still the need for the Context to be communicated, but it probably as simple a single var in PHP as opposed to some big class.
    The whole concept of Context seems somehow irrelevant. What does it tell us? What's it good to us? How is it constructed? Does it equal "the name of the action being dispatched to"?
    I think the Application Controller is different than the Mapper/Handler configuration of the Front Controller. It is really a state machine that reponds to events.
    What is an ApplicationController exactly? I'd like your definition here. Previously I similarized ApplicationController with PageController or the like, but you don't seem to be headed that way. Your second argument here is a bit perplexing. A state machine? I'm not familiar with the definition of "state machine", but as HTTP and PHP are both stateless, this seems odd; we do need session handling and the like, but still, a "state machine"? Your thoughts seem to be on a different level entirely, and I don't know if it's good or bad.
    Edit:

    I did some reading on finite state machines. A whole application forms a finite state machine, I think - introducing the concept here seems kinda, um, vague. But if that kind of thinking can bring something of value into our design, why not.

    Ezku posted code that shows a way to do validation. However I think one of the real positives on an Input Controller is that it encourages a key best practice which is to filter and validate all data from the request.
    I'm not as arrogant as to think my way is anywhere even near the optimal solution, but I feel like there's little option here: how will something outside the Action-Model interaction know how to validate incoming data? What's the good in putting the validation "outside"? Enforcing a best practice is all good, but you'd have to come up with one first.
    I'll see it I can come up with some Input Controller classes as an example. I do like the challenge of convincing Ezku otherwise.
    Glad to be of service. I'd be extremely delighted to see some actual code based on your ideas and I'm certain that it will answer at least some if not most of my questions. Teach us, o' great wise one. (And I'm not being sarcastic, either.)
    Last edited by Ezku; Jun 23, 2005 at 16:07.

  6. #281
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You think we should start a new thread? "MVC Skeleton, part 2: Application Controller"

  7. #282
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Application controller logic simply decides how to respond to a given request type. With static http pages, requests map one to one with responses. If you ask for a home page, that's what you get (server errors excepted). In dynamic sites, requests almost always map one-to-many with possible responses. That's the application controller logic.

    Note that the request type has already been identified before deciding what to do with it. Well, it would have to be. A FrontController receives input, identifies the request type and then applies any application controller logic. A PageController receives input and applies any application controller logic but doesn't have to identify the request type since the webserver maps these one-to-one with PageControllers. If you took the input-receiving code out of a PageController, you'd be left with an application controller.

    Multi-page forms are often used as an example of application controller logic, with the response depending on the success of earlier submissions but it's much more widespread than it might seem from this relatively complex example. Suppose you have a restricted page where, if the user is not authenticated, you show a login page instead of the requested page. One request type maps to two possible responses. Often there will be an authorisation stage as well: a "not authorised" page adds a further possible response.

    It gets even simpler than that. I mentioned earlier that in static sites you get what you ask for. In fact you might get some kind of server error instead: apache or etc has some application controller logic of its own to do. A php app similarly has to handle various error states. A database server might be unavailable or perhaps a requested forum topic is unavailable and so on, and so on.

    This might mean rolling back out of an "action", possibly undoing any undoables, and then on to the next in a ChainOfResponsibility or you might issue a redirect (which I'm personally less keen on since it disperses application controller logic throughout the program rather resolving into a single location). Or something else.

    There might be an ApplicationController class, or a group of classes, or just some "loose" code, but application controller logic will be in there somewhere.

  8. #283
    Massimiliano Bruno Giordano sid egg's Avatar
    Join Date
    Aug 2004
    Location
    Canada
    Posts
    1,280
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    If I understand this discussion correctly, I think you guys are making this far too complicated. While, I do not abide by the "PHP is a templating language" discussion, I still think my solution works well.

    I have a Page class, and an Object class. All my objects are inherited from the Object class, which does, well, nothing. All objects must define the function render, which returns the HTML for the Object.

    Then, I use Page->addObject(new Form([...])); to add all the objects, I then set a page template, which finds the objects, and therein adds them to the page.

    I have classes as low as Clock which outputs a simple Javascript clock, with very little customization available, and as high-level as Form, which is an object that can store objects (form elements).
    GamesLib.com - the slickest, most complete and
    easily navigatible flash games site on the web.

  9. #284
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sid egg
    If I understand this discussion correctly, I think you guys are making this far too complicated. While, I do not abide by the "PHP is a templating language" discussion, I still think my solution works well.
    You are using TemplateView, probably with a simple Page Controller. That is a excellent solution and a commonly implemented one. I use it as well. However none of the code so far in this thread relates to the code you are using. That has been a point of confusion. Plus the View is where all the fun is.
    Christopher

  10. #285
    Massimiliano Bruno Giordano sid egg's Avatar
    Join Date
    Aug 2004
    Location
    Canada
    Posts
    1,280
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    You are using TemplateView, probably with a simple Page Controller. That is a excellent solution and a commonly implemented one. I use it as well. However none of the code so far in this thread relates to the code you are using. That has been a point of confusion. Plus the View is where all the fun is.
    Assuming my Page Controller would be synonymous with my Page Class, I've always seen possibility in expanding it to more "handle decisions" but I wasn't really sure how, so, I didn't... do you have any good resources on Page Controllers?
    GamesLib.com - the slickest, most complete and
    easily navigatible flash games site on the web.

  11. #286
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sid egg
    Assuming my Page Controller would be synonymous with my Page Class, I've always seen possibility in expanding it to more "handle decisions" but I wasn't really sure how, so, I didn't... do you have any good resources on Page Controllers?
    It sounds like your Page class is more like Template View. Your Page Controller is probably the code outside of that.

    It is interesting that you mentioned 'expanding it to more "handle decisions"' because one of the common implementations of the Application Controller part is a state machine where you "setup" the potential states (and transitions) and then the Request (or other parts of the code) can trigger an event to set a new state.

    For example a form might have three states: show, check and done. The default (no event) is show. Submitting the form (a request) triggers the check state. The check code validates the form and depending on success triggers either a show or done event. The three states communicate with each other through the Application Controller using events, which in "skeleton" parlance is a handler registered with the Application Controller's CoR that runs when a condition is met.

    Now that sounds fancier (trigger events blah blah blah) than the code actually is. It's probably very similar in concept to code you use or have thought of implementing, it's just more generalized. And hopefully it is more modularized and therefore more testable and capable of being combined in different ways. And it's code I would like to have because my current code is probably more like yours.
    Christopher

  12. #287
    SitePoint Zealot Overunner's Avatar
    Join Date
    Mar 2004
    Location
    Sweden
    Posts
    180
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Is everyone on vacation or is this thread dead?

    Anyhow, I've some questions (regarding mostly the skeleton2.7 script)

    1) Where should the authentication/authorization process reside? (in a filter or the action?)
    2) The output gets pushed to the Reponse object and rendered there...why? If I implement the Template View, isn't it eaiser to just assign the template variables and render the template.
    3) Has anyone written any unit test for the code?

    Btw...Anyone one got an idea of how an lightweight and flexible application controller should look like codewise?

  13. #288
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Overunner
    1) Where should the authentication/authorization process reside? (in a filter or the action?)
    There are numerous ways to do this, and it's really hard to say which is better, since it depends a whole lot on what type and how fine-grained you want your security. One solution would be to put the authentication in a global filter, while the authorization could be placed at action-level. (Or even at model-level)

    Quote Originally Posted by Overunner
    2) The output gets pushed to the Reponse object and rendered there...why? If I implement the Template View, isn't it eaiser to just assign the template variables and render the template.
    You could do without the Response-object, but it would be less flexible. For example, it's much easier to write tests, if the response is an object. It also has practical uses though. When dealing with composite views, it's really nice that the output is encapsulated in an object.
    Quote Originally Posted by Overunner
    3) Has anyone written any unit test for the code?
    I wrote a test for Request and for Response just to get it started, but thoose are quite trivial. We need some real tests for the other classes.

  14. #289
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Overunner
    Is everyone on vacation or is this thread dead?
    It's not dead. It's just stunned. It's pining for the fjords.
    Quote Originally Posted by Overunner
    1) Where should the authentication/authorization process reside? (in a filter or the action?)
    I think either before the Front Controller in the Handler Chain, or in the Application Controller which we haven't got to yet. It would be good at some point to provide examples of both. For example, in the ActionLookupMapper there is a place in the external map for data for each action and a filter could use that for access control.
    Quote Originally Posted by Overunner
    2) The output gets pushed to the Reponse object and rendered there...why? If I implement the Template View, isn't it eaiser to just assign the template variables and render the template.
    I believe that the idea is that all output goes to the Response which then decides what to do with it. It may write it to a cache before displaying it. There might be something after the Front Controller in the Handler Chain that modifies the response. I believe that is the reason for the disconnect between Response and View. But you do not have to use the Response if you don't want to. Just pass a dummy $response var and remove the $response->out() call.
    Quote Originally Posted by Overunner
    3) Has anyone written any unit test for the code?
    kyberfabrikken has written a few unit tests which are in CVS. I would be great if others would add more.
    Quote Originally Posted by Overunner
    Btw...Anyone one got an idea of how an lightweight and flexible application controller should look like codewise?
    I just coded basic Filter, Validator and InputController classes that I will post as soon as I write an example using them. I consider an Input Controller to be the front-end of an Application Controller, so hopefully they will be a start.

    I mentioned above that I thought the Application Controller could be an event driven state machine. I am still mulling how to do that. How to represent/register/trigger events that can come from either the request and/or the program? And how to connect those events to the states that will then run the appropriate View or View(Model)? I think this design can create a very simple core Application Controller that is very flexible and extendable.

    PS - Goddag Danmark, good night California.
    Christopher

  15. #290
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    One solution would be to put the authentication in a global filter, while the authorization could be placed at action-level.
    To me it seems like this is the solution: global authentication, local authorization. That's how it works, right?
    Quote Originally Posted by arborint
    I just coded basic Filter, Validator and InputController classes that I will post as soon as I write an example using them. I consider an Input Controller to be the front-end of an Application Controller, so hopefully they will be a start.
    Looking forward to seeing what you've got

    I created an ActionPackMapper that takes an XML route definition file and digs up stuff from the URL, setting the variables to the Request. I'll have to run some tests before posting it here, though.

  16. #291
    SitePoint Guru
    Join Date
    Oct 2001
    Posts
    656
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    To me it seems like this is the solution: global authentication, local authorization. That's how it works, right?
    Could not agree more. In one of my posts I demonstrated that you cannot put authorization control at the global (filter) level, because authorization can depend on other things than merely the requested action.

  17. #292
    SitePoint Zealot Overunner's Avatar
    Join Date
    Mar 2004
    Location
    Sweden
    Posts
    180
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Ezku
    To me it seems like this is the solution: global authentication, local authorization. That's how it works, right?
    Quote Originally Posted by Captain Proton
    Could not agree more. In one of my posts I demonstrated that you cannot put authorization control at the global (filter) level, because authorization can depend on other things than merely the requested action.
    I must admit that I'm not entirely sure what the difference between authentication and authorization is (It's a shame that I don't know that ). I would really appreciate if you could post some code examples too regarding this.
    Quote Originally Posted by Ezku
    I created an ActionPackMapper that takes an XML route definition file and digs up stuff from the URL, setting the variables to the Request. I'll have to run some tests before posting it here, though.
    Just wonder why you chose to represent the route definition files in XML, rather than...perhaps .ini files (they are easier to parse, and the parsing is significantly faster) or PHP-arrays?

  18. #293
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    authentication is a matter of identifying a person.
    authorization is a matter of figuring if a given person has the rights to do a specific thing.

  19. #294
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Could not agree more. In one of my posts I demonstrated that you cannot put authorization control at the global (filter) level, because authorization can depend on other things than merely the requested action.
    I think the goal is to provide both and to hopefully use the same code a both levels. Complex sites would use both. But many sites would just use only one.
    I created an ActionPackMapper that takes an XML route definition file and digs up stuff from the URL, setting the variables to the Request. I'll have to run some tests before posting it here, though.
    Just wonder why you chose to represent the route definition files in XML, rather than...perhaps .ini files (they are easier to parse, and the parsing is significantly faster) or PHP-arrays?
    You should take a look at kyberfabrikken's ActionPackMapper and the ActionLookupMapper. It would be good to refactor all of these into a modular solution. I think the map should be given to the Mapper as an array because as noted that allows you to write readers for any format of configuration file.
    I must admit that I'm not entirely sure what the difference between authentication and authorization is
    I tend to use the term Access Control for code that limits user's acces to a page becaue authentication and authorization sound so much alike. I think of authentication and authorization as related to user accounts and login.
    Christopher

  20. #295
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Just wonder why you chose to represent the route definition files in XML, rather than...perhaps .ini files
    I also use XML for configuration, for a number of reasons but the most likely benifit for me is that you can take that XML file, and transform it into another format if required via an XSL stylesheet, such as transform the XML into INI format as an example

    There are other benifits, such as you can use either (or both) the DOM or XPath to read and write to the file, so you can be more flexible in what approach you use.

    Also, the configuration may not actually be a file on the server... A web service could be used to fetch configurations, there are just too many benifits of XML but I'll leave it that

  21. #296
    SitePoint Guru
    Join Date
    Oct 2001
    Posts
    656
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    /at the risk of hijacking this thread, but I'll take that risk:

    Dr Livingston, you (perhaps) give some good reasons to use XML in general, but not for using it as a configuration file:

    I also use XML for configuration, for a number of reasons but the most likely benifit for me is that you can take that XML file, and transform it into another format if required via an XSL stylesheet, such as transform the XML into INI format as an example
    Unless you can give an example why you would want to transform your configuration file, which is specific to your application anyway, to another format for another application?

    There are other benifits, such as you can use either (or both) the DOM or XPath to read and write to the file, so you can be more flexible in what approach you use.
    You can use one of PHP's built-in functions to read and write INI files, so what's the advantage here?

    Also, the configuration may not actually be a file on the server...
    I can store an ini file on another server as well. I really don't see why I would want to do that with an ini or xml configuration file, but I'm sure you have your reasons.

    So, now that all your arguments are invalid, what is the advantage of XML for configuration instead of something like an ini file?

  22. #297
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I picked XML because I couldn't come up with a sensible way to mark the routes up as ini. Personally I experienced no loss at doing so - I use PHP5 and have the SimpleXML extension available, which makes handling XML files a breeze. Parsing also doesn't need to be done more than once because the results are cached.

  23. #298
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Umm...

    There may be that there is one or more (outside of our control) applications that would possibly need access to a given configuration, but has to accept the configuration in another format.

    Take an ecommerce experience for example? At one point, I had to build functionality over the top of one such experience, but had to make do without the original script, but I scripted the configuration (at the time) via the database (and not XML), and this caused me some headaches at the time.

    Now I use XML, and if I am faced with that (above) problem again in the future, I suppose I'll be better placed with using XML, over any other formats no? At the end of the day, you have got to remember why we now have XML, ie The reasoning behind XML, why it was brought about, why it is a standard, etc

    Standards are good, they're good for me, they're good for you, they're good for everyone, ahem

  24. #299
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    I think the map should be given to the Mapper as an array because as noted that allows you to write readers for any format of configuration file.
    My inclination would be to use a Config class, with implementations for different file formats/database access etc., and either passing that to the mapper, or having it return an array which is then passed to the mapper. In the case of XML files, The Config object could be serialized to avoid having to parse the file each time it's used.

    Which makes me think, what do you guys think is the best strategy for dealing with state? I currently use a State object, but some people seem to prefer including state data in the request.

    Quote Originally Posted by Ezku
    To me it seems like this is the solution: global authentication, local authorization. That's how it works, right?
    Definitely; as far as implementation goes, have we decided to implement action level filters?

  25. #300
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by 33degrees
    My inclination would be to use a Config class, with implementations for different file formats/database access etc., and either passing that to the mapper, or having it return an array which is then passed to the mapper. In the case of XML files, The Config object could be serialized to avoid having to parse the file each time it's used.
    That makes sense and it would be good to have examples that use XML, INI and just strait PHP include with an array declared. I think there are actually Readers classes below a Config class. Readers would supply data in a standard way to Config and Mapper classes. Please contribute an XML or INI Reader if you have one and we can use it as a start. There is probably common code between the "Reader" classes. There is also may be common code between the Config and Mapper classes.
    Quote Originally Posted by 33degrees
    Which makes me think, what do you guys think is the best strategy for dealing with state? I currently use a State object, but some people seem to prefer including state data in the request.
    I have been pushing this need back because I don't then the Request is the place for it. I really think that we probably needs some standard implementation of a State/Session data model that we can provide different Data Sources on the backend. It is really just a Model that the Controllers know about as well as the View. If we think of it as being in the Model layer then it will be a cleaner and more flexible implementation.
    Quote Originally Posted by 33degrees
    have we decided to implement action level filters?
    Those would go in the Application Controller somewhere but as they don't exist it is hard to know where.
    Christopher


Bookmarks

Posting Permissions

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