SitePoint Sponsor

User Tag List

Page 1 of 4 1234 LastLast
Results 1 to 25 of 110

Hybrid View

  1. #1
    SitePoint Guru thr's Avatar
    Join Date
    Jun 2003
    Location
    Sweden
    Posts
    664
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Tired of non-standards? Take a look.

    So, I've been reading on this forum for about two years: It's very informative and educational to hang around these parts of the internet, most of you here are highly skilled software engineers - but there's one thing bothering me.

    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.

    I've been thinking about this idea for a long long time, what about if all of us(iif I can include myself ;p) skilled designers and good arguers tried to work together? What if we talked to some of the other big frameworks such as Mojavi, PHP-MVC, WACT, etc. and did our best to join forces and build a complete framework for developing php applications in? We can't put our trust in the PHP-devteam as they are responsible for developing the language itself, not it's available frameworks.

    We currently have Ruby+Rails, .NET, Java/JSP, Python and atleast two or three other competitors on the market, each trying to get the top spot as the language of choice for webapplicationdevelopment. The knowledge on this forum alone is remarkable and I think we should have no problem at all to pull this thing togethere, if everyone could just could swallow some of thier pride and do what's best for php, and the community.

    So, maybee I am crazy... but I think this is what php needs in order to survive and to evlove into something more then a "web scripting language". Almost all of the other platforms/languages we're competing with have a framework that is used by almost every developer out there, yet we have not one? Why? Let's join forces and make it happend, what do you say?

    (ps. God I sound like someone makeing a run for president ;p, and sorry for my intermediate english - it's not my mother tounge ds.)

  2. #2
    SitePoint Member
    Join Date
    Jan 2002
    Posts
    10
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    /me fully agrees.

    Also take a look at this post which is also steering towards a 'standard' framework in PHP: http://www.sitepoint.com/forums/show...7&postcount=40

    BTW both Mojavi and Wact are currently heavily refactoring their code. IMO it would be _great_ if these two communities could merge. Mojavi is very cool but lacks some stuff, Wact is great but misses some other things. IMO they would be great complements to each other. It would be fantastic if we could have a decent PHP framework. I've spent 30+ hours looking at approx 30 PHP frameworks just to discover that all current PHP frameworks are lacking in some way or another. Pretty frustrating. Especially when you see that smaller languages (Ruby, Python, Perl, even JSP) do have decent frameworks...

  3. #3
    SitePoint Guru thr's Avatar
    Join Date
    Jun 2003
    Location
    Sweden
    Posts
    664
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BartVB
    /me fully agrees.

    Also take a look at this post which is also steering towards a 'standard' framework in PHP: http://www.sitepoint.com/forums/show...7&postcount=40
    First, thanks for the great post you linked, and I came across this post by you while I was browsing the forum, I think it sums it up quite well:
    http://www.sitepoint.com/forums/show...7&postcount=19

    From my point of view, if we(the community) don't get anything good going for us soon - I think we'll run out of options very soon, and maybee runing out of our language(over dramatized, yes). If you look at SMARTY they could get that hosted under the *.php.net site, so why can't we get a good framework hosted under php? Talk to the developers, and do our best for the language we've worked so much with?

    On a more technical note: I think that trying to anchor the framework in PHP5+SPL would be a great idea.

  4. #4
    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 thr
    Almost all of the other platforms/languages we're competing with have a framework that is used by almost every developer out there, yet we have not one?
    Of course, this is so not true.

    We do have a framework, and it's called PHP. People seem to forget that Ruby on Rails/JSP/ASP.NET/CherryPy/insert your favorite Web framework is nothing but a way to make it possible to write Web applications in Ruby/Java/JScript/Python/insert your favorite scripting language. Most of them are general-purpose languages, and an implementation for Web development is required. PHP, on the other hand, has one implementation (actually, two with CLI), and that is the Web dev environment.

  5. #5
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BerislavLopac
    We do have a framework, and it's called PHP. People seem to forget that Ruby on Rails/JSP/ASP.NET/CherryPy/insert your favorite Web framework is nothing but a way to make it possible to write Web applications in Ruby/Java/JScript/Python/insert your favorite scripting language. Most of them are general-purpose languages, and an implementation for Web development is required. PHP, on the other hand, has one implementation (actually, two with CLI), and that is the Web dev environment.
    I think the attitude expressed there is a pretty good example of why there are very few standards. PHP is divided into several camps that are incompatible design wise. It's really no use trying to reconcile them.

    thr, your idea is considered a good one, and necessary goal for PHP, by some people here. I think rather than being general, you should ask politely up front that only those who are interested in your goal should post to the thread. Make it clear that your are not interested in debating whether this is a good idea or not, but that this is a discussion about the goal you have stated. Also be clear whether the standards you want are to be PHP5 only or PHP4 compatable.

    I would recommend that you search of other threads on this subject, which you may find enlightening or disheartening. If you can keep it focused, something good may come if it.
    Christopher

  6. #6
    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 arborint
    I think the attitude expressed there is a pretty good example of why there are very few standards.
    Would you be so kind to explain what attitude is that?

  7. #7
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BerislavLopac
    Would you be so kind to explain what attitude is that?
    There is enough drag on threads as it is, if you don't think a subject (frameworks in this instance) is worthwhile, yet others may ... just don't bother to get involved in the with the thread.
    Christopher

  8. #8
    SitePoint Wizard
    Join Date
    Jul 2004
    Location
    Minneapolis, MN
    Posts
    1,924
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Standards in coding is near impossible. Even some of the most powerful programming languages never had standards. Sure maybe a framework, but that really isn't a standard. Frankly I don't think that PHP even needs frameworks, and it operates quite well on its own.

    I have to agree with BerislavLopac here.

    I don't think that PHP should strive to be like something else. Everything else isn't in the lead. PHP has way more usage that say Ruby on Rails, so why would PHP change to be like something it's beating?

  9. #9
    SitePoint Guru
    Join Date
    Nov 2002
    Posts
    841
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Why do we keep re-inventing the wheel in PHP? The question to ask is what is it about PHP that prevents integrating code written by different programmers or different organizations.

  10. #10
    SitePoint Guru thr's Avatar
    Join Date
    Jun 2003
    Location
    Sweden
    Posts
    664
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Selkirk
    Why do we keep re-inventing the wheel in PHP? The question to ask is what is it about PHP that prevents integrating code written by different programmers or different organizations.
    Spot on.

    This is indeed the big problem in PHP, you have Mojavi, WACT, PHP-MVC, Phrame,etc. - and what have they all done? They've implemented the same that's been wheel that's been around for ever, in X amount of different ways. Sure, diversity is great but if the price you have to pay to get it is a split up community that never does anything but argue over Z vs Y, then atleast I dont like it or want it.

    PEAR hade the opportunity to become great, but they wasted thier chance imho - Even though they are trying to shapen up I would be ashamed to use most(not all, there's some quality code in there too) of what's in the PEAR-repository on a day-to-day basis.

    Quote Originally Posted by BerislavLopac
    Of course, this is so not true.
    No, it might not be 100% truthfully in every case, but if you look at the majority of our competitors maybee they have one or two big frameworks to work with, and many people that use them. What do we have? About 10 frameworks with about 5% of the community using them.

    And as arborint pointed out, if you are not interested in trying to get some type of framework up and running, or atleast discussing how we should do it - then please, don't post more. I'm no interrested in argueing this subject, as it's been done so many times before. Are there any people that would like to atleast think and talk about how this would best be done? And IMHO, PHP5 (E_STRICT) standards is a must. As we'd wan't to implement this for the future, not the past?

    I don't think that doing something like YASIW (Yet Another Struts Implementation for the Web) is something we should be aiming at, instead we should try to look at what does the community need? What does it want? etc. And how to people feel about trying to talk to the WACT/Mojavi/etc. guys ? I'm not expecting anyone to just drop thier project and come running to this sitepoint thread, but maybee they can give input, ideas or even contribute some code? Who knows. But it's worth a try I think.

  11. #11
    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 thr
    And as arborint pointed out, if you are not interested in trying to get some type of framework up and running, or atleast discussing how we should do it - then please, don't post more.
    For Pete's sake, guys, when did I say that I'm not interested?

    The point of my post was to stress an important point which is often overlooked by the designers of various PHP frameworks, who try to copy other languages' frameworks (Struts, Rails...) without taking into considerations various solutions that PHP already has implemented, thus reinventing the wheel. Here's a brief list, off the top of my mind, what is specific to PHP and should be used in frameworks:

    1. Dynamic inclusion and code parsing. In PHP, it is quite easy not only to include code on runtime, but to dynamically decide what files to include by constructing their names on the spot. It is even possible to dynamically determine what class or method will be called the same way. Compiled languages, like Java, must go through hoops to achieve a semblance of this; other languages that have that ability make a good use of it -- this is how Rails achieves its famous ActiveRecord mapping.

    2. Dynamic ini file parsing. Many PHP frameworks out there go after Java ones and use XML files for storing config information. While this got much easier with the advent of PHP5, PHP still has much simpler and I guess faster ways to store config data. One is the use of included PHP files, and another the sadly unknown function parse_ini_file() -- it uses a syntax similar to the one in php.ini file, which is much cleaner and simpler than both XML and PHP syntaxes.

    3. Arrays. I often see classes which are nothing more than glorified wrappers for PHP arrays. I have yet to see a more powerful handling of arrays than the one in PHP -- just a brief look at http://www.php.net/manual/en/ref.array.php gives an idea of a great number of built-in operations that can be performed on arrays. Just remember how much effort went into the SPL interfaces that give objects the ability to act like arrays!

    4. Superglobals. Various platforms has different ways to access system, application and session data -- PHP has superglobals like $_REQUEST or $_SESSION.

    5. Statelessness. Unlike other platforms, PHP doesn't have the ability to keep the created objects in memory during the lifetime's application. This calls for a different approach to session and application-wide persistance, as the approach that other languages use cannot simply be emulated.

    To put all this more concisely, any PHP framework should make as much use as possible of the PHP's dynamic properties. For example, use filename mapping instead of ini-file mapping; use dynamic ini files instead of XML ones; etc.

    Basically we don't need YA(insert your preferred non-PHP framework)PC -- what we need is to make a list of features that we want our framework to have, and then find the best way to implement those features using PHP. If that means copying a solution from another framework (e.g. I like how Ruby on Rails and CherryPy map their URL's to objects and methods), that's good; if that means to solve some problems in a PHP-specific ways (e.g. using __autoload, __set/__get or __call), that's even better.

  12. #12
    SitePoint Guru thr's Avatar
    Join Date
    Jun 2003
    Location
    Sweden
    Posts
    664
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    BerislavLopac, wonderfull response - this is what I was looking for. Maybee I/we judged you to quick, hope you can accept my apoligy.

    So, how should we go on about this? What's the best way to implement a framework? What kind of functionallity do we want? What's our scope? Should we build ontop of SPL or not? Do we want an event-drive aproach? Do we want to use some type of "Servlet"?

    I agree with about 100% of what yo siad BerislavLopac, many of the others PHP-frameworks have tried to force another language/platforms on php. For example porting struts to PHP is, imho. insane. The same thing goes for .NET clones like PRADO. We will never be able to do what Struts does in Java in PHP-MVC(this is the strutsport, right?), or what .NET does PRADO. We should look for what makes PHP uniqe(like you have Berislav) and try to capture that, and then build our framework.

    * First and foremost, should it a web-only framework like(not a clone of, but the same scope) ASP.NET or should it be a multipurpose framework for both CLI/GUI and Webapplications?

    * Should we build ontop of SPL and use the special array-like syntaxes?

    These are two of the questsions that I think we should answer first, mainly because they effect the structure of the framework, very very much.

    And the idea for .ini files i think is a great one. Sure XML got it's uses but atm it's slow and tedious, Java/Tomcat = XM(HELL). PHP Config-files open up a possible security issue with the ability to include any code inside them.

    Do we want to be able to keep some kind of state on our objects? How is this best acchieved if we need it? Or should we go with complete statelessness except sessions? How do we handle requests? Do we allow both _GET and _POST at the same time?

    There's hundreds of questsions like this, most of them require alot of thinking, argueing and testing to straigthen out. But if there's one place(forum/community) on the web that can do it, it's this one.

  13. #13
    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 thr
    BerislavLopac, wonderfull response - this is what I was looking for. Maybee I/we judged you to quick, hope you can accept my apoligy.
    No problem.

    Quote Originally Posted by thr
    So, how should we go on about this? What's the best way to implement a framework? What kind of functionallity do we want? What's our scope?
    Here's a brief list what I can quickly think of that we need:

    1. A clean way to implement URL mapping, i.e. to have a simple conversion from www.example.com/application/module to the relevant PHP code. Rails and CherryPy-like approach of calling Application->module() might be a good start here.

    2. Independence of templating system, preferably with a generic interface and a module which could be used to plug in any templating system and use it with only minor tweaking.

    3. Simple ORM engine. There are some quite decent ones, but they are quite complicated to setup and use. Rails again has a nice approach where classnames map to table names, so:
    PHP Code:
    class Product extends ActiveRecord {} 
    would automatically map to the table called "product" (I don't like Rails convention that class names are singular while table names are plural). The constructor would parse the table definition and set appropriate attributes and methods (probably using __set/__get/__call).

    4. Application-level persistance. It would be pretty simple using SQLite. It could also include a custom session handler that uses SQLite, so that we have all our data at one place.

    Quote Originally Posted by thr
    Do we want to use some type of "Servlet"?
    Definitely not -- PHP already handles most of what a Java servlet does.


    Quote Originally Posted by thr
    * First and foremost, should it a web-only framework like(not a clone of, but the same scope) ASP.NET or should it be a multipurpose framework for both CLI/GUI and Webapplications?
    I'd focus on the individual features rather than the big picture. So, if you have a good feature that would really help CLI development, go for it; other wise Web seems like a more likely target.

    Quote Originally Posted by thr
    * Should we build ontop of SPL and use the special array-like syntaxes?
    In my opinion, that works best if a method needs to be able to use objects or arrays interchangeably. So, if there is a need for that, definitely go for it.

    I see one possible use of it in calling controllers: use a global (singleton) Request object for main calls done by the Web server, where you validate the incoming data etc; but when calling controllers internally (e.g. to embed them on a composite page) just hack and pass a simple array.

    Quote Originally Posted by thr
    Do we want to be able to keep some kind of state on our objects? How is this best acchieved if we need it? Or should we go with complete statelessness except sessions?
    As mentioned above, I'd use SQLite to keep both the application and session-level data.

    Quote Originally Posted by thr
    How do we handle requests?
    Again, use Request object that would contain and handle (validate/format/whatever) incoming data.

    Quote Originally Posted by thr
    Do we allow both _GET and _POST at the same time?
    I would advise that URLs are parsed instead of being sent as _GET. So only _POST (as well as _SESSION, _COOKIE etc).

    These are just my suggestions/ideas.

  14. #14
    SitePoint Enthusiast
    Join Date
    Nov 2004
    Location
    Canberra, Australia
    Posts
    66
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BerislavLopac
    2. Dynamic ini file parsing. Many PHP frameworks out there go after Java ones and use XML files for storing config information. While this got much easier with the advent of PHP5, PHP still has much simpler and I guess faster ways to store config data. One is the use of included PHP files, and another the sadly unknown function parse_ini_file() -- it uses a syntax similar to the one in php.ini file, which is much cleaner and simpler than both XML and PHP syntaxes.
    I agree that .ini files can be useful, however the main problem I have with them is that it can be difficult to represent a hierarchy of objects/data within them.

    Quote Originally Posted by BerislavLopac
    3. Arrays. I often see classes which are nothing more than glorified wrappers for PHP arrays. I have yet to see a more powerful handling of arrays than the one in PHP -- just a brief look at http://www.php.net/manual/en/ref.array.php gives an idea of a great number of built-in operations that can be performed on arrays. Just remember how much effort went into the SPL interfaces that give objects the ability to act like arrays!
    True, arrays are powerful but I generally like using a wrapper class because otherwise you have to duplicate a lot of array-specific code everywhere, for example:

    PHP Code:
    function getModule($name=NULL)
    {
       if (isset(
    $this->modules[$name]))
       {
          return 
    $this->modules[$name];
       }

    vs

    PHP Code:
    function getModule($name=NULL)
    {
       return 
    $this->modules->get($name);

    I know that's a very simplistic example, but when you're trying to write a system that uses as much OO as possible, the constant use of array handling functions just seems kinda 'icky' (I guess because it's procedural code within OO code), in my humble opinion anyway.

    Quote Originally Posted by BerislavLopac
    4. Superglobals. Various platforms has different ways to access system, application and session data -- PHP has superglobals like $_REQUEST or $_SESSION.
    Like with regular arrays, I find dealing with the raw superglobals also icky. Usually I try to have some sort of wrapper class around them, like HTTPRequest and HTTPSession, which encapsulates functionality related to each. Again this is just how I feel about it, many others would probably have no problem with using the raw superglobals throughout their code but I don't like doing that generally. Also, I guess the "globals are bad bad BAD" notion gets drilled into you a bit from the OO camps.

    Quote Originally Posted by BerislavLopac
    5. Statelessness. Unlike other platforms, PHP doesn't have the ability to keep the created objects in memory during the lifetime's application. This calls for a different approach to session and application-wide persistance, as the approach that other languages use cannot simply be emulated.
    This is true, and you do need to be conscious of how much "stuff" you are doing per request/response cycle, however you can certainly emulate the approaches other languages use (without knowing the specifics you were refering to), you just need to be mindful of bloat and require a good persistence layer/session handling.

  15. #15
    SitePoint Guru thr's Avatar
    Join Date
    Jun 2003
    Location
    Sweden
    Posts
    664
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by {RainmakeR}
    I agree that .ini files can be useful, however the main problem I have with them is that it can be difficult to represent a hierarchy of objects/data within them.
    As I said, I love other peoples input and I didn't realy think about this. One sollution could be to have one .ini file for each "step" in the hierarchy, and the only reference to the rest of the .ini files it has is it's parent and it's childs.



    Quote Originally Posted by {RainmakeR}
    True, arrays are powerful but I generally like using a wrapper class because otherwise you have to duplicate a lot of array-specific code everywhere, for example:

    PHP Code:
    function getModule($name=NULL)
    {
       if (isset(
    $this->modules[$name]))
       {
          return 
    $this->modules[$name];
       }

    vs

    PHP Code:
    function getModule($name=NULL)
    {
       return 
    $this->modules->get($name);

    I know that's a very simplistic example, but when you're trying to write a system that uses as much OO as possible, the constant use of array handling functions just seems kinda 'icky' (I guess because it's procedural code within OO code), in my humble opinion anyway.
    I agree here, and I personally prefer wrapper classes vs. arrays. One example is that sometimes a stack is very efficient in terms of memory use and speed compared to a big array - where the array functionalltiy of keeping all the values in memory even after they've been used, just gets in the way.


    Quote Originally Posted by {RainmakeR}
    Like with regular arrays, I find dealing with the raw superglobals also icky. Usually I try to have some sort of wrapper class around them, like HTTPRequest and HTTPSession, which encapsulates functionality related to each. Again this is just how I feel about it, many others would probably have no problem with using the raw superglobals throughout their code but I don't like doing that generally. Also, I guess the "globals are bad bad BAD" notion gets drilled into you a bit from the OO camps.
    Could not agree more, dealing with raw superglobals is *icky*. You'd want some type of DataSpace interface and InputCleaner interface(that removes for example magic_quotes_gpc, etc.) for the HTTPRequest, HTTPResponse and HTTPSessions.


    Quote Originally Posted by {RainmakeR}
    This is true, and you do need to be conscious of how much "stuff" you are doing per request/response cycle, however you can certainly emulate the approaches other languages use (without knowing the specifics you were refering to), you just need to be mindful of bloat and require a good persistence layer/session handling.
    About the object persistance I'm quite sure that we'd want some type of easy managable way to unserialize/rebuild the objects. And this is where SQLite comes in, even if we can't use some type of HEAP-table I'd still pick a DB over "pure" file-storage just because it's a much cleaner approach. I'd also pick SQLite over MySQL here because the SQLite-file can be created at runtime if it doesn't exist - and you could have some config-variable to specifiy both the objectpersistance and session db-files location, for example:

    (config.ini)
    object_persistance = "/usr/local/framework_objper.sql"
    create_mask = 0700

    session_persistance = "/usr/local/framework_ssn.sql"
    create_mask = 0700

  16. #16
    SitePoint Evangelist Ian R. Gordon's Avatar
    Join Date
    Feb 2004
    Location
    New York
    Posts
    474
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by thr
    Spot on.

    This is indeed the big problem in PHP, you have Mojavi, WACT, PHP-MVC, Phrame,etc. - and what have they all done? They've implemented the same that's been wheel that's been around for ever, in X amount of different ways. Sure, diversity is great but if the price you have to pay to get it is a split up community that never does anything but argue over Z vs Y, then atleast I dont like it or want it.

    PEAR hade the opportunity to become great, but they wasted thier chance imho - Even though they are trying to shapen up I would be ashamed to use most(not all, there's some quality code in there too) of what's in the PEAR-repository on a day-to-day basis.

    No, it might not be 100% truthfully in every case, but if you look at the majority of our competitors maybee they have one or two big frameworks to work with, and many people that use them. What do we have? About 10 frameworks with about 5% of the community using them.

    And as arborint pointed out, if you are not interested in trying to get some type of framework up and running, or atleast discussing how we should do it - then please, don't post more. I'm no interrested in argueing this subject, as it's been done so many times before. Are there any people that would like to atleast think and talk about how this would best be done? And IMHO, PHP5 (E_STRICT) standards is a must. As we'd wan't to implement this for the future, not the past?

    I don't think that doing something like YASIW (Yet Another Struts Implementation for the Web) is something we should be aiming at, instead we should try to look at what does the community need? What does it want? etc. And how to people feel about trying to talk to the WACT/Mojavi/etc. guys ? I'm not expecting anyone to just drop thier project and come running to this sitepoint thread, but maybee they can give input, ideas or even contribute some code? Who knows. But it's worth a try I think.
    I don't know if someone already mentioned this but, if they did this is just re-iternation then.

    While, I can appreciate the need for a standards base unfortunately people have different views on how this can and should be accomplished, just think about those who code in a procedural format and those who use OOP. There are lots of other little differences too, in coding styles, use of types of controls, etc, etc.

    The problem is much grander than one group can realize, its kind of something that will never happen and I think that's fine. We don't have to unify behind a common framework and I think that is something that makes PHP great, we are "forced" into someone we might not really like and we are kind of free to do something completely custom and our own even if it is re-inventing the wheel or going back to the stone age.
    Ian Gordon
    CSS / XHTML / PHP Programmer
    http://www.iangordon.us

  17. #17
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    thr, you may want to look through the Skeleton threads where we attempted to build the core files that you could build frameworks on top of. It was a similar idea to what you want to do, only I believe the code worked in PHP4.

    http://www.sitepoint.com/forums/showthread.php?t=277808

    http://www.sitepoint.com/forums/showthread.php?t=271112
    Christopher

  18. #18
    SitePoint Guru thr's Avatar
    Join Date
    Jun 2003
    Location
    Sweden
    Posts
    664
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    thr, you may want to look through the Skeleton threads where we attempted to build the core files that you could build frameworks on top of. It was a similar idea to what you want to do, only I believe the code worked in PHP4.

    http://www.sitepoint.com/forums/showthread.php?t=277808

    http://www.sitepoint.com/forums/showthread.php?t=271112
    Thanks for the links arborint, I'll try to read em when I got time... not tonight tho. You're not interested in puting your POV down in words on some of the thing's me and BerislavLopac been discussing?


    Quote Originally Posted by BerislavLopac
    The basic form validation would be done in the Intercepting Filter, before it even reaches the Controller.
    Ah, well.. maybee I didn't express myself good enough, what I ment was something more in the lines of "How do we make the application aware of the fact that we wan't form-validation, and how do we handle error/success?".

    Quote Originally Posted by BerislavLopac
    Not at all. They are simply serialized and unserialized regularly. The only thing you need to take care of is that their class definitions are loaded before the actual objects, and that's all. I do this kind of things all the time:

    PHP Code:
    $obj = new Object();
    $_SESSION['object'] = $obj;

    // in the next session:

    $obj $_SESSION['object']; 
    PHP5's __autoload() takes care of the class loading.
    While I know that you're correct in theory of how it works I still have this annoying feeling that we should use heap storage for it, wellwell .


    Quote Originally Posted by jayboots
    Rather than abusing http, an alternative to mod-rewrite with apache is using a location container with a force-application directive. This is somewhat less obtuse and gives you the chance to handle url paths more directly from within your application -- although it too has its costs.
    The 404-hack might be a "bad" one but I still thought is was a quite clever one. Could you try to explain in more detail what a "force-application directive" is and how it's used? And what's the costs associated with it?



    Another thing we should consider is this(again): What's our scope? Do we want to implement a complete framework like ASP.NET or Ruby on Rails or do we want to implement some kind of "frame" that has part's that are not as tightly coupled as the ASP.NET/Ruby on Rails stuff?

  19. #19
    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 thr
    Another thing we should consider is this(again): What's our scope? Do we want to implement a complete framework like ASP.NET or Ruby on Rails or do we want to implement some kind of "frame" that has part's that are not as tightly coupled as the ASP.NET/Ruby on Rails stuff?
    Personally, I'd prefer the latter -- a kind of Lego blocks you build your app with.

  20. #20
    SitePoint Addict
    Join Date
    Aug 2003
    Location
    Toronto
    Posts
    300
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by thr
    The 404-hack might be a "bad" one but I still thought is was a quite clever one. Could you try to explain in more detail what a "force-application directive" is and how it's used? And what's the costs associated with it?
    Sorry, I meant the ForceType directive. It can also be considered hacky, particularly if used with a location container (which ideally are never meant for filesystem addressable content). The idea is that you can make apache respond to a specific root, path or match virtually passing control to a script which is treated as the mime-type given by ForceType (eg: a PHP script). The script then decodes the REQUEST_URI to determine the actual path requested and takes appropriate action. It involves some mechanics and in the end, it may not be the most appropriate choice so I refer you to google to find out more -- but here is a link that gives you the general gist: http://www.devarticles.com/index2.ph...ge=0&hide_js=1

  21. #21
    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 jayboots
    Sorry, I meant the ForceType directive.
    If I understood it correctly, ForceType has a couple of disadvantages:

    1. It requires the existence of one file for each application -- e.g., for www.example.com/application/module/ we need to have an "application" file. which means that we can't use a single point of entry (Front Controller) for everything. Even then, Apache's multiviews option seems much more appropriate.

    2. I don't think it's portable -- even if it is, other servers like IIS probably have a very different way of handling it.

    The 404 hack has the following advantages:

    a) It abides the HTTP standards, which means that all HTTP servers have some way of setting it up.

    b) Allowes for a more flexible entry point strategy; if we really want separate applications, we can set various subfolders with their own 404 handlers.

    That being said, the main disadvantage of this approach that all of your pages return a 404 Not Found response header, which can mess up your HTTP logs.

  22. #22
    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 {RainmakeR}
    I agree that .ini files can be useful, however the main problem I have with them is that it can be difficult to represent a hierarchy of objects/data within them.
    Depends on how complex a structure you need. Ini files can handle up to one level deep structures -- you can have:
    Code:
    [group1]
        var1 = value1
        var2 = value2
    
    [group2]
        var1 = value1
        var2 = value2
    which translates to:
    PHP Code:
    array('group1' => array('var1' => 'value1''var2' => 'value2'),
          
    'group2' => array('var1' => 'value1''var2' => 'value2')
          ); 
    For anything more complex use XML by any means, or multiple ini files if appropriate (e.g. multiple languages are best handled by multiple ini files, one per language).

    Quote Originally Posted by {RainmakeR}
    True, arrays are powerful but I generally like using a wrapper class because otherwise you have to duplicate a lot of array-specific code everywhere ... when you're trying to write a system that uses as much OO as possible, the constant use of array handling functions just seems kinda 'icky' (I guess because it's procedural code within OO code)
    Again, depends on what you currently need. The notion that mixing OOP and procedural is bad probably comes from Java influence -- the fact is that PHP has procedural roots, and that it has many powerful functions built in. We shouldn't be mindless purists and think in only one midset, whether procedural or OO. We should always keep in mind what would be the best PHP way to handle things.

  23. #23
    SitePoint Addict
    Join Date
    Aug 2003
    Location
    Toronto
    Posts
    300
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BerislavLopac
    The 404 hack has the following advantages:

    a) It abides the HTTP standards, which means that all HTTP servers have some way of setting it up.
    First, I'm not absoultely against this method -- I agree it is clever and I've used it myself. Still, it IS an ABUSE of the standard. If you want an OOP analogy, it is the same as using try/catch to implement application logic rather to handle error conditions. Unfortunately, the shortest "easiest" route is not always the best. Besides, using 404s to redirect content can lead to confusing and hard to debug issues.

  24. #24
    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. #25
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    PHP5's __autoload() takes care of the class loading.


    Does just what it says on the box


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
  •