--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send email to joomla-...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.
Cheers,
Victor Drover
Founder and CEO, Anything Digital
Co-founder, Watchful.li & jInbound.com
262-309-4140
Facebook: AnythingDigital | watchfulli | JInbound
Twitter: @VicDrover | @AnythingDig | @watchfulli | @JoomlaInbound
--
I fully agree with you, Michael. The current architecture is seriously outdated. What you're doing is really good. I have one question and one observation.Question: Are we still allowed to circumvent the renderer and provide our very own data representation, be it HTML or anything else (CSV, JSON, Office XML, bespoke XML, video, image, audio, something none of us can think of)? I am asking both for objective –what about all the data representations we can't think of– and selfish –I have a framework which outputs pre-rendered HTML, JSON and CSV– reasons.
Observation: While I agree 100% that JFactory is evil you could provide a bridge class in Joomla! 4, removed in Joomla! 5, to ease the transition pain. The main index.php will be creating a DI container, so why not set it by reference to a JFactory class which exposes its services? Calls to these old methods would produce a deprecated log entry. This would help convert legacy code. I'm speaking from experience. I understand it's a bit architecturally problematic, but it's the easiest way to tell developers to, let's say, go through the application object and get its container to grab the user object instead of going through JFactory. Mark the class as deprecated, put the new method in the docblocks, add the deprecated log message and there you go.
As long as we dont go the 1.5->1.6 route of ignoring the migration process completely and leaving that to 3rd parties I am all for progress.
--
--
You received this message because you are subscribed to a topic in the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/joomla-dev-cms/Zhkilq_uRNI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to joomla-dev-cm...@googlegroups.com.
--
--
--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send email to joomla-...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.
Alan Sparkes
Joomkit Ltd
Web Design, Branding,UX & Development
CMS Consulting
online: www.joomkit.com
contact: in...@joomkit.com
support: sup...@joomkit.com
phone: +44 (0)845 680 9513
mobile: +44 (0)7875189513
Company no :6682016
VAT no: 947906870
--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send email to joomla-...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to a topic in the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/joomla-dev-cms/Zhkilq_uRNI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to joomla-dev-cm...@googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send email to joomla-...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.5856 / Virus Database: 4315/9372 - Release Date: 03/24/15
You received this message because you are subscribed to a topic in the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/joomla-dev-cms/Zhkilq_uRNI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to joomla-dev-cm...@googlegroups.com.
I would encourage as many people as possible to put forward their experiments as Michael has done. We all know that a new architecture is needed so let's explore the boundaries of what can be achieved.Probably should start a new thread for that though.Before embarking on any radical change I think it is instructive to try to get a handle on what we're trying to achieve. What are the high-level goals? What characteristics of the current version are considered essential to maintain and what are the desirable characteristics that we're looking for in a new version? Why is the current version not delivering those characteristics?This will make it easier to explore different options because we will have an objective set of criteria against which each proposal can be measured.
Chris.
So I think the discussion in this thread is great, and I think it would also be great to start another discussion in another thread (as Chris suggested) about high level goals/objectives.
Thanks,
paul
--
--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
The most successful template providers for Joomla! have invested heavily in their own "frameworks" (which requires quotes as it has an array of meanings depending on the provider), and it's been happening for years. It's a very clear and real problem, especially for our end users, they shouldn't be forced to learn an entirely different administrative template interface just because they switched template providers. The marketplace has Gantry Joomla! templates, T3 Joomla! templates, etc. The CMS needs to provide an infrastructure that is conducive to simply just Joomla! templates without the qualifiers.
Standardizing output with Bootstrap 2 was one step in solving this epidemic, but that seemed to be more of a band-aid, than a remedy. Boil everything down, and the biggest goal of these "template frameworks" is about translating the logic of the template layer to site administrative users in an intuitive and efficient interface for management. In the end these are nothing more than a collection of form fields. Sure Joomla! provides a host of form field types that can easily be defined in a manifest file but they're extraordinarily rigid, and Joomla! makes a ton of assumptions of how the developer will use these. Joomla! making assumptions seems to be very common. As a result the lack of features (and the lack of documentation) ends in the community having n number of extensions, all who wrote a field type that essentially accomplishes the same goal.
HTML has a finite number of input types, each having a very specific set of possible data that could be available as options. Joomla! can and should provide extremely flexible form field types. Flexible to the point where it's more conducive for a developer to contribute back to the project than it is to layer yet another framework on top to achieve their goals. The only difference between a list of categories and a list of directories is the source of the data. Instead of writing two separate classes that extend JFormList why not allow the manifest to specify a source for the data (database, file, json/xml string, etc) and depending on the source type allow specific filtering parameters. As a practical example, say we want a field that adds a fontawesome icon in front of menu items. A really easy way to get all of the available options and provide them to the site administrator, in a way that doesn't require adding new option entries in the manifest file everytime fontawesome adds a new icon is to simply read their CSS file for a specific string pattern and return it to an array. Couldn't JFormField accept source type = 'file', location = '/path/to/file.css', pattern = 'expression' and preg_match giving the field an array of options? Instead of having a JFormFieldCategories and JFormFieldLanguages wouldn't it be great if we could just give it a type = 'model', component = 'categories', method = 'getList' or likewise for a list of Languages? (I likely could be wrong, but the best I can tell is this type of flexibility doesn't exist. At least not within documentation, and the fact that JFormCategories and JFormLanguages exist implies just that).