New Working Group Invitation: RAD

[David Hurley]

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.

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)

Let us know if you have any questions and we’ll be glad to answer.

-

Thanks,
David Hurley
Joomla! Community Development Manager

On behalf of the PLT

[Donald Gilbert]

If I may, I would suggest writing it on top of the Framework code base so that it can be an entirely encapsulated library that is not itself dependent on a specific version of the CMS or the Platform. Additionaly, when namespaces are adopted by the CMS (if ever), those using the RAD won't need to rewrite their software, which is one of the reasons for having the RAD to begin with. I realize that this precludes adopting it in the 2.5.x series, since that version does not require PHP 5.3 and thus can not "require" usage of namespaced code. But IMO it would be very much worth the effort to build it on the Framework.

--
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.
 
 

[Michael Babker]

I'd be willing to make an argument that at this point, writing new code for potential use in the 2.5 series shouldn't consider its support of PHP 5.2 unless the intention is to push the RAD into the core distro (which, for 2.5, I'd say that it shouldn't).  That version of PHP has been EOL as long as the 1.6-2.5 series has been stable, more hosts are (finally) getting on the PHP 5.3 bandwagon, and extension developers are starting to drop PHP 5.2 support (just off the top of my head, I know NoNumber and Akeeba have done so; I couldn't find system requirements for other extensions listed on the first page of the Top Rated Extensions list on the JED).  I'd rather us make it easier for developers to support 2.5 and 3.x with a single codebase with as minimal version_compare statements as necessary (for some, that means supporting 2.5.6+ just because of the J***Legacy classes being introduced there; for others, that might mean only 2.5.whatever_it_is_in_September+ and 3.2+ if RAD is available) than be bending over backwards to support EOL software and hosts who aren't ready or willing to update their servers.

For what it's worth, I've completely forked one of the Platform packages into my own codebase just because of the amount of differences in it between 2.5 and 3.x, and that package was only introduced in Platform 11.3 (CMS 2.5.0 is when it was ported)!  I'd rather not have to do that again.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-general+unsub...@googlegroups.com.

[Matt Thomas]

+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.

[Websiteconcepts]

" 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? " 

+1 for that !

Ruud van Zuidam
M  DE :  +4915730448257 oder  NL : +31637170938

Websiteconcepts Dienstleistungen van Zuidam UG (haftungsbeschrännkt) 

Zum Kamp 13 * 49716 * Meppen * Deutschland

Telefon +49 (0)5931 8780345 *  E-mail : in...@websiteconcepts.de  * Internet: websiteconcepts.de

Handelregister HRB 205975 * Ambtsgericht Osnabrück UsT-ID-Nr. DE282207658 * Steuer-Nr. 61/277/01574

Bankverbindung Sparkasse Emsland 

BLZ 266 500 01 * Konto-Nr. 1091005189 * IBAN DE37 2665 0001 1091 0051 89  * BIC NOLA DE 21 EMS

Disclaimer

De informatie verzonden in dit emailbericht is vertrouwelijk en is uitsluitend bestemd voor de geadresseerde. Openbaarmaking, vermenigvuldiging, verspreiding en/of verstrekking van deze informatie aan derden is, behoudens voorafgaande schriftelijke toestemming van Websiteconcepts niet toegestaan.

Die Informationen in dieser E-Mail ist vertrauliche und ist ausschließlich für denbezeichneten Adressaten bestimmt. Die Offenlegung, Vervielfältigung, Verbreitung oder Verteilung diese Informationen ohne vorherige schriftliche Genehmigung von Websiteconcepts ist nicht erlaubt. 

The information sent in this email message is confidential and it has been exclusively intended for the addressee. Publication, multiplying, distribution and/or supply of this information to third parties have not been permitted, subject to preceding written authorisation of Websiteconcepts

On Thu, May 9, 2013 at 10:51 AM, Jurian Even <in...@twentronix.com> wrote:

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? 

[Anibal]

+1 for PHP 5.3+ only support 

(BTW PHP 5.5.0RC1 is available http://php.net/archive/2013.php#id2013-05-09-2)

I'm already working and publishing extensions with FOF... so if you replace FOF with JOO is going to be perfect! LOL ... Eg FOFDispatcher x JOODispatcher

Regards,

Anibal

[Matt Thomas]

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

--

[Amy Stephen]

Hope to see Nic join in, time to FOF it. =)

[allrude]

Ha ha, Nico on steroid as alway's, 

But if you read this carefully, and leave away the emotions and the disappointments and so, he offers us an great base for the RAD (with documentation !), in wich he already invested much time, and is willing to invest more.

he is also willing to listen to other opinions and work with others to get the RAD ready for the 3.2 release.

so call me prejudiced and anything you want, come on lets do this and work on a successful community project.

Ruud

Ruud van Zuidam
M  DE :  +4915730448257 oder  NL : +31637170938

On Thu, May 9, 2013 at 12:01 PM, nikosdion <niko...@gmail.com> wrote:

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.

[Donald Gilbert]

Nic, I'll give a more thorough reply later once I've had a better chance to review, but feel like I need to let you (and others) know WHY I didn't contribute to unit tests as I suggested I would during the previous FOF conversation.

The main reason is (at the time) FOF was hosted on assembla, which I don't use, and have no intentions of ever using. The code has since moved to GitHub, so that's a plus, but in the mean time life happened, which prevented me from contributing code to the projects I _really_ wanted to, let alone to anything else.

Additionally, when I finally got around to taking a deep look at the code, it seems that much of FOF is just renamed and re-licensed Platform code that you took and changed the copyright from OSM to yourself. This gist here shows the amount of code directly copied from the Platform to FOF, over 10,000 lines!

https://gist.github.com/dongilbert/224df96ff4f72a3010e0

So, all that, combined with a constraint in time, made me not really want to take the time to help with unit tests for FOF anymore.

[elin]

I think 5.3+ makes sense. I'm not sure how much if any (besides the parts that are ucm or improved platform packages i.e. adding CREATE to JDatabaseQuery) should actually be shipped in a consumer distribution, although it really depends on how it ends up. 

[Donald Gilbert]

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.

[Nick Savov]

Hi all,

Re: licensing, in Nicholas' defense and based off of similar discussions:

Joomla! is licensed under the GPL. Freedom #0 of the GPL allows the
inclusion of any GPL licensed code in any other GPL licensed work. GPL
also doesn't require attribution. In fact, it is incompatible with
BSD-style licenses *because* of this clause.

Joomla! Platform is licensed with the implicit "or later" clause, which
means that its code can be used with GPL v3 code.

In fact, this is exactly what allows GPLv3 extensions to run inside the
Joomla! CMS without causing licensing conflicts (as the extension
essentially includes source code from the CMS).

The reason why things have been modified is because that's what the GPL
requires. Article 2 section a:

a) You must cause the modified files to carry prominent notices stating
that you changed the files and the date of any change.

He also followed section b of the same article of the same license:
b) You must cause any work that you distribute or publish, that in whole
or in part contains or is derived from the Program or any part thereof, to
be licensed as a whole at no charge to all third parties under the terms
of this License.

It continues to read:
These requirements apply to the modified work as a whole.

FYI http://www.gnu.org/licenses/old-licenses/gpl-2.0.html

Also see https://www.gnu.org/philosophy/free-sw.html

If there was any merit to the argument, Joomla! should have prominent
notices advertising that it is a derivative work of the Mambo CMS. Ever
since Joomla! 1.0.0 no such notice was included in the source code of the
CMS.

Third party code which is left unmodified and intact inside his software
comes with its original copyright headers. Classes which have been
modified and repurposed do not carry the original copyright headers as
they are derivatives. Leaving the original copyright headers would be
against the GPL license as he would be confusing people reading the source
code and misleading them into believing that his modified code is the
original work.

Hope this helps!

Kind regards,
Nick

[Nicholas Dionysopoulos]

Hello Don,

I have to admit that you reply left me speechless. But, please, let me address your points one by one.

> The main reason is (at the time) FOF was hosted on assembla, which I don't use, and have no intentions of ever using.

As any developer here can attest, I am perfectly capable of handling .patch files. These files could be sent by email or Skype. No need for a merge request (in fact, in Assembla that process sucks so hard that I had to leave them for GitHub – it was becoming a huge issue). You have both my email address and Skype contact information. I know so because you were part of an email conversation and a Skype chat with Amy and myself back in late February. That's not a reason, that's an excuse.

 

> The code has since moved to GitHub, so that's a plus, but in the mean time life happened, which prevented me from contributing code to the projects I _really_ wanted to, let alone to anything else.

That is a reason I am willing to accept. But at the very least you could have told me that you're no longer interested instead of leaving me hanging out to dry. But I digress.

> Additionally, when I finally got around to taking a deep look at the code, it seems that much of FOF is just renamed and re-licensed Platform code that you took and changed the copyright from OSM to yourself. This gist here shows the amount of code directly copied from the Platform to FOF, over 10,000 lines!

https://gist.github.com/dongilbert/224df96ff4f72a3010e0

Don, really? That was a cursory glance at the code, at best. All of the files in your report belong to version 1 which has been long obsolete, and have been removed in version 2 of the framework. You should have used the master branch (hint: look at the commit dates in each branch). As a matter of fact, the only reason these files were present in version 1 was an effort to back port the query builder to Joomla! 1.5. It is something that the Joomla! project itself would not do. It was something that the community of developers begged for.

The only reason the naming was changed (and the original copyright header removed) was to avoid making it look part of an official Joomla! project so that I could make sure that if any of that code failed I would get the blame and not the Joomla! CMS developers. It's actually a pre-requisite of the GPL. I couldn't have used the code within the terms of the GPL if I kept the copyright headers while changing the naming of the classes. A derivative work must be clearly marked as such. So, I used that code within the terms of the GPL license. Is this a crime? Isn't that why we publish the code of the Joomla! project under the GPL after all?

[David Hurley]

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.

[Websiteconcepts]

now thats why we needed a Community Development Manager!, thanks David.

now this has been solved lets pick up the challenge 

Ruud van Zuidam
M  DE :  +4915730448257 oder  NL : +31637170938

Websiteconcepts Dienstleistungen van Zuidam UG (haftungsbeschrännkt) 

Zum Kamp 13 * 49716 * Meppen * Deutschland

Telefon +49 (0)5931 8780345 *  E-mail : in...@websiteconcepts.de  * Internet: websiteconcepts.de

Handelregister HRB 205975 * Ambtsgericht Osnabrück UsT-ID-Nr. DE282207658 * Steuer-Nr. 61/277/01574

Bankverbindung Sparkasse Emsland 

BLZ 266 500 01 * Konto-Nr. 1091005189 * IBAN DE37 2665 0001 1091 0051 89  * BIC NOLA DE 21 EMS

Disclaimer

De informatie verzonden in dit emailbericht is vertrouwelijk en is uitsluitend bestemd voor de geadresseerde. Openbaarmaking, vermenigvuldiging, verspreiding en/of verstrekking van deze informatie aan derden is, behoudens voorafgaande schriftelijke toestemming van Websiteconcepts niet toegestaan.

Die Informationen in dieser E-Mail ist vertrauliche und ist ausschließlich für denbezeichneten Adressaten bestimmt. Die Offenlegung, Vervielfältigung, Verbreitung oder Verteilung diese Informationen ohne vorherige schriftliche Genehmigung von Websiteconcepts ist nicht erlaubt. 

The information sent in this email message is confidential and it has been exclusively intended for the addressee. Publication, multiplying, distribution and/or supply of this information to third parties have not been permitted, subject to preceding written authorisation of Websiteconcepts

[Nick Savov]

+1, thanks Don!

Cheers,
Nick

> 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*

[Nicholas Dionysopoulos]

Another point I forgot is that since I've already signed the Joomla! Contributor Agreement a long time ago, any code I submit to the project gets co-copyrighted by the project (OSM, I guess?) as well. Technically it would be code copyrighted by OSM using code copyrighted by OSM, therefore there would be no legal problem any way you look at it.

Of course the project also has lawyers. If there is any doubt whatsoever please ask them for legal advice. If the project can't afford the legal expenses I am willing to pay them myself.

On Thursday, May 9, 2013 7:29:58 PM UTC+3, David Hurley wrote:

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.

[Donald Gilbert]

Thank you Nick S and Nic D for the clarifications. I should have brought some of these issues up privately to save some headache, but I'm glad those items are resolved for me and anyone else that may have been wondering about them.

Nick, regardless if they are a reason or an excuse by definition, everything I stated were the factors behind my decision. I should have notified you about my change of intentions and I'm sorry I left you hanging out to dry. Friends?

Also, in regards to your last comment, I think that OSM could afford the legal services, since they just paid $60,000 or so to the US government in taxes.

[David Hurley]

+1 :) Licensing resolved.

Now, just for clarification - do we have any code compares between the latest FOF and the latest Platform?

-

Thanks,
David Hurley
Joomla! Community Development Manager

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-gene...@googlegroups.com.

[Donald Gilbert]

I don't have one, but it would be trivial to generate if people were interested in seeing.

[Nikolaos K. Dionysopoulos]

Hello David and Don,

You will find some overlap. This is because FOFController, FOFModel, FOFView and FOFTable were forked off the JLegacy* classes and refactored to heck. There are some methods, dating back from Joomla! 1.5, which have not been substantially modified and mostly have to do with internals, like instantiating a model object, finding a template override etc. There is also FOFForm which contains large bits of JForm because they were monolithic and impossible to override elegantly in a different fashion. There are only so many ways to write this code so, yes, there's overlap. There should be no 1:1 copy of entire classes, as was the case with the databases classes back in FOF 1.x.

Don, does your report only include percentage of code overlap in general or does it also report which classes are verbatim copies and which are derivatives? There's no point creating a generic report if it doesn't show that there is no 1:1 copy anywhere (which is what we want to avoid, of course).

Nicholas K. Dionysopoulos

[Amy Stephen]

Nic - thanks so much for your generosity sharing this code with the community. I think it's awesome you are giving us another chance, speaks to your commitment to make Joomla better.

I can help setup unit tests when you get your repo -- but -- I'll say right now that it needs to be acknowledged that there really is only so much that can be done given what there is work with. Go ask Arlen if you have any questions on how fun it is to unit test Joomla.

The main benefit Nic is offering is to help reduce the amount of code needed to create a component. It's crazy nuts. But, FOF didn't introduce the statics and the globals and all the fun stuff that make it very hard to test. Let's not let it hold this back.

What is good is that in the meantime, the framework folks *are* rebuilding that base code in a nice testable way and putting in those unit tests. So, in the end, it can all work out.

Nic - thanks again. I appreciate your commitment - and because of it - I'll try to help you as I can.
 

[Nicholas Dionysopoulos]

Hello Amy,

As you can see the statics in this version are kept to a minimum and are mainly the getTmpInstance methods. Can you write the same functionality without statics? Yes, but it's harder to use. Can you avoid using them in the framework code and still keep them lying around for developers? Yes, that's possible. If anyone wants to contribute the code to do that, GitHub is open for pull requests 24/7 (and I do check PRs even when I am away at a conference or something). Ditto for Unit Tests.

[David Hurley]

Ha! I can vouch for checking PR's at conferences ;) I've seen that one happen firsthand. 

-

Thanks,
David Hurley
Joomla! Community Development Manager

--

[Amy Stephen]

OK, what I tried to say was for those who might suggest unit tests need to be 100% there -- they need to remember that the core code has statics and other elements that make it tricky to test. That is *not* the fault of FOF. We can put a reasonable amount of tests in place, but suggesting 100% coverage is frankly just not reasonable. 

Generally, I try to remove the "you's" since it gets confusing. Too bad I didn't do that in my last note since those comments *wrongly* appeared directed at Nic. It wasn't. 

I volunteer for this effort. I believe that is the purpose of this thread? I assume there will be a repo set up for this initiative? When it's ready, I'll take a couple of days to put the basic unit testing framework in -- then we can build tests as we go. But, I will not commit to moving mountains - I will help with basic testing. 

Sorry for the confusion.

[Nikolaos K. Dionysopoulos]

Hello Amy,

Even though Unit Testing is not a prerequisite for contributing code to the CMS, any help on UT for FOF will be highly appreciated.

Nicholas K. Dionysopoulos

Email: niko...@gmail.com

Blog: www.dionysopoulos.me/blog

[David Hurley]

We will be centralizing development for RAD here:

http://github.com/joomla/joomla-cms/tree/feature-rad

We'll also be using the Issues within GitHub to handle bugs, feature updates, and other discussion topics. 

Send your PR's ;)

-

Thanks,
David Hurley
Joomla! Community Development Manager

--

[Amy Stephen]

On Thursday, May 9, 2013 12:37:01 PM UTC-5, David Hurley wrote:

We will be centralizing development for RAD here:

http://github.com/joomla/joomla-cms/tree/feature-rad

We'll also be using the Issues within GitHub to handle bugs, feature updates, and other discussion topics. 

Send your PR's ;)

 

Got it forked. But, it looks like a plain copy of the CMS to me. I don't see anything related to RAD/FOF. Am I missing something?

What's a good first step, David?
 

[allrude]

Great, with Amy stepping in for UT, David as manager,  and I'm sure that other developers who are already are using FOF will also help were possible, lets make this a real community effort, Joomla Rocks ;-)   

Ruud van Zuidam
M  DE :  +4915730448257 oder  NL : +31637170938

On Thu, May 9, 2013 at 5:22 PM, Daniele Rosario - Skullbock <realsk...@gmail.com> wrote:

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.

--

[Anibal]

A couple of months ago as an experiment I created this repo with Joomla 3 + FOF.

https://github.com/anibalsanchez/Joomla-FoF

It's a plain Joomla 3, with FoF already installed as library. It only required to copy the files and add the reference into the MySql and Postgres installation files (not azure).

Regards,

Anibal

[Chris Davenport]

On 9 May 2013 11:01, nikosdion <niko...@gmail.com> wrote:

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.

I have stated many times that regardless of whether the Kickstarter campaign was successful or not, I will continue to work on web services.  It's just that I won't have any extra time to spend on it.

Nic, I apologise for not getting back to you yet.  There are many demands on my time and you are still very definitely on the list of people I owe responses to.

As noted in my email to you, the Web Services Working Group can be found here: http://docs.joomla.org/Web_Services_Working_Group and you will find all of the current specification documents there too.

Before replying to you I wanted to take a closer look at the FoF code to see how the routing is handled and what the web API looks like as I think these are pretty basic and important questions.  I also wanted to see what, if anything, you had added to the REST router that is already available in the Platform.  Since you haven't read any of the WSWG specifications I wouldn't expect you to have complied with them, but I wanted to see how far apart your implementation was from the kind of thing I had envisaged.  That's still on my to-do list.

From your description of FoF there is not (yet) any hypermedia support in FoF.  This is actually a pretty big thing and it would not be possible to call the API RESTful without it.  A large part of the WSWG spec is concerned with defining the hypermedia aspects of the API and I chose to leverage an existing standard, HAL (see: http://stateless.co/hal_specification.html), rather than creating something new.  Partly this was because it fits well with both XML and JSON, but also because I happened to like and agree with the thinking behind it.  It turns out that Drupal are also working along similar lines, so we're in good company and creating applications that blend together both CMS's should be much easier as a result.

Anyway, if you want to discuss web services I would suggest that you start a new thread as the subject is somewhat peripheral to the topic of RAD (although there may be overlap).

Chris.

 

--
Chris Davenport
Joomla Production Leadership Team

[Nikolaos K. Dionysopoulos]

Hello Chris,

Thank you for the link! It wasn't in your email (at least I never saw it in the text?) and I was looking high and low for it.

Yes, I am aware that without hypermedia it's not RESTful. In all of my presentation you'll see me saying right upfront that FOF isn't RESTful. I don't want to give false impressions. What FOF provides is not an arbitrary API (I already did that mistake once), it does use a URL structure for data provisioning and does honour HTTP verbs. It doesn't have hypermedia. According to Martin Fowler's article on the Richardson Maturity Model we are sitting on Level 2. We need hypermedia to reach Level 3 before we can talk about RESTful.

Regarding your routing question, no, I am not using the Platform's router as my code long predates it. I do, however, route the application based on the HTTP verb and plural/singular name of the view which –to my understanding based on everything I've read– is a good place to be standing for beginning to consider a RESTful implementation.

Thank you very much for the link to HAL! Remember in my email to you, that was my biggest question, i.e. is there a standard for hypermedia in JSON? That's exactly what I was looking for. I agree with you, it makes sense. It's intuitive. It also seems something that can be implemented right away in FOF, with minimal impact to existing code – well, right away is a relative term by which I mean that it's possible without having to rewrite anything in the framework to make it happen. It's perfectly possible to create a new View class which implements hal+json (I wouldn't touch the plain old stupid JSON output View). Work on this front could (should?) occur in parallel to a potential FOF integration with the Joomla! CMS. Most of everything else you need for a RESTful implementation I believe is already built in – but I'd really like you take a look as you have the experience on this area that I simply lack. I am very open to any suggestions on that front.

I believe that if we all work together and coordinated we can add some very serious features for developers in 3.2, of the kind that are badly needed in Joomla! if we need it to be a core part of the web in the years to come. That's why I am writing to this list today, deciding to leave all past grievances behind me. Each one of us has experience in a particular field. Each one of us, as a unit, can't realistically amount to much (at least not in a timeframe which could be considered "reasonable"). If we all work together I believe we can end up having a RAD framework for Joomla! which provides RESTful web services, probably a decent router (another todo item...), unit tested, documented, the works.

Nicholas K. Dionysopoulos

Email: niko...@gmail.com

Blog: www.dionysopoulos.me/blog

[Amy Stephen]

Well said, Nic. Thanks for this message.

[Andrew Eddie]

On Thursday, 9 May 2013 07:13:39 UTC+10, David Hurley wrote:

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 David

How do you (or others) want to organise the working group? Will a skype chat be the central place to strategise, or this mailing list, or a new mailing list (anyone got a better idea)?

I think the timeline is probably a bit ambitious for any code. I think the best question to answer first is "what problem are we trying to solve?". That's going to take the better part of a quarter to answer and only then can we answer the next question "does solution X solve the problem we are trying to solve?". Once we know that, the working group can then agree on the minimum specs and acceptance criteria for, I would anticipate, "phase 1". 

Regards,

Andrew Eddie

[Amy Stephen]

If it's too ambitious, then we'll do like we always do - wait until the next release.

Scope seems as clear as any other initiative.

Everyone is invited to participate, so those with "better ideas" just need to contact David and get involved.

If we want support, we need to give it. There is lots of work to do. We don't all have to weigh in on all the topics. Let's spread out and support one another.

--

[David Hurley]

Hi! 

Thank you for the email and your thoughts. I appreciate you asking for next steps. I think it iss very important to always keep that in mind. Here's what I would like to see accomplished next. We have discussions occurring in the Skype chat (if you're interested, ping me and I'll add you, davidbhurley). In that room we're discussing a lot of the basic logistics with setting things up. Some of the initial things that need to be done are deciding on how we want to handle the repository - whether that be as a separate project or as a branch. There are pros and cons to both approaches. I hope to reach some conclusion on that by the first part of next week. 

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

Once we have defined that then the other milestones I believe will be much easer to outline and lay out. Once we have our goals and objectives clearly defined - for example: "Goal 1: Incorporate Namespacing" then it becomes much easier to define the tasks and milestones to follow to accomplish that goal. In this way we include the exact code we want to comprise our RAD layer and everyone is in agreement in regards to the proper implementation of the code. 

Sometimes I find breaking things down into bite-size tasks and associated code makes large, overwhelming blocks much easier to manage, understand and appreciate. :)

So, hope that provides some clarity on what I see as our next steps. And I am excited to say we're already beginning work on those. I will follow up with more detail regarding the milestones and how to contribute to those once I've figured out the best way to manage and maintain that list and associated discussion. ;) Obviously the process and results are going to be fully transparent and open for all to contribute. We are all in this for a common goal - the future success of the Joomla! project which we all love!

Thanks again for the opportunity to outline what I believe is the best plan for moving forward.

-

Thanks,
David Hurley
Joomla! Community Development Manager

On Fri, May 10, 2013 at 7:24 AM, Jisse Reitsma [Yireo] <ji...@koans.org> wrote:

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.

[Donald Gilbert]

How do you eat an elephant? 1 bite at a time.

[Nicholas Dionysopoulos]

Hello Jisse,

I would argue the exact opposite. If my mindset wasn't the exact opposite of the previous Joomla! core developers there would be no FOF, the Joomla! community would have only a very brief exposure to a RAD framework (anyone remembers Koowa a.k.a. Nooku Framework?) and this thread wouldn't exist, at all.

I can further attest from firsthand experience how difficult it is to shoehorn a RAD layer on top of Joomla!'s existing code. If I am to explain this, let's first declare what RAD (Rapid Application Development) means in the context of Joomla!. Creating a Joomla! component involves a lot of copying and pasting code and creation of pointless files and illogical organisation of your code. In order to create a basic database-driven view you need to create a main controller, two controllers for the list and edit views respectively, two models, one form file (placed in the models directory, even though it's got nothing to do with the business logic – business logic being the premise of the models), two view classes and at least two view templates. If you lost count let me help you: 10 files. For a single view. Which doesn't customise any of the out-of-the-box behaviour. Even worse, you are expected to override pretty much everything, the display method in all three controllers (what?), getModel in your JControllerAdmin instance (what?!), getTable/getForm/a gazillion more in your models (WHAT?!), even the display() and addToolbar() in your views (WTF?!). The worst part? This is copy/paste from core code, mostly changing the component name to your component's name.

If that sounds like a normal developer's mindset to anyone, that person is most likely intoxicated. Actually, one standard complain you'll hear from developers coming from other systems (or beginning writing software for the first time) is that this makes no sense. Joomla! has the reputation that developing for it is insanely difficult. You know what? They are right.

What do we need out of all that cruft Joomla! had us create. Let's take them one by one:

• main controller.php. LOL, really? Throw it in the trash. A dispatcher makes more sense. Bonus: it simplifies the router as well.
• two controllers, for browsing and editing records. Throw them in the trash and just use conventions. Also get rid of all the copy/pasted code. We're not in 1998 any more.
• two models. Oh, for crying out loud! That's junk. Throw it away, use conventions instead.
• view classes. For what? Changing the page title and rendering the same buttons every time? They are unnecessary. Convention. Throw them in the trash!
• view template to display the list of records. Yup, we need that one, it's a keeper.
• view template to display the edit form, which is actually handled by the XML form, which isn't really used. Am I the only one who facepalms on this atrocity? I guess not. Throw it to the fire.
• XML form file. That's a keeper. But don't put it inside models. Models are business logic. XML forms are (mostly) presentation layer. Put it where it belongs, inside the views/viewname/tmpl directory.

Total number of files required: 2. We started with 10. We reduced the clutter by 80%. Moreover we got rid of all copied/pasted code, increasing DRY-ness by 100%. How much time do we need to write this view now? 10 minutes is enough and I'll prove it in JaB13. Compared to 1-2 hours that's a great improvement. That's what a RAD framework is supposed to do: make your code DRY and spare you the agony of copying and pasting useless code. That's the main premise of FOF which is already written and used in the wild. It's here and now.

Trying to add features from a RAD framework into a framework that's the entire opposite makes little sense. You will either end up with the same non-RAD framework plus some extra trivial features; or you will end up breaking backwards compatibility. RAD requires using convention over configuration. That doesn't bode well for backwards compatibility.

Please note that the example you used (FOFViewCsv) is the least useful thing of the entire framework you could possibly pick. Adding a default data dump view in JSON/XML/CSV/whatever is trivial and doesn't save developers much time; it only take half an hour to write. The time saving features of a RAD framework come higher up the MVC stack, as I explained above. You can't have a framework which is both RAD and non-RAD at the same time. If you make it so that the framework takes care of missing classes and replaces configuration (copied/pasted code) with conventions you screw up backwards compatibility. I can attest to the fact that FOFController is not a drop-in replacement for JControllerLegacy.

Anyway, that's getting too much of a theoretical discussion for my taste. I'd rather walk the walk than talk the talk; there's a big to-do list of features I want to implement no matter if FOF makes it into the core or not.

BTW: Regarding the goal setting, David, I would start from the more abstract goals and objectives. When I was writing FOF my foremost objectives were DRY code and ensuring backwards compatibility. The former is necessarily broken down to a gazillion objectives/deliverables and took me a year to implement to an extent that made sense. The latter is more about project management than anything else. Also, it makes sense to note down the "why" behind each "what". Why did I want DRY code? Because less code means less chance to screw up, easier maintenance, easier addition of features and ultimately makes the second goal possible. I was able to port 6 components from Joomla! 2.5 to 3.0 in the course of a month, all the while adding new features and doing support. Components written in plain old Joomla! API still struggle and some ended up forking themselves, having to maintain two codebases for each component. That's wrong. To all: If my mindset of considering counter-productive practices in code writing is a bad thing, I give up. I can simply tell you that people ask me what's my secret for maintaining so many feature-rich components and how many dozens of people I have. There's no secret and my team is a total of 2 full time and 1 part time developers. The only "secret" is that I'm using a RAD framework, cutting my development time to the bare minimum. I think that this should be the basis of Objective #0 in the RAD layer project: cutting down the development and maintenance time of components to the bare minimum.

[allrude]

Great talk the talk Nico, 

but if jou what to make this a community effort ( us helping and assisting you) , 

you have to describe the walk the walk, split-off some tasks so others (developers) can work next to you.

I grasp that we only started this yesterday, so as David pointed out in his post today, lets setup some todo list, find out who els wants to walk (participate/coding etc), so people can get to work following you're lead one (bite at a time).

I'm no developer/coder but I,m willing to help were I can, if there nothing else I can take care of the coffee ;-)

Ruud van Zuidam
M  DE :  +4915730448257 oder  NL : +31637170938

--

[Nikolaos K. Dionysopoulos]

Hello Ruud,

Fair enough, I didn't fully explain my thinking. I meant to say that I consider FOF to be a few steps ahead of the current need to set basic milestones but, yes, it does have a lot of stuff which needs to get done.

So, first, let me explain the objectives that have already been accomplished:

• Use convention over configuration

I decided to use the same conventions as RoR because a. they made sense to me and b. I was previously using Koowa which follows the same conventions. Why use conventions over configuration? Because you can't call it RAD if you have to spec out every single bit of the application in code. Code should only be written when it does something, not just to tell the framework what's the component name, 100 times in a single component. The framework should be able to tie its shoelaces without having to define what a shoelace, thread, show, hand and the process is.

• Keep the code DRY

Instead of having to rewrite each and every method in each and every class I decided to use "event methods" like onBeforeSave / onAfterSave. Even better, most of them also trigger plugin events so that 3PDs can extend FOF-based components using standard Joomla! plugins. Not having to copy/paste framework code into extensions means that it's easier to port extensions to newer versions of the framework or even change the framework in ways otherwise impossible. In so many words: decouple the framework from the extensions using it.

• HMVC

I know that this is a blanket term for a gazillion different things. What I mean is: you should be able to call an entire component view (dispatcher, controller, model, view, the whole caboodle) from anywhere in the Joomla! application without request data getting in the way. Why? It makes intricate views (e.g. master/detail), modules and plugins about 100x easier to write.

• Decouple input data from the request

So that HMVC works and because it should ultimately be the application's responsibility to handle the request, not the component's (something we've been doing wrong since... Mambo, I guess?). Note: when I started working on this I had not seen JInput (I think it didn't even exist, let alone being used). It now sounds like a given as J! 3 uses it and stuff, but two years ago it wasn't. That's why I'm now extending from JInput.

• Reuse MVC classes from the back-end in the front-end and vice versa

Many times it makes more sense adding an extra front-end check in a model than having to duplicate your back-end code in the front-end.

• Reuse view templates in the same way as MVC classes

If you think about it, it's simply an extension of the same idea as above.

• Media files overrides

Again, when I began writing this feature Joomla! didn't have it, at all. It now kind of has something like that, but not quite. Eh, I wanted to use it, not wait forever. So I built it.

• XML forms

When I say "forms" I don't mean "edit forms". I mean list views, edit views and single item display views. Why? Because the biggest problem when upgrading from one J! version to the next is that the HTML output needs to change. This kind of manual change takes forever. An XML file is infinitely simpler to write and modify and can be rendered any arbitrary way we want. New Joomla! version with new JUI? No problem, just write a new renderer class. Want to add a field? No problem, it only takes 20 seconds.

• Configuration file in XML, fof.xml

RAD is good, but I ended up writing more files than I intended. Most of them were stupid things, like saying which is the default view of a component, change the task routing, ACL checks... You know what's the common pattern among them all? They are trivial configuration that needn't be expressed in code (most of the times). Wouldn't it be cool if there was a component configuration file describing all of that? Yes, it is. That's why the configuration file fof.xml was created. It still needs some improvement. The code is less than a week old :)

• Automatic JSON and CSV dump views

Because it allows easy export of data without the developer writing much (or any) code. These formats are ubiquitous and extremely simple. We could do the same for XML but, actually, does anyone prefer receiving XML instead of JSON?

And now let's see...

What needs to be done (= what I can think of by myself)

• Unit Testing

If I have to say these two words again I will be sick. You all know the backstory.

• Documentation

In progress. No matter how cool a framework is, if the only person who knows how it works is he who develops it it will suck big time for everyone else.

• A RESTful web services interface

In progress. Right now FOF is capable of outputting JSON data with proper HTTP headers depending on the action taken. It decides on the tasks to carry out based on the HTTP verbs. There is a strong structure of the resources instead of arbitrary RPC through a common entry point or arbitrary entry points. It misses two important things: hypermedia and using the Accept HTTP header to determine the output format. The former is something I am currently working on. The latter is a kinda moot point because FOF only supports JSON output anyway and implementing this feature requires support in core code (I think it's JApplication, I'll have to check – I'm not there yet). For me this is a priority. A RAD layer loses a lot if it doesn't also implement a RESTful API. The path to Joomla!'s success goes through making it easy for developers to write web services which will be used by the next generation of devices, apps and other clients we haven't imagined of yet.

• Namespacing

I am personally not fond of each class package being its own namespace. Does it make sense to have, let's say, \FOF\Dispatcher and \FOF\Controller when realistically neither can work without the other? Yes, I know that in theory they are separated blah blah... It still makes no sense to me to separate them like that. And no, having something like FOFMvcDispatcher and FOFMvcController is no good either. It's like wearing two left shoes because we fear that wearing a right show will make us appear less radical than we are. That's utter bovine excrements. I would prefer each version of the framework to be its own namespace instead. But! This is something we should (must) discuss if FOF is going to be included in the core.

• A default router

Hm, while we are on the subject of RESTful interfaces, perhaps it would make sense to tuck in another thing which is quite related: a default router (think router.php in the front-end). I did look at JApplicationWebRouterRest but I am not fully convinced that it's all we need. As Louis said in his PR, it's a great starting point.

• Tags support

Reading http://docs.joomla.org/Using_Tags_in_an_Extension I get the impression that the changes required to support tags in an extension could be rolled in FOF without tons of effort.

• Better assets management

Currently FOFModel's support for assets is nearly non-existent. In all fairness, until mid-January FOF was still compatible with Joomla! 1.5 so I couldn't go there yet.

• UCM support

I would put this on hold as UCM is bound to go through a lot of changes. It has to stabilise before we can talk about integrating with it. But this together with the default router and the unified page model of Joomla! 4 (Next?) can form a solid base of a modern CMS, not necessarily functionally similar to Joomla! 2.5/3.x – Please don't grab your pitchforks and torches, I'm just thinking out loud.

• Get rid of JObject

I believe I don't have to even explain why.

And now my thinking.

I would say this. If you disagree on the basic objectives already implemented (or don't like my mentality, which is getting stuff done yesterday instead of talking them to death for eternity) you shouldn't put FOF in Joomla! :) If you agree on those objectives, FOF could be a good candidate either for inclusion or for being forked and serve as a basis for whatever you want to build. If you do choose to include FOF we can work on the to-do list above (which might end up being thrown in the trash), setting objectives and milestones. I did the hard word of writing the code, offering it for inclusion in the core at a personal and business cost and spelling out what I had and have in my mind.

Now, please, I don't like my lengthy monologues – especially when I am dictating this to the computer instead of typing; I look like a madman talking to himself. Step up and offer your opinion and your time. Talk is cheap. If you're interested in putting a RAD layer in Joomla! (and, generally, get anything done in this project) please put your time and effort where your mouth is. As you see, I try to do so – even though I think it's against my better judgement, I still love this community too much, dammit! And that's why I said that I prefer to walk the walk than talk the talk. We have a lot of philosophers and too few workers in this community. Countless times contributions are talked to death. I refuse to let this happen! Let's do the work! Let's not waste it in eternal discussions about potential code that someone else could maybe write with uncertain results over undefined objectives. Let's discuss briefly and up to the point about actual code that we can definitely write with guaranteed results over well-defined objectives. What do you guys and gals think?

Cheers,

Nicholas K. Dionysopoulos

Email: niko...@gmail.com

Blog: www.dionysopoulos.me/blog

[Viktor Iwan]

Totally agree with nic... I support fof as rad layer... Fof has most of the concept of what we needed for RAD..why must reinvented the wheel

[Davide Tampellini]

Again, I'm voting to support FOF.

If you are a coder, this is a life-saver.
Trust me, if your work is to create custom Joomla components, different every time, you will love this library.
Once you start, you can never go back.

Creating a new component took me about half day... and you can spend the rest of the day working on something else (or just chill out)

[Andrew Eddie]

On Saturday, 11 May 2013 02:01:58 UTC+10, David Hurley wrote:

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

What if further refined that goal to save a bit of time? To my way of thinking this milestone shares a lot of overlap with the Web Services WG. That is, the Web Services take care of the "data" and let's say that covers, more or less, the controllers and the models. That just leaves the clients rendering. So, as a milestone 1.1, we could save a bit of work by just assuming the Web Services project has produced code that the RAD layer can consume to render the output.

In other words, I think the RAD layer can start trying to work out how a "view" works, assuming data is available from an agnostic source (which could be any other framework, or even another data service for that matter). Those interested in the data modelling could work with the Web Services group in the mean time. That might be a good way to split up the work, at least initially (just a suggestion).

Regards,

Andrew Eddie

[Nikolaos K. Dionysopoulos]

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?

Nicholas K. Dionysopoulos

Email: niko...@gmail.com

Blog: www.dionysopoulos.me/blog

[David Hurley]

Ok! :)

Nicholas, thank you for such a great email with so many good points about what you've done with FOF. I think I want to take those points both of what you've outlined that you have already accomplished with FOF as well as the issues that are still outstanding and put them into a doc so that we can share it and discuss it more effectively. Sometimes the mailing list is a nightmare to try and post long emails and as a result they end up looking like "rants" when they are most certainly not. I think the points you have listed are an excellent starting list to address and ask what is it that Joomla! wants in a RAD layer and which of these points are beneficial. Clearly the amount of work which has been done is enormous and there are certainly benefits to having such a strong working product to begin from should it be decided that the points listed are the points wanted by a Joomla RAD layer. 

And I'd simply like to caution everyone (and Nicholas you know where I'm coming from as I've expressed this to you on numerous occasions and in person as well)...this mailing list is not a vote on whether FOF is included into the Joomla core distribution. We are discussing the addition of a RAD layer for Joomla - in this case we have an excellent product with a strong list of features readily available. This provides an amazing list to review and helps tremendously in conceptualizing many features that perhaps haven't even been thought of for Joomla. And the issue list as well helps to identify problem areas and areas to pay attention to.

I hope everyone understands my intent and the overall goals we wish to accomplish with Joomla! and I'm confident this next release will be our best ever. ;)

-

Thanks,
David Hurley
Joomla! Community Development Manager

[Andrew Eddie]

On 11 May 2013 06:59, Nikolaos K. Dionysopoulos <niko...@gmail.com> wrote:

Hello Andrew,

Why not go the other way around?

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.

 

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 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

Regards,

Andrew Eddie

[Nikolaos K. Dionysopoulos]

Hello Andrew, 

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".

I agree with that. The component as a self-contained application-within-an-application concept is dead. There is a message from me in the FOF list (sorry for bringing up FOF all the time, I naturally tend to use the code I'm familiar with as an example) describing my vision in December 2012. They way I see it, a component should be a smart data provider. The HTML application will only get us this far – it's already looking old in the teeth. That's why I'm so keen on integrating web services into the RAD framework. Let's call it Clint Eastwood so that I don't get to poison the well by bringing up the name of the project I lead all the time as an example. Clint should primarily be a web service provider which incidentally can also work as a "traditional" HTML application, but not following the application-within-an-application approach.

If the view doesn't care about where it's data comes from, that is a good thing.

Absolutely!

Do you even want the View to be written in PHP at all ... that's an equally good question that deserves and answer.

TBH, when I started working on the idea of using a relatively abstract XML file as a view template I was skeptical about its usefulness. I could see how I would use it, but I was afraid I was a bit delusional. Seeing the feedback from other developers, it seems that in many cases not using PHP for the view template is liberating. Especially in the dull back-end kind of typical data management. This is, however, a completely moot point when you are talking about applications which consume data, be it a mobile application or a rich Javascript-based browser (not necessarily desktop) application or even an appliance. Hence the need to integrate web services in Clint.

I think it's about making the "best" wheel for today's internet technologies.

"Best" is a relative term and strongly depends on the problem which needs to be solved. Assuming that we're talking about changing the focus to component as a data provider instead of component as a standalone application the best wheel is something which is built with web services in mind. But since we're talking about the CMS, we shouldn't go overboard and neglect the fact that HTML output is still very important. We need to cover both aspects. Preferably in a single package; it wouldn't make sense to have two com_content components, one to render articles in the front-end and one to provide them through web services, right?

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

You missed my point. I am actually preaching that we should use something that integrates well instead of being a hodgepodge of random stuff added by different people over different points in time. My objection to your post wasn't that you implied not using FOF. I Don't Care™ if you use it. What I didn't like is the suggestion of waiting for one working group to finish its work based on the MVC paradigm we want to abolish in order to start working on Clint which abolishes that paradigm and then we need to do extra work to merge them together and rewrite the core components for a second time. My head hurts just thinking about it! If two working groups touch on each other's area of interest, merge and streamline. That's what i'm saying.

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.

[Andrew Eddie]

On 11 May 2013 08:21, Nikolaos K. Dionysopoulos <niko...@gmail.com> wrote:

Just to be clear, I don't care if Clint's final code doesn't include any of FOF's own code.

Sure, just as I don't really care if the UCM I've helped to write ends up being the UCM that the CMS ultimately uses (in hindsight, I'm a bit worried about where tags is heading in that respect, but that's another conversation).

 

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.

The way I see it is this.

Data controllers and models should be the same regardless of whether it is the services app that is calling them, or the CMS. If that's a valid assumption, it makes sense for the RAD working group and the Web Services working group to pool their resources

View controllers and renderers are the responsibility of the client only, be that a PHP CMS or a JavaScript (Angular, for example) type of application. If that assumption is correct then it's appropriate to say we can divide the work between, more or less, "client" (how to render the data and deal with user behaviours and interactions) and the "server" (the data controllers and models). 

It's not unusual in a team environment to have different people working on each. In fact, it's rather healthy if you completely segregate them because the server has to deal with all the problems that client is going to bring to it, and the client has to deal only with the data that it's given (for example, no more database calls in a template's index.php file thankyou very much).

Now, the CMS will probably have a bridging layer to make the interaction between the two seamless but it's equally important to have client and server work in their own right (and extreme example would be that a Joomla client could run off a Drupal server, or visa versa).

So, the things, I think, we need to work out are:

A. Minimum specifications

For me PHP 5.4 has to be part of "the plan" as well as a strategy for dealing with any future version of PHP.

B. Platform (PHP 5.2-esqe) or Framework (namespacing, packages, composer, etc)?

I would err on the side of going with the Framework because the development model it's following is more closely aligned with how the greater PHP community is actually working with PHP. Blending is not an option because of all the type hinting we have (I do have a blended solution and it is UGLY and would not recommend it).

C. The degree to which we will shift the architectural paradigm (in other words, throw away everything we ever knew about writing a component because there is a better way vs we want to keep the JModelAdmin and co. way as much as possible to developers don't have to learn new things).

We need to be looking at data value objects and data mappers supporting new data models and new controllers. In my view, if Clint is just a rebadged CMS component framework we might as well stop now. Bottom line is, yes, I expect developers will need to learn a new way to build extensions (actually, what you'll do is build a set of data services for the server and data renders for the "client", where "client" could mean a PHP application that renders output from a data source or a browser based Javascript app).

D. Whether the CMS is driving Clint or Clint is, ultimately, driving the CMS. In other words, whether Clint in independent of the development path of the CMS (in other words, Clint will work with 2.5, 3.x, 4.x - it doesn't matter) or tightly coupled to it (Clint's API will need to be versioned to align with the CMS).

My point of view is we do what we need to do to make things work as well as they can knowing all the mistakes we've made in the past. That means that the CMS needs to respond to changes in Clint and Clint obviously needs to be able to deal with that with a versioned API (ultimately, that's part of what FoF is trying to achieve which is something I totally agree with) so "old things" will still work.

Currently my work is server side so that is where I can help the most. What I don't want to see, however, is any data API returning HTML - that's where I draw the line. That needs to be in a rendering layer and things like the Form package in the Platform and the Framework need to be rethought in this regard (and I have some ideas about that).

Hopefully that aligns with some people's ideas of what RAD means. If it doesn't, that's ok, I'll just go and help the Web Services guys out exclusively :)

Regards,

Andrew Eddie

[Ove]

@All

Not beeing on a technic level that allows me to tell you how to organise
a library I'd rather ask you what the Joomla! RAD is/will be.

You don't know?

Why not sit down and and find out before you adopt code and/or start
coding? As David Hurley plan to. When you know, I would appreciate to
get that Information available somewhere.

Is it a way to develop applications rapidly? What is an application? The
only way to build future Cms or Joomla extensions? I guess you couldn't
then call it RAD anymore? Fill all gaps in underlying layers
(Cms/Platform/Framework)? Are the gaps to be filled within those layers
at all? Why, when there is a RAD handling it? Is there a need for a Cms
layer at all in future?

Only a couple of questions I can't answer myself and won't even try.

When you have the answers I'm sure you'll find "the right way" and we'll
all be happy :)

Good luck to an awesome WG!
Ove

[Nikolaos K. Dionysopoulos]

Hello Andrew,

I appreciate that you clarified your point of view. That was what I thought you had in mind and I have to tell you upfront that, in the context of the Joomla! CMS, I disagree with your approach.

What you have in mind when writing your reply is the way you are using Joomla! on a daily basis. You are not using the Joomla! CMS and you are not using it the way its userbase does. You are using the Framework (and, previously, the Platform and before that a stripped from all semblance to a CMS Joomla! 1.5 derivative) as the foundation of an enterprise application. That's cool and exciting... but it's not how Joomla! users use the Joomla! CMS or how Joomla! extension developers develop for those users.

I am not particularly eager to witness a massive paradigm shift towards enterprise development (that's what you suggested really is). That's 1% or less of our user base. There is no incentive to the project. The enterprise has money, but the project won't have any. The enterprise has developers, but they won't share. What's in it for us as a project? Just some bragging rights like "look, mom, my framework is used by (insert large corporation here)"? I believe that doing such a shift would alienate a very big part of the 99% which makes up this project's userbase, with severe adverse effects to the project.

Besides that I find your proposition of what needs to be done to be an exercise in futility and redundancy. Let me explain this. Everything you describe has already been done. Not by a working group in this project but by Joomla! co-founder Johan Janssens after he left this project. If you so strongly support the objectives and point of view you shared with us, why haven't you already joined the Nooku project? (Yes, I know why) Why should we want to plan and develop from scratch something that's already been done? Plus, Nooku comes with Nooku Server which had forked off Joomla! 1.5 and got fully rewritten (and much futher developed). If there is a round wheel, why should we try to re-invent it? And, yep, it's also on packagist. In fact they were pioneers in that area. Joomla! came two years late to the party. If you are so keen on code reuse you can add a dependency to Nooku and throw this whole WG (and the web services WG) in the trash bin.

Andrew, I believe that your vision and the Joomla! CMS are sitting on two different planets. Do you want my very honest opinion? I really like your vision. I believe it's a great way for PHP developers to develop web applications. But it's not what the Joomla! CMS stands for. And for this reason I am personally very happy that the Joomla! Framework is now a project independent from the Joomla! CMS.

Regards,

Nicholas K. Dionysopoulos

Email: niko...@gmail.com

Blog: www.dionysopoulos.me/blog

[Websiteconcepts]

@Andrew Eddie

If we doe the JRAD development the way you see it, it wil take us years because (that how read your post) you want to reshuffle everything, the framework and the CMS.

the best RAD for Joomla at the moment is probably Nooku, it has almost everything we could want, but its also the worst RAD because the developer, doesn't consider backward compability and never brings a stable finished product and keeps adding new features.

The second best (sorry Nico) is FOF, as it is stable, and because it's buil on and with the framework code we can integrate it in a short timespan.

I may not be the best way to do this, but it also wasn't the best way wen we integrated JX-Finder in Joomla to be the the new Smart Search.

 

perhaps there wil be an all new RAD, completely as you see it wen we reach 4.0 or 4.5, but for now we would/should be very happy to get FOF in as JRAD in the 3.2 release.

just my two cents.

@Ove yes lets sit down an discuss al the thousand way that lead to Rome, and al the sort of transportation ways the are, that wil bring us no step nearer to Rome in fact it wil bring us no were.

Ruud van Zuidam
M  DE :  +4915730448257 oder  NL : +31637170938

Websiteconcepts Dienstleistungen van Zuidam UG (haftungsbeschrännkt) 

Zum Kamp 13 * 49716 * Meppen * Deutschland

Telefon +49 (0)5931 8780345 *  E-mail : in...@websiteconcepts.de  * Internet: websiteconcepts.de

Handelregister HRB 205975 * Ambtsgericht Osnabrück UsT-ID-Nr. DE282207658 * Steuer-Nr. 61/277/01574

Bankverbindung Sparkasse Emsland 

BLZ 266 500 01 * Konto-Nr. 1091005189 * IBAN DE37 2665 0001 1091 0051 89  * BIC NOLA DE 21 EMS

Disclaimer

De informatie verzonden in dit emailbericht is vertrouwelijk en is uitsluitend bestemd voor de geadresseerde. Openbaarmaking, vermenigvuldiging, verspreiding en/of verstrekking van deze informatie aan derden is, behoudens voorafgaande schriftelijke toestemming van Websiteconcepts niet toegestaan.

Die Informationen in dieser E-Mail ist vertrauliche und ist ausschließlich für denbezeichneten Adressaten bestimmt. Die Offenlegung, Vervielfältigung, Verbreitung oder Verteilung diese Informationen ohne vorherige schriftliche Genehmigung von Websiteconcepts ist nicht erlaubt. 

The information sent in this email message is confidential and it has been exclusively intended for the addressee. Publication, multiplying, distribution and/or supply of this information to third parties have not been permitted, subject to preceding written authorisation of Websiteconcepts

--
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.

[Websiteconcepts]

sorry Nico, our post crossed each other you say it so much better then me.

Ruud van Zuidam
M  DE :  +4915730448257 oder  NL : +31637170938

Websiteconcepts Dienstleistungen van Zuidam UG (haftungsbeschrännkt) 

Zum Kamp 13 * 49716 * Meppen * Deutschland

Telefon +49 (0)5931 8780345 *  E-mail : in...@websiteconcepts.de  * Internet: websiteconcepts.de

Handelregister HRB 205975 * Ambtsgericht Osnabrück UsT-ID-Nr. DE282207658 * Steuer-Nr. 61/277/01574

Bankverbindung Sparkasse Emsland 

BLZ 266 500 01 * Konto-Nr. 1091005189 * IBAN DE37 2665 0001 1091 0051 89  * BIC NOLA DE 21 EMS

Disclaimer

De informatie verzonden in dit emailbericht is vertrouwelijk en is uitsluitend bestemd voor de geadresseerde. Openbaarmaking, vermenigvuldiging, verspreiding en/of verstrekking van deze informatie aan derden is, behoudens voorafgaande schriftelijke toestemming van Websiteconcepts niet toegestaan.

Die Informationen in dieser E-Mail ist vertrauliche und ist ausschließlich für denbezeichneten Adressaten bestimmt. Die Offenlegung, Vervielfältigung, Verbreitung oder Verteilung diese Informationen ohne vorherige schriftliche Genehmigung von Websiteconcepts ist nicht erlaubt. 

The information sent in this email message is confidential and it has been exclusively intended for the addressee. Publication, multiplying, distribution and/or supply of this information to third parties have not been permitted, subject to preceding written authorisation of Websiteconcepts

[rahul borole]

Hi everybody

can i use my knowledge for development?

can i participate in this project?

Thanks,

Rahul

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.

[Nikolaos K. Dionysopoulos]

Yes, of course you can. As soon as David publishes the document with the objectives you can chip in your opinion. When a decision is made for the code direction we should follow we will need as many developer as we can get hold of :)

Nicholas K. Dionysopoulos

Email: niko...@gmail.com

Blog: www.dionysopoulos.me/blog

[Herman Peeren]

Just wanted to let you know that I'm working in a similar direction, but implemented a bit different. I'll show some of it in my Jooctrine-presentation on JAB13 (Sat. 17.00h). http://jandbeyond.org/program/sessions/jooctrine-doctrine-orm-in-joomla.html . Hope to see a lot of you there! I have some things that might give you some new ideas. Unfortunately my time to spend on this Jooctrine-project is limited, so I cannot afford to also join a RAD-wg, UCM-wg, WS-wg and contribute to the Joomla! Framework and CMS, although all of them are related and the overlap has been mentioned several times in this thread.

My bread nowadays mostly comes from making custom applications, often complex, that work within a Joomla! intranet/website. So for me there never has been a separation between the CMS and other Joomla!-applications. Quite the contrary: for my customers it is a whole. In doing this, one of the first walls I hit was Joomla!'s active record implementation and the way one db-table and one "entity" are clung together. I wanted to work with a domain model as I had a.o. learned from books like Evans (DDD) and Fowler (PEAA). So I was very glad with Doctrine2, which implemented that in PHP. I'm now still on that road I sketched on JAB11: http://www.slideshare.net/HermanPeeren/joomla20-architecture

Once I started changing some basic things in Joomla!, everything started to move. All kinds of structures have to be rewritten if you start changing the basic building blocks. It is an interesting process, but not very Rapid. That is why this is from the sideline and I'm not actively working with you all in this RAD-wg.

Some things I came across, related to this RAD-group-thread:

Dispatching
We have an event-system in Joomla: events and listeners are registered and as soon as an event is triggered, the listeners are dispatched. All right. The most logical thing to render a component would thus be to dispatch the component when an onContentRender-event or something similar occurs. But our component's entry files are no objects, just plain php-code. In JApplication we have a dispatch()-method. Via  renderComponent() and executeComponent() of JComponentHelper it just includes the code of the component's entry file. There you start to instantiate and execute a main controller and from there the rest of the component. FoF puts a "dispatcher" in the entry-file, as Nooku did, but I see more in a solution that a component is a plugin that is dispatched on an event.

Nice about this solution is, that I can work on plugin-components without interfering with the current core-Joomla! components.

Modules and Plugins: Components
One of the basic things in Joomla! is that you render one component and then add modules. If you want to display 2 or more components on one page you have to do some tricks to have 1 main component and put the other components in modules. Modules are often a kind of view for a component. In a more elaborate module or plugin, often a MVC-structure is missing (OK, then you put the "model" things in a module-helper...). It is easier to have one structure. I named those elements components. And they can be used on module-positions. And are plugins, so they can be dispatched when needed.

In the original UCM-proposal this was also the idea: everything is content and it all has the same structure. One of the reasons why the MVC-classes were simplified and decoupled was to make it easier to use them outside components, like in modules and plugins. If components, modules and plugins are in essence the same and all have the same structure, things will be much simpler in Joomla (and hence more rapidly developed).

Mapping
I mainly started using Doctrine ORM because I needed a mapping of hierarchical relations between entities: performers that have acts, orders that have orderlines, articles that have tags or comments, etc. Structures like that can be very well and clearly modeled (in a domain model) and it is very nice to not have to worry at all about persistence, as this is all handled by the mapping- and persistence-layer (in my case by Doctrine). Therefore the entities in the domain layer can behaviourally be more rich than just CRUD and structures like hierarchies can be defined seperately from the way they are persisted. The mapping can be done in several ways (lazy loding or not, cascading or not, etc.) and be cached. Also the different ways of inheritance mapping (one tabel, concrete table and class table) can be used out of the box. And here we come to UCM: that is basically just a class table inheritance mapping. No need to reinvent a wheel and make a new JDataMapper for that, which would be less powerfull and more work.

HMVC
In HMVC another MVC-triade is included in a view. That can be very handy, but I've seen some misuse of it: where the structure between or within entities is expressed in the presentation layer instead of in the domain layer where it belongs. For instance: if you would use HMVC to render orders and orderlines (I've seen it implemented). If the structure is part of the domain layer (or: "business logic", to use an older word), then you should keep it there and not in the presentation layer. MVC, or at least the view, is mainly part of a presentation layer and that is not the right place to define the structure of your entities. Some of this HMVC-misuse is coming from a lack of possibilities to properly map the entities to the data/persistence layer. When using a proper datamapper, some of the HMVC is not needed anymore.

Another thought about MVC: it is a pattern, not necessarily implemented as classes with the same name. In Symfony2 the controllers are methods for instance (which is related to the idea of 1 task controller-classes, BTW). I don't like classes ending on -er, so when I saw an opportunity to get rid of a controller-class, I did that... My MVC now stands for: model-view-component. My component (which also is a module and a plugin) is the controller too: it manages the model and the views.

Fields defined in XML
One of the things I realised while working with Seblod CCK is, that input-forms are just another view of the same content types (called "entities" in Doctrine). The fields that make up a content type are not just good for rendering and so I disagree with Nicholas that the form-xml should be in the presentation layer and not in the domain layer. As I'm into Domain Driven Design, I think that is the only right place where structures like that should be defined. That is also why in Doctrine the entities and mapping are defined first and the database is made from that. The domain layer is leading, the data layer and presentation layer are following.

I've got a lot more... but I'm running out of time now. See you at JAB13 I hope!

Ciao,
Herman

[jonatasbr]

I don't want to make false assumptions, but the impression I got from reading this is that for some past conflict, Nicholas (great Akeeba extensions btw!) is having a hard time to convince people to use or even adapt [part of] his solution. By the current approach it seems to me that it will take a long time to have a RAD layer in Joomla.

Let's just ignore existing solutions from willing contributors and write some concepts before. Did I hear UML?

I think we may just get this going before 2018!

BTW, RAD in German means "wheel". Talk about reinventing it :)

[Ove]

Yes, it might be better to try to get all on the fast train to Berlin
than just a few to Rome ;)

[brian teeman]

The way I see it is as follows

It is a stated roadmap item of the Joomla project to include some sort of RAD

We need to define what it needs to do, and who it is intended for at a high level and only then can we define what it needs to do at a more specific level and any system requirements that may be needed. (although I can't see it being sensible to have different sys reqs for the RAD and for Joomla)

Currently we have an suggestion on the table of FoF and nothing else. 

For me the next stage then is to take the definitions created above and look to see which FoF satisfies already, which need more work and which need creating.

Then we have to decide if the project wants to work with Nicholas and the FoF community to completely satisfy the specification OR if it wants to fork what he has done or that FoF completely fails to meet the requirements.

Personally it makes more sense to work with him. Help him to complete the specification and discuss if necessary any changes rather than forking, been there and done that.

We have to remember that we are talking about ADDING something to the 3.2 release which means that we will only have a further 6 months until the 3.5 release by which time the RAD must be complete and stable.

[Nick Savov]

+1, but one point needs clarification. The RAD solution must be stable by
3.2's release (see:
https://en.wikipedia.org/wiki/Software_release_life_cycle#General_availability_.28GA.29).

We won't add anything that's not stable. It doesn't need to be perfect,
but it does need to be "good enough". New features (e.g. UCM integration)
can always be added later, if needed.

Kind regards,
Nick

[Donald Gilbert]

Why are we forcing something to be code complete in 2.5 months just so it has time to be tested and ready for 3.2? Seems like insanity to me. Remember Tags? Yeah, that still has an API that is pretty horrible in terms of architecture and integration with your own components. It's got a half-implementation of UCM which baffles me. Now, we want to work on this "next big thing" called RAD for because if we don't then we don't have any "feature" to ship with 3.2 to even make it worth looking at. 

IMO, the CMS release cycle is pretty demanding and leads to half done code that "works" but isn't even close to a complete implementation. 

So, if we decide FOF meets most of the requirements and we can make it feature complete within the allotted time frame then great, lets use it as our starting point. But remember, whatever we do, our developers will be using for the next 3 years. Even if we release improvements and tell people to upgrade, there are those who won't. And if we choose to use FoF as is for now and then build something else, we're still in the same situation of people needlessly re-writing code. 

With that in mind, it's much __MUCH__ better to build something that meets all the requirements (whether on top of FoF or otherwise) and release it when it's READY. NOT with 3.2 because of some arbitrary and unmanageable deadline. Otherwise, we'll be back here in 5 months wondering wtf happened. Lets not do a repeat of Tags just so we have "something new" that makes 3.2 shine. 

—
Sent from Mailbox for iPhone

[Nick Savov]

Hi Don,

As far as I'm aware, no one is forcing anything into 3.2, so your
assumption is false. If someone desires to submit a RAD feature for
Joomla 3.2, then it must be stable. It can't be added to 3.2 as an
unstable feature. We simply wouldn't add it. The code must be stable.
If someone desires to submit a RAD feature for Joomla 3.5, the same holds
true, respectively.

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'd suggest you open up a new topic in the JCMS mailing
list about Tags implementation if you have any *specific examples*.
Simply saying "pretty horrible in terms of architecture and integration
with your own components" is neither helpful nor constructive. It's also
not respectful to our volunteer's time and efforts. If you have issues
with implementation, please do it in a more respectful manner next time.

No, the CMS release cycle is not demanding. The release cycle doesn't
demand code, in fact; it gives an opportunity for code to be added sooner
(and so far it's working out very well, I must add). Just like FoF didn't
get added in 3.1 and now it has an opportunity to get added in 3.2, in the
same way it can not be added to 3.2 and still have an opportunity for 3.5.

For more information about our development strategy, check out:
http://developer.joomla.org/cms/development-strategy.html

Kind regards,
Nick

[Donald Gilbert]

Nick you said RAD needed to be ready by 3.2 about 2 posts up. If you have questions about the ease of implementation look at other posts on this mailing list. 

—

Sent from Mailbox for iPhone

[Nick Savov]

Yes, that's on the assumption that it's being submitted for 3.2, which is
the upcoming minor release, which is what this discussion is about, which
is carried on from the previous discussion before 3.1's release.

Kind regards,
Nick

[Radek Suski]

@Donald:

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? 

[Websiteconcepts]

@Radek +1

Ruud van Zuidam
M  DE :  +4915730448257 oder  NL : +31637170938

Websiteconcepts Dienstleistungen van Zuidam UG (haftungsbeschrännkt) 

Zum Kamp 13 * 49716 * Meppen * Deutschland

Telefon +49 (0)5931 8780345 *  E-mail : in...@websiteconcepts.de  * Internet: websiteconcepts.de

Handelregister HRB 205975 * Ambtsgericht Osnabrück UsT-ID-Nr. DE282207658 * Steuer-Nr. 61/277/01574

Bankverbindung Sparkasse Emsland 

BLZ 266 500 01 * Konto-Nr. 1091005189 * IBAN DE37 2665 0001 1091 0051 89  * BIC NOLA DE 21 EMS

Disclaimer

De informatie verzonden in dit emailbericht is vertrouwelijk en is uitsluitend bestemd voor de geadresseerde. Openbaarmaking, vermenigvuldiging, verspreiding en/of verstrekking van deze informatie aan derden is, behoudens voorafgaande schriftelijke toestemming van Websiteconcepts niet toegestaan.

Die Informationen in dieser E-Mail ist vertrauliche und ist ausschließlich für denbezeichneten Adressaten bestimmt. Die Offenlegung, Vervielfältigung, Verbreitung oder Verteilung diese Informationen ohne vorherige schriftliche Genehmigung von Websiteconcepts ist nicht erlaubt. 

The information sent in this email message is confidential and it has been exclusively intended for the addressee. Publication, multiplying, distribution and/or supply of this information to third parties have not been permitted, subject to preceding written authorisation of Websiteconcepts

@Donald:

--

[Radek Suski]

Nice try but I haven't said "positive" but "constructive"

The other comment stays ignored although for the moment it seems that your only motivation and goals are to avoid any constructive discussion.

And it's actually remarkable that you are talking about your goals and your motivations.

On Saturday, 11 May 2013 22:17:46 UTC+2, Donald Gilbert wrote:

@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.

[Andrew Eddie]

Hi Nic.

I think the challenge here is how a team of people can work together with different ideas and come to some sort of middle ground. It's clear to me that this conversation is only for developers that use Joomla in a particular way and anyone doing anything different is not invited to the party, but you want all the things wrong with Joomla solve without changing anything. That's ok. I know where to put my efforts and offer my experiences of attempting to solve those very same problems. Thanks for the clarification. Good luck!

Regards,
Andrew Eddie
http://learn.theartofjoomla.com - free tutorials and videos on Joomla development

--
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.

[Andrew Eddie]

On 12 May 2013 02:41, Nick Savov <ni...@iowawebcompany.com> wrote:

Hi Don,

As far as I'm aware, no one is forcing anything into 3.2, so your
assumption is false.  

I read your comment the same as Don. It sounded like everything had to be done by 3.2. I think you should not mention any version number at all and, rather, establish the milestones for when a RAD would be considered ready to submit. Of course, that just how I would approach it.

 

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'm sorry Nick but you need to start listening to the senior engineers around you and the advice of people with more experience than you. Tags was not stable when added to the core and there was enough warning to know that was going to be the case. You rushed it in because it was "better than nothing". You can, of course, accept any code you want but at least be consistent.

Regards,

Andrew Eddie 

[Nikolaos K. Dionysopoulos]

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.

Best of luck with your endeavours!

Nicholas K. Dionysopoulos

Email: niko...@gmail.com

Blog: www.dionysopoulos.me/blog

[Andrew Eddie]

On 12 May 2013 05:52, 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

For what it's worth I completely sympathise with Don. I wish I had a dollar for every time I promised to help someone and then life or work got in the way. That's part of being human and we should treat people with dignity when they are being open and honest (unless you thought Don was lying).

 

- Accused Nicholas of a plagiarism and license violation

There is no license violation. Nic can fork any Joomla code and change the license to GPL 3 if he wants. What I do have an issue with is the fact that Nic hasn't attributed his changes when he has consumed OSM code verbatim (at the time of looking at the code). The GPL requires that you annotate where your changes are. If you copy a file verbatim, I consider it polite to at least say "File based on x.php copyright OSM".

 

- Withdrawn your accusation about the license violation (I'm no licensing expert)
- Talked about zoological-nutrition matters

I must have missed that one.

 

- Critised the idea about including it in 3.2

There are many reasons why I wouldn't include FOF in 3.2.

 

- Talked about building something from scratch to met non-existent requirements

There have been several calls now to talk about those requirements. Starting from scratch is also a viable option and one I'd recommend, but if there's no buy-in from anyone else, there's no point in flogging that horse because it appears to be dead even before we've started.

 

I just wondering if you have anything constructive to say in this thread?

Well, *you* could start by outlining all the problems you are having with the current Platform using Joomla everyday. Whether you fall into Nic's "regular Joomla user" category or not remains to be seen. 

Regards,

Andrew Eddie

[Radek Suski]

I don't have any problems with platform/framework. I just have problems wit people which talks just for talking and write just for writing.
There was no a single valid point in all his "arguments" nor a shadow of a constructive critique.

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.

[Nikolaos K. Dionysopoulos]

Andrew,

The non-issue you brought up was brought up before and responded to in an appropriate and concise manner. Please refrain from a constant barrage of off-topic remarks which have the sole purpose of provoking an emotional response. What you are engaged in is called trolling and is certainly not what I'd expect to see from a Joomla! co-founder. It's the second time in three months I am on the receiving end of these thinly veiled attacks coming from you. Do you really want to engage in a flame war where every past choice you made might be used in an attack against you? 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.

Over and out.

[Michael Babker]

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.

[Nikolaos K. Dionysopoulos]

Michael,

I believe that is not a counterargument to adding a RAD layer to the core, but it is an objective: backwards compatibility. Something that the Platform and the CMS have traditionally neglected (to put mildly).

Moreover, one of the objectives I said I have in mind and, actually, can't live without is namespacing. It's quite conceivable that if Alice wants to use the official RAD layer and Bob wants to use the latest bleeding edge release then Bob can wrap his version in a private namespace until Joomla! catches up. I know that if FOF was to be used in the core at some point I might have to do that for my own software.

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.

Nicholas K. Dionysopoulos

Email: niko...@gmail.com

Blog: www.dionysopoulos.me/blog

On 12 Μαϊ 2013, at 01:55 , Michael Babker <michael...@gmail.com> wrote:

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 Eddie]

On 12 May 2013 07:53, Nikolaos K. Dionysopoulos <niko...@gmail.com> wrote:

Andrew, two objections to your bitter post:

It's not bitter at all. Lacking patience maybe, but not bitter.

 

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.

That was why I was asking who was driving the RAD. From my point of view, I'm trying to solve exactly the same kinds of problems with bespoke Framework projects as I would be trying to solve them in a traditional Joomla CMS component. I cannot see that the rules have to say "this RAD layer is only something that can only ever be used by the CMS". I think that would be a tragedy and I would petition the interested parties to think bigger. There are, after all, many many consultants using Joomla to build custom web solutions using Joomla as a Platform. The "component" developers are not the only stakeholders in OUR code (and after all, I still wrote a lot of the lines of code, from scratch, that are in the CMS today and I still care about them).

 

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.

I suspect you think I'm laying down the law? It's just my opinion. It's different from yours. So? The point is, is there any latitude to meet in the middle?

 

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 told you we were on the same page :P

Regards,

Andrew Eddie

[Andrew Eddie]

On 12 May 2013 08:46, Nikolaos K. Dionysopoulos <niko...@gmail.com> wrote:

I refuse to be dragged to this gutter.

I have no idea what you are talking about. I would no more putting UCM 1.0 code (which is "done") into 3.2 than I would recommend putting FOF in (which is also "done") - both, I think, miss the mark in terms of what I personally think the Joomla project as a whole needs to fulfil its mission. Joomla, I'll remind everone, is not spelled C.M.S.  I just don't think this conversation should start with "have we got code we can use?". It should start with "what do we want to achieve?" and how far are we willing to go to achieve it.

 

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.

We shouldn't blindly agree. But I do think that the opinions of experienced developers like yours and myself should factor heavily in evaluating a solution. To that end, I'm more interested in the process of working through the extremes of points of view than what the actual outcome is. In other words, I don't care what the final code is, but have we done our best to work together to agree on the best and most balanced solution?

 

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.

Still agreeing ;)

 

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).

I would put it that I think there is a better solution that allows the RAD to be used by the CMS and also anyone else wanting to do anything cool with Joomla code (including, for example, the Web Services group). Now the delta between my ideal solution and what we come up with as a team could be significant, but it does not mean that we should not examine many possible scenarios and the related pros and cons.

For example, I think we need, let's call it an imaginary 10 points of change to get where we need to go. We might settle on 5 points of change because that is the most balanced approach, but I think we can all agree that 0 or 1 points of change are not acceptable in this discussion.

 

We want to pursue a RAD layer which works today, for reasons you don't agree with.

Who is "we"? Does this discussion not affect the Web Services working group as well? Can it not include people building custom, one-off components? I don't see that anyone should be excluded from this conversation.

 

You have other goals.

My goal is simply to work on getting the best solution that can be used by the majority of developers who want to adopt Joomla as a platform. I personally think this conversation is more than "we just want to build a better CMS component". This is actually healthy. I'm going to stretch your thinking, and you are going to pull me back into reality, but at the end of the day we should end up with a "better" solution that everyone can buy into. But Nic something has to give? I'm willing to concede on many points. Are you prepared to do the hard yards of working out where the optimum middle ground is?

 

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.

And there I agree. Hence my previous questions. They are to gauge how far are you willing to go to achieve the best solution for everyone involved. If we are establishing that "everyone" ONLY includes CMS extension developers, well, so be it - sad, but them's the brakes. If we want to go further than that so any developer learning to use "Clint" will also be able to build stand-alone web services, or CLI's or completely different types of web applications, then that is another conversation. The advantage with that is, suddenly, you as a developer are more marketable than just "I know how to write a Joomla component".

But if it takes several groups to work on their own to come up with differing strategies ... that works too.

Regards,

Andrew Eddie

[Andrew Eddie]

On 12 May 2013 09:07, Nikolaos K. Dionysopoulos <niko...@gmail.com> wrote:

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.

To me, this is one of the most important questions to answer. To be honest, maybe this is the starting point because if we find the "ideal" solution, then the way to code it more or less sorts itself out. Coupled (pun moderately intended) with that is the question of whether the RAD layer is even aware of what is using it. Ideally, the RAD layer should not care if it's a Joomla Component or a Drupal Module calling the code.

My initial thoughts are the we need a way to version the API that, for example, a Component would interact with. A Component should only be able to touch the RAD in a certain way. Those versions could then have very long life cycles - the RAD could always be upgraded to the latest version but one Component might use RAD-1.0 interfaces and another component might use RAD-3.4 interfaces, but happily co-exist. That would be a neat trick is we could pull it off.

Again, thinking out loud, we could throw some ideas about what could the interface for RAD-1.0 look like (starting small, not trying to design too much into the system). For example, what do we need to get "Hello World" working (I need a way to get some data, and I need a way to render it)?

Regards,

Andrew Eddie

 

[Amy Stephen]

@Anibal - I believe you said you have a Joomla 3.x instance with FoF installed from a couple of months back? What would it take for you to update it for Joomla core and FoF today? Would you kindly do so, if you have time? What that would do is give everyone who wants to comment on the technical merit or lack therein of FoF an installable Joomla instance from which to offer constructive comment and maybe even get some pull requests flying back and forth. 

Now, one very important task that will help clarify the scope of this idea is to identify what has changed in the forked Joomla core code. In some cases, it's likely there were not changes, other than class name, etc., since FoF needed this in order to help support BC changes. We'll want to figure out what those classes are, drop them out of FoF and use the core classes/make those reference changes in FoF.

Then, what we will have is a very clear picture of what FoF is and how it works. That'll help us keep these conversations constructive.

Provided Anibal has time to help us this way, would everyone agree it is acceptable to do those things and that such an approach would at least clarify very specifically what code we are talking about, and help us think this through in a more constructive way.

BTW - some don't agree with comment, and that's fine, but, I do want to remind everyone that you have a personal choice to delete your posts if you feel those posts were not constructive. No one gets to make that choice for you, it's your right. Personally, I think it would help others trying to catch up if there were some filtering going on. But, that's just my opinion and it's your right to say what you want!

Thanks.

[Andrew Eddie]

Here's a very *rough* representation of what an ideal work could look like:

https://docs.google.com/presentation/d/11n0mtLkQe3TTrf4Kx2g6wmQn3Oh6qr9KOTX-kUDnocE/edit?usp=sharing

What this essentially says is this:

* The RAD should be independent of the calling application or unit of functionality.

* You should be able to use the RAD for any application, be that stand-alone, a component, module, plugin or web service end-point

* A component (and a module) is roughly equivalent to a web services end-point.

* Data should be modelled centrally regardless of whether being called from a component, module, plugin or web service (in other words, the data for a component is going to call the same code as a supporting web service).

* The RAD should provide a PHP based rendering engine.

* The RAD should be able to support to return of data (JSON, XML) or rendered data (HTML).

* How you design a component or end-point container is not important. What's important is that you use the RAD consistently.

* RAD will probably consist of multiple sub-packages used to support different elements of functionality. Wiring up and sequencing those sub-packages would be the responsibility of the calling "thing" (CMS, component, module, end-point, etc).

In terms of backward compatibility, you can still follow semver (no breaks within a major version). But you could possibly do something like this:

---------------------------------------------------------

Component A:

use Joomla\Rad\V1\DataModeller

// Load the array of params into the data modeller.

$dataModeller = new DataModeller($params);

---------------------------------------------------------

Component B:

use Joomla\Rad\V2\DataModeller

// V2 supports a Dependancy Injection Container - let's use it.

$dataModeller = new DataModeller($dic);

---------------------------------------------------------

Web Service End-Point C:

use Joomla\Rad\V3\DataOrm

// Use the new V3 ORM modeller (DataModeller was dropped).

$dataModeller = new DataOrm($dic);

---------------------------------------------------------

^^^ All of the above can coexist without conflict assuming that V1-3 is shipped with the application. The Joomla CMS may choose to ship up to the three latest versions of RAD (I dunno, that could mean something like a 5 year lifetime for the oldest version). A bespoke web services app may only ship the latest version of the RAD.

The Joomla\Rad package would be maintained independently of the CMS itself and would include all Joomla stakeholders (not just component developers).

Now, that doesn't solve backward incompatible schema changes, but let's solve on step at a time.

I realise some of that code might be over some people's heads ... that's what I'm talking about when I ask "how far are you willing to go?" and "how far are you willing to change your thinking?".

If we can achieve that, then I can happily write my "enterprise" (have to chuckle at that - that just means something is "e"xpensive to build) web services using the same methodology as a Hello World component, Zoo, K2, Akeba ARS, whatever. The only difference is that the Joomla CMS calls a unit of functionality a "component" or a "module" or a "plugin" and a web services application calls it an "end-point". But why can't everyone use the same RAD? I can't accept "you just can't" as an answer.

[Amy Stephen]

Yup, Andrew, and I believe the industry is already heading there, given standardization on Interfaces and Composer, alone. I used to think there would be a "standard component" but now I think it's going to be a structured services layer, it's emerging already.

This will naturally grow out of continued progress on shared interfaces, adoption of Composer and interminging of third party code. This is exactly what the framework  is positioning for, the framework's efforts will be what opens up this world for the CMS and more importantly gets the service layer in place that allows that plug and play you are driving towards. The real improvements will come from that fundamental code improvements, adoption of solid OO practices and patterns, unit testing, and you guys are doing that. It is going to take time but the framework is pointing the right direction.

All well and good and you know I am already a believer.

Whether FOF is the right thing to do or not, I'm not sure. I tried to add a component builder a couple of years ago because I found the process repetitive and it got to where I really felt like I was going to have to turn in my developer pin if I kept copying pasting like I was.

The truth is it's a ridiculous amount of code to create a component. Let's look at the code and comment on that basis. My gut feel is FoF can be adapted where needed and be included in Joomla without any harm. That'll buy valuable time for the work you guys are doing.

Anyway, no more from me without code in hand.

Thanks Andrew.

[Nicholas K. Dionysopoulos]

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.

Nicholas K. Dionysopoulos

Lead developer and owner, Akeeba Ltd. 

Sent from my iPhone. Please excuse my brevity. 

[Nikolaos K. Dionysopoulos]

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. In order to relieve the calling application from the duty of loading the correct platform class, we can use auto-detection. This is something I am already doing in Akeeba Engine – it was more obvious in earlier versions of Akeeba Backup which supported Joomla! 1.5 and 1.6/1.7/2.5 at the same time. It's also used in the FOFRenderer classes; it's an adaptation of the same code.

This solves the problem of having code tied to the CMS without major changes and retaining backwards compatibility. Moreover it does make the code more easily testable because we no longer have the ugly static method which defines the behaviour of FOF and makes it fail cold under test. One could even provide a mock platform class for tests, ensuring what exactly is being tested.

As you see, Andrew, I am not expending myself to cheap theoretical talk, I do answer each valid point and I am willing to make changes to my code.

PS: A little background. I am also an Engineer. Just like you are a civil engineer, I am a mechanical engineer. Do not treat me like I'm some kind of a moron. No moron graduates a 5-year mechanical engineering university courses programme cum laude, more so when his diploma paper is on programming. All right? Let's get back to writing code now.

Nicholas K. Dionysopoulos

Email: niko...@gmail.com

Blog: www.dionysopoulos.me/blog

[Amy Stephen]

Nic - In all honesty, I'm 100% certain you took offense to something that was not intended to be offensive. I understand how you did, but I believe the assumption you made was incorrect.

In fact, in re-reading Andrew's post to try to understand your response, I realize I also misunderstood the intent of his comments, I placed too much weight on the uncoupling the CMS from the component aspect and not enough on his vision on the middleware aspect.

Yea, that's pretty cool, Andrew, in fact that's right in the neighborhood of what I went about a service layer. Later today, I plan to share some code and ideas on that on the Framework list but, yea, I  agree that's the ticket, that's what we are missing, that'll be what ends up helping with dealing with change.

Here's where I see a disconnect between the two types of thinking in this thread. One group is neck deep into uncoupling, and DI considerations, and trying to make certain on this next generation of framework code, the sins of the past do not repeat. A lot of my time is in that type of thinking too - so I can completely understand and appreciate where you are coming from.

The other type of thinking is much more oriented to the realities of living and breathing in the world as we find it today, imperfect, ugly in some places, but it's where we are at and what kinds of improvements can be made to help those who share that environment RIGHT NOW. I don't spend as much time in that world so in many ways, I feel like it's important to entrust those who do.

One mindset knows the layers on layers on layers of the MVC need to come tumbling down and be replaced with a structure much more correct. The other mindset is this is the world we live in, we can't wish in huge improvements tomorrow but we do need to ease the pain YESTERDAY.

Both perspectives are correct. My suggestion would be to continue with Andrew's thinking on that services layer - yahoo! to that and I'm going to share some stuff that I hope at least helps shape some thinking, if not add a little code to that idea.

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.

[Andrew Eddie]

On 12 May 2013 19:54, Amy Stephen <amyst...@gmail.com> wrote:

Other than the BC point, that Andrew's idea addresses, there is the more central point to RAD which stands for Rapid Application Development.

I think SDK would be a better term, because we actually (I think) aren't talking about writing different applications (that is, things other than the CMS) faster and more efficiently. 

In thinking further, I guess my vision is that a "component" could become something that can be consumed by and independent (but still Joomla) application (CMS, Web Service layer, whatever). Write code once - publish everywhere.  Idealistic? Most certainly. Realistic? Depends how far people want to tippy toe outside of their comfort zones.

 

Anyone disagree it takes way too long to build a component? As I understand things, FoF addresses that problem.

I'm not sure it goes far enough (yes, I have looked at the code - I don't really want to do a second review to *prove* that I have). As a code base I still think there is too much "buffering" of unexpected or unwanted change in the underlying CMS code. I'd prefer to see more "bridging" between the way the CMS does things and "a better way". There is still far too much code duplication in FoF for my liking. That may sound critical but I'd be the first to say we shouldn't be touching UCM 1.0, that I published last year, with a barge pole even though it would patch some short term problems.

 

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. 

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.

Regards,

Andrew Eddie

[Andrew Eddie]

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 ignorant

I 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").

Regards,

Andrew Eddie

 

[Andrew Eddie]

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.

Regards,

Andrew Eddie

[Nikolaos K. Dionysopoulos]

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?

Very bad example follows.

Instead of this in FOFController:

list($isCli, $isAdmin) = FOFDispatcher::isCliAdmin();

if ($isAdmin)

{

$basePath = JPATH_ADMINISTRATOR;

}

elseif ($isCli)

{

$basePath = JPATH_ROOT;

}

else

{

$basePath = JPATH_SITE;

}

You could have

$basePath = FOFPlatform::getInstance()->getBasePath();

Each FOFPlatform class could implement, say, an $order property and an isActive() method. In the system under test you could use a mock platform class which implements the methods and returns expected results, without having to run the entire framework inside a front-end, back-end and CLI instance of the Joomla! CMS.

If you want me to elaborate, please ask me something more specific. The idea for this implementation is 60% ready in my head, most likely I can answer your question.

 

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.

Let me get a few steps back.

Clint will be used primarily (or also – depends on where you're standing) to create Joomla! CMS components. First basic misunderstanding. I do not believe in the separation of modules and components. IMHO, both are components. So whenever I say "component" you have to understand "components, modules and arbitrary applications".

CMS components can be used to provide either HTML (typical, or "legacy" mode – what we are used to) or pure data (via web services). The latter is the way of the future, the former is there because it does make sense in many cases and because we don't want to drive away existing developers. Moreover, the CMS currently assumes that components will churn out HTML.

No matter how much JUI kool-aid you drink, with the current CMS structure you still need to be able to do template overrides. It's not so much about changing the layout as it is the need to modify the entire output. I will give you an example from my own site. Akeeba Subscriptions normally outputs a list of all subscriptions. I have separate component subscriptions and bundle subscriptions. I needed them to appear in two separated areas. In order to do that I could a. create yet another layout in Akeeba Subscriptions which I'd have to maintain along the other three I use for the "levels" view or b. do a template override and make cheap use of modules to render two views of the same component in the same component area. In my mind there's no question as to whether you need template overrides in the CMS.

And here's the problem. I could definitely go your way and say screw the CMS, I'm working on a lower level. In fact I would love to be able to say that! I could do things like using HTTP Accept headers to define the output format (instead of hardcoding a format URL parameter), use a proper router (instead of busting my you-know-what to write a router.php which takes into account the abysmal and unnecessary complexity of Itemid's) and so on. But that's a long term goal with two obstacles:

a. it does not address the need for extension developers to not copy/paste vast amounts of code to write Joomla! CMS extensions today; and

b. such a change supposes that the CMS be rewritten, rendering all existing Joomla! extensions obsolete. The strength of the CMS is its extensions and that would be against the CMS' best interests.

As a result I decided to forget about what I'd ideally want to do and think about how I can make the best forward-thinking solution within the confines of the reality I'm facing as a Joomla! extensions developer.

It's easy to throw everything in the bin and start over with something new. It's a royal pain in the rear trying to engineer a solution based on existing constraints. I understand why you want to pursue what I consider the easy solution. As I said, I agree that it's a noble architectural goal and I personally believe that this is the way applications must be built. However, like it or not, we're stuck with the current application (Joomla! CMS). This thread is about improving the Joomla! CMS, not the Joomla! Framework. You keep proposing a solution which is apt for the Framework. Andrew, really, I get it. I am not an idiot. I agree with your proposed architecture and I said over and over that it's great and please do pursue it... but in the Framework. Once it's ready I would suggest forking off the CMS and doing heavy refactoring to work on the Platform. That could be the mythical Joomla! Next and it could run in parallel with Joomla! CMS for a while, until it gets developer buy in. But I don't see how this is relevant to this thread.

[Nicholas Dionysopoulos]

Hello Andrew,

On Sunday, May 12, 2013 2:16:54 PM UTC+3, Andrew Eddie wrote:

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.

As far as building applications, yes. As far as the current Joomla! CMS is concerned, no. Together with my previous message to you I hope it's now clear what I believe and why.

 

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.

And I agree with that... but not for the CMS. Nothing personal, I just believe that since you're not talking to the many people using the CMS in the wild you can't understand this fine point.

 

 

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

Obviously you did. What I was implying is that on an enterprise level you have a different approach to priorities and lifecycle management. I won't say that either endeavour is easier than the other because it's not. I respect the different priorities in enterprise, but I don't and can't accept them for the community project.

 

 

Finally, knock it off with the personal attacks. In every single thread you accuse people of being ignorant

I believe that was actually Nick.

Andrew, you said that FOF is as ready as com_tags. Those who know me understand why I took it personally.

 

 

and not knowing how to engineer code.

Sometimes there's no easy way to say what needs to be said.

Sometimes you should think the context under which code has to engineered and run. You can't go carte blanche for the next version of the Joomla! CMS and you can't even suppose that the code will run in a semi-decent server, running up to date software. In the enterprise world you don't ever think about those things, they are under your control. In a community project you have to think very hard because none of this is a given. Before you criticise code think about the context. I never publicly criticised the one-file-per-controller-method approach in the Platform, um, Framework. I can see its value for applications written from the ground up (and Michael is the living proof of a developer flourishing under this model), but I don't believe it's relevant to the CMS, at least not for the next few years. But I didn't tell you that you don't know 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.

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").

At the time it was up for discussion I was unaware of the conversation and too busy working two jobs. Since I didn't participate in that discussion I won't comment on it.

[Nicholas Dionysopoulos]

Hello Andrew,

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.

This is not perceived as a personal attack, it is a very valid point that I did address in my reply to Michael. I believe this can be solved with namespaces (something that FOF currently lacks and it's high up on the list of things in dire need of being done). Let me elaborate.

Since the RAD layer is going to be added to the CMS and not the Framework it doesn't have to follow PSR-0. I am actually not really fond of PSR-0 for the reasons stated in http://hybridlogic.co.uk/2012/04/psr-0-great-idea-bastardised-execution/ and because versioning is not taken into account. So what's the benefit from namespacing? Just getting our class names sorter? Polluting our folder hierarchy? It makes little sense. I would rather have semantic versioning in the namespaces, like (example! probably bad! I have thought about it exactly 3 seconds): \Akeeba\FOF\v20 encapsulating the entire framework, perhaps with sub-namespaces like \Akeeba\FOF\v20\MVC. This is up for discussion, as I noted in an earlier post.

I know that I'm going to be labelled as an heretic now. Whatever.

[Amy Stephen]

Nic - on the PSR-0 thing, a new standard PSR-x will be voted on Monday and it will be more to the liking of those who need to implement it outside of the Composer/vendor folder world. Andrew has already expressed support for that - it will take a couple of weeks for the vote, but I think it's as good as in. You will be able to map a folder to a namespace prefix and get rid of some of those layers. If you wanted to include version in your namespace, you should be able to do that.

BTW - you'd be a heretic if you didn't see the folder hierarchy as problematic. "PSR-0 Folders Suck" is the number 1 hit on Fig Radio. Feeling as you do makes you normal on this topic. =)

On Sunday, May 12, 2013 10:02:45 AM UTC-5, Nicholas Dionysopoulos wrote:

Hello Andrew,

[Nikolaos K. Dionysopoulos]

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.

Nicholas K. Dionysopoulos

Email: niko...@gmail.com

Blog: www.dionysopoulos.me/blog

[Amy Stephen]

On Sun, May 12, 2013 at 10:25 AM, Nikolaos K. Dionysopoulos <niko...@gmail.com> wrote:

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.

Here you go =)

https://github.com/php-fig/fig-standards/blob/master/proposed/package-oriented-autoloader.md

Thanks.

[Nikolaos K. Dionysopoulos]

Thank you for the link, Amy! This is pretty much what I had in mind. If it becomes a standard, so much the better!

Also answering Andrew's concern, if this approach is used the immediate consequences are:

• Compatibility with existing FOF application will be broken, as they are unaware of namespaces. This means that if FOF is chosen for inclusion as the RAD layer then the included version would not affect existing extensions, therefore it's no longer mandatory to keep backwards compatibility, liberating us in our choices. This has always been my plan for FOF 3.0. I was just not sure what BC-breaking changes would be required. It seems that the results of this thread would define exactly that.
• Semantic versioning can be implemented using namespaces, allowing future versions of the CMS to include the previous and the current RAD layer implementation, without compromising backwards compatibility even if a newer version of the RAD layer needs to introduce a BC breaker. I would, however, recommend that in this case STS versions include the RAD layer versions found in the previous LTS and possibly the one found in the previous STS. This allows developers to have up to 6 months to catch up with RAD layer changes, something that wasn't possible with the current MVC structure up to this date and led to the inclusion of the ugly version_compare if-blocks that you, Andrew, just like me, despise.

All in all, I believe that this concern is easy to address and is one part code and one part management. One down, a million other things left to discuss :)

Nicholas K. Dionysopoulos

Email: niko...@gmail.com

Blog: www.dionysopoulos.me/blog

[Viktor Iwan]

This is just an Intermezzo and bit out of topic... but i really hope someone from Joomla Magazine can summarize these discussion for june issue.. i really can't keep up the conversation

... hey guys.. its weekend.. :D.. !

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.