New tracker item: add Framework on Framework to Joomla 3.1

[Paul Orwig]

Hi all,

I have just added this tracker item that proposes to add Framework on Framework as a library to Joomla 3.1:

http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=30136

What questions/comments/concerns do others have about this tracker item?

Thanks for your consideration about this.

Best regards,

paul

[Phil Brown]

Personally I have started using FOF and am loving it.  FOF was my decision maker to stay with Joomla instead of migrating to Symfony.

+1

Regards,

Phill Brown
M  04 2481 9754
Digital Factory
Bathurst Software Solutions
-------------------------------------------------------------------------------------------------------------------

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

[Ronni KC]

+1 seems to be about the quickest way to add a lot of nice possibilities including HMVC and a very nice abstraction level building on a rock solid library.

And the best part is that its non-excluding and does not introduce dependancies in the CMS.

[Matt Thomas]

+1 That would be a great move!

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

On Tue, Feb 19, 2013 at 5:49 PM, Ronni KC <ron...@gmail.com> wrote:

+1 seems to be about the quickest way to add a lot of nice possibilities including HMVC and a very nice abstraction level building on a rock solid library.

And the best part is that its non-excluding and does not introduce dependancies in the CMS.

[Donald Gilbert]

It sure has good code that is widely tested and used, but we might be better to served to improve Joomla core, rather than just plugging in another library. However, it's not a hill I'm willing to die on, and if there is broad support for adding it, then I say go for it. If we do, there are some questions to answer:

1. How do we keep it updated?
2. Who's job is it to update and maintain?
3. How do we deal with extensions that already have an FoF dependency? What if they depend on an older version than what's included? Do we now just break their code by including an up to date version in core?
   
4. Is it enabled by default (available globally), or must developers include the FoF boostrap? (If so, that MIGHT solve #3)
5. Will core components transition to using FoF?

[Ronni KC]

In my opinion:

1+2) I think a lot of this is up to Nicholas input so will let him jump in too (he did the hard work).
3+4) There is different options one could be an option in the installer there is others - i think its just a matter of finding the right approach.
5) No - the point as i see it is that FOF is an option - its non-excluding, non-dependancy creating, non-legacy - meaning that in terms of the actual CMS its completely uninhibited from FOF - So should CMS 4.x introduce some of the things FOF offers (which would be highly expected in terms of HMVC etc.) then it does not affect anything in terms of the core nor does it require lots of rewriting etc.



Den onsdag den 20. februar 2013 00.06.35 UTC+1 skrev Donald Gilbert:

...

[David Hurley]

I would agree with this assessment, if there's enough support then definitely go for it. I like some of the points Donald raises, and would also wonder in addition to his points:

6. How well documented is the actual code (on a development level)?

7. Is it simply a library added or is it part of the CMS project now and stored/maintained in Github?

8. Is there any need to unit test it?

I'm eager to see how we can add HMVC and some of the other benefits into Joomla! and look forward to moving this along.

-

Thanks,
David Hurley
Joomla! Community Development Manager

[Nicholas K. Dionysopoulos]

Hello Donald,

FOF is not a replacement for Joomla! core code. It's a specialisation of the generic Joomla! MVC aimed to provide an easier way to develop database-centric components. It uses a quite different approach to the one used by Joomla!, that's why its features are not something that you can add to Joomla! itself without breaking existing components.

Answering your particular concerns:

1. How do we keep it updated?

I have vested interest in maintaining it. Without it my business doesn't work. Moreover, in order to ensure that there is a "bus factor" > 1 I have made its Git repository public and I can assign committers besides myself. There are already some people who regularly contribute code and could fulfil this role, therefore eliminating the project's dependency on one person alone.

1. Who's job is it to update and maintain?

I have no objection to whatever the call is. I do volunteer to do it. 

1. How do we deal with extensions that already have an FoF dependency? What if they depend on an older version than what's included? Do we now just break their code by including an up to date version in core?
   

FOF takes painstaking care to ensure backwards compatibility. Each major version is backwards compatible with the previous, deprecating old methods rather than removing them, unlike what the Joomla! CMS and the Joomla! Platform does. Stability of software during major version upgrades is a clear consideration for me and one of the reasons I wrote FOF. No FOF extension breaks by adding FOF to the core. Moreover, if FOF is updated to a new minor version in the same major version or at the very least the next dot zero major version I guarantee that there will be no backwards incompatible issues and, if there are, they will be documented at least three months in advance. As I said, not breaking existing extensions is priority #1. You can ask other developers who use FOF since the 1.x versions (like Jurian of Twentronix) how well that process works.

1. Is it enabled by default (available globally), or must developers include the FoF boostrap? (If so, that MIGHT solve #3)

No, it uses a simple bootstrap code:

if(!defined('FOF_INCLUDED') include_once JPATH_LIBRARIES . '/fof/include.php'; 

1. Will core components transition to using FoF?

I am not at liberty to decide that, but I don't see any benefit for many core components. I could imagine, for example, com_users, com_banners, com_redirect, com_newsfeeds and com_weblinks using FOF but not, say, com_media or com_installer. com_content and com_categories are special cases and refactoring them presumes a great deal of effort which I deem unlikely to be provided by an interested party.

The major benefit FOF would have is the ability for third party developers to create new extensions very fast. One of the things I've implemented in FOF 2.0 is FOFForm, which is basically JForm on steroids. Instead of rendering edit forms it can be used to render list views (think articles list) and detail views (think single article display) using nothing but an XML file. The example component, com_todo, proves that it's perfectly viable to create a working component with nothing but XML files and minute amounts of PHP and LESS. It can help developers go from idea to proof of concept to working, maintainable component in very little time.

[Roberto Segura]

My thoughts:

• Joomla! already needs something like FoF into the core to avoid repetitive code (DRY)
  
• If you build big extensions you will end writing your own FoF
• Extra abstraction layer between base classes and component classes
  
• It doesn't force developers to use it
• Adds cool features as HMVC & json data
• Uses a good naming convention
• New developers will see Joomla! development easier. We need more developers/contributors!
  

I think that it should be used and maintained into the core. Probably into the cms library.

Not including it is not a problem because anybody can follow the instructions to install it through your extension install script.

I'd add it :)

[Nicholas K. Dionysopoulos]

Hello David,

6. How well documented is the actual code (on a development level)?

Every method of each class comes with its own docblock. If something's missing let me know.

 

7. Is it simply a library added or is it part of the CMS project now and stored/maintained in Github?

No! It's a library which depends on Joomla!. As I have said in my presentation at JaB and JWC, FOF does not replace or undermine Joomla!. It extends it. I'm using the word "extend" in the PHP sense. If you look at my code you'll see that I am extending from JControllerLegacy, JModelLegacy, JViewLegacy, JForm* family of classes and so on. It would be stupid having to install a modified copy of Joomla! with each and every of my components, don't you think?

 

8. Is there any need to unit test it?

I would love to see that happening, but I'm not sure how MVC can be unit tested. As far as I can see the Joomla! Platform has not tackled this area for years and there seems to be no intention(?) to do so. FOFModel can be unit tested quite easily. So are some helper classes. The form classes are a bit tougher but can be tackled. That said, I am the least suitable person to do the unit testing. As I've said time and again, any help in this area is more than welcome.

 

I'm eager to see how we can add HMVC and some of the other benefits into Joomla! and look forward to moving this along.

Joomla! is missing a Dispatcher class and a way to share an input object between MVC triads (or even the individual components of an MVC triad). This is the basic requirement before you can think about HMVC.

In FOF you can do FOFDispatcher::getTmpInstance('com_example', 'myview', $config)->dispatch(); from anywhere (be it a component's view or a module) and know that you're rendering the exact view of the exact component using the exact data you push in the $config variable, no matter what the request data is.

[Nicholas K. Dionysopoulos]

Hi Roberto,

I'd rather see it in its own top-level libraries directory (libraries/fof) for several reasons:

• It's a third party library, much like PHPmailer is. Yes, it depends on Joomla! Platform (and the CMS tree, of course) but that doesn't change this fact.
• Not breaking backwards compatibility with existing FOF-based extensions (albeit a small "stub" file could do the trick)
• FOF implements its own autoloader which uses slightly different rules than the Joomla! autoloader. Putting it under the cms tree requires either the FOF classes' naming to change (with detrimental effects to backwards compatibility) or change the way the Joomla! CMS autoloader works (slower, increased maintenance cost, possibility of breaking).
• Being in its own directory allows end users to upgrade it. If the upgrade doesn't work well they can roll back to the version included with Joomla!. I intend to keep a proper repository with installable library packages for cases like this.

[Mark Dexter]

I am very positive about adding this to the core. To the extent that
we might need to fix up things like code style, developer docs /
examples, or unit test coverage, I think these are things we can work
on over time (like we will do with the rest of the CMS).

I think there is a huge advantage to having this in the core vs.
having it available as an extension. If it is in the core, 3pd's can
have a higher level of confidence that it will continue to be
maintained and improved with the entire Joomla community behind it.

My .02. Mark

[Don]

I'm not saying it should be a replacement, I'm just saying that if it is so good - we should consider making the CMS better using it. :)

1 + 2) I can buy that. Most if my questions are playing devils advocate so that we have a place to point people to when they ask these questions. 

3) that's good. I'm glad you are committed to backwards compatibility, but to be clear, a 3 month warning is currently 9 months shorter than what the CMS and platform give with our 12 month deprecation strategy. 

4) Not enabled by default does solve most issues I had with it. 

After hearing your responses, I'll throw my hat in with the "lets get it in" crowd

Sent from my iPhone

[Amy Stephen]

First, Happy Birthday, Nic.

I'm going to ask the tough questions and this will be my one and only post.

Paul - when you say "include as a library", do you mean like phpMail, where that project maintains the software, and Joomla simply distributes it? In the past, the libraries included have been directed at users, not developers. Why does it have to be in core? What percentage of people do you think will use this?

Also, Paul, in your feature request, you mentioned that the inclusion of this software as a library will "encourage more people to get involved with Joomla and drive more innovation, both for extension development as well as the Joomla core." I know this question puts you on the spot, but, how do you see that happening? How can that much needed enthusiasm and involvement be built without including it in core? 

In the past, we removed developer support software, like the sample plugins, modules and the package samples, and placed those files into the github repo. If I remember correctly, the rationale was twofold: 1) concern over the size of the distro which is closing in on 40 mb 2) the thinking that developers know where to locate the materials and that end users do not need developer "raw materials" in the distro. So, how is this different?

When we added the JXtended library, we did so with a commitment of working that software into the core extensions. In this manner, it became the new standard for development and core served as the examples devs could use to get started. If there is a strong desire to get it into core, then are people also committed to migrating core to the FOF approach? If not for all, perhaps at least for the new tags component?

It needs to be acknowledged that Nooku is in the top-10 of the Idea requests. http://ideas.joomla.org/forums/84261-joomla-idea-pool/suggestions/1850251-nooku-fm-integration  To the best of my knowledge, FOF is not mentioned. What message does that send?

Are there concerns that adding platform advancements in the CMS at the time that the platform is revitalizing, might send mixed messages and create confusion as to overall project confusion? If so, how can that be clarified?

All of these individual efforts are working towards the same goal of revitalizing the project and regenerating the developer community. Is it possible that will only happen when there is a more unified approach?

[Don]

Amy, those were my concerns and as always, you have a knack for presenting them better than I. :)

Sent from my iPhone

--

[Nick Savov]

Hi all,

For what it's worth, the deadline for getting new features into the core
is February 25th, which is 6 days from today (practically 5, since the
today is almost over). So if the discussion goes well and there's a
consensus that FoF should be added to the core, the following things need
to happen within the next 5-6 days:

1) The code needs to be added to its feature tracker item (preferably
tomorrow; the sooner the better) along with testing instructions.

2) The code needs to be tested. Anyone can do this part and the more
testers, the better.

If the testing results are good and if there's a consensus in the
discussion that FoF should be added, then Mark (likely) will do the final
review and merge it.

So if you're able, try to clear some time for testing within the next 5-6
days, preferably earlier rather than later.

Cheers,
Nick

[Paul Orwig]

Hi Amy,

Thanks a lot for your email. I appreciate the larger questions you are thinking about and asking. Our best chance to make Joomla better comes when we listen to and consider and weigh all of these and hopefully questions. 

My responses to your questions are inline below. I hope you will reconsider your statement about this being your one and only post!

Thanks again,

paul

On Tue, Feb 19, 2013 at 7:22 PM, Amy Stephen <amyst...@gmail.com> wrote:

First, Happy Birthday, Nic.

I'm going to ask the tough questions and this will be my one and only post.

Paul - when you say "include as a library", do you mean like phpMail, where that project maintains the software, and Joomla simply distributes it? In the past, the libraries included have been directed at users, not developers. Why does it have to be in core? What percentage of people do you think will use this?

Yes, I meant it in a way similar to phpMail, mostly because that is what I think is most consistent with Nicholas' vision for FOF, and I want to respect that. But as far as maintaining it vs simply distributing it, earlier in this thread Nicholas said he was open to whatever the decision might be about that.

I think there are a lot of good ideas in FOF that can help the CMS now, and some of those ideas might also influence some future development in the Platform. Also, I think including it in the core will help to give it some more visibility that will help it grow and improve, which is something I think is good and important. Yes it's a library, but as Nicholas has shared above, it's a different kind of library - a library written with one purpose, and that's to extend Joomla.
 

Also, Paul, in your feature request, you mentioned that the inclusion of this software as a library will "encourage more people to get involved with Joomla and drive more innovation, both for extension development as well as the Joomla core." I know this question puts you on the spot, but, how do you see that happening? How can that much needed enthusiasm and involvement be built without including it in core? 

I think the main value of FOF from the standpoint of encouraging more people to get involved is how it can significantly reduce the learning curve for creating  components. I think when the learning curve goes down, that will open the door for more people to become aware of and attracted to Joomla. I think that will lead to more innovation in extensions, which everyone benefits from. And I think some of those new developers who become attracted to Joomla because of FOF will also end up contributing in other ways.

In the past, we removed developer support software, like the sample plugins, modules and the package samples, and placed those files into the github repo. If I remember correctly, the rationale was twofold: 1) concern over the size of the distro which is closing in on 40 mb 2) the thinking that developers know where to locate the materials and that end users do not need developer "raw materials" in the distro. So, how is this different?

For your (1), I think if FOF gets added to 3.1, part of the reason should be that there was enough support that the benefits it brings justify the cost of a bigger distro. For your (2), I think one way that FOF might be an exception for the precedent you mention is because of the HMVC support it adds. I think if extension developers know that capability is there and know they can use it, then it might be a more effective solution toward improving ways that different components can integrate with each other, compared to if it was only available as an external resource.

When we added the JXtended library, we did so with a commitment of working that software into the core extensions. In this manner, it became the new standard for development and core served as the examples devs could use to get started. If there is a strong desire to get it into core, then are people also committed to migrating core to the FOF approach? If not for all, perhaps at least for the new tags component?

It sounds to me like the consensus (at least so far) is that there isn't necessarily a commitment to migrate core to the FOF approach. I think as far as tags goes, that's a good timely question, but not one I feel qualified to answer.

It needs to be acknowledged that Nooku is in the top-10 of the Idea requests. http://ideas.joomla.org/forums/84261-joomla-idea-pool/suggestions/1850251-nooku-fm-integration  To the best of my knowledge, FOF is not mentioned. What message does that send?

I think since Nooku rose to the top 10 of the ideas pool, hasn't its development path diverged a bit from Joomla's? As I understand it, the purpose of the ideas pool is as a way to allow developers to find each other and work together on the features they are interested in and want to potentially propose, but it wasn't necessarily intended as a voting tool to determine what the development priorities should be for the project as a whole.

I think there is a great discussion to be had about ways that we can improve the development process, I just don't want to have that discussion in this thread :-P.
 

Are there concerns that adding platform advancements in the CMS at the time that the platform is revitalizing, might send mixed messages and create confusion as to overall project confusion? If so, how can that be clarified?

All of these individual efforts are working towards the same goal of revitalizing the project and regenerating the developer community. Is it possible that will only happen when there is a more unified approach?

At a high level and in general, I think the more unified we can be the better. I think that applies not only to development, but in other areas as well such as governance and communications. As far as how that works itself out at the level of a proposal for a 3.1 feature, I think that's exactly what this discussion is for, and my hope is that we will figure it out together.

[Davide Tampellini]

Hi everyone,

probably very few people know me, but I can consider myself an early adopter of FOF.
I discovered it while I was looking at Nicholaos code, found he was using a very interesting library and I contacted him.
Now each of my public extension (J4Schema, TrackTime and Domus Organizer) are FOF powered, moreover, since I work as freelance developer, a bunch of custom extension are FOF powered: it really speeds up your work, trust me.

While using it, I found some bug and submitted the pull-request to help and improve the framework.
As far as I know, every new feature was born from a developer need: you're writing something for you/ a customer, you find it interesting and you create a pull-request. If it's good enough, you'll have it approved ASAP.

Regarding stability and compatibility, I think I'm the living proof that everything works fine :)
90% of sites uses Akeeba Backup (with FOF), and both components (mine and Nicholaos ones) are fine despite several updates.

Just my 2 cents as developer consumer

[Ronni KC]

Amy: I think FOF 2.0 offers a good solution to give breathing space for the CMS to actually interact and conceptualize and plan with the platform.

Meaning that a lot of the features and maturity we need to add to the CMS should be based in the platform and wellplanned with the platform developers.

FOF 2.0 offers instant availability of HMVC, FFOForm (use backend views in frontend and vice versa) and many other and very cool features - that we really should have in the Core of Joomla itself.

Now since FOF 2.0 extends Joomla and its non-excluding i really think it in reality becomes a lifeboat for the CMS.

With FOF 2.0 included as a library in the core (or otherwise) we get the chance to focus the CMS development on CMS 4.x and then start planning with the platform on how to get there.

Personally i think that is exactly what is needed to make sure we get good and well thought off solutions coming to the future of the CMS.

As for Nooku it is quite clear that nooku has never sought stability or inclusion in Joomla - the founders has publicly stated time and again that only the contributing developers will know the direction and they do not pledge to anything in terms of stability and backwards compatibility etc. - these are well known reasons why nooku was never and never will be a widescale success - and exactly what Nicholas decided FOF should not do.

Den onsdag den 20. februar 2013 03.22.58 UTC+1 skrev Amy Stephen:

....

[Bakual]

Personally I think it should not be in the core. But the core should support libraries in a way which allows an extension developer to say "install this library if not already present in same or newer version". I don't know if that's already possible.

But then I don't mind if it's included in the core, if most people think it's needed.

[Naouak]

I don't agree adding this to the core.

If I remember correctly, FOF was created as a way to fix problems with Joomla Framework between versions.Hence, it should be the core that need fixing not FOF.

Adding a new abstraction to an abstraction seems a bit weird to me. If people really need this, let them install it, don't push it on others. I thought Joomla was about extending with extensions not bloating (I'm not saying FOF is awful code, I've never gone through it) with third parties because people are using it.

Naouak, Grade 2 de Kobal.
Site web: http://www.naouak.net

[Javier Gómez]

Just in case somebody missed, here is Nicholas' video presenting FoF at Joomla World Conference: http://conference.joomla.org/speakers/sessions/session/session/61-rapid-application-development-with-fof.html

[Allon Moritz]

As soon as it gets into the core as library a new fof release makes only sense when it will be updated in the core too, because the developers have to rely on the library in the core. So it doesn't rely makes sense to add is as a library. I would suggest to make it part of the platform. To make it the right way then, I would wait till version 3.2 and not doing something in a hurry now. I think adding fof would be a huge benefit for all extension developers, but I would make it part of joomla and inviting nicholas as commiter of the core to maintain the fof part.

Just my thoughts as an extension developer who doesn't use (but will use soon) fof because it is not part of joomla core.

On Wed, Feb 20, 2013 at 9:05 AM, Bakual <werbe...@bakual.ch> wrote:

[Nicholas K. Dionysopoulos]

No. FOF was created as a replacement to Koowa (Nooku Framework) for use with Akeeba Subscriptions after Koowa decided to create a massive backwards incompatibility with zero advance warning. It literally broke everything overnight. I had to choose between rewriting my component (and risk needing rewriting again in a few months) or roll my own framework. I chose the latter. As I was developing for Joomla! 1.5 and 1.7 at the time yes, I also happened to add some abstraction to some of their differences. I would be a complete moron if I tried developing one framework for each Joomla! version... Don't take one minor also-ran feature and blow it out of proportion. FOF is NOT a Joomla! version abstraction framework. If it were we wouldn't be having this discussion ;)

Nicholas K. Dionysopoulos

Lead developer and owner, Akeeba Ltd. 

Sent from my iPhone. Please excuse my brevity. 

[Nicholas K. Dionysopoulos]

As I said, I have no objection to either way as long as I get to review all FOF-related commits. As Davide can tell you, despite the best intentions, sometimes developers miss the big picture and create a patch which is a hack around their particular problem even though there was a more elegant way already implemented. I want to review patches to make sure committed code had merit, is not a hack and does not add to the cruft level of the framework. 

Nicholas K. Dionysopoulos

Lead developer and owner, Akeeba Ltd. 

Sent from my iPhone. Please excuse my brevity. 

[Nicholas K. Dionysopoulos]

Regarding 3, I did not explain it correctly. I announce deprecated stuff and their replacement three months before a release. With one major release every year, developers have 12 + 3 months to deal with it. Joomla! deprecates things a year in advance, they are usually not announced in detail (that changed with 3.0 and I am grateful for thatl) and there is no replacement in some cases until they become obsolete

Nicholas K. Dionysopoulos

Lead developer and owner, Akeeba Ltd. 

Sent from my iPhone. Please excuse my brevity. 

[Ronni KC]

All of us 3rd parties who make big components or multiple components will end up making our own FOF's - simply because its needed.

So lets not reinvent the wheel all over, lets work together and put the combined efforts into FOF instead.

If FOF goes into the core with CMS 3.1 we will use it with a new 5000+ hour development project - and in this process i am sure we will have contributions that will help make FOF even better in the future too :)

[Michael Babker]

My two cents is that FoF would be integrated like a third party library, meaning unless it was absolutely necessary to hack something to make it work (we've done it to the Bootstrap JS due to MooTools conflicts), we wouldn't touch it aside from updates.

As someone who hasn't thoroughly looked at the code (but man was my excitement peaked listening to your JAB presentation), I think there's a good bit of merit to this proposal.  As with any proposal adding another third party library, there's a need for discussion which is happening here, and I think overall we can find a way to keep everyone happy and expand the possibilities for development.  It was pointed out before that we aren't forcing FoF on anyone (nothing's being converted at this point or written new with it for core), which is how it should be for a third party library IMO; if you want it, use it, otherwise ignore it.  For those saying they don't want it, this would be a great time to get to a Square One approach to optional extensions, but that's a discussion for another time ;-)

From: "Nicholas K. Dionysopoulos" <niko...@gmail.com>
Reply-To: <joomla-de...@googlegroups.com>
Date: Wednesday, February 20, 2013 2:25 AM
To: "joomla-de...@googlegroups.com" <joomla-de...@googlegroups.com>
Subject: Re: [jgen] Re: New tracker item: add Framework on Framework to Joomla 3.1

As I said, I have no objection to either way as long as I get to review all FOF-related commits. As Davide can tell you, despite the best intentions, sometimes developers miss the big picture and create a patch which is a hack around their particular problem even though there was a more elegant way already implemented. I want to review patches to make sure committed code had merit, is not a hack and does not add to the cruft level of the framework. 

Nicholas K. Dionysopoulos

Lead developer and owner, Akeeba Ltd. 

Sent from my iPhone. Please excuse my brevity. 

20 ??? 2013, 10:18, ?/? Allon Moritz <allon....@gmail.com> ??????:

[Don]

Does that mean if it is not in core then you won't use it? Why have that attitude? I'm sure you know how simple it is to package 3rd party libraries with your code. 

Sent from my iPhone

--

[Ronni KC]

No - i meant that if FOF is in the Joomla distribution - as a 3rd party library or in the "core" we will use it.

So wrong use of the term core - something beeing multi-lingual is a challenge :)

[Donald Gilbert]

Let me rephrase: If it's not included in the Joomla distribution, you will not use it? Why? You do know how easy it is to package 3rd party libraries with your code, right? Don't limit your resources to only code included with the Joomla download.

[Donald Gilbert]

The release notes on the FOF wiki have me a little concerned, as BC is very clearly dropped without an explanation:

Joomla! 1.5/1.6/1.7 compatibility dropped

FOF 2.0 will only work on Joomla! 2.5 and 3.x. This is a strategic change. I am not at liberty to explain why, but I hope that by March I will be able to share the reasoning with you and you'll understand the untypical secrecy. Thank you for not asking (I won't tell you a thing if you do ask me).

What's the reason for the secrecy? If / when this does get merged into core, I would hope this wouldn't continue.

[Ronni KC]

I think you fail to understand the importance of the collaborate efforts behind us doing this together - and the signal value it has to add FOF into the CMS.

Adding FOF to Joomla (whatever way it happens) makes it alot more interesting to utilize for a lot of people - exactly the same reasoning and argument could you set for Boostrap et al.

FOF offers an instant solution to some of the many short comings there is in the CMS.

Beyond that some of the most popular extensions for Joomla on the planet is already built on FOF and one of the most respected 3rd party developers in our community is behind it.

So in my book its not a hard choice.

[Donald Gilbert]

IF it's that great - then let's rewrite the CMS to use those classes. Developers know where to find resources. And FOF development is open to pull requests, I don't see how it benefits END USERS to include it in the core. Dev's know where to find their resources. 

[brian teeman]

Well that cant happen until the library is added can it - chicken and egg

On Wednesday, 20 February 2013 16:46:55 UTC, Donald Gilbert wrote:

IF it's that great - then let's rewrite the CMS to use those classes. Developers know where to find resources. And FOF development is open to pull requests, I don't see how it benefits END USERS to include it in the core. Dev's know where to find their resources. 

On Wed, Feb 20, 2013 at 10:38 AM, Ronni KC <ron...@gmail.com> wrote:

I think you fail to understand the importance of the collaborate efforts behind us doing this together - and the signal value it has to add FOF into the CMS.

Adding FOF to Joomla (whatever way it happens) makes it alot more interesting to utilize for a lot of people - exactly the same reasoning and argument could you set for Boostrap et al.

FOF offers an instant solution to some of the many short comings there is in the CMS.

Beyond that some of the most popular extensions for Joomla on the planet is already built on FOF and one of the most respected 3rd party developers in our community is behind it.

So in my book its not a hard choice.


Den onsdag den 20. februar 2013 15.40.54 UTC+1 skrev Donald Gilbert:

Let me rephrase: If it's not included in the Joomla distribution, you will not use it? Why? You do know how easy it is to package 3rd party libraries with your code, right? Don't limit your resources to only code included with the Joomla download.

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

But if you read the thread Brian, the consensus is to NOT rewrite the core onto FOF.

[Ronni KC]

The consensus forming seems to be to add FOF as a 3dp library in the Joomla CMS distribution - as far as i can count.

Some suggested it even more integrated - but i think adding FOF as a 3dp library for CMS 3.1 seems to be a darn good solution :)

Then we keep it all open - the core components _could_ utilize FOF, the CMS could also get smarter/better/etc and evolve / be inspired / etc - but in any case adding FOF is a instant solution offering things we would not see till CMS 4 (in my opinion).

[brian teeman]

On Wednesday, 20 February 2013 16:54:40 UTC, Donald Gilbert wrote:

But if you read the thread Brian, the consensus is to NOT rewrite the core onto FOF.

YEs I read that - I was answering you specific comment which also ignored the previous statements about the core

[Andrew Eddie]

Amy pretty much summed up the queries I had. I have no doubt that the code most likely rocks (Nic's is amongst a short list of developers whose components I trust to run on my site), but this seems to be a deviation to what we've traditionally done (that's not to say you should always do what you've always done).

In terms of the code offering, I would treat it no less than a new contribution to the Platform. That would require:

1. Better than 80% unit test coverage.

2. Passes code style checks.

3. Has full developer documentation over and above the API DocBlocks (see the Platform Manual for what I mean).

My main concern though is why we are dropping in an opt-in library to augment the core code? Why not just augment the code directly? Additional, if this is added, we'll now have three ways to do MVC (the old way, the new way and the FoF way). I'm not against adding it per se, but it seems that we could equally argue to drop in Symfony, Cake, Fuel, or any other external framework along the lines of "you don't have to use it if you don't want to". It's grating on my inner-architect and I don't see any compelling reason why it can't be just treated as an installable library - we set the installer up to handle this kind of case.

Regards,

Andrew Eddie

[Donald Gilbert]

@Brian - My comment was why is the consensus to NOT rewrite it onto the core if FOF is so great? Why wouldn't we use it?

I'm really where Andrew is at with the whole thing. I'm not 100% against it, I just want to be sure all avenues are explored, rocks are unturned, and questions are answered. So in a year, when someone asks questions we have something to point them too so they can see why / what decisions were made, and who made them.

--

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.

[Ronni KC]

Andrew:

So future commits to the CMS is on par with requirements for the platform onwards? Is this new policy from the PLT or an opinion? (just clarifing).

FOF is an extension of Joomla - not a standalone framework - there is a big difference.

We could built everything FOF offers in Joomlas Core - but realisticly (please) we are talking CMS 4 atleast to get close.

Right now i think adding FOF as a 3dp library makes available a great solution - while the new platform maintainers and the platform finds its feet and the CMS and Platform get planning for the future.

So FOF is not only nice - the timing is very nice.

[Donald Gilbert]

So let's assume it gets added to the distribution.

Does it then become the goal of CMS v4 to build itself on FOF?

Or is it then the goal to integrate FOF code into the core (it would no longer remain FOF, it would become J code)?

Does FOF offer everything that we want the CMS to become for v4? Or is it merely offering an advanced v3?

In regards to Andrews 80% number, are you against that approach? Shouldn't code that get's added to Joomla have great documentation so that it's VERY clear how to use it? It's my belief that one of the reasons so many struggle with developing with the CMS now is because of an utter lack of clear documentation on how to utilize core classes properly. Just look at all the questions on JGen like "How do I do this?"

--

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.

[brian teeman]

Asking a question here not commenting

Did the 80% rule get applied to all external libraries before they were included in the core

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

[Donald Gilbert]

I wasn't around then, but if I took a guess, I'd say no. But we haven't added a new 3rd party since the 1.5 days (we've updated, but not added new) so, there really is no precedent. Also, none of the existing 3rd party libs were meant to augment / replace core classes. So, no matter what, this is entirely a special case, and needs thorough consideration and due diligence. Whatever the outcome, it will have lasting effects on the J community ( not necessarily bad :] )

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

[brian teeman]

Isn't bootstrap an external library?

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-general+unsubscribe@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.
 
 

[Ronni KC]

For me the goal of CMS v4 is stil something we need to figure out together - and as well the interaction with the platform.

I want more of the platform and CMS planned in cooperationer because that makes more sense i think.

So as for if FOF will inspire the Core etc. lets see where it goes over time - i dont think its an argument to not include FOF as a 3dp library.

So for me - for now - untill we know where we are going on 4.x i think FOF offers an advanced 3.x that will elevate the practical level for 3.x series of the CMS with very little work involved.

I am not against unit testing etc. on the contrary we will volunteer to chip in manhours to add what we can - but talking unit testing in the CMS is also more complex than in the platform - does the figure make sense?

I am not fearing lack of documentation etc. either.

What i fear is that some shortcomings on the short run will prevent it from going into CMS 3.1 and then we loose momentum and another 6 months of nothing.

Also perhaps i was not clear in my answer earlier i see - let me use myself as an example.

I own the worlds largest consultancy business working purely with Joomla.

I employ 60 people working 100% with Joomla.

Now in a short time we start a big development project on 5000+ man hours.

Could we use FOF? Yes we could but without the formal inclusion it would not be an easy choice.

Would we use FOF if included in Joomla? Yes 100% - and we would add to it too.

Its a matter of the psycholocigal effect and the formality of being included - look what happens once bootstrap got included.

If we add FOF to CMS 3.1 - we will see tons of developers start using it.

If we dont FOF will still be great - but it will be a lot less used because people will think "ohh yes but its not in the distribution".

So on all accounts - i say lets get it in there and if there is wishes of more unittesting, documentation etc. lets get that done on the path to the release of J3.1 :)

[Rouven Weßling]

I've read most of the thread but I'm missing an important piece of information.

1. Is Nick submitting his code or are we just including it?

2. What license will the code be? To my knowledge FOF is currently GPL3+. Would that change?

Rouven

[Andrew Eddie]

On Thursday, 21 February 2013 06:22:42 UTC+13, Ronni KC wrote:

Andrew:

So future commits to the CMS is on par with requirements for the platform onwards? Is this new policy from the PLT or an opinion? (just clarifing).

I said that's how "I" would (and do) treat it.

Regards,

Andrew Eddie

[Donald Gilbert]

@Brian - Not in the libraries/ folder, and it's not PHP, so code style and test coverage doesn't matter. Please stop throwing up straw men.

[Donald Gilbert]

@Ronni, I'm not sure why you and Brian keep comparing this to integrating the Twitter Boostrap lib - it's 100% different.

5000+ man hours? That's over a years work for 1 dev. :) Should produce something awesome then - looking forward to seeing it.

Again, I'm not sure why you wouldn't use the "best tool for the job" - it shouldn't matter if FOF is "blessed" by including it the core, and thus perception is different. Nick has already guaranteed that FOF will be around and supported for a long time, so - again I'm not sure why you would have reservations of using it just because it wasn't included in core.

[brian teeman]

On Wednesday, 20 February 2013 18:23:01 UTC, Donald Gilbert wrote:

@Ronni, I'm not sure why you and Brian keep comparing this to integrating the Twitter Boostrap lib - it's 100% different.

I 100% dont see the difference but I'm not going to waste my time. You've clearly made your decision and are just creating imaginary barriers that need to be overcome. At which point you will probably create more imaginary barriers.

 

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

[Donald Gilbert]

I 100% dont see the difference but I'm not going to waste my time. You've clearly made your decision and are just creating imaginary barriers that need to be overcome. At which point you will probably create more imaginary barriers.

Bootstrap is HTML, CSS, and JS that lives in the /media/ folder.

FOF is PHP that would live in the /libraries/ folder.

See the difference? 

[Bakual]

I think a main question would also be what happens if Nic updates his FoF.

 

If we include it as a regular library in /libraries/fof like it is today, it could be overwritten by any extension who includes another version of it. So this option probably is bullshit as any extension including a different (older or newer) version of it could possibly break other extensions using it. That would be a nightmare.

 

So FoF would need to be included into /libraries/cms/fof or something. But then it will probably only be updated on the bigger Joomla updates since it's an external library and needs proper testing before an update happens. Kind of like when we update Bootstrap. Now what happens if Nic updates his FoF: I'm sure he doesn't want to wait till the CMS takes over his changes, and he will not be able to rely on new code since he doesn't know what version of Joomla (and thus FoF) is installed. He will include his current release of FoF in his extensions like he did so far, maintaining /libraries/fof like he always did. Other developers will do the exact same. I don't see a gain here.

 

I'd rather see Joomla including some of the improvements FoF makes into the core. That could be done by adding the classes to the CMS or by improving existing ones with the added functionality. As long as it doesn't break backward compatibility I don't see an issue with this. And developers can rely on the classes and functions being available in a specific Joomla version.

 

And I would like to see a way to register an extension to a library version. So let's say my extension uses FoF 1.3 and my extension ships with it. Then I would like to tell Joomla that my extension uses this version and Joomla should not allow other extensions to overwrite the library with a different version which probably breaks my extension. So Joomla would be allowed to install for example a FoF version 1.4, but not FoF 2.0 (assuming major versions have backward compatibility breaks) and not FoF 1.2 (assuming older versions miss functionality). Currently I would never rely on such a library myself if it's installed in the global /library path. I just don't have control over it.

[Nicholas K. Dionysopoulos]

Hello all,

First of all let me be absolutely blunt and perfectly honest. FOF is licensed under the GPLv3 or later. By agreeing to include it with the Joomla! CMS I get to relicense it under GPLv2 which I don't like (especially because GPLv2 lacks the patent protection offered by GPLv3). I will overlook this issue for the benefit of the community. If it does end up being distributed with the Joomla! CMS I also get to lose a lot of my business' flexibility. So far, if I needed to implement a new feature in my software which required a new feature in FOF I could simply code it in and distribute it with the next version of my software. By agreeing to distribute it with the Joomla! CMS I lose that privilege and I have to wait for about 6 months. So, please, all of you, do understand that including FOF in the Joomla! CMS only has major drawbacks for me personally which I am willing to overlook for the benefit of the community. It's not like I want to force it down your throat.

This was the context of my replies to your queries which follow below.

@Andrew:

> In terms of the code offering, I would treat it no less than a new contribution to the Platform.

Why is that and not the case for each and every other third party library included in the CMS? Please don't tell me "because we know the other third party libraries work". I can counter-argue that we already know that FOF does work within the same level of confidence as with other third party libraries. With a major difference. Joomla! cannot influence the development of, say, PHPmailer and its developers are not so keen to listen to our feedback. Joomla! can influence the development of FOF and I am very keen to listen to the Joomla! developer community's feedback. But that's a load of bull and I won't claim this is a serious argument. I agree that everything you mentioned is desirable.

If that is required I can definitely work on code style (I've already done a lot of work in that area). I will provide better documentation anyway. The plan is to provide a developer's guide for FOF, dealing with both the big picture and each class in particular, initially based on what we have on the wiki already. It's something I'm planning on doing no matter if it's distributed with the CMS or not. I didn't do it yet because my first priority was to develop, document and test new versions of my existing extensions and two new extensions. I did that because that's the only way for me to test FOF given the lack of unit tests. It's Catch-22, isn't it? :)

Now, why no unit tests? I can't do unit testing because I don't have the experience and there are no MVC unit tests in the CMS that I could use as a starting point. I am lost. I admit that I have no idea whatsoever how to do unit testing of the MVC classes. Lacking the experience, I am afraid that my unit tests will be utter crap and useless (no point covering 80% of the code with tests that can't possibly fail because I have no idea what to test against, right?). If someone can come up with the initial unit tests I can study them (I learn quickly!) and add to them. But I can't do it by myself. Please, please, PRETTY PLEASE, if anyone out there CAN write unit tests and is willing to help me, PLEASE contact me. I beg you! I've been saying that since JaB12. I've had a few people say they would contact me, but none did. So, PLEASE, help me in this area. There's a limit to what I can do.

> I'm not against adding it per se, but it seems that we could equally argue to drop in Symfony, Cake, Fuel, or any other external framework along the lines of "you don't have to use it if you don't want to". It's grating on my inner-architect and I don't see any compelling reason why it can't be just treated as an installable library - we set the installer up to handle this kind of case.

The answer lies in the question itself. Symfony, Cake, Fuel or whatever is not extending from Joomla! and follows a completely different mentality regarding application architecture. Trying to use them for a Joomla! extension is like using a large hammer to force a square peg in a round hole. On the contrary, FOF doesn't depart from the Joomla! architecture and mentality. It extends, it doesn't replace. You have to use it to understand this point. I deliberately stuck with Joomla! CMS conventions. Judging from the feedback of the dozen or so developers already using FOF who have contacted me I guess it was a good idea that leads to its easier adoption.

@Don and Ronni:

> We could built everything FOF offers in Joomlas Core - but realisticly (please) we are talking CMS 4 atleast to get close.

This pretty much tells the story. Refactoring complex components requires a dedicated developer and 2-3 months for each one. Given our abundance of core components and shortness of time and developers we can't realistically say that core components can be rewritten to use FOF for FOF to be distributed with the core. We could begin such a process and do progressive refactoring. IIRC, core components were not updated overnight to the Joomla! 1.6/1.7/2.5 architecture. It took two (or was it three?) releases to get there.

> Does it then become the goal of CMS v4 to build itself on FOF?

It doesn't make sense to convert all components. Even though you can, there's no point. I am not in favour of change for change's sake. I don't see the merit of converting com_login to FOF. I do see a huge merit converting com_users and com_content to FOF for third party developers and, by extension, end users of the CMS. Should such a conversion be the goal of CMS 4.0? I can't answer that because I would be seen as trying to force something down everyone's throat.

> Or is it then the goal to integrate FOF code into the core (it would no longer remain FOF, it would become J code)?

Well, given my loss of flexibility even if it's just integrated into the core either way is fine with me. I would love to have the final say on architecture but I'm willing to lose that privilege if that would somehow benefit the Joomla! community.

> Does FOF offer everything that we want the CMS to become for v4? Or is it merely offering an advanced v3?

Neither and both. The major feature it has is that it allows developers –even those starting up with CMS extensions development– to roll out extensions fast. My vision is eventually providing a component builder. Unlike existing component builders it will not churn out epic amounts of ill-documented, impossible to read code. I envision a component builder which generates stark amounts of code using FOFForm and XML to render the component's interface and which can be easily extended by an outsourced developer with basic Joomla! and FOF knowledge. That's my end game, if you want.

> Could we use FOF? Yes we could but without the formal inclusion it would not be an easy choice.

> Would we use FOF if included in Joomla? Yes 100% - and we would add to it too.

I do see your point, Ronni, but I don't "buy it". No matter if it's distributed with the CMS or standalone it's the same library.

> Again, I'm not sure why you wouldn't use the "best tool for the job" - it shouldn't matter if FOF is "blessed" by including it the core, and thus perception is different. Nick has already guaranteed that FOF will be around and supported for a long time, so - again I'm not sure why you would have reservations of using it just because it wasn't included in core.

I agree with Don on that one.

> @Ronni, I'm not sure why you and Brian keep comparing this to integrating the Twitter Boostrap lib - it's 100% different.

Not 100% different, just 50% :) In theory, Bootstrap should be unit tested. Actually, Selenium-tested to make sure that all core components output valid Bootstrap markup. Obviously, lacking actual PHP code, you can't do unit tests on the non-existent PHP code and we don't do JS unit testing anyway.

@Rouven:

> 1. Is Nick submitting his code or are we just including it?

A bit of both. Developers using FOF thought that it would be a good idea to include that in the CMS and kicked off this discussion. Since my code is GPLv3 I have to relicense it, essentially having me submit my code. As I have signed the developer agreement (sorry, I can't remember the exact title of the document) any code I submit is licensed under the proper J! license. Does that make sense?

> 2. What license will the code be? To my knowledge FOF is currently GPL3+. Would that change?

Yes. Even though I am not a fan of GPLv2 I am willing to bite the bullet and relicense it.

Best regards,

Nicholas K. Dionysopoulos

[brian teeman]

Thank you for the detailed reply (o your birthday) Nicholas

[Donald Gilbert]

Great answers Nick that really get to the core of the issues. Thanks for the food for thought.

--

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.

[Donald Gilbert]

I'll work on any more questions that I have and ask them here later. Lot's of work just came up. (lunch)

[Bakual]

A main issue is that FoF also looses a main feature if it's included into Joomla: It will no longer be possible to use FoF as an easy way to support multiple Joomla versions in your extensions. In the end you would face the same issue we already have with the Joomla core. You would have to support multiple FoF versions in your extension, or you just raise the minimal Joomla version for your extension.

As I understand it one main improvement of FoF is that you can develop Joomla extensions for Joomla 1.5 up to Joomla 3.0 without using different code and switch statements. You can even use bootstrap on Joomla 2.5 or query builder on Joomla 1.5. That will not work onward from today if it gets included in Joomla 3.1, you will not be able to use new FoF or Joomla features on a Joomla 3.1 installation. Since the features just will not be present in the installed library.

 

One big thing about FoF is that you ship it with your extension and you know what will be available, and that you can use it on any Joomla installation using the same code.

[Nicholas K. Dionysopoulos]

Hello Bakual,

I would appreciate it if you had spend 5 minutes to read my first posts on this thread before offering your opinion based on false assumptions.

> I think a main question would also be what happens if Nic updates his FoF.

The Joomla! CMS project will include it in the next release, whenever that is. If I do a minor update it can be included in the next subminor Joomla! version. If I do a major update we will have to cooperate, evaluate the impact (which is guaranteed to range from minimal to non-existent because backwards compatibility is the primary feature of FOF) and decide when to include it.

> If we include it as a regular library in /libraries/fof like it is today, it could be overwritten by any extension who includes another version of it. So this option probably is bullshit as any extension including a different (older or newer) version of it could possibly break other extensions using it. That would be a nightmare.

I will say it again, in bold capital letters to catch your attention: ALL FOF VERSIONS ARE BACKWARDS COMPATIBLE WITH THE SAME MAJOR VERSION AND THE MAJOR VERSION PRECEDING IT. I said it in my first posts on this list. The only "bullshit" I see in your option is that it won't happen. Even if a lazy developer forgets to check for Joomla! 3.1+ and proceeds with the FOF installation code, the currently installed version is checked and an older FOF version cannot be installed. So, old versions cannot be installed and new versions do not cause a problem (see bold letters). Please read https://akeeba.assembla.com/spaces/fof/wiki/3_Installing_FOF_with_your_component Let me reiterate that even if what you mention does happen it doesn't cause any issues because I've gone to great lengths to make sure newer FOF versions are backwards compatible (see bold letters above).

> So FoF would need to be included into /libraries/cms/fof or something. But then it will probably only be updated on the bigger Joomla updates since it's an external library and needs proper testing before an update happens. Kind of like when we update Bootstrap.

See above.

> Now what happens if Nic updates his FoF: I'm sure he doesn't want to wait till the CMS takes over his changes, and he will not be able to rely on new code since he doesn't know what version of Joomla (and thus FoF) is installed. He will include his current release of FoF in his extensions like he did so far, maintaining /libraries/fof like he always did. Other developers will do the exact same. I don't see a gain here.

Wrong assumptions leading to FUD.

1. I will not be able to rely on my new code. See #3.

2. I don't know what version of Joomla (and thus FOF) is installed. OK, I will take that as a joke. Of course I do know because they both let you know of their exact version and date of release. Hints: JVERSION and FOF_INCLUDED constants (not to mention the #__extensions table).

3. I will include the current release of FoF in my extensions. No, I won't (after 2.5 is out of comission). In the meantime I will include FOF with my extensions and install it only on Joomla! 2.5. It's rather trivial. If I have to rely on a feature found in an interim version of FOF not included in Joomla! yet I can, at installation or run time, detect an old version of FOF (because we always know the installed versions) and tell the user to install the new version of FOF using an downloadable, installable package. I can do that without hesitation because of what I wrote in the bold letters above. As a result this will have no ill effect on other extensions using FOF. That's exactly why I put all the extra work to ensure backwards compatibility and have rejected patches which would break it: upgrading FOF (within the same or the next major version) is supposed to not break existing extensions. That's non-negotiable. It's a requirement. Backwards incompatibility is a bug.

That's why we would ideally need unit testing for FOF, so that any change is guaranteed (by unit testing) that it has no adverse effect on existing extensions. Again, if anyone can help with unit testing please do.

> I'd rather see Joomla including some of the improvements FoF makes into the core. That could be done by adding the classes to the CMS or by improving existing ones with the added functionality. As long as it doesn't break backward compatibility I don't see an issue with this. And developers can rely on the classes and functions being available in a specific Joomla version.

Which is pretty much the same as including it in the CMS distribution because you will know which classes and methods are available on each CMS release. Just like we have to do if(version_compare(JVERSION, '3.0', 'ge') { ... } with existing extensions. If you have written extensions compatible with at least two versions of Joomla! with the same codebase you know perfectly well what I mean. Not to mention that unlike Joomla! (which can include backwards incompatible changes between major versions) FOF can't. I could easily break BC in FOF 2.0. Instead, I spent a week working around BC issues, even though I could rewrite my own extensions to the new standards. But doing so would mean that I'd break the extensions Jurian, Davide and other developers have made based on FOF. That's what drove me away from Nooku and I'd be damned if I did the same mistake with FOF!

> And I would like to see a way to register an extension to a library version. So let's say my extension uses FoF 1.3 and my extension ships with it. Then I would like to tell Joomla that my extension uses this version and Joomla should not allow other extensions to overwrite the library with a different version which probably breaks my extension. So Joomla would be allowed to install for example a FoF version 1.4, but not FoF 2.0 (assuming major versions have backward compatibility breaks) and not FoF 1.2 (assuming older versions miss functionality). Currently I would never rely on such a library myself if it's installed in the global /library path. I just don't have control over it.

No, no, no! See the bold letters above. In the worst case scenario you can check which FOF version is installed and ask the user to install a newer version in the same or the next major version. If something works on FOF 1.3 it works on FOF 2.0. The only thing I removed was FOFQueryAbstract because it was a fork of JDatabaseQuery. That was necessary for Joomla! 1.5 extensions, but it makes no sense maintaining it for FOF 2.0 which only runs on Joomla! 2.5 and 3.x. I could have easily included a stub class FOFQueryAbstract extends JDatabaseQuery but it made little sense (and it wasn't really being used by other developers). That's the only BC issue and I did check that it didn't screw other developers before ultimately deciding not to bother maintaining this forked class.

Is this abundantly clear why I am treating backwards compatibility as king? I thought of the issues you mentioned about 18 months before you did and solved them. I don't want MY extensions to need extensive rewrites. I don't want MY extensions to break one another when one of them is updated (and updates FOF) and the other one is not. I don't want MY extensions to break YOUR extensions. So, backwards compatibility is king. It's really as simple as that.

> A main issue is that FoF also looses a main feature if it's included into Joomla: It will no longer be possible to use FoF as an easy way to support multiple Joomla versions in your extensions. In the end you would face the same issue we already have with the Joomla core. You would have to support multiple FoF versions in your extension, or you just raise the minimal Joomla version for your extension.

False assumption, see above. Not to mention it's not a major feature, it's a corollary.

> As I understand it one main improvement of FoF is that you can develop Joomla extensions for Joomla 1.5 up to Joomla 3.0 without using different code and switch statements.

Wrong assumption. You still need to use switch statements. If you don't believe me search Akeeba Backup for JVERSION. 136 matches in the component and 15 matches in the modules and plugins.

> You can even use bootstrap on Joomla 2.5

That's not FOF. That's Akeeba Strapper, a library which uses FOF but is not part of the FOF library itself. I happen to bundle both, but it's not necessary.

> or query builder on Joomla 1.5

This is a removed feature as FOF 2.0 does not run on Joomla! 1.5, at all.

> That will not work onward from today if it gets included in Joomla 3.1, you will not be able to use new FoF or Joomla features on a Joomla 3.1 installation.

Wrong assumption. Akeeba Strapper is an unrelated library which you can use on your components. It's not required on Joomla! 3.x unless you want to use Bootstrap styling on templates which do not provide Bootstrap styles. You wouldn't be able to use the query builder with FOF 2.0 on J! 1.5 because FOF 2.0 doesn't run on 1.5. And since we're talking about J! 3.1, it doesn't need the query builder, it has one of its own. Besides, FOF would be included as-is, with the version switch statements (all 52 of them).

> Since the features just will not be present in the installed library.

Wrong assumption, see above.

> One big thing about FoF is that you ship it with your extension and you know what will be available, and that you can use it on any Joomla installation using the same code.

That was the idea behind putting it in Joomla!. You won't have to ship it any more with your extension.

[Bakual]

I see that I've made false assumptions and apologze for it. I did read your post before, but obviously didn't get everything right (not native english myself). And of course I didn't want to attack you nor FoF.

 

However I still don't see the main improvement. If you already take care of version checking and everything, and it is so easy to include in an extension, why even take the drawbacks you listed? I would think the flexibility and control you have over your framework would weigth a lot more than offering an even easier way for developers to use it.

Personally I think the community would benefit more from a more flexible system like it is today.

[Rouven Weßling]

On 20.02.2013, at 19:49, Nicholas K. Dionysopoulos <niko...@gmail.com> wrote:

> 1. Is Nick submitting his code or are we just including it?

A bit of both. Developers using FOF thought that it would be a good idea to include that in the CMS and kicked off this discussion. Since my code is GPLv3 I have to relicense it, essentially having me submit my code. As I have signed the developer agreement (sorry, I can't remember the exact title of the document) any code I submit is licensed under the proper J! license. Does that make sense?

Completely. You managed to pinpoint the reason why I was drawing the distinction.

> 2. What license will the code be? To my knowledge FOF is currently GPL3+. Would that change?

Yes. Even though I am not a fan of GPLv2 I am willing to bite the bullet and relicense it.

Thank you for this!

Best regards

Rouven

[r...@osdcs.com]

Can I just ask a quick question?

WHat is this FOF and will I have to rewrite my J3.0 extension that I've already invested $50k in development to that it will work for the next release of Joomla?

Or, because my extension works with J3.0 already, will it be ok?

---

From: joomla-de...@googlegroups.com [mailto:joomla-de...@googlegroups.com] On Behalf Of Donald Gilbert
Sent: Thursday, February 21, 2013 12:18 AM
To: joomla-de...@googlegroups.com
Subject: Re: [jgen] Re: New tracker item: add Framework on Framework to Joomla 3.1

[Nicholas K. Dionysopoulos]

Yeah, sorry, I didn't mean to appear to be a psychopath :D I was miffed with something unrelated and some of my bad temper seems to have slipped in my reply to you. I'm not a native English speaker either. No problem, it's all good :)

[Ronni KC]

It does in no way affect your J3.x extension - it is fully non-excluding, non-dependancy creating, non-legacy in terms of all existing pure Joomla extensions for J2.x and J3.x

That is what makes it so smooth :)

[Nicholas K. Dionysopoulos]

Hello Rob,

First, replying to your most important question: No, you will NOT have to rewrite your extension. I have always ranted about how large, backwards incompatible changes will be detrimental to the CMS and developer adoption. I'd rather be violated with a cactus than causing such a despicable situation myself!

Now, to your least important question. What is FOF? I'm glad you asked. Everyone else over here took it as granted. FOF is a rapid application development framework for Joomla!. It extends Joomla! but does not undermine or replace it. It's an add on. Think of Joomla! being the BLT (that's a common kind of sandwich for the non-US folks... like me) and FOF being the extra hot ketchup and mustard. If you like your sandwich simple and plain you can have your straight BLT. If you crave for the extra spice, throw in the hot FOF ketchup and mustard. You can eat your Joomla! without FOF or you can eat it with FOF. You can definitely not eat FOF without Joomla!. Hm, I might use that simile on my next FOF presentation.

Oh, speaking of which, here is my latest FOF presentation, as delivered in the Joomla! World Conference: http://www.youtube.com/watch?v=Yue_DxKTHO0 It will answer most of your questions.

BTW, if I recall correctly you are a subscriber of mine or I have discussed with you on the former free support forum on my site. When you're installing my software do you see that very first item on the installation success message which says that Framework on Framework (FOF) was installed or updated? That's the same FOF we're discussing here.

On Wednesday, 20 February 2013 23:55:02 UTC+2, rgjoyce wrote:

Can I just ask a quick question?

WHat is this FOF and will I have to rewrite my J3.0 extension that I've already invested $50k in development to that it will work for the next release of Joomla?

Or, because my extension works with J3.0 already, will it be ok?

---

From: joomla-de...@googlegroups.com [mailto:joomla-de...@googlegroups.com] On Behalf Of Donald Gilbert
Sent: Thursday, February 21, 2013 12:18 AM
To: joomla-de...@googlegroups.com
Subject: Re: [jgen] Re: New tracker item: add Framework on Framework to Joomla 3.1

@Brian - My comment was why is the consensus to NOT rewrite it onto the core if FOF is so great? Why wouldn't we use it?

I'm really where Andrew is at with the whole thing. I'm not 100% against it, I just want to be sure all avenues are explored, rocks are unturned, and questions are answered. So in a year, when someone asks questions we have something to point them too so they can see why / what decisions were made, and who made them.

On Wed, Feb 20, 2013 at 11:11 AM, brian teeman <joom...@googlemail.com> wrote:

On Wednesday, 20 February 2013 16:54:40 UTC, Donald Gilbert wrote:

But if you read the thread Brian, the consensus is to NOT rewrite the core onto FOF.

YEs I read that - I was answering you specific comment which also ignored the previous statements about the core

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

[Donald Gilbert]

Nicholas, do you think the Joomla Community would be better served by integrating FOF into core, keeping in mind the limitations it puts on FOF and it's future development? Do you think the current FOF development strategy is somehow broken and that integrating FOF into the Joomla Distribution will make that process better?

From what I've read, you (rightly) see the detriments that integrating it will have on your personal development strategy, but beyond that, other devs implementing FOF will be effected in the exact same way. I'm with you in that it is a very good system for rapid application development, and I don't want to see that success hindered.

In my opinion, FOF would be better served to be PROMOTED by Joomla as a Rapid Application Development framework for devs who are interested.

[Mark Dexter]

@Donald: I agree that we should promote FOF. I would like to perhaps
see FOF used if/when we re-write core components. We have always tried
to "eat our own dog food" and I think this would be another example.
Also, by using FOF ourselves, we would be more likely to find (and
therefore fix) any shortcomings it might have. Mark

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

[Matt Thomas]

Is there any reason why it can't be included, at least for now, as an optional plugin?

Just exploring options :-)

Best,

Matt Thomas
Founder betweenbrain™
Lead Developer Construct Template Development Framework
Phone: 203.632.9322
Twitter: @betweenbrain
Github: https://github.com/betweenbrain

Composed and delivered courtesy of Nexus 7.

[Donald Gilbert]

It already IS an optional plugin (well, library), Matt. That's what makes it awesome. :) I don't see why we need to change it.

[Nikolaos K. Dionysopoulos]

Hello Donald,

Valid point. I hope that even around 1 a.m. my time I can maintain enough coherence to address it properly.

Just to frame my replies, let me tell you that I consider solving developer woes to be the key to the CMS thriving. The CMS by itself is great but can only go that far. There are plenty of CMS out there which can do pretty much what Joomla! does. The main strength of Joomla! is that what the CMS cannot (or should not) provide a third party extension does. In order to maintain and increase that strength we need more developers. Joomla! has a bad name out there as being either too hard to learn (development-wise) or having backwards compatibility issues. There's a grain of truth in them and if we are honest with ourselves we have to agree. Mastering the MVC is difficult. Elegantly handling ACL is even worse. Making everything work across 2.5 and 3.0 is challenging. These are barriers to entry that may be a little too high. 

FOF significantly lowers the barrier to entry. Paul was able to tweak the sample to-do list FOF component without being an experienced developer. I wrote a fully functional ticket system in a month, all the while maintaining my other extensions and doing support. With all the extra FOF 2.0 features (like FOFForm) that would have taken me 10-15 days less. All that because you no longer have to write a lot of repeated, copy-pasted code in your MVC components (the onBefore* / onAfter* methods usually suffice if and when needed at all), you don't have to explicitly handle database queries to do view filtering (unless you really want to - my ticket system is an example of how not to do it unless you are a raging masochist) and so forth. I could even add a nice JSON API to my release system by changing a total of 10 lines of code. Imagine that in a com_content clone based on FOF and a mobile application developer. Imagine a skinnable mobile application which works with every Joomla! site running this FOF clone. That would be awesome. It would open new avenues to site owners – and Joomla!. That's why I believe that the low barrier of entry (which will get better as I document it in my thorough documentation style you all, um, love) and powerful built-in features can benefit the Joomla! community. It doesn't have the instant gratification effect of, say, adding a tags component to the CMS –btw, great work Elin– but it can have the long term effect we're now missing as a community: attracting those very important, naturally lazy creatures called "developers". Yes, developers are lazy. If they weren't lazy they wouldn't work all day trying to squeeze the last ounce of automation out of every task imaginable; they'd do those tasks manually (developers have a strange definition of "lazy" and a wicked sense of self-sarcasm; they also refer to themselves in the third person).

Now moving onwards to why I would personally believe that FOF would benefit from being distributed with the CMS, to the degree that I am willing to forfeit a large degree of my business' flexibility to such an inclusion.

Right now FOF is seen as an Akeeba product. The positive connotation is that it's code by a trusted and well known developer. And that's where it ends. The downside is that to the many this is seen as "Akeeba's framework", designed to be used for Akeeba products and that's the end of the story. It's clearly not, but judging by the reactions of other people on this thread I realise that this is a major force holding back FOF adoption to a limited number of developers. Having it distributed with Joomla! is proof enough that Akeeba is far and wide from being the "Akeeba framework".

I would argue that, as with all open source projects, "the more, the merrier". There's a different class of bug fixes and feature patches you can expect to get when the project is visible to 50 developers and when it's visible to 5,000 or 50,000 developers. I don't doubt that putting it in the core will take FOF to places I have not yet thought of. That's not selfish. It's selfless. In this scenario all developers get to benefit from the improvements, not just me and my "followers" (I'm using the term light-hearted).

As I implied above, FOF is not well-known. Developers who are starting to write their own extensions or refactor their existing ones have probably never noticed it. For many of them that would be either their ticket to taking up Joomla! development or a very good tool to refactor their components to using less code. Having it in the CMS distribution will undoubtedly give it more visibility and hopefully help more people write more awesome software for this amazing CMS.

FOF is GPLv3. For some people that's a deal breaker (too bad for them, if you ask me). Unless it's included in the core I'm not going to change its license due to lack of adequate incentive.

With a handful of developers currently using it, it's easy to put restrictions like the proper way to install it (sadly, library packages do not allow us to use installation scripts to ensure an old version doesn't get accidentally installed). If that number increases I am sure that we'll end up with people unconditionally installing whatever version they please, breaking other people's extensions. Obviously, having it in the CMS distribution means that these people will be seen as breaking Joomla!, so they won't do it. Important note here: FOF is backwards compatible, not necessarily forward compatible. Installing a newer version is not a problem, installing an older one may just as well be.

If FOF is ultimately used in the outwards-facing, data-centric core components I can imagine a wealth of possibilities. For example, creating a user could be as simple as: FOFModel::getTmpInstance('Users','UsersModel')->save($userinfo); or the same thing accomplished by a PUT request to index.php?option=com_users using an AES-128 encrypted request with an encryption key augmented with a TOTP (this is built in to FOF already). Or rendering an article inside a module using something as simple as FOFDispatcher::getTmpInstance('com_content','article', array('id' => 123)->dispatch();. Or have a BMS system auto-publish an article to the Joomla!-based intranet when the air-conditioning is scheduled to go off-line for maintenance, without doing any kind of change or customisation to an out-of-the-box Joomla! installation. When you have HMVC and a JSON not-quite-RESTful-but-kinda API the sky is the limit.

Finally, it's the end game I casually mentioned a few posts ago: providing a component which allows non-developers to create their own components. If FOF is not included in the CMS distribution such a tool would be ill-maintained (there's only one of me and 24 hours in a day), not be visible enough (it would generate code for an obscure framework) and not useful enough (people would have to distribute both FOF and their component – for non developers that's Mission: Impossible). That means I don't have incentive to work on this. If FOF is distributed with the CMS this has the potential to become something awesome, therefore makes sense for me to spend time building it as it would help the Joomla! community. And I don't doubt that more people being familiar with FOF would mean more people offering their code and more usefulness coming out of it.

Best regards,

Nicholas K. Dionysopoulos

Email: niko...@gmail.com

Blog: www.dionysopoulos.me/blog

[Matt Thomas]

Sorry, I meant as an optional plugin that ships with Joomla core.

Best,

Matt Thomas Founder betweenbrain™ Lead Developer Construct Template Development Framework Phone: 203.632.9322 Twitter: @betweenbrain Github: https://github.com/betweenbrain

[Ronni KC]

I fully agree with Matt on this one - what is lost by doing atleast that?

Good post Nicholas - you put it a lot more clear what i have been trying to explain as to why it would make it a no brainer to go on with FOF for us if it gets included.

And also you bring up a crucial point for 3rd party developers - lets face it all of us struggle to keep up with new versions of Joomla - i know we do with the amount of extensions we have and at every single Jday, JAB, JWC you talk to others who has the same challenges of maintaining up to 3 different versions of your extensions to fit J1.5, J2.5 and J3.x.

Having something like FOF to make the transistions more painless will not be a bad solution - when the J1.5 extensions go away on JED it drops from 10,5k to 6k extensions - i guess its a number also containing some merit in its own way.

[Don]

Very clear and coherent Nicholas. :)

With the deadline for features fast approaching, would this be more reasonable to get into 3.2 to give you and those interested time to get these unit tests and documentation issues worked out? We may even by that time be able to work out name spacing and other (possible) features of the CMS and make 3.2 our best release ever. With clear developer documentation and a clear path on how to move forward, FOF could be the thing the CMS has been missing, but pushing it through within the final hours of feature freeze, IMO, could cause more harm / confusion than good. 

Sent from my iPhone

[Amy Stephen]

On Wed, Feb 20, 2013 at 6:08 PM, Ronni KC <ron...@gmail.com> wrote:

I fully agree with Matt on this one - what is lost by doing atleast that?

Does the installer support it? If not, will someone build it into the installer (quickly)?

I agree that this is a good direction. What it does is provide an opportunity to start to collect developer productivity tools  and make those optionally part of the install.

It would also allow the project to put those extensions that were removed back and allow others with dev tools to share. The tutorials being placed at Github and the Platform examples. 

I would even share JFoobar -- it creates a component. 47 comments in the magazine *beaming.* I actually did offer to the project as a feature - on Joomlacode - but at that time, it was thought that tools that generate components are only needed by developers and therefore not suitable for the standard repo.

Of course, I also know that JFoobar would quickly overshadowed by other component creators that are much more sophisticated.

This idea is something I believe would serve to accomplish those goals Paul outlined and help rebuild involvement. It would encourage developers to share with one another and it wouldn't create confusion.

Post 2. Amy So, I lied. But, I like this idea. =)

[Michael Babker]

At the moment, no it doesn't support it.  But, I do believe you were one of the people watching on Twitter that fateful day in December when I gave birth to said code ;-)

So, with some thinking, we could integrate the changes in https://github.com/JLite-POC/Framework into the CMS, and the next thing we know, all these great optional tools are available at the click of a button.

But, I'll leave my hi-jack at that.

From: Amy Stephen <amyst...@gmail.com>
Reply-To: <joomla-de...@googlegroups.com>
Date: Wednesday, February 20, 2013 6:45 PM
To: <joomla-de...@googlegroups.com>
Subject: Re: [jgen] Re: New tracker item: add Framework on Framework to Joomla 3.1

[Matt Thomas]

Having just watched Nicholas' JWC FOF presentation, I can honestly say that I haven't been this excited about Joomla in quite a while. I realise that this isn't necessarily quantitative input, but this is the kind of thing that can help invigorate growth and innovation within a project.

If it's not in core, I'll certainly pursue using it. But, it does seem like an good opportunity that the project can benefit from.

Best,

Matt Thomas
Founder betweenbrain™
Lead Developer Construct Template Development Framework
Phone: 203.632.9322
Twitter: @betweenbrain
Github: https://github.com/betweenbrain

Composed and delivered courtesy of Nexus 7.

At the moment, no it doesn't support it.  But, I do believe you were one of the people watching on Twitter that fateful day in December when I gave birth to said code ;-)

[Andrew Eddie]

On Thursday, 21 February 2013 04:49:56 UTC+10, Nicholas K. Dionysopoulos wrote:

@Andrew:

> In terms of the code offering, I would treat it no less than a new contribution to the Platform.

Why is that and not the case for each and every other third party library included in the CMS?

Before I answer that, let me say I'm just trying to express my professional and community opinion. I'm also not asking for anything I don't at least do or stand behind myself (for those that think I'm just making up rules for the sake of them, go visit what we do on the Platform sometime).

Now, I never mentioned the CMS. I only mentioned how I'd start to assess this contribution. I actually can't remember the last time we added an external library to the Platform - it's been some years. I can say that if one was added today, test coverage would be a significant factor in evaluating the pull request. Should it be different for the CMS? For me that's a yes and no answer. Yes, it should be different for component changes - I don't expect people to know how to mock our things properly at the extension level. However, at the library level, I equate that with what we do on the Platform. In other words, I don't think that the CMS should accept a lower standard than the Platform when considering adding library code.

 

Please don't tell me "because we know the other third party libraries work".

I won't tell you something I don't believe.

 

I can counter-argue that we already know that FOF does work within the same level of confidence as with other third party libraries.

And you'd be right.

 

With a major difference. Joomla! cannot influence the development of, say, PHPmailer and its developers are not so keen to listen to our feedback. Joomla! can influence the development of FOF and I am very keen to listen to the Joomla! developer community's feedback. But that's a load of bull and I won't claim this is a serious argument. I agree that everything you mentioned is desirable.

I'm happy to say that the extreme case that you are thinking is not remotely what I meant. I am slightly disheartened that you thought that of me though.

 

If that is required I can definitely work on code style (I've already done a lot of work in that area). I will provide better documentation anyway. The plan is to provide a developer's guide for FOF, dealing with both the big picture and each class in particular, initially based on what we have on the wiki already. It's something I'm planning on doing no matter if it's distributed with the CMS or not. I didn't do it yet because my first priority was to develop, document and test new versions of my existing extensions and two new extensions. I did that because that's the only way for me to test FOF given the lack of unit tests. It's Catch-22, isn't it? :)

It is and I know where you are coming from. I also know the pains that I've gone through to contribute code to the Platform. It takes time.

 

Now, why no unit tests? I can't do unit testing because I don't have the experience and there are no MVC unit tests in the CMS that I could use as a starting point. I am lost. I admit that I have no idea whatsoever how to do unit testing of the MVC classes.

I was there once myself. I was lucking enough to be trained by Sebastian when he came out to Australia once. I cannot understate that this changed the way I viewed development. It changed the way I code and my view of quality.

 

Lacking the experience, I am afraid that my unit tests will be utter crap and useless (no point covering 80% of the code with tests that can't possibly fail because I have no idea what to test against, right?). If someone can come up with the initial unit tests I can study them (I learn quickly!) and add to them.

I suggest you start borrowing from the tests for the new MVC. They are all pretty simple.

 

But I can't do it by myself. Please, please, PRETTY PLEASE, if anyone out there CAN write unit tests and is willing to help me, PLEASE contact me. I beg you! I've been saying that since JaB12. I've had a few people say they would contact me, but none did. So, PLEASE, help me in this area. There's a limit to what I can do.

I would hope that all the +1-ers would jump in and give you a hand. If 80% is too high, then what? Can you make it to 60%, 40%, 20% of the new code that is added? Even percent that is done now reduces the technical debt that "someone" has to pay in the future.

 

The answer lies in the question itself. Symfony, Cake, Fuel or whatever is not extending from Joomla! and follows a completely different mentality regarding application architecture. Trying to use them for a Joomla! extension is like using a large hammer to force a square peg in a round hole. On the contrary, FOF doesn't depart from the Joomla! architecture and mentality. It extends, it doesn't replace. You have to use it to understand this point. I deliberately stuck with Joomla! CMS conventions. Judging from the feedback of the dozen or so developers already using FOF who have contacted me I guess it was a good idea that leads to its easier adoption.

And that's what sets you apart from, for example, Nooku which made a huge song and dance about being bigger and better, with absolutely no intention of following through and adding any value to the core Joomla. However, I'm still not being convinced (yet) that it can't remain an external library in the same fashion as the JXtended libraries I worked on quite a few moons ago.

Several questions remain, mainly why use FOF* instead of adding directly to J*Legacy? Why not use the new MVC to base the HMVC on (I know, because it wasn't around when you wrote FoF - but now we have no less than 3 standards to work off)? Is the whole repo coming or just part of it (for example, your inflector already exists in the Platform - we don't need both)?

So, for me, I will tick the "it looks like a good idea", but there seems to me to still be some not-so-trivial amount of work to be done to get from there to a pull request that can be considered. I would expect that same sort of treatment for any type of proposal I put forward for changing the face of development (UCM comes to mind).

Please hear me, I am not deliberately trying to be difficult. I'm speaking from the "let's not repeat past mistakes" part of my heart. I don't need convincing that other people think this is cool stuff - that's obvious. We are adults and should realise that disagreement is permissible.

This pretty much tells the story. Refactoring complex components requires a dedicated developer and 2-3 months for each one. Given our abundance of core components and shortness of time and developers we can't realistically say that core components can be rewritten to use FOF for FOF to be distributed with the core. We could begin such a process and do progressive refactoring. IIRC, core components were not updated overnight to the Joomla! 1.6/1.7/2.5 architecture. It took two (or was it three?) releases to get there.

I would find it extremely helpful to see a semi-simple Hello World component and/or module that supports a simple list and simple edit form. I think that might help the penny drop for me in terms of taking this from "it sounds like a good idea" to "I can see how this is a good idea".

It doesn't make sense to convert all components. Even though you can, there's no point. I am not in favour of change for change's sake. 

I think there is a lot of value in maintaining consistency. 1.6 was much criticised for it's alleged "duplicate code" - but you only found out about that because all the extensions used the same methodology.

That's all I've got for now. Jet-lag starting to settle in.

Regards,

Andrew Eddie

[Nick Savov]

Hi all,

It's been a good discussion so far.  Thanks for taking the time to contribute!  Looks like we're at a pretty good transitioning point to start seeing the code and turn the discussion from a more theoretical one to a more tangible one.  Could someone add the code to the tracker item (the sooner, the better)?  http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=30136

As a reminder, with the new-feature deadline soon approaching, the code needs to be added to the tracker item (with testing instructions), tested, and have good test results...all in 4 days.  And "getting added to the core" assumes there's a consensus (from this discussion and the tracker item) that it should get added, as well as the regular review process.

Kind regards,

Nick

[Amy Stephen]

There is no way that in 4 days the Joomla developer community can evaluate this approach and provide feedback as to whether or not this should be the stated direction for future component development. It's impossible.

If you all think it's going to be great, it should go in. I have only one concern -- and that is configuring this in a way that Nic and the Platform team are set into a collaborative role, not in a role of conflict since both have been given the same responsibility and authority.

What has been discussed in this thread essentially puts what is being labeled an external library, and therefore an external developer, with full authority over the direction of how developers build components. Developers will be encouraged to use to create their extensions with full confidence knowing their work will be supported because it's in core.

That's all cool and groovy, but, this is a platform issue. So, giving Nick that authority and responsibility creates a conflict. The platform has already been given that authority and responsibility. Let's not leave it in such a way that people have to duke it out for authority. That's not the way to support people in their role.

I believe that it can all come together, but not in 4 days. Provided everyone is willing to proceed with the understanding there is no agreement at all about how that will work until the platform team and Nic figure it out, my concern is cleared.

Now, I am pretty sure no one is picking up on something that I believe is encouraging and it dovetails nicely with this and that is  Andrew's post last week https://groups.google.com/d/msg/joomla-dev-platform/yXS9fVE-93M/PbLu-O9293AJ

Nic - if you have not read it yet, please do. I believe your role and your tool could be the first "test case" for figuring out just what Andrew is suggesting, and that is building the next iteration of the platform in such a way that responsibility and leadership is spread out. It does matter *how* this is done because it will be repeated and it needs to be fair and it needs to work. I see everyone talking about the same themes, it should work out.

Paul, this is for you. http://www.youtube.com/watch?v=3nbEeU2dRBg

I can share that video in public with Paul with full confidence he is not going to be insulted and respond in an angry way. He's going to be respectful. He's going to see the humor. He's still going to accept me (for the most part). He'll still listen to me and hear me, in his patient way.

When people see that in us, when they see us respecting our coding standards, our unit testing, the responsibilities and authorities we have entrusted in one another, when they see it doesn't matter who you are, everyone is held to our standards, when they see us not taking ourselves too seriously, that we can have fun too, when they see us acting like Paul, in spite of his pixie dust dream, that is when we will rebuild our community. People want to be a part of that.

I'm glad to hear Matt say he is encouraged by Nic's approach. I want everyone to know, I feel the same way about the platform's directions. What I worry about the most is these two projects diverging in terms of direction. It would be okay if it did, the sun would still come up every day, but better if it stayed (yes, I'm going to say it) all together, as a whole.

[Andrew Eddie]

On 21 February 2013 16:15, Amy Stephen <amyst...@gmail.com> wrote:

If you all think it's going to be great, it should go in. I have only one concern -- and that is configuring this in a way that Nic and the Platform team are set into a collaborative role, not in a role of conflict since both have been given the same responsibility and authority.

I'm not hearing this is being proposed to be added to the Platform, so that's not a problem. However, if it was, we don't have any formal agreements (we don't have @author tags for this reason) but we know who adds what lines of code and we generally keep that in mind when evaluating changes. Anything beyond a first-level typo or obvious fix is usually referred to the original author for their opinion. But, sorry to harp on this, this is where unit tests really, really help. If someone proposes a "fix" and it breaks a unit test the author designed, we have an immediate flag that there's a problem. 

As an example, when Louis and I designed JForm, we wanted to make sure it didn't suffer the fate of the routers that changed on a whim. So, we made the unit tests as solid as we could so that if someone came along and wanted to make a minor change to the code, we had the tests to make sure the changes wouldn't break anything. I think that's sort of thinking is vitally important with respect to this issue (let the tests be the author's proxy).

 

Now, I am pretty sure no one is picking up on something that I believe is encouraging and it dovetails nicely with this and that is  Andrew's post last week https://groups.google.com/d/msg/joomla-dev-platform/yXS9fVE-93M/PbLu-O9293AJ 

Yeah, so, it's funny but in the long term that work is going to, hopefully, make this whole discussion moot. I hope we can have something to report in a few weeks.

But anyone - as to your assessment, there's no way this will clear all checks and balances in four days. What I would do, if people are serious about this, is:

1. Fork the CMS and add FoF

2. Strip out any obvious duplication (the inflector, possibly others) or anything else that isn't rock solid

3. Code sniff it

4. Put in at least empty test skeletons for each class

5. Prepare FoF as a library extension for separate installation into 2.5 and 3.1

6. Prepare a cool Hello World example component and module that includes the FoF package to show devs how to package it together and wire up all the new cool FoF magic

7. Chip away at honing the developer tutorials (that's as easy as README.md files in appropriate places), API docblocks and, of course, unit tests.

I think *that* is a good 6 month project (as opposed to a less-than-6-day project). But, if that process is demonstrating real traction after a few months or even less, I'd certainly be making a pitch to include it in a maintenance release or 3.1 (or just ship 3.2 early, pfft).

Those are just my suggestions - don't take it as a mandate from the PLT or anything crazy like that.

Regards,

Andrew Eddie

[Nicholas Dionysopoulos]

Hello Don,

Don't hold your breath on unit testing. For the last 9 months I have received promises that people would help... and nothing. At the same time Joomla! itself does not have unit tests for the MVC classes. Somehow I am required to do what nobody else has done even for core code to have FOF shipped with Joomla!. 

Regarding developer documentation, the current situation in FOF is a hell of a lot better than what the core MVC (JControllerLegacy and co) provides. Somehow I have to provide something which is a tutorial on component creation, in par with what the 40$ a copy books offer so far but for free, something that Joomla! doesn't do.

So, let's recap. As long as 80% unit testing and high level documentation are requirements I have to pull back my support for including FOF with Joomla! until the day the core MVC classes get this kind of documentation and unit tests. I will also oppose every single feature patch added to the Joomla! CMS unless it is 80% unit tested and fully documented BEFORE its inclusion. If you want to have such strict standards you have to apply them equally to everything and everyone. If you don't, I don't see the point wasting my time with this discussion if only the chosen ones can contribute code to the CMS without being required to walk on water and raise the dead from their graves. 

Nicholas K. Dionysopoulos

Lead Developer, AkeebaBackup.com

Web: https://www.akeebabackup.com

Blog: http://www.dionysopoulos.me/blog

Sent from my iPad. Please excuse my brevity.

[Ronni KC]

To Amy:

If FOF goes into core some of the points you raise are not relevant - Nicholas wrote he would give away control of FOF if this happens - so i dont see the conflict.

If FOF goes into the CMS as a 3dp library - Nicholas remain in control and thus as a completely independant library - i dont see the conflict either.

So a compromise perhaps?

As i see it adding FOF into the CMS as a 2dp library for CMS 3.1 is not unrealistic - this could be a "trial" period.

Then during 3.1 lifespan the finalization of FOF for Core inclusion could be done.

As i have stated multiple times i will put in ressources to help with php unit testing and help add to it - i dont think anyone else on the planet has 15+ full time joomla devs in their company and trust me when i say that we will go FOF fully and help support it.




Den torsdag den 21. februar 2013 07.15.53 UTC+1 skrev Amy Stephen:

[Ronni KC]

Andrew i am assuming your list of 7 applies only if FOF is to into the Core and not as a 3dp library?

I mean serveral of the pointers are already there like 5 and 6.

1. is a quick job

2. seems to be irrelevant as a 3dp library (wel

3. can be done in 2 days.

4. again i am thinking this may be some future requirement for the CMS Core - but for a 3dp?

7. github readmes and unit testing?

In terms of FOF 2.0 did you go through the code etc.?

Does it make sense to setup some barrier of contribution to be unit testing with a 80% figure?

How would you unit test things?

It seems to be that most of our current CMS could not live up to the standards you think should be applied.

Id like to see this ending up with us showing that we are inclusive and that the direction of the CMS is not in the hands of a handfull of people - if a lot of os thinks FOF is a good idea the least you could do is support the 3dp library addition for 3.1 and then lets see it grow from there.

Afterall lets face it - FOF is already the most installed non core Joomla on the planet - it powers all of the Akeeba extensions and i think that proves without a doubt that its rock solid.

Heck we could add a label saying "tested by millions" - "merited by the community".

If that as a track record does not count, or nicholas reputation and skilllevel does not count, or the support and backup there is from a wide range of community members - then i still think we are stuck in the dark ages feudalistic society model.

And yes then some of you may not agree, some of you may think you could do better code etc. - but as a 3dp library you all still get the chance to prove that - without the rest of having to wait 18 months to get HMVC, FFOForm etc.

So please people - lets be inclusive.

[Andrew Eddie]

On 21 February 2013 17:31, Nicholas Dionysopoulos <niko...@gmail.com> wrote:

Hello Don,

Don't hold your breath on unit testing. For the last 9 months I have received promises that people would help... and nothing. At the same time Joomla! itself does not have unit tests for the MVC classes. Somehow I am required to do what nobody else has done even for core code to have FOF shipped with Joomla!. 

Nic, please read what people are saying (often more than once). The new MVC is fully tested. The old, legacy MVC has some tests (not none) but it's poor coverage at best.

"Today" you are required to provide unit tests and basic documentation for all new work in the Platform. This was not the case over 2 years ago when the legacy MVC's were being worked on in earnest. As for writing tests - I can't say this any other way but you need to invest some time in learning. Don't put it off like I did for far too long. Once you master the art of test driven development, it will pay dividends (wholly cow - the code "just works" in situ).

Let's say it again - the Platform "currently" requires this, the CMS, sadly in my opinion, does not. I would very much like to see the rules applied equally across Platform and CMS. This is a good thing to aim for. I have raised the same point amongst those doing the tags component if it makes you feel any better (I would be wanting to see unit tests on library level files). You'll probably also remember I raised it with the upgrade checking code (that, and its unit tests, are complete).

Your FoF looks more like something that would be added to the Platform (as compared to a CMS extension) so I (alone, singular, me) have suggested the same rules that we apply to the Platform are appropriate here. Everyone here is free to ignore that advice and pass the technical debt on to undisclosed future souls.

This is not a mandate from the PLT. The final decision is not up to me at all.

Your code doesn't suck, but I'm not convinced it's ready to just copy from your Assembla repo into the CMS. A little peer review would be in order don't you think? It's not a trivial amount of code to examine.

These are my humble opinions. I hope this prevents further misunderstanding.

Regards,

Andrew Eddie

[Nikolaos K. Dionysopoulos]

Hello Andrew,

Nic, please read what people are saying (often more than once). The new MVC is fully tested. The old, legacy MVC has some tests (not none) but it's poor coverage at best.

When you say "the new MVC" you mean that sketchy thing that has exactly zero functionality out of the box –as far as the CMS is concerned (this is the context of this discussion)– unless you write tons of code? Yes, it is unit tested. And it's like comparing testing a bicycle to testing a car. Hardly the same scope of work. The real, legacy MVC unit testing status is... what exactly? "Poor coverage" is an understatement. As far as I can see in https://github.com/joomla/joomla-platform/tree/staging/tests/suites/legacy the REAL tests of the controller (testAuthorise, testCheckEditId, testCreateModel, testCreateView, testDisplay, testExecute, testGetModel, testGetView, testHoldEditId, testRedirect, testRegisterDefaultTask, testRegisterTask, testUnregisterTask, testReleaseEditId, testSetAccessControl, testSetPath) are marked incomplete. Testing the trivial functions is quite easy and I could do it. But what is the point? Most of them I already inherit from JControllerLegacy (ergo, they are already tested). Those I replaced, if they didn't work consistently I couldn't run any of my components but yes, I can write unit tests for them very easily. I'll scrap my weekend plans and my release schedule (to the detriment of my business) and start working on it.

But this still leaves us with FAR less than 80% of the code tested as 90% of the code has to do with the task handling and the tasks itself. This is exactly what is not tested in the core which is exactly what I am complaining about. You can't ask me to single-handedly write the unit tests that a dozen of developers over three years didn't write. It's unfair to say the least. Right now there are 10k extensions using the completely untested MVC framework. We consider it functional because extensions don't break. This is exactly the status of FOF as well. How can I provide fully unit tested code when the code I am extending from does not provide unit tests in itself? Even if I could magically provide tests for all of my code you could say that my code is not properly unit tested because the base MVC classes are not unit tested. Do you understand how big of a turn off that is to a developer?

"Today" you are required to provide unit tests and basic documentation for all new work in the Platform. This was not the case over 2 years ago when the legacy MVC's were being worked on in earnest. As for writing tests - I can't say this any other way but you need to invest some time in learning. Don't put it off like I did for far too long. Once you master the art of test driven development, it will pay dividends (wholly cow - the code "just works" in situ).

I'm sorry, I thought that we were discussing about distributing a third party library with the Content Management System, not the Platform.

I did not say that unit tests are useless. On the contrary, I begged and pleased anyone -ANYONE!- who can help with unit testing to please help me. I can't imagine how I can test, let's say the browse task in the controller. Do I have to set up a mock component and some sample data and make sure that the list of items I get from the model is what I expect? Isn't that testing the model instead of the controller? This is the kind of mystery that prevents me from writing unit tests. What do I test? I don't want to waste months writing useless unit tests which test the wrong thing. I will happily spend time learning, but not waste time guessing.

Let's say it again - the Platform "currently" requires this, the CMS, sadly in my opinion, does not. I would very much like to see the rules applied equally across Platform and CMS. This is a good thing to aim for. I have raised the same point amongst those doing the tags component if it makes you feel any better (I would be wanting to see unit tests on library level files). You'll probably also remember I raised it with the upgrade checking code (that, and its unit tests, are complete).

OK, I'm taking off my developer hat and putting on my business consultant hat. Requiring unit tests and documentation will definitely increase code quality because it transcends from something empirical to something quantifiable. When you have measurable KPIs you can have planning. But this means that all code contributions must adhere to the same rule. Right now the majority of the Joomla! developer community has no experience on unit testing. If you enforce that rule right away you suffocate the CMS development. From a business perspective, it makes more sense to educate your developers first (as an organisation this means putting resources to the task), provide constructive feedback (help out instead of just having someone tell the potential contributor "Once you master the art of test driven development, it will pay dividends", this is merely insulting) and enforce this rule to ALL code contributions. Otherwise rejected contributors have every right to talk about double standards. Is Joomla! ready and willing as an organisation to do that? Or are we just selectively enforcing standards which drive innovators away from it and let it stagnate?

Your FoF looks more like something that would be added to the Platform (as compared to a CMS extension) so I (alone, singular, me) have suggested the same rules that we apply to the Platform are appropriate here. Everyone here is free to ignore that advice and pass the technical debt on to undisclosed future souls.

Fair point, but it's not a Platform contribution. And if that's such a show stopper why do you allow completely untested new code be included in Joomla! 3.1? The same kind of technical debt exists for every feature patch I see in the feature tracker. Even worse, some of it doesn't have a chance of being unit- or Selenium-tested. If you want to be consistent apply this rule to everything. Why can a core component get away with no testing whereas a library can't?

This is not a mandate from the PLT. The final decision is not up to me at all.

Well understood. But you are a PLT member and maintainer of the CMS so when you speak you are seen as echoing the PLT's point of view. Speaking of which, who gets to decide anything in the CMS? Almost seven years down the line and I still haven't made heads and tails of who gets the final say on what gets in the CMS or not. The process of contributing to the core is much like a gang initiation ritual: you get beaten up by everyone until you give up or make it into the gang barely alive and severely bruised. Occasionally you are simply left for dead without an explanation This doesn't seem right. If there are no concrete guidelines and rules for contributing how the heck am I supposed to contribute? Spend my time writing code in hope that it might be added to the CMS if the star alignment is right? Try to lobby behind the scenes and have a friend sneak in a last minute commit? There's no vision, no planning, no rules and no sense in any of that.

Your code doesn't suck, but I'm not convinced it's ready to just copy from your Assembla repo into the CMS. A little peer review would be in order don't you think? It's not a trivial amount of code to examine.

Everyone who wants to participate in a peer review is free to do so and more than welcome to provide his or her feedback. All suggestions and patches are always seriously taken into account based on their merit alone (without considering who submits them) and implemented unless they compromise backwards compatibility (bug!) or try to reinvent a wheel which already exists (bug!). I never claimed to possess the godly power of writing perfect code. The more people reading the code the better it is for all of us. I am sure that some areas of my code do suck (and I know which they are). But I don't aim for perfection. I aim for ease of use and backwards compatibility. Those pieces of code which suck are replaced in newer versions, without breaking BC. It's not easy, it's not fast, but it's consistent.

Now, seriously, if I get you right you said that FOFInflector is untested code. You do realise it's just the Akelos PHP Inflector which is widely used and was used by Koowa simply renamed to KInflector for years? Comparing it to JStringInflector I see that Akelos PHP Inflector is more flexible and just as fast. In fact, I am under the impression that JStringInflector is based on Akelos PHP Inflector with a lot more method calls instead of inline code which could make it slightly slower (but so slightly that it's not meaningful). Asking me to replace FOFInflector with JStringInflector can't happen as I'd have to either a. break backwards compatibility by splitting its functionality to using JStringInflector (where there is overlap) and FOFInflector (where there is no overlap) or b. copy 60% of the FOFInflector code back to the new FOFInflector extends JStringInflector with the extra problem that some rules are not present in JStringInflector and could break existing extensions. I'm not sure how that would benefit anyone?

So let me recap what I've said:

• I do want to do unit testing on FOF but I need some serious help. Not promises. I want help. People working with me setting up the tests. If 80% code coverage is a requirement for inclusion and given the fact that not even the Platform provides 80% code coverage for the real, legacy MVC I don't see that ever happening and I'd rather pull out of this discussion.
• FOF is a third party library with backwards compatibility ranked as its primary feature. When it comes to foundation classes like FOFInflector I cannot trust the Joomla! Platform as long as it cannot commit to backwards compatibility. As you may have observed, this is not an issue with the MVC classes as I get to replace functionality whenever the Platform changes. Replacing one of FOF foundation classes with one of J! Platform classes means that I can no longer guarantee backwards compatibility and that is a bug as far as FOF is concerned. If that's a requirement I'd rather pull out of this discussion.
• Basic documentation already exists in the form of docblocks, a wiki (which is continuously updated by the community) and a sample component (com_todo). Based on this thread I have reasons to believe that this covers most of the documentation requirements set forth by Andrew, Don and others. I will go the extra mile and offer a full guide in due time, even discussing the overall idea of MVC in web applications with a skinny controller and a fat model. But this is not my core business and I can't commit on a date of release because I don't want to provide crappy documentation and, frankly, I have to put food on my table before I can help others put food on their table. If that's a requirement I'd rather pull out of this discussion.
• FOF is already available as a downloadable, installable package. Pretty soon it will even have its own update stream. What I am missing is a way for the package itself to check if a newer version is installed because library packages cannot have installation scripts. That's a JInstaller limitation. If anybody has a viable workaround which is backwards compatible with at least Joomla! 2.5.9 please tell me. Do mind that should the package be deemed uninstallable (because a newer version exists or the minimum PHP version is not satisfied) Joomla! should NOT remove the #__extensions record, which is yet another limitation of JInstaller.
• Forking the CMS and adding FOF is a trivial three minute affair. But unless the above points are clearly considered and a decision is made upon them I don't see why anyone should do that and what purpose it could serve.

I hope that's clear enough.

Nicholas K. Dionysopoulos

Email: niko...@gmail.com

Blog: www.dionysopoulos.me/blog

[Davide Tampellini]

And here we are again.
New ideas come up, they're ready to use, but burocracy stops them.

[Don]

For the record, I don't directly contribute to the CMS, only the platform. :) I find the contribution process to the CMS to be so convoluted and hard for the sake of being hard that its bit worth my time. 

However, even for my contributions to the platform, I've written extensive tests simply due to the fact no tests existed for the items I wanted to improve. So my patch (which fixed a very annoying bug) sat around for a couple months while I learned how to unit test. Once i did learn, then write the tests, only then was my bugfix accepted. And, for the record, I was writing tests for JModelLegacy. So, if you would like some sympathy from me, you're not going to get it. :)

And, as Andrew said, tests are really the only way to ensure that what you as the developer of FOF get your desired functionality to not be changed when the pull requests come in. A unit test is not a complicated thing - you are simply testing each unit of code to ensure that it is doing what you are expecting it to do. So- testing MVC is no different than testing a function call. You literally are only testing that each method returns expected data under different circumstances. It might seem pointless at first, but it's really the only way to protect your code from the deluge of pull requests. Get this distributed with core and more widely used without tests, and then see how glorious the life of a maintainer with no tests is. People's patches and improvements will sit around and bit rot. But don't take my word for it. 

So, a recap, I'm not asking for anything I don't do myself. Unit testing is not as hard as it seems. Developers are extremely good at breaking things and tests are are powerful tool to protect against those breaks and make sure desired functionality stays in tact. 

Sent from my iPhone

[Don]

Ronni, it already is a 3dp lib that you install. Distributing it with the CMS doesn't change that. I'm not sure (and neither is Nicholas) why you keep confusing that point. 

As for the fact that legacy classes and other CMS code is not tested (this is for you as well Nick) we need to keep in mind that Unit Testing only came into popularity in PHP in the last 18 months, well AFTER most of this code was written. When the wright brothers built the first plane, there were no safety guides to follow for passenger protection, but today there are hundreds and thousands of tests an airplane design must pass before it flys. :) So, should Boeing complain to the FAA that since Wilbur and Orville never had to pass tests that they shouldn't either?!? NO! That would be absurd. New times bring new standards, and that's that. 

Sent from my iPhone

--

[Don]

Help out with some tests or documentation and push the process along. I imagine you cracking open a beer and slumping back in your easy chair after hitting send on that one. Did it feel good?

Sent from my iPhone

On Feb 21, 2013, at 6:36 AM, Davide Tampellini <tamp...@gmail.com> wrote:

And here we are again.
New ideas come up, they're ready to use, but burocracy stops them.

--

[Don]

Onerous thing, and I promise I'll let someone else post. :) please don't overlook this just because its my fourth post in a row.

Who here remember CMS v2.5.5 release? And how it was immediately followed not 2 days later with 2.5.6? I certainly do, because I was the one that caused the critical bug that was breaking people's sites to get into 2.5.5. Im not afraid to adit that.

How could something like that get into a Joomla release? Certainly there are procedures in place to prevent that. And there certainly are. However, my patch that caused that problem was to a very small section of modMenuHelper and seen as just a cleanup of code - no WAY it could have unintended consequences. Well, modMenuHelper is not tested at all (just like most of the CMS) and had it been, I dare say that would have never happened.

So Nicholas, you and your supporters can happily push in ow with no tests, but keep in mind that even what seems like a 100% innocuous change that will have side effects, both to the person submitting the change as well as those reviewing it, you can STILL break backwards compatibility. As I said, I know from experience.

[Davide Tampellini]

No, I'm here, working, since I have to bring food on my table.
I already help with FOF development (as you can see by merge requests on Assembla) and I created stubs and skeletons for FOF unit tests (if you want I can forward a mail dated 2012-11-19 between me and Nicholaos).

I rarely speak, but I never say stupid things (at least I try).

On Thursday, February 21, 2013 2:17:39 PM UTC+1, Donald Gilbert wrote:

Help out with some tests or documentation and push the process along. I imagine you cracking open a beer and slumping back in your easy chair after hitting send on that one. Did it feel good?

Sent from my iPhone

On Feb 21, 2013, at 6:36 AM, Davide Tampellini <tamp...@gmail.com> wrote:

And here we are again.
New ideas come up, they're ready to use, but burocracy stops them.

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

[brian teeman]

Donald please stop with the Us vs Them approach its not constructive or helpful

Your comment about you not contributing to the CMS because its so dam hard is interesting as everything you are saying is an example of why people dont try to contribute to the CMS.  We are talking about Joomla the CMS not the platform project which from what I can see is completely changing its approach o everything at the moment. If the CMS was to wait for the platform then we will never get anything new in the CMS.

As for your mod_menu example from v2.5.5 nothing has changed to prevent the exact same thing happening in the CMS - btw have you now contributed the unit test for mod_menu to prevent it happening again?

[Donald Gilbert]

Well then I withdraw my comment, and apologize.

[Nikolaos K. Dionysopoulos]

Since the Joomla! CMS is determined to follow double standards and allow all other code except mine to be included without unit testing and documentation I hereby retract my support for this proposal. I am no longer willing to change the license of my code or contribute to the project in any other way. If Joomla! ever decides to adopt a clear contribution process which applies to everything and everyone I might reconsider. I don't see why I should be wasting my time with a process which has a predetermined result (if you're not "one of them" you can't contribute) and fending off snarky replies with zero substance to my questions.

If you want to figure out why contributing to Joomla! is perceived as being so damn hard take a look in the mirror. It's you, people. As a developer I expect to be treated respectfully and receive constructive feedback. I ask for help with unit testing and I'm told that I should learn how to do unit testing and I'll like it. That's not what I asked and I don't appreciate being patronised like that. I asked why other code BEING ADDED THIS WEEK TO JOOMLA! 3.1 is accepted without unit tests and I was given an idiotic simile with Boeing and long-extinct plane makers. What the hell?! That's not what I asked! I asked why the "legacy" MVC isn't tested and I was told that it's kinda tested (it's really not) and that I should unit test my code. That's not what I asked! I asked how to test my code, in the unlikely case someone could give a useful idea, and all I got in return was that I should test that it works. You don't say? Wow! And I thought I have to test if the Controller can make me a cup of coffee... You are either an idiot or you think that I am an idiot. If you're treating contributors who ask for your help and clarifications with contempt you get no contributors. So, screw all of this. I'll go about my business and you get to do whatever you want. I can't be bothered any more and I don't care any more.

So long and thanks for all the fish.

Nicholas K. Dionysopoulos

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

[Donald Gilbert]

No Brian, as I said, I've now decided contributing to the CMS is a waste of time and any CMS shortcomings or errors I put into my own Joomla Development Abstraction Library.

Just ask Michael Babker if there is a concerted effort to unit test the CMS.

--

[Donald Gilbert]

*sigh* if you overlooked the part where I said I personally unit tested part of the "legacy" MVC, then I see no reason in offering any more opinions on the matter.

One last proven statistic, and I'll be gone: Test Driven Development takes 40% more time, but results in 90% fewer bugs. That's something I'd be willing to learn.

[Radek Suski]

On Feb 21, 2013, at 14:15, Don <dilber...@gmail.com> wrote:

When the wright brothers built the first plane, there were no safety guides to follow for passenger protection, but today there are hundreds and thousands of tests an airplane design must pass before it flys. :) So, should Boeing complain to the FAA that since Wilbur and Orville never had to pass tests that they shouldn't either?!? NO! That would be absurd. New times bring new standards, and that's that. 

Sorry but this is rather stupid comparison. You forgetting about simple fact that FOF wasn't developed yesterday but you want to apply rules from tomorrow.

BTW: Just curious, is there a test unit for SimplePie or PHPMailer?

Regards,

Radek  

[Adam Rifat]

I would just like to say that if nothing else I am now aware of FOF whereas about 24h ago I had no idea it existed so thanks everyone for that.

Looks like a useful addition (I already installed it by dropping it into the libraries folder) unit tested or not.

:-\

On Thursday, 21 February 2013 14:32:00 UTC, Donald Gilbert wrote:

*sigh* if you overlooked the part where I said I personally unit tested part of the "legacy" MVC, then I see no reason in offering any more opinions on the matter.

One last proven statistic, and I'll be gone: Test Driven Development takes 40% more time, but results in 90% fewer bugs. That's something I'd be willing to learn.

On Thu, Feb 21, 2013 at 8:20 AM, Nikolaos K. Dionysopoulos <niko...@gmail.com> wrote:

Since the Joomla! CMS is determined to follow double standards and allow all other code except mine to be included without unit testing and documentation I hereby retract my support for this proposal. I am no longer willing to change the license of my code or contribute to the project in any other way. If Joomla! ever decides to adopt a clear contribution process which applies to everything and everyone I might reconsider. I don't see why I should be wasting my time with a process which has a predetermined result (if you're not "one of them" you can't contribute) and fending off snarky replies with zero substance to my questions.

If you want to figure out why contributing to Joomla! is perceived as being so damn hard take a look in the mirror. It's you, people. As a developer I expect to be treated respectfully and receive constructive feedback. I ask for help with unit testing and I'm told that I should learn how to do unit testing and I'll like it. That's not what I asked and I don't appreciate being patronised like that. I asked why other code BEING ADDED THIS WEEK TO JOOMLA! 3.1 is accepted without unit tests and I was given an idiotic simile with Boeing and long-extinct plane makers. What the hell?! That's not what I asked! I asked why the "legacy" MVC isn't tested and I was told that it's kinda tested (it's really not) and that I should unit test my code. That's not what I asked! I asked how to test my code, in the unlikely case someone could give a useful idea, and all I got in return was that I should test that it works. You don't say? Wow! And I thought I have to test if the Controller can make me a cup of coffee... You are either an idiot or you think that I am an idiot. If you're treating contributors who ask for your help and clarifications with contempt you get no contributors. So, screw all of this. I'll go about my business and you get to do whatever you want. I can't be bothered any more and I don't care any more.

So long and thanks for all the fish.

Nicholas K. Dionysopoulos

On 21 Φεβ 2013, at 16:06 , Davide Tampellini <tamp...@gmail.com> wrote:

No, I'm here, working, since I have to bring food on my table.
I already help with FOF development (as you can see by merge requests on Assembla) and I created stubs and skeletons for FOF unit tests (if you want I can forward a mail dated 2012-11-19 between me and Nicholaos).

I rarely speak, but I never say stupid things (at least I try).


On Thursday, February 21, 2013 2:17:39 PM UTC+1, Donald Gilbert wrote:

Help out with some tests or documentation and push the process along. I imagine you cracking open a beer and slumping back in your easy chair after hitting send on that one. Did it feel good?

Sent from my iPhone

On Feb 21, 2013, at 6:36 AM, Davide Tampellini <tamp...@gmail.com> wrote:

And here we are again.
New ideas come up, they're ready to use, but burocracy stops them.

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

[Donald Gilbert]

Radek - Yes they do.

SimplePie: https://github.com/simplepie/simplepie/tree/master/tests

PHPMailer: http://code.google.com/a/apache-extras.org/p/phpmailer/source/browse/trunk/test/phpmailerTest.php