Accessible Joomla integration into core.

[ennsol]

As A8J is now up-to-date with 1.0.11 can anyone tell me why its not pulled into the core and then 1.0.12 is release fully accessible?

OK 1.5 is out there but a secure stablke and accessible CMS - on the existing branch - will take a fair while to be outmoded and (hopefuly - ducks the flying pig :-)) 1.5 accessibility may move by th time the 1.0.x branch reaches its 'best before' date.

There seems a real issue getting useful (if not essential) code pulled into the core if it has not be coded by one of the core devs - thought this was open source land here - am I on my own thinking such irreverent thoughts? From what I read, Linux seems to have a core team in 'qc/qa' mode so they can pull any code that is useful - judging by that success there seems mileage in adopting similar tactics and strategies for Joomla.  Ok end of heresy - any other heretics out there?
Regards
Mark

(Mod note: Moving this post to the Wishlist and Feature Request forum. - MMMedia)

[absalom]

Unfortunately, your comments about heretics may be right..

D&A has been pushing the core to get its act in order for a while now..

[studio814]

I also couldn't agree more.. to a point.

I understand why these accessibility modifications wouldn't be implemented into the 1.0 series due to compatibility with the large amount of templates and components that exist nowadays however with the upcoming 1.5 series there is now a chance to take accessibility and usability and integrate it into the Joomla core.

I can only hope that once 1.5 reaches beta that tables will NOT be used for layout purposes. As a serious supporter of accessibility and usability  standards and semantic markup, I feel without question that providing this into the Joomla core is not only a good idea but simply a MUST.

[MarkV]

I see it as a MUST as well. With so many user Joomla! can create such a big step forward.

[studio814]

Now that all the output in 1.5 is controlled via component/module templates this problem is starting to become less of a concern to me. Thanks Joomla!

[absalom]

Now that all the output in 1.5 is controlled via component/module templates this problem is starting to become less of a concern to me. Thanks Joomla!

It's still a problem. Suffice to say, that even with the MVC model currently deployed in 1.5, "hacks" and "accessibility patches" will still be needed.

Let me illustrate this to you..

1 ) You download 1.5 Stable (whenever that release is)
2 ) You don't like one of the views in the way it creates output, so you modify that view
3 ) A maintainence release comes out - 1.5.0.1.
4 ) You yet again have to modify the same view the same way
5 ) Another maintainence release comes out - 1.5.0.2
6 ) You again modify the view
7 ) A major release is then released - 1.5.1.0
8 ) Guess what ? Again you have to modify the view..

Starting to feel irritated by the amount of times you have to modify the view ?

(Considering I've been doing this very thing via SVN for each iterative release of 1.5, you can see where the version control headache is)

Edit: typos

[eyezberg]

If there is no functionality change (1.5 stable), then just keep your view, it wouldn't be overwriten by maintainance releases..?

[absalom]

If there is no functionality change (1.5 stable), then just keep your view, it wouldn't be overwriten by maintainance releases..?

Nope. The MVC structures I've been tracking do have some level of CMP depedence, unfortunately, so they are open to having changes in the model affect the overall view. It also doesn't solve the problem of making all parts of J! accessible, which is one of the stated aims per the Joomla Mission Statement regarding D&A/U&A.

[Hackwar]

And thats again where you are wrong. The views are placed in the template folder and wouldn't be touched by any updates. Since an update to a view would mean that there was an error in it, you most likely would have worked around the error and allready fixed it in your modified view or you would have to edit it anyway. Either way, your view in the template folder is still the one thats chosen.

[absalom]

And thats again where you are wrong. The views are placed in the template folder and wouldn't be touched by any updates. Since an update to a view would mean that there was an error in it, you most likely would have worked around the error and allready fixed it in your modified view or you would have to edit it anyway. Either way, your view in the template folder is still the one thats chosen.

Please see this post: http://forum.joomla.org/index.php/topic ... 2.html#new for why it still doesn't work..

[pollen8]

2 ) You don't like one of the views in the way it creates output, so you modify that view
3 ) A maintainence release comes out - 1.5.0.1.
4 ) You yet again have to modify the same view the same way

hehe this *shoudn't* happen - the controller should pass the complete model to the view to render. Display logic for the model would then show what it wanted.

*However*. this most certainly has *not* been the case in the 1.0.x series. In using html.php files in my templates, I've been stung a number of times when a security update has changed the variables passed to the display function. This is really annoying!

I do like the idea of overriding views from within the template but Q&A need to ensure that the interface between the controller and the view remains the same.

Possibly the easiest way to do this is to pass a $params object or a $list which the controller can then add extra info to without chaning the interface

[absalom]

*However*. this most certainly has *not* been the case in the 1.0.x series. In using html.php files in my templates, I've been stung a number of times when a security update has changed the variables passed to the display function. This is really annoying!

Now you understand why we need a better design for 1.5.

I do like the idea of overriding views from within the template but Q&A need to ensure that the interface between the controller and the view remains the same.

Possibly the easiest way to do this is to pass a $params object or a $list which the controller can then add extra info to without chaning the interface

From where I stand, it's not overriding the views as such (there are serious limitations on the override hack for third party development, for instance). It's just getting a template engine that works and meets the needs of what D&A has built up as a collective knowledgebase. Initial scope put that at pT but there's a swag more PHP based templating engines out there. Sooner or later, we should find something that works..