Hi all,
We're post Joomla 3.1's launch now, so it's time to get moving on the Rapid Application Development (RAD) Layer Working Group. This is an open invite to all extension developers, as well as other interested individuals, for starting the working group for RAD. If you are interested, please let us know and let's get this going.
The goal of the group is to develop a RAD layer within the core to speed up development and prevent duplication of code (DRY) when creating extensions.
Depending on how it's implemented, it might optionally be backported to 2.5 to allow extension developers to use one package for both Joomla 2.5 and Joomla 3.x. The code deadline for an alpha version is temporarily set for July of 2013 to allow at least one month of testing etc. before the Joomla 3.2 feature deadline, which is scheduled for August of 2013.
Let us know if you have any questions and we’ll be glad to answer.
--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-gene...@googlegroups.com.
To post to this group, send an email to joomla-de...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-general?hl=en-GB.
For more options, visit https://groups.google.com/groups/opt_out.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-general+unsub...@googlegroups.com.
+1 for PHP 5.3+ support. I am seeing fewer and fewer hosts using it, and most that still do, also offer 5.3 as an option.
Best,
Matt Thomas Founder betweenbrain™ Lead Developer Construct Template Development Framework Phone: 203.632.9322 Twitter: @betweenbrain Github: https://github.com/betweenbrain
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-gene...@googlegroups.com.
I totally agree with Michael and would also suggest PHP 5.3+. We want to keep forward and I don't think it's a good idea to create a new framework with old PHP 5.2.I don't want to put oil on the fire, but isn't RAD what FOF already is? Why would we reinvent (a good round) wheel?
Hi all,
It looks like Nicholas is trying to post to this thread regarding FoF, but is being moderated by Google.
Best,
Matt Thomas Founder betweenbrain™ Lead Developer Construct Template Development Framework Phone: 203.632.9322 Twitter: @betweenbrain Github: https://github.com/betweenbrain
--
Hello all,I know that I'm probably going to regret this. I know that I'm doing this against my better judgement. What happened in February is still very fresh in my memory. "Oh, well, what the hell" (those who have read Catch-22 will get the reference). I would like to resubmit FOF for consideration.Let me clarify. I honestly do not care which solution will end up inside the Joomla! CMS. It is completely indifferent to me if it's going to be FOF or something entirely different. The reason I am resubmitting FOF for consideration is time. What I mean is that you have a little less than two months to create an entire RAD framework from scratch. For such a framework to be successful, you need to ensure that it addresses the needs of developers today and in the future. This would require a long discussion which would leave no time for the actual code to be written. Let alone documentation to be written on top of this. As a result, unless an existing solution is used – not necessarily mine – the project is doomed due to an unreasonable deadline.Moreover, now that Chris' Kickstarter campaign has failed he's probably not going to work on web services. It's a shame but probably I have a solution, in FOF. I say "probably" because even though I replied to Chris' enquiry email to yours truly regarding FOF and web services at 2 a.m. on a weekday and despite him acknowledging the receipt of my reply he never got back to me as promised. No hard feelings, but I just don't know if what I am "selling" here as "almost REST-full – but not quite – web services" is what Chris had in mind or not. It doesn't help that the results of the web services working group are nowhere to be found (at least without knowing a direct URL which, if someone has, I would be grateful if they could pass along). In any case, if something's lacking in the area of web services I am willing to put my own time and my money (as in: my developers' paid time) into the effort to provide a good solution for web services in FOF. If anyone wants to help, great, but it's not a pre-requisite. I'm not soliciting for money or code, just ideas.Further clarification on the reason of my contribution as I do NOT intend to make myself trollbait this time around. I do not pretend I am the One, a code prophet or that my code is the best thing since sliced bread. If that kind of code is our goal let's wrap it up, throw everything in the rubbish bin and go with Symfony, Zend Framework or something like that. Yep, that's what I thought. Anyway. There are too many people with a superiority complex. I ain't one of 'em (or, at least, try not to be). In all honesty, I believe that my code is utter crap, but it works. Just like any code ever written by pretty much every developer. Look. We are in the business of using string and duct tape to hold things together. Not to mention that you can never find two developers who agree which is the correct way to do the same thing. As a result, all of our code is crap to the eyes of pretty much all other developers. Now that we're past the debunking of our self-delusion let's analyze the practical issues and areas of the framework that need to be worked on. These are the issues that were cited in February and which led to me withdrawing my contribution. Three months later and with more code reading I consider these reasons to be utter cow manure, for the simple reason that Joomla! itself (even the Joomla! Platform, written by those who were complaining) doesn't provide a solution to said issues. Let me elaborate.For starters, we have unit tests. Or, should I say that we have no unit tests. It's not that I didn't try. I did take the time to try to understand what needs to be done. It seems that what is testable is only a few individual methods in the base classes which neither guarantee that the framework works nor do they ever change. In other words, I could do the same sort of unit tests the Joomla! CMS does. For all the crappy code I write, I do not wish to write crappy unit tests. I'd rather not have any unit tests that have something which is a bad joke. I have been promised by two different people to receive help on writing proper unit tests but neither ever stepped up to the challenge. On the contrary, two other people tried, but couldn't quite get it. I gave it a shot myself. Dead end. So, before you accuse me that I am an idiot who doesn't know how to write unit tests please provide working unit tests for the MVC classes. As far as I can see, in order to test them we would need to have two sample components installed on a functional Joomla! website and use system tests, like selenium, to test the actual framework. Of course, this has a major drawback. We would actually be testing the Joomla! CMS, the two test components and, incidentally, the framework itself. What did you say are we supposed to be testing? Right-o. Let me say this again. If you have a solution to the testing problem, please share it! If you don't, I'll just say this: let him that is without sin among you first cast the stone.The other known issue is the use of JObject. Oh, the cursed JObject! While it can be removed from most classes, it cannot be removed from the table class (I guess? JTable still uses it in 3.1.1; thing about sinners and stones applies here as well). That are two reasons for this. The first reason is that we are using the getProperties method to get a list of the fields without having to do on more database request. This could be improved, of course. The other reason is that the check method is using the error messages stack. Some of you would argue that we would better use exceptions. I disagree. I found it extremely useful to sanitize and fill in missing data in all fields before throwing the actual error. This way, when the user returns to an edit page the data on screen makes more sense. Probably the error message stack could be imploded inside the table class and finally remove this requirement. As far as the models are concerned, using exception sexily makes more sense than using the error message stack.Another issue brought up three months ago was the lack of proper developer documentation. Note that the Joomla! project actually provides any of that, but I digress. Since third-party submissions have to leave up to higher standards than the core code itself – arguably, this is a good idea as the core is extremely lacking – I did take the time to start writing this documentation. It is written in DocBook XML format and not complete, yet. By July it's going to be ready. Probably much earlier than that. In full. Published on my site as HTML, PDF and if you want me to as ePub and what have you. All the stuff that Joomla! itself does not provide but third party contributors are expected to have. And, no, the Joomla! wiki doesn't count. Last time you-know-who was complaining that all I have to offer is a wiki which is not proper documentation. Based on the same logic, Joomla! itself doesn't provide proper documentation but FOF now does. If you decide to not use FOF and write your own you MUST provide the same kind of documentation, otherwise the project should be scrapped – if you want to apply arbitrary rules, apply them equally to every contribution no matter where it's coming from.So, here we are. The offer is back on the table. If you have a question of substance I will be delighted to answer it. If you start denigrating the contribution attempt based on cheap excuses about missing stuff that even the core code doesn't have or arbitrary rules that apply only to me and not, say, on com_tags (solely used as an example, I have nothing against Elin) then I'm outta here. I don't intend to be treated like rubbish and reach the point of nearly having a stroke like back in February. I've had enough of that crap. If you want to discuss this seriously, I'm here to discuss seriously. If you complain about something and the CMS itself suffers from it, please read the earlier comment about sinners and stones. Thank you in advance.PS: My contribution is free of charge. I put my code, time and money exactly where my mouth is. I make my money selling download and support access tomy Joomla! extensions. Like you all, I make money by using Joomla!. So what more reasonable than wanting to give back my time and code back to Joomla!, as a "thank you" gesture. It's as simple as that.PS2: FOF 2.x only runs on PHP 5.3. It uses LSB to provide backwards-compatibility static access to FOFInput (already deprecated) and __DIR__ instead of basename(__FILE__) in several places. If the former is obsoleted and the latter is rolled back then it can run just fine under PHP 5.2. Not that I am thrilled on this prospect. PHP 5.2 is long dead, we shouldn't encourage people using it. Some of them might actually follow our advice and then we are responsible for pushing them over the edge of the cliff.
Also, I want to make it clear, I'm no licensing expert. The changes to the code, license and copyright in FOF may be perfectly acceptable and no one has done any wrong. It was just my interpretation of those facts and the lack of time that made it not very appealing to help with unit tests anymore.Sorry Nic if my previous post caused any extra stress. That's not what was meant by it. I know from our previous conversations that we're both pretty reasonable people, and you have a ton more experience with these things than I do. So, please, help me to understand if I have misunderstood.
I believe the licensing issue has been resolved. And obviously we don't want large amounts of duplicate code anywhere so that part will need to be looked at and addressed through the process.Don, I know you only mean to bring up things for the success of Joomla and I appreciate your insights greatly, thank you for the follow-up post to clarify that. :)
-Thanks,
David Hurley
Joomla! Community Development Manager
On Thu, May 9, 2013 at 11:59 AM, Donald Gilbert <dilber...@gmail.com> wrote:
Also, I want to make it clear, I'm no licensing expert. The changes to the code, license and copyright in FOF may be perfectly acceptable and no one has done any wrong. It was just my interpretation of those facts and the lack of time that made it not very appealing to help with unit tests anymore.Sorry Nic if my previous post caused any extra stress. That's not what was meant by it. I know from our previous conversations that we're both pretty reasonable people, and you have a ton more experience with these things than I do. So, please, help me to understand if I have misunderstood.
--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-general+unsub...@googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-gene...@googlegroups.com.
--
--
We will be centralizing development for RAD here:We'll also be using the Issues within GitHub to handle bugs, feature updates, and other discussion topics.Send your PR's ;)
As you already know Nicholas, i'm 100% positive in getting FOF into Joomla.I'm also volunteering for making this integration possible and help in any way i can
Il giorno giovedì 9 maggio 2013 12:01:29 UTC+2, Nicholas Dionysopoulos ha scritto:Hello all,I know that I'm probably going to regret this. I know that I'm doing this against my better judgement. What happened in February is still very fresh in my memory. "Oh, well, what the hell" (those who have read Catch-22 will get the reference). I would like to resubmit FOF for consideration.Let me clarify. I honestly do not care which solution will end up inside the Joomla! CMS. It is completely indifferent to me if it's going to be FOF or something entirely different. The reason I am resubmitting FOF for consideration is time. What I mean is that you have a little less than two months to create an entire RAD framework from scratch. For such a framework to be successful, you need to ensure that it addresses the needs of developers today and in the future. This would require a long discussion which would leave no time for the actual code to be written. Let alone documentation to be written on top of this. As a result, unless an existing solution is used – not necessarily mine – the project is doomed due to an unreasonable deadline.Moreover, now that Chris' Kickstarter campaign has failed he's probably not going to work on web services. It's a shame but probably I have a solution, in FOF. I say "probably" because even though I replied to Chris' enquiry email to yours truly regarding FOF and web services at 2 a.m. on a weekday and despite him acknowledging the receipt of my reply he never got back to me as promised. No hard feelings, but I just don't know if what I am "selling" here as "almost REST-full – but not quite – web services" is what Chris had in mind or not. It doesn't help that the results of the web services working group are nowhere to be found (at least without knowing a direct URL which, if someone has, I would be grateful if they could pass along). In any case, if something's lacking in the area of web services I am willing to put my own time and my money (as in: my developers' paid time) into the effort to provide a good solution for web services in FOF. If anyone wants to help, great, but it's not a pre-requisite. I'm not soliciting for money or code, just ideas.Further clarification on the reason of my contribution as I do NOT intend to make myself trollbait this time around. I do not pretend I am the One, a code prophet or that my code is the best thing since sliced bread. If that kind of code is our goal let's wrap it up, throw everything in the rubbish bin and go with Symfony, Zend Framework or something like that. Yep, that's what I thought. Anyway. There are too many people with a superiority complex. I ain't one of 'em (or, at least, try not to be). In all honesty, I believe that my code is utter crap, but it works. Just like any code ever written by pretty much every developer. Look. We are in the business of using string and duct tape to hold things together. Not to mention that you can never find two developers who agree which is the correct way to do the same thing. As a result, all of our code is crap to the eyes of pretty much all other developers. Now that we're past the debunking of our self-delusion let's analyze the practical issues and areas of the framework that need to be worked on. These are the issues that were cited in February and which led to me withdrawing my contribution. Three months later and with more code reading I consider these reasons to be utter cow manure, for the simple reason that Joomla! itself (even the Joomla! Platform, written by those who were complaining) doesn't provide a solution to said issues. Let me elaborate.For starters, we have unit tests. Or, should I say that we have no unit tests. It's not that I didn't try. I did take the time to try to understand what needs to be done. It seems that what is testable is only a few individual methods in the base classes which neither guarantee that the framework works nor do they ever change. In other words, I could do the same sort of unit tests the Joomla! CMS does. For all the crappy code I write, I do not wish to write crappy unit tests. I'd rather not have any unit tests that have something which is a bad joke. I have been promised by two different people to receive help on writing proper unit tests but neither ever stepped up to the challenge. On the contrary, two other people tried, but couldn't quite get it. I gave it a shot myself. Dead end. So, before you accuse me that I am an idiot who doesn't know how to write unit tests please provide working unit tests for the MVC classes. As far as I can see, in order to test them we would need to have two sample components installed on a functional Joomla! website and use system tests, like selenium, to test the actual framework. Of course, this has a major drawback. We would actually be testing the Joomla! CMS, the two test components and, incidentally, the framework itself. What did you say are we supposed to be testing? Right-o. Let me say this again. If you have a solution to the testing problem, please share it! If you don't, I'll just say this: let him that is without sin among you first cast the stone.The other known issue is the use of JObject. Oh, the cursed JObject! While it can be removed from most classes, it cannot be removed from the table class (I guess? JTable still uses it in 3.1.1; thing about sinners and stones applies here as well). That are two reasons for this. The first reason is that we are using the getProperties method to get a list of the fields without having to do on more database request. This could be improved, of course. The other reason is that the check method is using the error messages stack. Some of you would argue that we would better use exceptions. I disagree. I found it extremely useful to sanitize and fill in missing data in all fields before throwing the actual error. This way, when the user returns to an edit page the data on screen makes more sense. Probably the error message stack could be imploded inside the table class and finally remove this requirement. As far as the models are concerned, using exception sexily makes more sense than using the error message stack.Another issue brought up three months ago was the lack of proper developer documentation. Note that the Joomla! project actually provides any of that, but I digress. Since third-party submissions have to leave up to higher standards than the core code itself – arguably, this is a good idea as the core is extremely lacking – I did take the time to start writing this documentation. It is written in DocBook XML format and not complete, yet. By July it's going to be ready. Probably much earlier than that. In full. Published on my site as HTML, PDF and if you want me to as ePub and what have you. All the stuff that Joomla! itself does not provide but third party contributors are expected to have. And, no, the Joomla! wiki doesn't count. Last time you-know-who was complaining that all I have to offer is a wiki which is not proper documentation. Based on the same logic, Joomla! itself doesn't provide proper documentation but FOF now does. If you decide to not use FOF and write your own you MUST provide the same kind of documentation, otherwise the project should be scrapped – if you want to apply arbitrary rules, apply them equally to every contribution no matter where it's coming from.So, here we are. The offer is back on the table. If you have a question of substance I will be delighted to answer it. If you start denigrating the contribution attempt based on cheap excuses about missing stuff that even the core code doesn't have or arbitrary rules that apply only to me and not, say, on com_tags (solely used as an example, I have nothing against Elin) then I'm outta here. I don't intend to be treated like rubbish and reach the point of nearly having a stroke like back in February. I've had enough of that crap. If you want to discuss this seriously, I'm here to discuss seriously. If you complain about something and the CMS itself suffers from it, please read the earlier comment about sinners and stones. Thank you in advance.PS: My contribution is free of charge. I put my code, time and money exactly where my mouth is. I make my money selling download and support access tomy Joomla! extensions. Like you all, I make money by using Joomla!. So what more reasonable than wanting to give back my time and code back to Joomla!, as a "thank you" gesture. It's as simple as that.PS2: FOF 2.x only runs on PHP 5.3. It uses LSB to provide backwards-compatibility static access to FOFInput (already deprecated) and __DIR__ instead of basename(__FILE__) in several places. If the former is obsoleted and the latter is rolled back then it can run just fine under PHP 5.2. Not that I am thrilled on this prospect. PHP 5.2 is long dead, we shouldn't encourage people using it. Some of them might actually follow our advice and then we are responsible for pushing them over the edge of the cliff.
--
Moreover, now that Chris' Kickstarter campaign has failed he's probably not going to work on web services. It's a shame but probably I have a solution, in FOF. I say "probably" because even though I replied to Chris' enquiry email to yours truly regarding FOF and web services at 2 a.m. on a weekday and despite him acknowledging the receipt of my reply he never got back to me as promised. No hard feelings, but I just don't know if what I am "selling" here as "almost REST-full – but not quite – web services" is what Chris had in mind or not. It doesn't help that the results of the web services working group are nowhere to be found (at least without knowing a direct URL which, if someone has, I would be grateful if they could pass along). In any case, if something's lacking in the area of web services I am willing to put my own time and my money (as in: my developers' paid time) into the effort to provide a good solution for web services in FOF. If anyone wants to help, great, but it's not a pre-requisite. I'm not soliciting for money or code, just ideas.
Depending on how it's implemented, it might optionally be backported to 2.5 to allow extension developers to use one package for both Joomla 2.5 and Joomla 3.x. The code deadline for an alpha version is temporarily set for July of 2013 to allow at least one month of testing etc. before the Joomla 3.2 feature deadline, which is scheduled for August of 2013.
As we take a proactive approach to each of our working groups, we are providing a separate branch in our GitHub repository to allow for a unified development area. You can find the RAD branch here: http://github.com/joomla/joomla-cms/tree/feature-rad. We encourage those interested in working on this feature to fork this branch to their own repository as a starting point.There is also a Skype chat available - if interested in being added please send me or someone in the PLT a message. (My Skype: davidbhurley)
--
Hi all,To throw in my 50 cents: It seems this thread started with a call for braindumps by David, but was then changed a bit by Nics post on the possible usage of FoF-code, and especially remarks about the licensing changed the thread-topic a bit too too much. So to get back to the main point of David: How to move forward?
I would say that the point of FoF already being available is a very valid point. If there is good code available, why not use it? - especially if we want to move forward with Joomla! as quickly as possible. But I would say I'm against just including the FoF-framework to the Joomla! framwork: Not because of copyrights, but because the mindset of Nic is a bit different than the mindset of the J coreteam. (If the mindsets would be the same, we would have almost identical code anyway.)An approach could be just to setup some basic Joomla!-classes, copy the code of FoF to it, and see how it fits in the Joomla!-core the best. So a class FOFViewCsv would get copied to JViewCsv; its calls for FOFInput would be replaced with JFactory::getApplication()->input, and so on. It is for sure more work, but it could result in code that could be embraced by all Joomla! developers - including those who do not favor FoF (I have yet to meet such a developer, kudos to Nic).Note that my mouth is full of crap: I have at this moment too little time to volunteer.
--
The second item which I believe can be handled at the same time is the organization of Milestones and associated tasks to be assigned and completed. The first milestone is easy:Milestone 1: Define goals and objectives to be accomplished with a RAD layer
Hello Andrew,Why not go the other way around?
If you already have a RAD layer which supports web services and it only needs to be taken to the last mile to comply with the vision of the Web Services WG, why not back it up? Is it really better to wait one working group to write code from scratch and then have another working group figure out if it does make sense for their area or, if it doesn't, have the re-invent the wheel?
I mean take a look at the current state of MVC in Joomla!. It's MVC with a bandaid for ACL, with a bandaid for JForm, with a bandaid for backend management, with a bandaid for tags, with a bandaid for UCM. Is our goal, as a project, to have a facade of cardboard, string and duct-tape or do we want to build something solid?
It depends on what problem you are trying to solve. I think we can do better than "I want to build a better Joomla component".
If the view doesn't care about where it's data comes from, that is a good thing.
Do you even want the View to be written in PHP at all ... that's an equally good question that deserves and answer.
I think it's about making the "best" wheel for today's internet technologies.
I mean take a look at the current state of MVC in Joomla!. It's MVC with a bandaid for ACL, with a bandaid for JForm, with a bandaid for backend management, with a bandaid for tags, with a bandaid for UCM. Is our goal, as a project, to have a facade of cardboard, string and duct-tape or do we want to build something solid?The current code is what it is. Who really care how bad or good anyone thinks it is. We all agree that it isn't the best we can do. Let's not waste time. It just a suggestion. You don't have to like it and it shouldn't stop people thinking that way if that's the way they choose to analyse the problem. I'm not stopping you from preaching the we should just use FoF :P
Just to be clear, I don't care if Clint's final code doesn't include any of FOF's own code.
If I can use something written by someone else I can focus back on what puts food on the table. FOF doesn't, sadly. It's one thing having a "good enough" framework for your own components (makes money and saves time) and a totally different kettle of fish writing a framework apt for everyone's use case (bleeds money and time, profusely). I think you know how that goes.
--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-general+unsub...@googlegroups.com.
To post to this group, send an email to joomla-dev-general@googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-gene...@googlegroups.com.
To post to this group, send an email to joomla-de...@googlegroups.com.
@Donald:
@Donald:
--
@Radek, I've talked about zoological nutrition matters?Yes I do have something positive to say. I'm positive you have no idea what my goals and motivations are.—
Sent from Mailbox for iPhone
On Sat, May 11, 2013 at 2:52 PM, Radek Suski <suski...@gmail.com> wrote:
I know that I'm most likely putting my hand in the fire but if you analise the whole thread, you have so far:
- Tried (poorly) to explain why you promised help and you didn't
- Accused Nicholas of a plagiarism and license violation
- Withdrawn your accusation about the license violation (I'm no licensing expert)
- Talked about zoological-nutrition matters
- Critised the idea about including it in 3.2
- Talked about building something from scratch to met non-existent requirements
I just wondering if you have anything constructive to say in this thread?
--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-general+unsub...@googlegroups.com.
--
You received this message because you are subscribed to a topic in the Google Groups "Joomla! General Development" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/joomla-dev-general/YdpXTpGO65k/unsubscribe?hl=en-GB.
To unsubscribe from this group and all of its topics, send an email to joomla-dev-gene...@googlegroups.com.
Hi Don,
As far as I'm aware, no one is forcing anything into 3.2, so your
assumption is false.
I don't agree with your assessment of Tags. Your assessment appears to be
on the basis of ignorance and not understanding why things were done. You
should instead ask "why" rather than coming into a discussion throwing
flaming arrows.
I know that I'm most likely putting my hand in the fire but if you analise the whole thread, you have so far:
- Tried (poorly) to explain why you promised help and you didn't
- Accused Nicholas of a plagiarism and license violation
- Withdrawn your accusation about the license violation (I'm no licensing expert)
- Talked about zoological-nutrition matters
- Critised the idea about including it in 3.2
- Talked about building something from scratch to met non-existent requirements
I just wondering if you have anything constructive to say in this thread?
And yes, I'm for Joomla being mainly for people that are our regular user base and not creating a kind of an enterprise framework.
As much as I can understand the excitement about creating huge framework which can be used by big companies,it is not what we as Joomla should consider as the main goal.
I know that this is a point which I'm standing for and it is permanently ignored but I just won't change main point of view without valid argument and these weren't presented so far.
If I may...Some folks are focused on CMS version support and pushing it into the CMS for a specified version (the most common mentioned being 3.2). I think we're making a huge mistake even considering putting it into the CMS and it is best left as a standalone library distributed separately. I know a lot of folks are going to argue about why we'd even build a RAD if it weren't in the core distribution, and for the answers to that, I point to the simple installer method recommended by Nicholas for FOF. Simply put, its only installed or updated if necessary, and because of how B/C is handled, I don't have to worry if NoNumber extensions use FOF and put a newer version of the library on a site that I haven't tested with my code. If RAD is included in the distro, quite frankly, we've only added yet another problem to our development structure. Has anyone tried using JHttp consistently between 2.5 and 3.x (by the way, that only got into the CMS at 2.5)? I'll give you a hint, short of forking it, good luck with that.
Andrew, two objections to your bitter post:
1. "this conversation is only for developers that use Joomla in a particular way" This thread is for developers who use the Joomla! CMS to provide software to Joomla! CMS users. It's not for developers using the Joomla! Platform or Framework to write applications from the ground up. That's why the working group is about adding a RAD layer to the Joomla! CMS. So, yes, it is for people using Joomla! in a particular way. That's part of this thread's kickoff post.
2. "you want all the things wrong with Joomla solve without changing anything". I beg your pardon? If by "without changing anything" you meant to say "change everything that doesn't make sense in the RAD layer but do not axe the existing MVC solutions so that BC is not broken and developers don't go running up the hills" then, yes, that's what I personally believe in. But I'm not the only developer participating in this discussion. Maybe the consensus will be different.
It's OK if you want to follow a different approach to solve the same problems. As I said, it's a good thing that the Framework forked off the Platform. Nothing precludes having multiple competing solutions to the same problem under the Joomla! brand. After all, in Joomla! CMS 3.1 you will find the legacy MVC, the 1.6/1.7/2.5/3.x MVC and the "new MVC" (which is now maintained in the Framework). Three ways to solve the same problem. We're going for number 4. You want to go for number 5. I don't see any problem with that.
I refuse to be dragged to this gutter.
Back on topic. As I said over and over again, it's all right if you do not blindly agree with everyone else and everyone else doesn't blindly agree with you.
I don't believe in One True Solution for any given problem or that anyone –me, you, or anyone else– possesses the divine power to come up with one.
It's abundantly clear that you want to pursue a completely different solution than what other participants of this thread are willing to discuss (note that we have not reached an agreement).
We want to pursue a RAD layer which works today, for reasons you don't agree with.
You have other goals.
We can respect that, but it doesn't align with our current interests. Be respectful and accept this. But do pursue your approach, present your code when it's ready and maybe developers will use it. There will be no hard feelings if your solution is better and replaces our solution. This is not a contest against individual players. It's a team effort.
But you do raise an important concern. What happens if Charlie wants to use the RAD layer of J! 3.2.5 and Fred's site is still on J! 3.2.1. I don't have a solution to this. Perhaps the RAD layer could be an installable package which can be installed on earlier versions of the CMS. Since Joomla! 3.2 will fully support min/max compatibility versions for extensions and installation scripts for library files this becomes viable.
Other than the BC point, that Andrew's idea addresses, there is the more central point to RAD which stands for Rapid Application Development.
Anyone disagree it takes way too long to build a component? As I understand things, FoF addresses that problem.
There is no perfect way, guys. But there is code on the table from a member of our community that we all respect and it is our responsibility and privilege to look at it.
Out of all your points FOF covers all but two. I'll let you figure out which.
There is a dependency on the CMS because the application object in Joomla! is a mess - but you know it, don't you? The dependency is there to support template overrides. They are mandatory in real world CMS usage. I don't see how you can abstract this without losing this functionality. Code patches are most welcome; that's why the project is now on GitHub.
Did I ever imply I am not willing to write code or make changes? Did you even read my previous posts? Have you even looked at the Git history of my project? Stop projecting whatever grief you have upon other people. Just because you want to believe I am lazy won't make me lazy.
Finally, knock it off with the personal attacks. In every single thread you accuse people of being ignorant
and not knowing how to engineer code.
f you think you are the only person who can spec out, architect and write the code, stop talking and do it already. Code's worth isn't proven in theoretical discussions, it's proven in the field.
Actually, you know what, FOF can be abstracted in a way that it can work with anything that makes Joomla! Platform/Framework/"Platwork"/Whatever available and make it more easily unit testable at the same time.
Right now there is an ugly static method FOFDispatcher::isCliAdmin. I never liked it very much. It's used in all placed of the code where FOF needs to know if it's running in back-end, front-end or CLI mode. Hm, that's insane. I'd rather have a FOFPlatform abstract class and concrete implementations like FOFPlatformJcmsfront, FOFPlatformJcmsback, FOFPlatformJcli, FOFPlatformJapplicationweb, or even FOFPlatformDrupal if you know what I mean.
On 12 May 2013 16:03, Nikolaos K. Dionysopoulos <niko...@gmail.com> wrote:
Actually, you know what, FOF can be abstracted in a way that it can work with anything that makes Joomla! Platform/Framework/"Platwork"/Whatever available and make it more easily unit testable at the same time.Ok. Can you give some pseudo code examples?
Right now there is an ugly static method FOFDispatcher::isCliAdmin. I never liked it very much. It's used in all placed of the code where FOF needs to know if it's running in back-end, front-end or CLI mode. Hm, that's insane. I'd rather have a FOFPlatform abstract class and concrete implementations like FOFPlatformJcmsfront, FOFPlatformJcmsback, FOFPlatformJcli, FOFPlatformJapplicationweb, or even FOFPlatformDrupal if you know what I mean.I'm not sure I do know what you mean, but that sounds like it's at the application level. I think the SDK should be near the component/model or end-point level.
On 12 May 2013 15:25, Nicholas K. Dionysopoulos <niko...@gmail.com> wrote:
Out of all your points FOF covers all but two. I'll let you figure out which.What's more interesting to me is whether you agree with those two points.
There is a dependency on the CMS because the application object in Joomla! is a mess - but you know it, don't you? The dependency is there to support template overrides. They are mandatory in real world CMS usage. I don't see how you can abstract this without losing this functionality. Code patches are most welcome; that's why the project is now on GitHub.I think it's far better to determine the strategy for the SDK first. Nothing personal - it's just how I'd approach the problem.
Did I ever imply I am not willing to write code or make changes? Did you even read my previous posts? Have you even looked at the Git history of my project? Stop projecting whatever grief you have upon other people. Just because you want to believe I am lazy won't make me lazy.
Sorry, I must have taken your "your enterprise ways are not wanted here" the wrong way :P
Finally, knock it off with the personal attacks. In every single thread you accuse people of being ignorantI believe that was actually Nick.
and not knowing how to engineer code.Sometimes there's no easy way to say what needs to be said.
f you think you are the only person who can spec out, architect and write the code, stop talking and do it already. Code's worth isn't proven in theoretical discussions, it's proven in the field.I certainly hope I'm not the only one who knows this stuff. I know there are people with other ideas and even more experience than I have. The sooner we draw them into the conversation the better. But I will cite precedence. The access control debate for 1.6 presented at least 4 possible options by different people. Everyone looked at the pros and cons and everyone had a fair go at critiquing (without prejudice or fear of being labelled "personal attackers").
One of the things I'm still not clear on is whether, should we include FoF, we are burdened with maintaining backward compatibility with the existing published product. I think if that happens we are back in the same position we have with the CMS's native code. I very strongly believe we should be adding code that is free of historical encumbrances (and yes, maybe dev's are going to have to learn a few new tricks). Pulease don't interpret that as any sort of personal attack (double *sigh*). I'd apply the exact same rule to any code I actually offered up.
Hello Andrew,
Hello Amy,Good news, I'm not as insane as I thought. Phew! Now, do you have a link for the working draft of PSR-X? I hadn't heard of it or Andrew's comments on it – sorry, my multitasking has its limits.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-general+unsub...@googlegroups.com.
To post to this group, send an email to joomla-de...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-general?hl=en-GB.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-general+unsub...@googlegroups.com.
To post to this group, send an email to joomla-de...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-general?hl=en-GB.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-general+unsub...@googlegroups.com.