I agree, and your definition would seem to be at odds with every professionally written definition.
The example I linked to divides the code by responsibility. The domain logic is separated out, the presentation is separated out, and in the middle, the controller, translating input into operations.
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.
Yet. Websockets are on the horizon.
This:
Think of web dev. To me he’s proposing to use JS for presentation instead of the normal template meta language that is CSS.
[QUOTE=itmitică;5114448]This:
Think of web dev. To me he’s proposing to use JS for presentation instead of the normal template meta language that is CSS.[/QUOTE]
Then you’re imagining things, cause that’s about as far as what I intend as Pluto is from Mars.
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.
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.
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.
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…
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?
… 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!
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
$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.
… 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.
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.
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.
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.
Makes total sense.
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.
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!
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.
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.
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:
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.