SitePoint Sponsor

User Tag List

Page 2 of 2 FirstFirst 12
Results 26 to 46 of 46
  1. #26
    Non-Member
    Join Date
    Feb 2012
    Posts
    892
    Mentioned
    10 Post(s)
    Tagged
    0 Thread(s)
    It seems to me you're imagining things too, at this point. Anyway, let me know about your progress. I'm really interested. As far as the distance goes, anything is relative. But you already know that.

  2. #27
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    988
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    Going back to your initial post. I totally agree. Such a huge configuration file in a format that requires a lot of reading around to understand is horrid.

    I believe in a 100% convention over configuration approach to things like that. There's no need for it.

    Ignoring the horrible lack of separation of concerns that xml file seems to demonstrate (why are the required javascript files defined there, rather than where they're actually use. I guarantee everything which uses that layout doesn't need all the javascript files, which is what's caused it to get so large, it's a god file), it seems like abstraction for the sake of it. Why is this file even needed?

    As another example, I'd like to add: Router configuration (Cake for example is dire).

    The worst part about what these essentially superfluous configuration files create is the number of file edits needed for simple task such as adding a new module.

    However, on the topic of template engines themselves, they are incredibly useful. Whether they use php or a custom syntax is irrelevant. The benefits they bring are huge. Custom-syntax ones do force a better separation of concerns and by extension improved re-usability.

    Quote Originally Posted by Jeff Mott View Post
    Perhaps the MVC confusion is because you came from a world of desktop programming, rather than Web programming. HTTP is stateless, so there's no such thing as the view responding to user input. Every user action is a new request that gets funneled through the controller.
    Indeed! I think this is where MVC confusion lies and where the lines blur and the major frameworks get it wrong. I cringe every time I see a controller action create a view. I wrote a really basic MVC example a couple of years ago http://r.je/mvc-in-php.html where a controller:view has a true 1:1 relationship.

  3. #28
    SitePoint Enthusiast
    Join Date
    Jul 2005
    Location
    Norway
    Posts
    88
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Magento is flexible in many ways, and that comes at a price. For example, one can have multiple webshops within the same installation, and they can each have different skins and different prices for the same products and even different behavior and languages. In addition to this, as a module developer, one should be able to alter core behaviour without actually modifying magento core code. This makes things complex. For example, if magento uses a model class, it loads it with Mage::getModel('sales/order'). Which class is loaded with that statement depends on what's in the config.xml files. So that means I can make my own version of the order model class, which extends from magento core order model, and configure magento so that my class gets loaded every time instead of the magento core class. I can then add or overwrite behavior in that class without actually modifying it.

    However, this brings on a lot of metaprogramming. I knew PHP pretty well before starting on magento, and basically had to learn a new language. What's worse is that there is no syntax-check for the XML files, so if you write something wrong, like <frontname> instead of <frontName>, then it just doesn't work, and you basically have to guess what went wrong. I've also been thinking that there must be a better way, but so far haven't got much other than cutting down on features and flexibility.

    Also, Magento has over 2 million lines of code.. it easily takes 20 seconds to load a page without caching, and that's on a quad core machine.

    Maybe it's time for a new programming language, that is like a framework, but not so bloated.. and with proper syntax checking..

  4. #29
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by oeyvind View Post
    However, this brings on a lot of metaprogramming.
    Which is where my issue with the concept lies -- what in blazes is it doing that needs some goofy meta language that couldn't be done in the ACTUAL language it's written in?

    Quote Originally Posted by oeyvind View Post
    I knew PHP pretty well before starting on magento, and basically had to learn a new language.
    ... and that's the problem when said 'new language' is as complex or redundant to the one it's written in.

    NOTHING you mentioned requires any meta language nonsense to do it; at least nothing that couldn't have just as easily been done in PHP code using includes, functions, extensible classes, syntactic object lists, and a host of other things that wouldn't meant wasting time with writing and running an interpreter -- inside an interpreted language.

    I mean, I know I'm writing my own interpreted language right now, but at least I'm using a compiled language to do it!

  5. #30
    I solve practical problems. bronze trophy
    Michael Morris's Avatar
    Join Date
    Jan 2008
    Location
    Knoxville TN
    Posts
    2,011
    Mentioned
    57 Post(s)
    Tagged
    0 Thread(s)
    What I'm doing, what seems to be working in my early experiments, is to stop the abstraction. Basically, abstracting the core components - the classes that are loaded by the code the user isn't supposed to touch, is one thing, but abstracting the code the user is going to be routinely working with is just gross overkill.

    There is no router configuration in PNL. Controller load files lie in the map directory at the same location one would expect them to lie in htdocs (the reason they are not in htdocs is PNL uses that directory for caching in the attempt to preclude itself and most all of PHP from the majority of page loads). Every class we load getting to that point except the root starting class is configurable just as in Magento, Cake, Symphony or the like. Once we reach the controller load files we branch to two major possibilities.

    First is that the "control load file" is actually a view. It will echo out content and fetch things from models without using (or heavily using) a template library. This is a design choice, but for small pages and projects a legitimate one. MVC still exists here - we're still using a front controller to reach this view file, but further separation hasn't occurred.

    Second is the load file starts up one of more classes *directly* like this

    Code php:
    $response = new Page($this); // This is the front controller and dispatcher, pretty much all control classes require it as a parameter.
    $response->parse();

    And the Page class is custom logic for that page that knows what it's templates and models are without being told by any config files. If you need to change these things, you extend the base class as needed. To abstract with a factory at this juncture is pointless - you end up with binding code at least as, if not more complex than, the code you end up writing here in PHP.

    The general flow outside the loader remains the same - parsing the page causes it to load its event(s) onto the event dispatcher in the desired order of execution - loading the queue. Then each is dealt with separately.

    I'm taking a middle ground here - I don't think the overkill of Magento, Cake, Zend, Symphony et al is the answer. I don't think Death Shadow is anywhere near right either. I'm probably going to be wrong on my first few attempts but my hunch here is that some abstraction is indeed good, all abstraction is bad.

    I will note I agree with Deathe on the need to handle parser code with compiled code for maximum speed. Eventually the front controller & router of this framework will be a C++ extension for PHP. The PHP version will remain though as a reference and teaching tool - the C version will be the optimized version.

  6. #31
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Michael Morris View Post
    you end up with binding code at least as, if not more complex than, the code you end up writing here in PHP.
    ... and that in a nutshell is my problem with meta-languages. They are usually as complex, if not more so, than the language you're already using.

  7. #32
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2006
    Location
    Augusta, Georgia, United States
    Posts
    4,053
    Mentioned
    16 Post(s)
    Tagged
    3 Thread(s)
    Meta languages though normally have a much smaller scope in terms of features so that someone who doesn't understand the language which the meta one is built *can be understood. I guess for those who know PHP it is a valid argument but a lot of these systems such as; Magento are not really targeted at programmers but business owners, designers or those who do not have a *great grasp on PHP and/or programming fundamentals. So they perhaps *appear less daunting for someone who does not understand PHP? Also, in some cases features that would be available in PHP can be omitted so that somone working at the template layer can't royally f**k things up. If your working by yourself though without other team members with different strengths and understand (language) than I can fully understand why a meta language might feel like a useless level of abstraction though.
    The only code I hate more than my own is everyone else's.

  8. #33
    SitePoint Wizard wonshikee's Avatar
    Join Date
    Jan 2007
    Posts
    1,223
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by oddz View Post
    If your working by yourself though without other team members with different strengths and understand (language) than I can fully understand why a meta language might feel like a useless level of abstraction though.
    This is the gist of the whole thing. All these abstractions and layers upon layers of complexity feel pointless if you're working solo or in a small team. But for a 3rd party application that is intended for a broad range of users, it's one of the most logical ways to organize certain meta data that the rest of the system needs to be able to access, particularly add-on modules.

  9. #34
    I solve practical problems. bronze trophy
    Michael Morris's Avatar
    Join Date
    Jan 2008
    Location
    Knoxville TN
    Posts
    2,011
    Mentioned
    57 Post(s)
    Tagged
    0 Thread(s)
    As a designer who ended up learning how to program and program well, I don't buy the argument. The meta languages are usually more complicated than the PHP they are meant to replace. That doesn't mean they don't have a point. In Magento's defense, there are reasons for everything it does. But I don't think its necessarily the best way, even within the context of its own methodology. Some of the worst problems are being addressed by Magento 2.

    Still, I'm not building an enterprise level cart system. I'm building something more akin to a kit car. I need to avoid laying on the layer of complexity because it's out of scope for the intended audience, if it makes any sense.

  10. #35
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2006
    Location
    Augusta, Georgia, United States
    Posts
    4,053
    Mentioned
    16 Post(s)
    Tagged
    3 Thread(s)
    Quote Originally Posted by Michael Morris
    Still, I'm not building an enterprise level cart system. I'm building something more akin to a kit car. I need to avoid laying on the layer of complexity because it's out of scope for the intended audience, if it makes any sense.
    Makes total sense.
    The only code I hate more than my own is everyone else's.

  11. #36
    SitePoint Mentor silver trophybronze trophy

    Join Date
    Feb 2008
    Location
    Preston, Lancashire
    Posts
    1,376
    Mentioned
    72 Post(s)
    Tagged
    1 Thread(s)
    As a designer who ended up learning how to program and program well, I don't buy the argument. The meta languages are usually more complicated than the PHP they are meant to replace. That doesn't mean they don't have a point. In Magento's defense, there are reasons for everything it does. But I don't think its necessarily the best way, even within the context of its own methodology. Some of the worst problems are being addressed by Magento 2.
    When using one layer adds complexity complicates things, then you'd be fooling to stick learning that new layer of complexity. Now if that layers makes life 'easier' for the overall process, then go ahead.

    That being said I certainly would not learn something I did not have to. Never used Magento, nor do I plan to, don't want to either! Shopify seams to be an amazing job on e-commerce site, and it's layer of complexity is very easy to learn.
    follow me on ayyelo, Easy WordPress; specializing in setting up themes!

  12. #37
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Sega View Post
    When using one layer adds complexity complicates things, then you'd be fooling to stick learning that new layer of complexity. Now if that layers makes life 'easier' for the overall process, then go ahead.
    That's the thing -- where does ANY of this idiotic nonsense make it easier; We're already talking about being in a high level language, how much more "abstraction" do you need? All we hear is lame excuses like "oh it confuses the people writing templates" as if magically adding another language is somehow simpler than using *SHOCK* markup with a bit of PHP laced in.

    Take the example from the original post -- take just ONE MALFING LINE!!!

    How in blazes is this:

    <action method="addJs"><script>prototype/prototype.js</script></action>

    ANY BETTER than:

    <script type="text/javascript" src="prototype/prototype.js"></script>

    Slower since it has to be parsed IN PHP, Slower since it has to turn it into markup instead of just BEING markup... That's the poster child for everything wrong with said #DDD moron approach to building sites.

    <action method="addCss"><stylesheet>css/styles.css</stylesheet></action>

    Where's the media type? How is that better? How is having MULTIPLE XML elements going to be faster or better than ONE DOM ELEMENT?!? That is some of the most idiotic half assed BS I've seen in thirty-five years of writing code! Seriously, what in blazes type of drooling idiot would even WANT to use that? Much less find it easier?!?

    Take that entire original 3.3k he posted, where the devil is the advantage in that over simply using markup?!? What purpose could that POSSIBLY serve? The ONLY thing I could figure is perhaps adding absolute paths automatically -- useful PERHAPS if serving on multiple domains; otherwise it's just an indicator you don't know how to structure your directories properly or don't know enough HTML to be making skins in the first place!

    HerpaFreakingDerp!

  13. #38
    I solve practical problems. bronze trophy
    Michael Morris's Avatar
    Join Date
    Jan 2008
    Location
    Knoxville TN
    Posts
    2,011
    Mentioned
    57 Post(s)
    Tagged
    0 Thread(s)
    Magento needs to know the javascript files and css files and their load order in order to collate them into one file each for production use. It takes less time to load one 60K javascript file than 6 10K ones. So that is the reason behind it.

  14. #39
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Well,then I'd still question it, though the question would become -- why not just wrap it in a PHP function?

    view->addJavascript('css/styles.css');
    view->addStylesheet('screen,projection,tv','screen.css');

    etc, etc...

    Again, just not grasping how and XML file or oddball meta-language is any better for that than just *SHOCK* using the actual language it's written in.

  15. #40
    Grumpy Minimalist
    Join Date
    Jul 2006
    Location
    Ontario, Canada
    Posts
    424
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    A lot of what is being discussed here is an anti-pattern with a name: the Inner Platform Effect. Unfortunately, it seems to be particularly popular in the PHP world. Essentially, it is using a platform, such as PHP, to build a poor replica of that platform, such as a PHP-based metaprogramming language.

    The appearance of the Inner Platform Effect often occurs when we fail to remember that Programming Sucks! Or At Least, It Ought To. A wonderful quote from that article that remains highly applicable today is:

    Quote Originally Posted by Michael A. Jackson, 1975, Principles of Program Design
    Programmers… often take refuge in an understandable, but disastrous, inclination towards complexity and ingenuity in their work. Forbidden to design anything larger than a program, they respond by making that program intricate enough to challenge their professional skill.
    Of course, this tendency is not the only reason for the emergence of the IPE. Oftentimes it is guided by an honest attempt to address legitimate concerns about the underlying platform.

  16. #41
    SitePoint Addict SirAdrian's Avatar
    Join Date
    Jul 2005
    Location
    Kelowna, BC
    Posts
    289
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It's very hard to read this thread and not to chime in... Quite the opinions floating around already!

    Michael, to respond to your OP, it comes down to this - which level of abstraction do you want to work in. The larger your codebase gets at the initial level of abstraction, the more you have to repeat yourself, and the more code you write (think of building a massive tower). Building up is not always good. There comes a point where it becomes more efficient and manageable to build more and more foundation to support the growth. The language you describe this in usually becomes more of your domain knowledge - or at least tied to the relevant domain / layer you're working at. Building blocks make sense in the context of Magento or layouts. It's English and readable. Defining routes as configuraiton makes a lot of sense, and is a lot more convenient and maintainable than writing the generated code manually.

    By creating another layer, in this case the meta programming - essentially configuration - you can replace a lot of the repetitive code with something much much more readable. This adds a lot of complexity to the library code, but it keeps your actual application simple to read which is the primary goal.

    Now, the other question - is it actually necessary. It depends... if you don't like it, then you should probably use a framework or tool that's not as configurable. These tools are meant to be highly configurable (configuration over convention). In the examples given, the resulting functionality is nothing alike.
    Code:
    $baseUrl . '/posts/?id=x
    vs
    Code:
    {{ _path('_posts_view', post) }}
    The latter is configurable. You can modify how routes are generated - you can even change the URLs entirely. You can apply SEO rewriting (if it wasn't done yet, etc.) Same for Javascript / CSS includes. Using assetic or similar tools is also massively different from not - you can automatically combine assets, apply filters (minification, obfusication, etc.) at (first-)run-time. You can easily append unique version identifiers and set your cache expiry years ahead of time and never worry about cache expiration woes. You can easily add more JS or CSS dynamically, and also apply these factors.

    All these functionalities are added or applied externally. This is the difference. It's not necessary most of the time, but when you work on larger projects, it's extremely beneficial. Symfony2 and Magento especialy are targetted towards people who want to configure or modify them quite extensively.

    Just my 2c.
    Adrian Schneider - Web Developer

  17. #42
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    vs...
    Code:
    makePath('post',$postNumber);
    Which is why these 'metalanguages' are just stupid... in most cases adding a complex parser on top of the language instead of just *SHOCK* using the existing language -- it's almost like people are afraid of functions and methods, and would rather have needlessly cryptic one letter variables and even more cryptic/nonsensical nesting of oddball characters.

  18. #43
    Non-Member
    Join Date
    Feb 2012
    Posts
    892
    Mentioned
    10 Post(s)
    Tagged
    0 Thread(s)
    The no-framework PHP MVC framework
    is a simple example of how you can use PHP as-is, without additional complex external layers, to apply an MVC approach with clean and simple views and still have all the goodness of fancy Web 2.0 features. If you think I am out to personally offend you and your favourite framework, then you have the wrong idea. I just happen find most of them too complex for my needs and this is a proposed alternative. If you have found a framework that works for you, great.

    Sounds familiar? http://toys.lerdorf.com/archives/38-...framework.html

    A little more research: http://negative11.com/

    It has already been taking care of, no need for another vanilla MVC. Not that some good frameworks out there forbid you to make the choice of also go vanilla on them, views, templates and the works. And it's not like it's been impossible to do if not: implements, extends. You know, OOP keywords. No, they just offer a choice for something else beside vanilla PHP. Which is good... because you have a choice now... as opposed to having but one choice... which is not so good.

    And I agree. PHP should be enough. No need for metalanguages like HTML or CSS. Enough! (HI: The author is being ironic)
    _____________________
    N.B. HI Humor impaired

  19. #44
    Non-Member
    Join Date
    Feb 2012
    Posts
    892
    Mentioned
    10 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Tarh View Post
    Essentially, it is using a platform, such as PHP, to build a poor replica of that platform, such as a PHP-based metaprogramming language.
    It should be called Inner Platform Repair. PHP is not perfect, it could be called itself a poor replica of another language or be looked at as a beast of two worlds, both qualities and flaws.

    FIX IT! (HI: SNL's Oscar Rogers FIX IT!)


    <hr>


    Quote Originally Posted by Tarh View Post
    The appearance of the Inner Platform Effect often occurs when we fail to remember that Programming Sucks! Or At Least, It Ought To.
    Programming doesn't have to suck, especially with high level languages, which are specifically designed for a larger audience than your medium level programmer; it's for low level, amateur programmers or even non-programmers.

    Which is not to say that using PHP makes for a low level programmer. Sometimes there is no other alternative for medium to high level programmers. Maybe that's why we see so many variants, because PHP is tackled by so many various individuals having various professional levels.

    _____________________
    N.B. HI Humor impaired

  20. #45
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    "no-framework"
    Code:
      <script type="text/javascript" src="/yui/YAHOO.js"></script>
      <script type="text/javascript" src="/yui/dom.js"></script>
      <script type="text/javascript" src="/yui/event.js"></script>
      <script type="text/javascript" src="/yui/connection.js"></script>
      <script type="text/javascript" src="/yui/animation.js"></script>
    Right...

    "model"
    Code:
    protected function fatal_error($msg) {
        echo "<pre>
    Right....

    "controller"
    Code:
      echo json_encode
    Right...

    Wow, that was good for a laugh.

  21. #46
    Non-Member
    Join Date
    Feb 2012
    Posts
    892
    Mentioned
    10 Post(s)
    Tagged
    0 Thread(s)
    I only brought it up because the author seems to have the same reasoning as the OP, and the same goal, that is teaching over functionality: it's in his toy page.

    He also means no-PHP framework and he is honest about what he uses:
    The main pieces are:

    PHP 5
    Yahoo! User Interface Library
    JSON
    being that he also engineered for Yahoo! at the time. And he is "Original author of the PHP scripting language".


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
  •