SitePoint Sponsor

User Tag List

Page 1 of 5 12345 LastLast
Results 1 to 25 of 110
  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 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.

  4. #4
    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

  5. #5
    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?

  6. #6
    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

  7. #7
    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?

  8. #8
    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.

  9. #9
    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.

  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 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.

  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 Guru thr's Avatar
    Join Date
    Jun 2003
    Location
    Sweden
    Posts
    664
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BerislavLopac
    No problem.

    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.
    What exactly does Application and Module represent here? Is application one view? or is the module one view? And what if we forexample need to send some parameters? www.example.com/DoSomething/WhitThis ?

    Quote Originally Posted by BerislavLopac
    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.
    Yes, this is a great idea. Being able to have some kind of univerasl adaptor/interfaces that you can write "template"-plugins to. So we can have a Framework->TemplatePlugin->SMARTY converter that enables us to use smarty templates.

    Quote Originally Posted by BerislavLopac
    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).
    Here we can take two aproaches, we could do this at run-time(quite a performance hit, but it's more dynamical) or we could do this with some type of script/file-generation? What's the ideal case?

    Quote Originally Posted by BerislavLopac
    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.
    One sollution is to use some kind of HEAP table, because you need(imho) fast responsetimes when working with object(application) persistance. But does SQLite support HEAP?

    Quote Originally Posted by BerislavLopac
    Definitely not -- PHP already handles most of what a Java servlet does.
    Yes, I agree... don't know why servlets slipped my mind .

    Quote Originally Posted by BerislavLopac
    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.
    Yeah, web is definatly the main target.

    Quote Originally Posted by BerislavLopac
    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.

    As mentioned above, I'd use SQLite to keep both the application and session-level data.
    While using SQLite for session-level data is ok, I still think we need some type HEAP-table for objectpersistance. And yes, a singleton request object is, imho, mandatory.

    Quote Originally Posted by BerislavLopac
    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.
    The problem with URL-parsing is that it requires Apache+mod_rewrite, sure *most* people use apache.. but far from all. Going to look into this some more.

  15. #15
    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
    What exactly does Application and Module represent here? Is application one view? or is the module one view? And what if we forexample need to send some parameters? www.example.com/DoSomething/WhitThis ?
    Actually, none of them is the view. Application is a Controller (Front Controller to be exact), while the module is a Command (I'm talking about the design patterns here). The Command then selects the Models it needs and the View to display with.

    If you needed parameters, you could do something like http://www.example.com/application/m...the.parameters -- it would be the module's job to take care of its parameters, although there could be some standard syntax.

    Quote Originally Posted by thr
    Yes, this is a great idea. Being able to have some kind of univerasl adaptor/interfaces that you can write "template"-plugins to. So we can have a Framework->TemplatePlugin->SMARTY converter that enables us to use smarty templates.
    Actually, I'm currently using some kind of a Decorator pattern, with a class that encapsulates the actual template engines. But it can also be done with an Abstract Factory.

    Here we can take two aproaches, we could do this at run-time(quite a performance hit, but it's more dynamical) or we could do this with some type of script/file-generation? What's the ideal case?[/QUOTE]Off the top of my head, the best approach might be to create some kind of an ini file with the table data and save it on the disk. On future passes this file would be used instead of parsing the db.

    Quote Originally Posted by thr
    One sollution is to use some kind of HEAP table, because you need(imho) fast responsetimes when working with object(application) persistance. But does SQLite support HEAP? ... While using SQLite for session-level data is ok, I still think we need some type HEAP-table for objectpersistance.
    Not in the way that could be used here. You don't want to optimize prematurely here.

    You see, sessions are by default stored at the disk. In any case, they need to be serialized before they are stored for persistance -- the overhead of reading a file or SQLite db is minor here.

    Quote Originally Posted by thr
    The problem with URL-parsing is that it requires Apache+mod_rewrite
    Not necessarily. Custom 404 page (set in .htaccess, but equally easy in IIS), works just fine.

  16. #16
    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 BerislavLopac
    Not necessarily. Custom 404 page (set in .htaccess, but equally easy in IIS), works just fine.
    This must be one of the smartest "hacks" I've ever read . Going to answer to the rest of your post soon, but just wanted to say this before I go out, cheers.

  17. #17
    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 BerislavLopac
    Actually, none of them is the view. Application is a Controller (Front Controller to be exact), while the module is a Command (I'm talking about the design patterns here). The Command then selects the Models it needs and the View to display with.

    If you needed parameters, you could do something like http://www.example.com/application/m...the.parameters -- it would be the module's job to take care of its parameters, although there could be some standard syntax.
    While I realy like this type of aproach, one "problem" that hit me when I was out was how we should handle for example form-validation? Should be it's own module/application? Or should we implement a CoR where the "/application" is now?

    Quote Originally Posted by BerislavLopac
    Actually, I'm currently using some kind of a Decorator pattern, with a class that encapsulates the actual template engines. But it can also be done with an Abstract Factory.
    Agree here, some type of Decorator would probably be best... but I think we need more peoples input on this if we want to be able to plug directly into different templateing-systems/engines.

    Quote Originally Posted by BerislavLopac
    Off the top of my head, the best approach might be to create some kind of an ini file with the table data and save it on the disk. On future passes this file would be used instead of parsing the db.

    Not in the way that could be used here. You don't want to optimize prematurely here.

    You see, sessions are by default stored at the disk. In any case, they need to be serialized before they are stored for persistance -- the overhead of reading a file or SQLite db is minor here.
    I'm fully aware that sessions are stored on disk, but considering that objects are quite more messy and complicated to store then $_SESSION['admin'] = 1 I do think we need some type of HEAP storage. Could try to do some benchmarks on my dev-machine tonight/tomorrow possibly.

  18. #18
    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

  19. #19
    SitePoint Addict
    Join Date
    Aug 2003
    Location
    Toronto
    Posts
    300
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by thr
    This must be one of the smartest "hacks" I've ever read . Going to answer to the rest of your post soon, but just wanted to say this before I go out, cheers.
    As a small addendum, I'd say that subverting custom 404's (and 403's) to handle front controller issues can be useful -- but it remains a rather bad hack. It is generally inappropriate and does not work exactly as one might hope. It should not be recommended as a "standards" type of approach, IMO.

    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.

  20. #20
    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
    While I realy like this type of aproach, one "problem" that hit me when I was out was how we should handle for example form-validation? Should be it's own module/application? Or should we implement a CoR where the "/application" is now?
    The basic form validation would be done in the Intercepting Filter, before it even reaches the Controller.

    Quote Originally Posted by thr
    I'm fully aware that sessions are stored on disk, but considering that objects are quite more messy and complicated to store then $_SESSION['admin'] = 1
    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.

  21. #21
    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?

  22. #22
    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

  23. #23
    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.

  24. #24
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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?
    Someone suggest that you use Intercepting Filters, so the submitted data is validated before it reaches any sort of controller - makes sense, so in saying that maybe you could redirect directly from the Intercepting Filter in question based on the validation?

    So you get to one of two controllers in that event. Another benifit of course would be that the process of form validation is separated from the controller altogether. If for some reason, the means of how you validate your forms changes later, you do not need to refacter any controllers either - you simply swap over to a different Filter.

  25. #25
    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


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
  •