SitePoint Sponsor

User Tag List

Page 4 of 5 FirstFirst 12345 LastLast
Results 76 to 100 of 110
  1. #76
    SitePoint Guru thr's Avatar
    Join Date
    Jun 2003
    Location
    Sweden
    Posts
    664
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    thr,

    Wow, lots of stuff to comment on.

    Ok, addressing the Datasource:

    Quote Originally Posted by illusina
    I agree with you on this one, the words used with regards to something like a FilesystemDatasource just sound clunky. However, on that now, I'm still considering whether it's really worth it to factor files into the Datasource layer or not. This is definately something I need to think about, however, I think that the method renamings connect() -> open() are reasonable either way.
    Considering that a file infact IS a datasource, imho it should be within the scope of Datasource.

    Quote Originally Posted by illusina
    As for comments regarding the SPLReader -- I'm interested, but I don't know how heavy said format is, and how much runtime cost it will cause. This is something I'd like to see a diagram or some proof of concept code for before accepting/declining.
    I could look this up and try some sample code for it, going to have to get my source back from a crashed server first.

    Quote Originally Posted by illusina
    Regarding confiration files -- Configuration files are tricky creatures. People want them, people hate them, people disagree about the standards, people want them more flexible, and people want them simple all at the same time. So, here's my thoughts on configuration files: The plan for m4 was to use Xml configuration files soley, with heavy caching. Almost all of Mojavi 3's ini configuration files are being consolidated into settings.xml, which will be cached as, basically, a series of nested containers. However, at this moment configurations are nothing something I'm thinking about. At least, configurations that are in a format other than php. Something I've learned about trying to start writing a framework is that leaving configuration 'til the end is a great idea due to 1) added flexibility/agility when you really need it. There's no sense in having a configuration compile class that you're going to have to change 20 times at this stage in the game when you can just use a more ad-hoc proof-of-concept type php-configuration.
    Well, you could use a SimpleXML object for all config files and just serialize>cache it as we said on IM.

    Quote Originally Posted by illusina
    And lastly the $resource field in the interface. Well, I would have added this, but I'm under the impression that PHP5 doesn't allow member variables in interfaces . If I'm wrong, please correct me, and a few diagrams will be updated accordingly.
    My baaaad ;p he.

  2. #77
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I didn't read the complete exchange between thr and illusina, but what I saw I got that nagging feeling of overdesigning again. All that talk about interfaces and XML config files make that impression.

    I'm glad to see such an enthusiasm, and wouldn't want to curb it in any way but you should first consider how would people use the framework. I. e. design the park -- expecially the walking paths -- before you start clipping hedges.

  3. #78
    SitePoint Enthusiast
    Join Date
    Mar 2005
    Posts
    53
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    BerislavLopac,

    Yeh, I'm trying to be more wary of overdesign. Largely, I'm trying to take the "whatever makes it work the fastest/simplest" route on a number of aspects, including preliminary configurations. For example, currently my configurations are plain php. Now, I personally would have no problem staying with plain php, but there will be a push in the community for configurations, so I will most likely have to comply, though I may end up making a case for plain php configurations.

    Otherwise, I feel that very few aspects of the system thusfar are overdesign in any heavy sense. Mostly of what thr and I are discussing is simply another (and pretty interesting, though maybe not so useful ) way to do a Chain. That particular side discussion is largely just in the name of research, but either way -- we're making progress, and there seems to be a lot of continiuty between the people I've been able to bring together thusfar, so I'm really excited.

    If you don't mind, could you take a look at the framework and point out any thing you feel is being overkilled and I'll try to answer it?

    Regards,

  4. #79
    SitePoint Zealot
    Join Date
    Feb 2003
    Posts
    156
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BerislavLopac
    That being said, as I said earlier, the problem with 404 hack is that all your regular page calls start returning 404 errors, which will mess up your logs and give you wrong stats.
    No, you can set the correct HTTP-Header and the webserver will log it just fine. The Problem in Apache with using 404-ErrorPages is that POST-Requests don't seem to work properly when being "redirected". Other webservers are smarter about it, and don't have that problem.


    To get back to Topic: Isn't this the exact circumstances under which work on WACT started a while back in these forums? So what would going to be different with anything that is started now and stop the same discussion from coming up in 18 months with the next new framework?


    Or is the goal to convince people to really switch to just one framework (no matter which one)? Then what you are looking for is the question "How do I create a buzz?" which is not technical in nature at all. Design is a question that has many different decent answers. RoR is not successful because it is the best answer, but because it was good enough that it delivered on some of its promises and there was/is a significat buzz. It will be very hard to get that kind of buzz going with anything in PHP. One: the community is a lot larger and Two: the community is a lot more "loosely coupled" than the Ruby community and Three: The community is a lot more experienced in the language (whereas the RoR Hype quickly went over to catching people that were new to Ruby, so they were eager to learn by imitation rather than critically evaluating and discussing alternatives).

    So all in all, I am not trying to say "don't" or "can't", but I guess my point is that it's the wrong questions that are being discussed here. It's not the technical details of the solution that will mark its success (though it has to be good enough to deliver on its promises).

  5. #80
    SitePoint Guru thr's Avatar
    Join Date
    Jun 2003
    Location
    Sweden
    Posts
    664
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Me being such a fan of strange designs, here's my implementation of a self-containing chain:

    PHP Code:
    <?php
    interface Chainable
    {
        public function 
    setRight(Chainable $link);
        public function 
    setLeft(Chainable $link);
    }

    abstract class 
    Filter implements Chainable
    {

        protected 
    $left null;
        protected 
    $right null;
        
        public function 
    executeChain(&$target,$backwards=false)
        {
            
    $this->execute($target);
            if(
    $backwards === false && $this->right !== null){
                
    $this->right->executeChain($target,$backwards);
            }elseif(
    $backwards === true && $this->left !== null){
                
    $this->left->executeChain($target,$backwards);
            }else{
                
    // throw new FilterException;
            
    }
        }
        
        public function 
    setRight(Chainable $link)
        {
            if(
    $this->right === null){
                
    $this->right $link;
                
    $link->setLeft($this);
            }else{
                
    // throw new FilterException;
            
    }
        }
        
        public function 
    setLeft(Chainable $link)
        {
            if(
    $this->left === null){
                
    $this->left $link;
                
    $link->setRight($this);
            }else{
                
    // throw new FilterException;
            
    }
        }
        
        public abstract function 
    execute(&$target);
        
    }
    ?>
    The idea comes from that the fact in the real world a "chain" is not an object itself, but it's constructed out of many small objects called links. Each of these links have a let and right end in which they connect other links to themselves. So if the real world can have a chain without some type of "chain"-object, so can we ;p. Here's a small example:

    PHP Code:
    <?php
    // A small implementation + example:

    class ReplaceFilter extends Filter
    {
        protected 
    $search;
        protected 
    $replace;
        
        public function 
    __construct($search,$replace){
            
    $this->search $search;
            
    $this->replace $replace;
        }
        
        public function 
    execute(&$target)
        {
            
    $target preg_replace($this->search,$this->replace,$target);
        }
    }

    $string "ABC";
    $filter1 = new ReplaceFilter('/A/','D');
    $filter2 = new ReplaceFilter('/B/','E');
    $filter3 = new ReplaceFilter('/C/','F');
    $filter1->setRight($filter2);
    $filter2->setRight($filter3);
    // No we have Filter1<->Filter2<->Filter3
    $filter3->executeChain($string,true); // Run it from right to left instead of left to right
    // $filter1->executeChain($string); // runs the filter from left to right
    echo $string;
    ?>
    I discussed this quite alot on MSN with illusina, and to be honest this design dont have any real value except for the fact that you dont need to pass around a Chain-object.
    Quote Originally Posted by illusina
    (and pretty interesting, though maybe not so useful )
    ...as he said ;p

  6. #81
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by illusina
    (...)
    Oops. Looks like I should've scanned the thread before posting - not only were you here, but you announced Mojavi 4 just a few posts before mine. Sorry for that, I hope I didn't come off as rude and ignoring you.

    I'm sorry for I still haven't enough time to read the replies with thought, but here are some questions I'd like your statement on:

    1. How do you plan on doing composite views?
    2. I might be mistaken, but in previous versions of Mojavi, constructing a single page seems to have required quite a many classes and files to be created. I had the impression that you picked up on Rails etc. for ideas on how to make the procedure as simple as possible. Could you describe the possible conclusions you ended up in?

    Finally: I'm glad the effort we put into the skeleton threads is starting to pay off.

  7. #82
    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 R. U. Serious
    Or is the goal to convince people to really switch to just one framework (no matter which one)? Then what you are looking for is the question "How do I create a buzz?" which is not technical in nature at all.
    I think we're a lot of people who'd like to know the answer to that. Good point there.

    Getting technical again. I skimmed the m4 source, and one think stroke me as odd. Why do you want a package-manager ? If your aim is that the code should be un-obtrusive, I think that is totally missing the point. Wouldn't you agree ?

  8. #83
    SitePoint Zealot
    Join Date
    Jul 2004
    Location
    Oklahoma
    Posts
    119
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    I think we're a lot of people who'd like to know the answer to that. Good point there.

    Getting technical again. I skimmed the m4 source, and one think stroke me as odd. Why do you want a package-manager ? If your aim is that the code should be un-obtrusive, I think that is totally missing the point. Wouldn't you agree ?
    I would actually say the exact opposite. By coming up with some form of a standard "package" for the framework, it allows the core part of the framework to be just that, the core. Then if you want custom form generators, get the package. You want to use the newest, bestest XYZ templates, get the package. If the framework has a simple standard way to integrate components into it, that allows the core of the framework to remain extremely light. I think calling it a "package manager" is a bit heavy, and probably a very loaded term. From what I've seen it's really more of a standard way for adding (and removing) features from the framework without having to hack a lot of code apart to do it.

  9. #84
    SitePoint Enthusiast
    Join Date
    Mar 2005
    Posts
    53
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Ezku
    Oops. Looks like I should've scanned the thread before posting - not only were you here, but you announced Mojavi 4 just a few posts before mine. Sorry for that, I hope I didn't come off as rude and ignoring you.

    I'm sorry for I still haven't enough time to read the replies with thought, but here are some questions I'd like your statement on:

    1. How do you plan on doing composite views?
    2. I might be mistaken, but in previous versions of Mojavi, constructing a single page seems to have required quite a many classes and files to be created. I had the impression that you picked up on Rails etc. for ideas on how to make the procedure as simple as possible. Could you describe the possible conclusions you ended up in?

    Finally: I'm glad the effort we put into the skeleton threads is starting to pay off.
    Ezku,

    No problem on missing the post -- I figured you did given that you were saying seemed to have not taken into account my post .

    Firstly, to address composite views. I'm going to assume, by "Composite views" you are referring to a way to somehow make Views heirarchical, so, for example, you can nest templates logically underneath one another (if this isn't what you mean, please correct me). Well, there are many answers to this, and many approaches to this problem, all of which would be possible within the current architectural plans. Firstly, a View class in Mojavi 4 is intended only to serve as an encapsulator of View logic, and as a place for Renderer invocation. Renderers were initially used in Mojavi 2, and might work like this in Mojavi 4 (if it's implemented):

    PHP Code:
    <?php

    class MyHtmlView extends View
    {

        public function 
    executeSuccess(Context $context)
        {
        
            
    $someRenderer = new SomeRenderer();
            
            
    $request $context->getService('request');
            
            
    // this renders the mytemplate.tpl using the "SomeRenderer" 
            // render techniques with the dataspace provided from our request
            // instance
            
    $output $someRenderer->render('sub.tpl'$request);
            
            
    // here we could, in theory, have a main template rendered
            // against the output of an already rendered template....
            
    $compositeOutput $someRenderer->render('main.tpl'$output);
        
        }



    }

    ?>
    It should be noted that that example won't work, firstly because I didn't transform my $output variable at all to be a Container, but you can get the jist. So that's one possible solution. Another possible solution would be to bypass this idea of composite views in favor of a component based approach (mind the pipe dream), which I intend on trying out. The way I invisioned this thing working was basically it being another action that gets executed along with the currently requested action, which, like the other action, gets executed, then gets rendered. However, unlike regular actions, it's output gets piped to the originally requested action, which then does what it wants with it. And here's the best part about all this -- it's all theoretical and could be easily changed. If you guys have a thread I can read about composite views, maybe I can get some other (probably better?) ideas on how to create a View heirarchy. Thoughts?

    Regards,

  10. #85
    SitePoint Enthusiast
    Join Date
    Mar 2005
    Posts
    53
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    I think we're a lot of people who'd like to know the answer to that. Good point there.

    Getting technical again. I skimmed the m4 source, and one think stroke me as odd. Why do you want a package-manager ? If your aim is that the code should be un-obtrusive, I think that is totally missing the point. Wouldn't you agree ?
    kyberfabrikken,

    I can see how a package manager might initially sound like bloat. And, at first, it was going to be bloat, but I've scaled it back a great deal since my initial thoughts on the topic. At this moment, it is nothing more than a mechanism that allows users to easily cache a series of classes by directory, thereby decreasing by a great the the disk reads required on framework execution (though at this very moment, the cache is regened on every request for testing purposes).

    In one so desired, they could _completely_ unplug a package from the packages system and use it elsewhere. Also, users are not required to use the package manager, it's just there to allow the functionality I mentioned above.

    Just to expand a bit, Mojavi 4 execution is modeled on a few concepts. Firstly, there is the concept of an an execution profile. Basically what this profile does is create a list of packages needed by a particular page. A good example of where this might come in handy is coding an Ajax page, where you don't need every piece of code the framework has to be loaded, maybe just a few controller classes, database classes, and maybe an XmlHelper or something. You'd then create your "ajax-profile.php" and select the packages you wanted to have loaded. Then in your my-ajax-page.php, you'd call to that particular profile, whereas on your main page (maybe running a front controller?) you call a default-profile.php, which selects a moderate list of packages that allows most actions to run without the need for additional overhead. I hope that clears at least a little bit up for you .

    If you have any comments on either the package idea, or the profile idea, I've love to hear them.

    Regards,

  11. #86
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by illusina
    It should be noted that that example won't work, firstly because I didn't transform my $output variable at all to be a Container, but you can get the jist. So that's one possible solution. Another possible solution would be to bypass this idea of composite views in favor of a component based approach (mind the pipe dream), which I intend on trying out. The way I invisioned this thing working was basically it being another action that gets executed along with the currently requested action, which, like the other action, gets executed, then gets rendered. However, unlike regular actions, it's output gets piped to the originally requested action, which then does what it wants with it. And here's the best part about all this -- it's all theoretical and could be easily changed. If you guys have a thread I can read about composite views, maybe I can get some other (probably better?) ideas on how to create a View heirarchy. Thoughts?
    In my spinoff of the Skeleton code I have implemented the heirarchy with the Response rather than the View. Each Response object is a standard container (working like WACT's ResponseModel), plus it contains header info, plus it can have children (composite/component style). You can simply give them a content string or attach an object with a render() method. The root node then gathers up all the content and headers for the response. I find it flexible because I can mix strings, Template objects and View objects together and they are all then merged.
    Christopher

  12. #87
    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 illusina
    At this moment, it is nothing more than a mechanism that allows users to easily cache a series of classes by directory, thereby decreasing by a great the the disk reads required on framework execution
    That is the job of an opcode-cache.

    Quote Originally Posted by illusina
    Also, users are not required to use the package manager, it's just there to allow the functionality I mentioned above.
    If it's used in the core framework, people will have to relate to it if they are to use that framework. So they are required to use it.

    Sorry for being harsh, but I really think a package-manager is a way to emulate missing langauge-level features. I can see the need for packages, but I don't like such hacks. Rather the issue should be solved by the language-developers. (Namespaces have been discussed heavily on the internals lists)

  13. #88
    SitePoint Enthusiast
    Join Date
    Mar 2005
    Posts
    53
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    In my spinoff of the Skeleton code I have implemented the heirarchy with the Response rather than the View. Each Response object is a standard container (working like WACT's ResponseModel), plus it contains header info, plus it can have children (composite/component style). You can simply give them a content string or attach an object with a render() method. The root node then gathers up all the content and headers for the response. I find it flexible because I can mix strings, Template objects and View objects together and they are all then merged.
    arborint,

    That certainly sounds like an interesting technique. Though the treeing of Response objects with View objects and so on feels a tad unsemantic to me, I'd certainly like to see the code if you have it.

    Regards,

  14. #89
    SitePoint Enthusiast
    Join Date
    Mar 2005
    Posts
    53
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    kyberfabrikken,

    Firstly thanks for the response.

    Quote Originally Posted by kyberfabrikken
    That is the job of an opcode-cache.
    As a framework designer, I do not see how I can rely on technologies that the end-user (developer) may or may not have.

    Quote Originally Posted by kyberfabrikken
    If it's used in the core framework, people will have to relate to it if they are to use that framework. So they are required to use it.

    Sorry for being harsh, but I really think a package-manager is a way to emulate missing langauge-level features. I can see the need for packages, but I don't like such hacks. Rather the issue should be solved by the language-developers. (Namespaces have been discussed heavily on the internals lists)
    Well, it's not used in the "core" of the framework in any sense. I'm not sure if you've looked at the code, but there are no reliances on the package system anywhere in my code, other than in the "bootstrap" stages of execution (where classes are being included...). That's about the extent to which the current "package manager" encroaches on users of the framework. And even this stage could be completely altered/bypass by the end user if they so desired, and framework execution would not be altered one bit.

    I can understand why one would be critical of this, but it seems that either you haven't looked at the code itself to see how it's working, or just got a bad vibe somewhere along the way -- which is fine, but I hope that you'll look at the code to verify any inkling you may have regarding the package manager being bloat.

    As far as namespaces are concerned, well, I must say I'd enjoy having them for the sake of library independence, but I don't see that happening anytime soon, and I will not alter my designs for a possible future language feature.

    Regards,

  15. #90
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    Sorry for being harsh, but I really think a package-manager is a way to emulate missing langauge-level features. I can see the need for packages, but I don't like such hacks. Rather the issue should be solved by the language-developers. (Namespaces have been discussed heavily on the internals lists)
    I have a similar reaction to this. However I do like the idea of packages for some reason. I am just not clear what problem they are solving. As kyberfabrikken points out, using them for optimization sound like a lot of work that could be solved better in another way. However, I think using packages to solve the problem of organizing the huge number of files that MVC systems produce would be a plus for me. If packages grouped related files and distributed configuration information into efficient runtime units (I know you are trying to get away from a million INI files) then I could see it as a useful thing.
    Christopher

  16. #91
    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 illusina
    As a framework designer, I do not see how I can rely on technologies that the end-user (developer) may or may not have.
    And you shouldn't. That's my point really.

    Quote Originally Posted by illusina
    Well, it's not used in the "core" of the framework in any sense. I'm not sure if you've looked at the code, but there are no reliances on the package system anywhere in my code (...) it seems that either you haven't looked at the code itself to see how it's working, or just got a bad vibe somewhere along the way
    Fair enough - I didn't have a very close look. But even if it stays in the back, any developer will at some point need to be aware of it's existence, right ? That's obtrusive in it self.

    Another thing - If the packages are merely used for organisational purpose, why didn't you go with PEAR's naming-convention ? I know it's ugly, but it's defacto standard. It would seem that your choice is purely aesthetic, and even though I sympathize with that, I think it's a very weak ground for a design-decision.

  17. #92
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by illusina
    That certainly sounds like an interesting technique. Though the treeing of Response objects with View objects and so on feels a tad unsemantic to me, I'd certainly like to see the code if you have it.
    It does mash the Response, View, and Template together in a "tad unsemantic" way. I was looking looking for simple, minimal, and DataSpace centric.

    My latest Skeleton code is here:

    http://ap3.sourceforge.net/skeleton-0.3.2.zip

    Caveats and Notes: Like all the Skeleton code it is minimal and never meant to be a framework like WACT or Mojavi. The goal was a lean code base to do the standard stuff. I used the code on a small site a few months ago so it is semi-debugged. I went through it the other day and cleaned it up a little, but there are only a few tests and examples. There are a couple of classes (like Template and FormField) that are only included so the examples work. The Hangman example from WACT (via Prado I believe) probably best shows how things work.
    Christopher

  18. #93
    SitePoint Enthusiast
    Join Date
    Mar 2005
    Posts
    53
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    2. I might be mistaken, but in previous versions of Mojavi, constructing a single page seems to have required quite a many classes and files to be created. I had the impression that you picked up on Rails etc. for ideas on how to make the procedure as simple as possible. Could you describe the possible conclusions you ended up in?
    Ezku,

    I missed this point earlier, so I'm going to address it now. Firstly, I've studied Rails a tad, mostly as a bird, but I did read some of the code itself, though I don't know ruby (funny how once you know approx. 5 languages you can "get the jist" of most languages ). But anyways, there are a number of things that are being done to try to make a developer's job easier, first and foremost of which is automation of tasks. This means _phing_. I've decided to continue Mojavi 4 with a phing build set for the automation of mundane tasks such as creating new pages, new modules, templates, etc. For users who do not have command line, there is going to be a minimal Mojavi 4 control panel bundled (theoretically) which will give a basic interface to the phing buildset via an online environment. Now, I've met considerable opposition to the idea of having any sort of control panel because of the aura it gives out -- that Mojavi 4 is somehow going to turn into a CMS. I'd just like to say that I think that's a bunch of crap, and that providing the best tools to make a developer's job easier without forcing any particular methodologies on them is _the way to go_. I'm sure we won't get it right the first time, but we can certainly try.

    Another important aspect of Mojavi 4 that is going to be changed is the way Views are organized. In the past, there was a multiplicity of Views for each screen of an action. Given the simplicity of each View, it occured to me and other individuals within the Mojavi community that other techniques would most likely be more effective. Here's the basic idea:

    Past setup:

    views/CreateUserInputView.class.php
    views/CreateUserConfirmView.class.php
    views/CreateUserSuccessView.class.php

    Example View:

    PHP Code:
    <?php

    class CreateUserInputView extends PHPView
    {

        public function 
    execute()
        {
        
            
    $this->setTemplate('CreateUserInput.php');
            
            
    $this->setAttribute('SomeAttr''value');
        
        }


    }

    ?>
    The old setup has a number of inherent problems as far as I'm concerned, so here's a few of them: No way to differentiate between content types, the class heirarchy is related to it's rendering method, which is un-necessary. If you guys want to discuss either of these two points, I'll expand.

    New (theoretical) setup:

    PHP Code:
    <?php

    class CreateUserHtmlView extends View // or just implements View?
    {

        public function 
    executeInput(Context $context)
        {
        
            
    $phpRender = new PhpRenderer();
            
            
    $request $context->getService('request');
            
            
    // here we could, in theory, have a main template rendered
            // against the output of an already rendered template....
            
    $content $phpRender->render('CreateUserInput.php'$request);
            
            
    // do something with content, maybe set it into a variable, 
            // or set it into response? return it? not sure yet :)
            
        
        
    }

    }

    ?>
    Some of the advantages: Decoupled dataspace from the View itself, which allows things to be moved around with much, much more ease. Allows any type of renderer to be created, and, theoretically, the renderer to be of a type dynamically chosed by a configuration, where PHPView limited the rendering routine.

    One ultimate goal is to make content-types pretty much inconsequenctial, but this isn't reasonable for a number of reasons. However, for many pages, doing something like $xmlRenderer = new XmlRenderer(); ... and performing the same routines on it wouldn't cause any problems as long as XmlRenderer could handle Container objects which, I think, is same to assume.

    Anyways, I'm _sure_ there are more ways to make developer life easier that I haven't even touched. Something Rails when into a great deal was their emphasis on View Helpers and the Active Record pattern, which, in my opinion, is out of the scope of the core framework. That's not to say, however, that it's not something to look at as an extension of Mojavi. View Helpers, on the other hand, I seem to feel are "ok" being bundled due to their unobtrusive nature (you don't want it, you don't have to use it). I have an inkling though that I may be in the wrong on this one. Anyone care to comment?

    This was sort of a non-linear post, and if I lost any of you I apologize, I'll try to clarify any questions you may have.

    Regards,

  19. #94
    SitePoint Enthusiast
    Join Date
    Mar 2005
    Posts
    53
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    And you shouldn't. That's my point really.
    Got it.


    Quote Originally Posted by kyberfabrikken
    Fair enough - I didn't have a very close look. But even if it stays in the back, any developer will at some point need to be aware of it's existence, right ? That's obtrusive in it self.

    Another thing - If the packages are merely used for organisational purpose, why didn't you go with PEAR's naming-convention ? I know it's ugly, but it's defacto standard. It would seem that your choice is purely aesthetic, and even though I sympathize with that, I think it's a very weak ground for a design-decision.
    Well, first off I'd just like to link you to a bit I wrote on this topic before I made any moves: http://trac.mojavi.org/wiki/ResearchPackageManagement

    Anyways, to continue, I think the point regarding developers "being aware" of it's existence is..sort of muted by how simple it is to work with/manipulate. As far as a developer should be concerned, all they have to do is change elements of an array. Currently something like:

    PHP Code:
    $packages = array
                (
                
    'mvc.*',
                
    'common.*'
                
    ); 
    Loads everything, recursively, under the mvc and common base packages. How difficult is that to use? Not very.

    Continuing, what are you referring to when talking about "PEAR's naming-convention" in particular? Directory naming? Class naming?

    Regards,

  20. #95
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    illusina, I agree with your thoughts about needing build tools to help programmers out. My concern is that these tools are mainly needed when websites pass a certain level of complexity. Below that threshold they can become ponderous overkill. That has been one of my problems with many current frameworks -- when I actually track how many files are included for a common page and it is 20, 30, 40, 50 includes, something seems wrong.

    I think a layered approach would be better. As an example take configuration: at the lowest level it is as simple as importing/merging a PHP array into a Container. The next level would be to read an XML or INI file and put that data into a Container (if it uses the same array format even better DRYwise). Finally at the highest level you have a tool that can manage multiple XML files and associate them with sets classes/files they configure, maybe optmize loading them. So the implementation scales depending on complexity.

    The package system may be similar. Define a manual layer below and have the package system sit on top if that, so the programmer has a choice of no packages, manual packages, auto packages.
    Christopher

  21. #96
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by illusina
    Ezku,
    I missed this point earlier, so I'm going to address it now.
    Thanks for the lengthy response. I posted my reply to the Mojavi forum in hopes of it being a better place to discuss this. I hope arborint, kyberfabrikken et al. will care to join us there

  22. #97
    SitePoint Enthusiast
    Join Date
    Oct 2002
    Posts
    75
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by thr
    This thing that's bothering me, and that is so heavly debated on the internet(and in particular this forum), is called standards. I think most of us want PHP to evolve into something bigger then it is today, shake of it's loose ends and to be able to present a standardized framework for developing applications. But while this opportunity is right at hour hands we're sitting here argueing about best practices, best this, best that, there must be atleast 10 "decent" MVC frameworks for PHP available today... and yet, they all lack something... community support.
    The community is the standard. What makes PHP so special (and so useful) is its ability to conform to the specifications of any particular individual.

    Look at it this way: There is no standard way of doing business--of acquiring scarce resources, manufacturing them into useful products, and distributing them to the markets. There are thousands upon thousands of businesses out there, each run by a different team and a unique leadership style. Each business is built around its inputs / outputs (resources -> acquisition / products -> markets). The methods [business processes] of managing these I/O functions must be highly flexible in order for the business to be competitively acquire resources and serve the markets.

    Web applications are part of the business process--they take inputs and serve outputs. If there were standardized ways of performing these functions, we would probably see in web app development what we now see in business app development, where standards have been created: few companies even develop apps anymore, and among them are SAP, Oracle, and Microsoft.

  23. #98
    SitePoint Member
    Join Date
    Oct 2005
    Posts
    2
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Framework First Language Second

    People adopt Rails because it a jolly good framework, easy to get started with and then they look at ruby and start learning it.

    QD web programming is dead and that was what raw PHP was first class at.

    Let's face it there is no de-facto PHP framework and no spirit of consensus that would foster some standard.

    Real-world applications (not talking of Web 2.0 !) with PHP has become a code-intensive practice with little hope of relief. To me, it is very reminiscent of C++.

    I happen to have tried to develop yet another PHP OO framework (reflexivecms) that I couldn't find, so I did try honestly.

    But now I realize that Rails is already what I wanted to achieve. No need to struggle on. And by the way Ruby is a nice language and fun to learn.

    The only thing I will partly miss is the wealth of existing PHP components. Partly miss only, since it is often more work to make them work with one another that to rewite them from scratch. No framework, no clean reuse.

    One last thought. The chief difference between PHP and Ruby is not (IMHO) about language but about culture. Is it because of Ruby's eastern origins ? Confucianism ? Judo ? Who knows.

  24. #99
    SitePoint Member
    Join Date
    Aug 2005
    Posts
    15
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    My Framework

    Depending on what im doin my framework is

    PHP Code:
    <?   
    //code   
    ?>

  25. #100
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by JdL
    The community is the standard. What makes PHP so special (and so useful) is its ability to conform to the specifications of any particular individual.
    The reality of this is endless re-inventing of the wheel.

    Quote Originally Posted by JdL
    Look at it this way: There is no standard way of doing business--of acquiring scarce resources, manufacturing them into useful products, and distributing them to the markets. There are thousands upon thousands of businesses out there, each run by a different team and a unique leadership style. Each business is built around its inputs / outputs (resources -> acquisition / products -> markets). The methods [business processes] of managing these I/O functions must be highly flexible in order for the business to be competitively acquire resources and serve the markets.
    Actually there are really not that many ways to run a business or different leadership styles. That is another area with a lot of reinventing the wheel and a lot of failure because of it.

    Quote Originally Posted by JdL
    Web applications are part of the business process--they take inputs and serve outputs. If there were standardized ways of performing these functions, we would probably see in web app development what we now see in business app development, where standards have been created: few companies even develop apps anymore, and among them are SAP, Oracle, and Microsoft.
    Web apps for businesses are business apps. Companies like SAP, Oracle, and Microsoft are tools makers, and if anything they have lead to an explosion of business app development because of their standards based tools.
    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
  •