Well I'm going on past conversations (some we had on other sites) in regards to MVCR output.
If I misubderstood then (possible...) then please accept my apology!
In those conversations you were upset that all output wasn't forced through a WCAG 2.0 output layer incuded in the core.
At the time you wanted J! Devs to make a WCAG2.0 output layer (using PatTemps or some other system) that all 3PDs would be forced to use.
Your main concern was that the 3PDs were not being forced to use Joomla standard output and that they were themselves creating the output section of their project to be added to the J! output system.
OK. You've seriously misunderstood. If you've misunderstood, that probably means the Core has misunderstood as well, and they've banned people for their own misunderstanding over this.
My main concern has been (for the last year or so) that there isn't a ubiquitous semantic structure between / through components, modules and plugins. This is due to the Core saying semantic and data structures remain CMP-locked and following that mentality to the letter. You can't share data between bits of the CMS. You can't remix or mashup componentry on the fly. You likewise have to reinvent the wheel by replicating the same code over and over again. And then there's the whole semantic issue.
All components (com_content, com_weblinks, com_ whatever) should have the ability to have the same heading / content structures styled in the same way, by using a WORM solution that creates the semantic model for them and they then all
gain the same benefits. It is, after all, a content management system, and really all components do is output differing forms of data into some content structure (this applies to CMS design in general as well). This philosophy again appears foreign to the Core mentality because they want to pass the buck for accessibility and semantic well-formedness (i.e output) for their work to 3PDs through stuff like the override hack.
In no way does this imply 3PDs would be forced to follow the Core coding through a semantic library, but simply means 3PDs, if they choose to, can gain the same semantic benefits that could be envisioned for core code, if they followed the same templating schema. It's based on an ease of use buy-in. By making it easier for core and 3PD work to both
be accessible, extensible and semantically well formed at the same time, it means people can then think more about the quality and direction of their work as the problem would be solved "silently" for them.
I believe your concern then was (rightful concern I might add) is that the 3PD if given the keys to creating their own output would allow the inexperienced 3PDs to make non WCAG compliant code.
They do already. In no way would this stop as people can and do construct bad CMPs that interface to the CMS.
All I would really be doing is providing an alternative path for them to leverage the same templating schema that would have been "core" so that they gain the same semantic benefits / accessibility structures as the "core". In this way, core and 3PD work then start being a unified strategy, instead of the Core treating 3PD work like it was some black sheep or child born out of wedlock. See, at the end of the day, both
core and 3PD work need to follow the same structures and guidelines to get the same benefits, and the really simple way of delivering it to both
of them is via a templating schema.
but No matter which way you lean on that score, the task to add that extensability and flexability into a complex system like Joomla is a very large nut to crack!
Let's just say we're a lot closer to cracking that nut that we were 3 years ago, when this problem was first identified.
Think of the work involved. It is much more than just rewriting the output layer and making it extensible. an entire output configuration system must be built so that you can assign different content items (and extentions) to the customized extensible layer! IT's not about just extending how you output, it also must extend the backend so you can edit, configure, assign content to a particular output routine and then save all that info in the database!
You're approaching this from the wrong direction, at least from where I stand. You don't rewrite the output layer (at the end of the process). You fundamentally rethink the way CMPs are designed from the ground up - which is why I became more vocal the closer we got to feature lock-in of 1.5 Beta. See, with 1.5, we had the opportunity to rewrite CMP structures to be device agnostic (
remixing or mashups). That didn't happen. We likewise had an opportunity to make the semantic layer across all core CMPs to based on a templating schema. That didn't happen either. CMPs have been rewritten for 1.5, yes, but not to the extent that was needed to give these benefits to the wider community.
That means, at least from what I can ascertain from Core "policy" and discussion, that these sorts of things are 24 to 36 months away now with J! 2.0, even though the ideas have been floating around J! since it's inception (thanks to Vav and others).
On top of all that it should also have a system that will allow users to download and install entire output stylings for use in their site. Me and you can probably rewrite the routines for accessability, But many users of J! are not proficient in PHP and accessability and can not easily use a system like this unless it is made particularly user friendly!
I've thought through this and I have some ideas on how to solve it, thanks in part to my discussions with Jeffrey Veen a few years ago.
What we both want is in essence an entire framework unto itself built to focus on output and extensability of output.
Correct. In no way does that mean it has to be WCAG 2.0. I forsee there would be a time when your site admin negotiates with a reputable accessibility consultant as to what your site needs (WCAG, ATAG, 508, etc..) and to deliver that semantic model, all they do is implement something according to a predefined template schema.
It can not just be ADDED to 1.5 since in all likelyhood it will totally break many extentions and sites who simply want to upgrade to the new framework. J! 1.5 is a transitional release. It's not really a ADD FEATURES release (although some new features are present.) It is being made to remove past limitations of the legacy code so that all of these features we want can be built in.
My point was.. if you're going to do a decent point release, you may as well do it now. This was the philosophy that existed in the U&A team when Vav was guiding it (with the potential 1.1 and 1.2 roadmaps for accessibility). Since the window has now closed, we are looking 2 to 3 (maybe even 4) years from now before anything even gets recognised as valuable in terms of J! core principles. What makes it even worse is that the core has said post-1.5 the roadmap is undefined.
The Devs made a thoughtful decision and decided, if we can't take our time and do this system right for release in 1.5 then lets spend all of our time on the main J! 1.5 framework building it with these sorts of future features in mind. they concentrated in the foundational infrastructure needed to complete such a complex task like output extensability for J1.5 and worked instead on making a system that would bring leagacy users along to the new system with the least amount of hardship.
The problem, from where I stand, is that it hasn't been built with these sort of future features in mind, since we're still at CMP-dependency, even with the template overrides.
Will it take another 3 years before CMP dependency gets phased out ?
Customized output is important but it can wait until 2.0. It's not as important as making the transition to the new framework as easy and as backwards compatible as it can be.
Because if no one upgrades to the new framework then there won't be a Joomla 2.0 just a joomla 1.0.20!
No one will use the newer more advanced framework that will allow all these things we both want done!
Ah, you're still not thinking about the buy-in principles. If it's easier for a developer to code to some templating schema that does the heavy lifting for them than to hand craft, duplicate and replicate an existing structure of a CMP (in the current form), which path do you think they'd choose ?
1.5 was already "advanced", anyway. So what's stopping it from becoming more advanced now ? Two things, from where I stand:
- Beta equals feature lock down
- Core development is not committed in any way to device agnosticism of any form (CMP / semantics / whatever)