Differences between Joomla Framework & Joomla Platform

[Matt Thomas]

Hi all,

This may be a rather naive question, but what is the difference between the Joomla Framework & Joomla Platform? I do see the Joomla Framework as being described as being experimental, and Joomla being a Vendor in the framework. Is this just where the namespacing and the new MVC might happen, or is there more to it?

Thanks for any and all insight!

Best,

Matt

[Donald Gilbert]

The massive changes required to introduce namespacing to the platform would have huge backwards compatibility issues with the CMS, and would basically lock the CMS into the version it is using right now. So, we created the framework repo where we can make these changes and not worry about potential backlash from the CMS development community possibly mis-understanding the purpose of the change before it was ready to be presented.

--
You received this message because you are subscribed to the Google Groups "Joomla! Platform Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-plat...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Matt Thomas]

Thanks Don! In essence, would it be safe to say that the Joomla "Framework on Github is basically a drastically newer version of the Joomla Platform? That is, it's not a new project with new goals or serves a new purpose. Correct?

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

[Donald Gilbert]

Yes, that would be a good assessment. We are breaking out each of the packages into their own repo so that they can be installed via composer in any environment that needs them. Someone coding with Laravel might want to use our Github code (since it's AWESOME) but with the platform, that's not possible. With the framework, it is possible, because it's been decoupled from the other classes in the platform and is able to be used with few other requirements.

[Matt Thomas]

That sounds fantastic! Thanks for taking the time to explain it. I look forward to seeing more greatness come about.

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

[Andrew Eddie]

Is it too late to get that little interview into this months JCM? This is a question that is going to be asked a lot.

Matt, what sort of resources do you think we need to help people to connect the dots and see the potential in what we are doing? A powerpoint, regular blogs, video someone doing a short talk at their JUG? And from an outside perspective, what other questions do you think people are going to need answering?

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

[Nick Savov]

The JCM is going out tomorrow most likely and their deadline is usually
around the 22nd, however I can check for you. It's worth a try.

Also, could someone please move the github experimental framework repo
below the CMS one and also below the stable platform one? Thanks in
advance!

Kind regards,
Nick

> Is it too late to get that little interview into this months JCM? This is
> a
> question that is going to be asked a lot.
>
> Matt, what sort of resources do you think we need to help people to
> connect
> the dots and see the potential in what we are doing? A powerpoint, regular
> blogs, video someone doing a short talk at their JUG? And from an outside
> perspective, what other questions do you think people are going to need
> answering?
>
> Regards,
> Andrew Eddie
> http://learn.theartofjoomla.com - free tutorials and videos on Joomla
> development
>
>
> On 1 March 2013 06:18, Matt Thomas <ma...@betweenbrain.com> wrote:
>
>> That sounds fantastic! Thanks for taking the time to explain it. I look
>> forward to seeing more greatness come about.
>>
>> Best,
>>
>> Matt Thomas

>> Founder betweenbrain <http://betweenbrain.com/>�

>> Lead Developer Construct Template Development

>> Framework<http://construct-framework.com/>

>>>> Founder betweenbrain <http://betweenbrain.com/>�

>>>> Lead Developer Construct Template Development

>>>> Framework<http://construct-framework.com/>

[Andrew Eddie]

On 1 March 2013 07:49, Nick Savov <ni...@iowawebcompany.com> wrote:

Also, could someone please move the github experimental framework repo
below the CMS one and also below the stable platform one?  Thanks in
advance!

Github has a mind of its own and generally orders according to the most recent activity. It's annoying sometimes but that's the way they think you want to use Github.

Regards,

Andrew Eddie 

[Michael Babker]

On GitHub, we can't order the repos.  They are automatically ordered by the latest updates.

--
- Michael

Please pardon any errors, this message was sent from my iPhone.

[Nick Savov]

Thanks guys! Cheers :)

>> <javascript:;>>

>> wrote:
>> >
>> >> That sounds fantastic! Thanks for taking the time to explain it. I
>> look
>> >> forward to seeing more greatness come about.
>> >>
>> >> Best,
>> >>
>> >> Matt Thomas
>> >> Founder betweenbrain <http://betweenbrain.com/>�
>> >> Lead Developer Construct Template Development
>> >> Framework<http://construct-framework.com/>
>> >> Phone: 203.632.9322
>> >> Twitter: @betweenbrain
>> >> Github: https://github.com/betweenbrain
>> >>
>> >>
>> >> On Thu, Feb 28, 2013 at 3:03 PM, Donald Gilbert

>> >> <dilber...@gmail.com <javascript:;>>wrote:

>> >>
>> >>> Yes, that would be a good assessment. We are breaking out each of
>> the
>> >>> packages into their own repo so that they can be installed via
>> composer
>> >>> in
>> >>> any environment that needs them. Someone coding with Laravel might
>> want
>> >>> to
>> >>> use our Github code (since it's AWESOME) but with the platform,
>> that's
>> >>> not
>> >>> possible. With the framework, it is possible, because it's been
>> >>> decoupled
>> >>> from the other classes in the platform and is able to be used with
>> few
>> >>> other requirements.
>> >>>
>> >>>
>> >>> On Thu, Feb 28, 2013 at 1:59 PM, Matt Thomas

>> >>> <ma...@betweenbrain.com <javascript:;>>wrote:

[Nick Savov]

Just got word that if someone writes it up today, pronto, they can get it
added for you for the upcoming issue :) Now who's going to write it? :)

Kind regards,
Nick

[Matt Thomas]

I'm going to channel the general Joomla community and brainstorm some questions right now that might be helpful to answer. Hopefully, they can help flush this out.

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

[Andrew Eddie]

On 1 March 2013 09:13, Matt Thomas <ma...@betweenbrain.com> wrote:

I'm going to channel the general Joomla community and brainstorm some questions right now that might be helpful to answer. Hopefully, they can help flush this out.

Thanks Matt. Appreciate the help from a fresh set of eyes.

[Matt Thomas]

Thanks for the idea Andrew! I really appreciate everyone's help in this.

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

[Matt Thomas]

Hi all,

Following is my first-pass at a hastily drafted set of questions, and partial answers, to the above question. I had done a bit of searching before starting this thread, and will see if I can find some of the mentions that prompted me to asking here. I'll send along more questions and notes as they are created.

/**

* Constructor: interview style questions and partial answers describing the differences between Joomla Framework & Joomla Platform

*

* @since  0.1

*/

What is the Joomla Framework, why do we need it when we already have the Joomla Platform?

Essentially, the Joomla Framework can be thought of the next generation of the Joomla Platform. The massive changes required to introduce advances, such as namespacing, have huge backwards compatibility issues with the CMS, and would basically lock the CMS into the version of the Platform it is using right now. The Joomla Framework was created as sort of an isolated incubator to further development with the goal of not creating any mis-understanding of the purpose of the change before it was ready to be presented to the community.

A component based framework (in the sense of Symfony Components, not what the CMS historically refers to as "components") allows new code can be added and tested and easily integrated by downstream users. It would make it much more simple for the CMS to integrate things like Diana's OAuth work as well as JTwitter / JFacebook.

Does this mean that the Platform will get absorbed back into the CMS?

It might. That would be one way to handle the backwards compatibility issues these advances introduce.

Does this mean that extensions will break, or need to be rewritten, in the next version of the CMS?

Why create another repository for this when there is already one for the Platform? Won't that confuse everyone?

We are breaking out each of the packages into their own repository so that they can be installed via composer in any environment that needs them. For example, someone coding with Laravel might want to use our Github code (since it's AWESOME). Currently, with the Platform, that's not possible. With the Framework, it is possible, because it's been decoupled from the other classes in the platform and is able to be used with few other requirements.

Okay, sounds great. When will it be ready? What version of the CMS will it be in?

Good question! As of right now, it's a work in progress. 

Where can I find the Framework?

Head on over to https://github.com/joomla and you'll see a few repositories named starting with joomla-framework

Sounds cool! How can I get involved?

We've done up a bit of a list of to-do's for what we need to do to get the Framework to version 1.0. We might be missing a few things but there's quite a bit to do. You can see the list at https://github.com/joomla/joomla-framework/issues?state=open

[Matt Thomas]

Hi folks,

I seem to think the two following excerpts from Andrew's post "The Joomla Platform and Composer" might round out the basics for that most need to know, at least for now. I'll be up and around for a couple of hours if anyone can expand on, or answer, some of the questions, and I will be happy to assemble everything into one article tonight. But, bedtime comes in a few hours for me... ;-)

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

Does this mean that we will be able to use Composer and Packagist with the Framework?

Composer, and its companion Packagist, have become the defacto standard for integrating PHP libraries into your applications. The new Joomla Platform (a.k.a. the Joomla Framework) needs to fit more easily into this paradigm as well as making it easier for people building Joomla application to be able to leverage other libraries available through Composer more easily. Therefore, with all the work that is going on with namespacing, the current platform is being broken up into individual packages that can be published to Composer and installed with Packagist.

We envisage that there will be one “core” platform package that will contain coding elements that are either very common or critical to most other platform packages. This would include such things as JRegistry, as well as introduce and external dependencies like PHP-FIG interfaces.

Each package would have its own set of maintainers that would manage pull requests against the package but all packages would be bound by the current coding standards or any other related Joomla policy. People would obviously be able to manage more than one repository.

Each package would manage it’s own version numbering according to semantic versioning.

There is also the opportunity to clean up any package (removing legacy code), or even dropping existing packages (like JFile, etc).

What opportunities and challenges does this create for the project?

Opportunities:

1. Delegates management away from a small group of platform maintainers that can easily become a bottleneck for accepting or reviewing contributions on the platform as a whole. It is much easier for people to focus on approving code for smaller chunks of code.

2. Allows developers to pick-and-choose what they need to build applications regardless of what core library those applications are built on.

3. Still maintains the Joomla “brand”

4. Allows for packages that fall into disrepair or just hold no interest to be easily retired.

5. The Joomla leadership just has to be responsible for providing the right tools and for guiding policy.

Challenges:

1. There is some new overhead in creating repositories and maintaining access control lists.

2. We’d have to work out how to approve new packages.

3. Probably a host of others we haven't thought about yet.

[Andrew Eddie]

On 1 March 2013 09:44, Matt Thomas <ma...@betweenbrain.com> wrote:

Following is my first-pass at a hastily drafted set of questions, and partial answers, to the above question. I had done a bit of searching before starting this thread, and will see if I can find some of the mentions that prompted me to asking here. I'll send along more questions and notes as they are created.

Awesome work. Thanks. Comments inline - wordsmith/chop/change/ask more questions as appropriate.

 

What is the Joomla Framework, why do we need it when we already have the Joomla Platform?

Essentially, the Joomla Framework can be thought of the next generation of the Joomla Platform. The massive changes required to introduce advances, such as namespacing, have huge backwards compatibility issues with the CMS, and would basically lock the

... compatibility issues with the CMS >and even the existing Platform<

 

CMS into the version of the Platform it is using right now. The Joomla Framework was created as sort of an isolated incubator to further development with the goal of not creating any mis-understanding of the purpose of the change before it was ready to be presented to the community.

Maybe that last sentence is more like this:

This change presented an opportunity to create a new incubator for further development that could be used not only by the CMS and those branching out developing applications natively on the Joomla Platform, but also by the wider PHP community.

 

A component based framework (in the sense of Symfony Components, not what the CMS historically refers to as "components") allows new code can be added and tested and easily integrated by downstream users. It would make it much more simple for the CMS to integrate things like Diana's OAuth work as well as JTwitter / JFacebook.

I think it's important to mention somewhere that the CMS pretty much has to take all or nothing of the platform, and so do other developers. With this new way, everyone will be able to choose the bits they actually need. It's a move away from the monolithic stack.

 

Does this mean that the Platform will get absorbed back into the CMS?

It might. That would be one way to handle the backwards compatibility issues these advances introduce.

It means that all the work that's been done up till now excluding the namespacing can be absorbed back into the CMS's control. That's good for the CMS because it cuts down on the double handling they currently have fixing bugs.

 

Does this mean that extensions will break, or need to be rewritten, in the next version of the CMS?

No, in fact the change will prevent this from happening. The CMS will be at liberty to reintroduce parts of the new Joomla Framework as it needs to, and in a way that present no compatibility issues with existing extensions.

However, it is important to note we are not making the Joomla Framework backward compatible with the Joomla Platform. We are cleaning up all deprecated code in the process, as well as removing any remaining CMS code or poorly maintained packages. We feel that will be ok because the shift to namespacing is pretty big (you have to change your code) and also shifting to composer mean developers will have to start fresh anyway.

 

Why create another repository for this when there is already one for the Platform? Won't that confuse everyone?

We are breaking out each of the packages into their own repository so that they can be installed via composer in any environment that needs them. For example, someone coding with Laravel might want to use our Github code (since it's AWESOME). Currently, with the Platform, that's not possible. With the Framework, it is possible, because it's been decoupled from the other classes in the platform and is able to be used with few other requirements.

Basically the reason is it was much easier to start a new repo to do all the prep work in. We had a fair bit of discussion and it would seem that referring to things as the "old Platform" and the "new Platform" would get very confusing. So, changing the name and the repo allows us to very clearly delineate between the monolithic stack that is Joomla Platform, and the new, namespaced, Composer aware code that is the Joomla Framework (if that makes sense).

 

Okay, sounds great. When will it be ready? What version of the CMS will it be in?

Good question! As of right now, it's a work in progress. 

Timing - good question. Our goal is to get at least put "Humpty back together" and get things working again, but also in a way that you can install individual packages and composer works out all the dependancies.

The CMS won't have any of the new Framework in it. It will sync whatever it can from the current Joomla Platform and then we'll more than likely retire the Joomla Platform as a separately maintained entity. All new work will go directly into the CMS or the Joomla Framework.

...

See what you can use out of that. The main take away is that everyone gets more control over what code they need to use, and that it will be possible for anyone in the wider PHP community to be able to use "bits" of our code as they need it.

Regards,

Andrew Eddie

[Andrew Eddie]

Does this mean that we will be able to use Composer and Packagist with the Framework?

Composer, and its companion Packagist, have become the defacto standard for integrating PHP libraries into your applications. The new Joomla Platform (a.k.a. the Joomla Framework) needs to fit more easily into this paradigm as well as making it easier for people building Joomla application to be able to leverage other libraries available through Composer more easily. Therefore, with all the work that is going on with namespacing, the current platform is being broken up into individual packages that can be published to Composer and installed with Packagist.

Stop there. The next bits are still in flux

 

We envisage that there will be one “core” platform package that will contain coding elements that are either very common or critical to most other platform packages. This would include such things as JRegistry, as well as introduce and external dependencies like PHP-FIG interfaces.

We aren't doing that any more.

 

Each package would have its own set of maintainers that would manage pull requests against the package but all packages would be bound by the current coding standards or any other related Joomla policy. People would obviously be able to manage more than one repository.

Jury is still out on this one.

 

Each package would manage it’s own version numbering according to semantic versioning.

Yes, we'll be doing this ... I think. Still some argument for having major increments align, but we'll keep talking about it.

 

There is also the opportunity to clean up any package (removing legacy code), or even dropping existing packages (like JFile, etc).

And we are doing that aggressively.

 

What opportunities and challenges does this create for the project?

Opportunities:

1. Delegates management away from a small group of platform maintainers that can easily become a bottleneck for accepting or reviewing contributions on the platform as a whole. It is much easier for people to focus on approving code for smaller chunks of code.

2. Allows developers to pick-and-choose what they need to build applications regardless of what core library those applications are built on.

3. Still maintains the Joomla “brand”

4. Allows for packages that fall into disrepair or just hold no interest to be easily retired.

5. The Joomla leadership just has to be responsible for providing the right tools and for guiding policy.

Challenges:

1. There is some new overhead in creating repositories and maintaining access control lists.

We've sorted some of this out with git sub-split. Still other details to sort out.

 

2. We’d have to work out how to approve new packages.

A bridge we are yet to cross.

 

3. Probably a host of others we haven't thought about yet.

That too.

Regards,

Andrew Eddie 

[Matt Thomas]

Thanks Andrew, it's my pleasure! 

Revised as below. If this looks good to everyone (do we need PLT approval too?), I'll ship it off to Dianne right away.

/**

* 

*/

What is the Joomla Framework, why do we need it when we already have the Joomla Platform?

Essentially, the Joomla Framework can be thought of as the next generation of the Joomla Platform. The massive changes required to introduce advances, such as namespacing, have huge backwards compatibility issues with the CMS and the existing Platform, which would basically lock the CMS into the version of the Platform it is using right now. This change presented an opportunity to create a new incubator, for further development, that could be used not only by the CMS and those developing applications natively on the Joomla Platform, but also by the wider PHP community.

Additionally, with the current Platform, it's a take it all or nothing situation. With this new approach, everyone will be able to choose the bits they actually need. It's a move away from the monolithic stack. A component based framework (in the sense of Symfony Components, not what the CMS historically refers to as "components") allows new code can be added and tested and easily integrated by downstream users. It would make it much more simple for the CMS to integrate things like Diana's OAuth work as well as JTwitter / JFacebook.

Does this mean that the Platform will get absorbed back into the CMS?

It means that all the work that's been done up till now, excluding the namespacing, can be absorbed back into the CMS's control. That's good for the CMS because it cuts down on the double handling they currently have fixing bugs.

Does this mean that extensions will break, or need to be rewritten, in the next version of the CMS?

No, in fact the change will prevent this from happening. The CMS will be at liberty to introduce parts of the new Joomla Framework as it needs to, and in a way that present no compatibility issues with existing extensions.

However, it is important to note we are not making the Joomla Framework backward compatible with the Joomla Platform. We are cleaning up all deprecated code in the process, as well as removing any remaining CMS code or poorly maintained packages. We feel this is a good strategy as the shift to namespacing is pretty big (you have to change your code) and also shifting to composer mean developers will have to start fresh anyway.

Why create another repository for this when there is already one for the Platform? Won't that confuse everyone?

Basically, the reason is that it was much easier to start a new repository to do all the prep work in. We had extensive discussions and it would seem that referring to things as the "old Platform" and the "new Platform" would get very confusing. Changing the name, and the repository, allows us to very clearly delineate between the monolithic stack that is Joomla Platform, and the new, namespaced, Composer aware code that is the Joomla Framework.

We are also breaking out each of the packages into their own repository so that they can be installed via composer in any environment that needs them. For example, someone coding with Laravel might want to use our Github code (since it's AWESOME). Currently, with the Platform, that's not possible. With the Framework, it is possible, because it's been decoupled from the other classes in the platform and is able to be used with few other requirements.

Okay, sounds great. When will it be ready? What version of the CMS will it be in?

Good question! Our goal is to at least put "Humpty back together" and get things working again, but also in a way that you can install individual packages and composer works out all the dependencies.

The CMS won't have any of the new Framework in it. It will sync whatever it can from the current Joomla Platform and then we'll more than likely retire the Joomla Platform as a separately maintained entity. All new work will go directly into the CMS or the Joomla Framework.

Does this mean that we will be able to use Composer and Packagist with the Framework?

Composer, and its companion Packagist, have become the defacto standard for integrating PHP libraries into your applications. The new Joomla Platform (a.k.a. the Joomla Framework) needs to fit more easily into this paradigm as well as making it easier for people building Joomla application to be able to leverage other libraries available through Composer more easily. Therefore, with all the work that is going on with namespacing, the current platform is being broken up into individual packages that can be published to Composer and installed with Packagist.

There is also the opportunity to clean up any package (removing legacy code), or even dropping existing packages (like JFile, etc).

What opportunities and challenges does this create for the project?

Opportunities:

1. Delegates management away from a small group of platform maintainers that can easily become a bottleneck for accepting or reviewing contributions on the platform as a whole. It is much easier for people to focus on approving code for smaller chunks of code.

2. Allows developers to pick-and-choose what they need to build applications regardless of what core library those applications are built on.

3. Still maintains the Joomla “brand”

4. Allows for packages that fall into disrepair or just hold no interest to be easily retired.

5. The Joomla leadership just has to be responsible for providing the right tools and for guiding policy.

Challenges:

1. There is some new overhead in creating repositories and maintaining access control lists. We've sorted some of this out with git sub-split. Still other details to sort out.

2. We’d have to work out how to approve new packages, something we have yet to tackle.

3. Probably a host of others we haven't thought about yet.

Where can I find the Framework?

Head on over to https://github.com/joomla and you'll see a few repositories named starting with joomla-framework

Sounds cool! How can I get involved?

We have a to-do list for what needs to be accomplished to get the Framework to version 1.0. We might be missing a few things but there's quite a bit to do. You can see the list at https://github.com/joomla/joomla-framework/issues?state=open

I have more questions, where is the best place to ask them?

The Joomla Platform Development list is the best place for now.

[Andrew Eddie]

That looks good Matt. Ship it.

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

--

[Nick Savov]

No PLT approval is needed for the JCM article :) Though, it would be
beneficial to have a PLT member look it over for you and, this case,
Andrew's doing just that, so you're set to go :)

Thanks for doing this, Matt!

Kind regards,
Nick

> Thanks Andrew, it's my pleasure!
>
> Revised as below. If this looks good to everyone (do we need PLT approval
> too?), I'll ship it off to Dianne right away.
>
>
> /**
> *
> */

> *What is the Joomla Framework, why do we need it when we already have the
> Joomla Platform?*

> Essentially, the Joomla Framework can be thought of as the next generation
> of the Joomla Platform. The massive changes required to introduce
> advances,
> such as namespacing, have huge backwards compatibility issues with the CMS
> and
> the existing Platform, which would basically lock the CMS into the version
> of the Platform it is using right now. This change presented an
> opportunity
> to create a new incubator, for further development, that could be used not
> only by the CMS and those developing applications natively on the Joomla
> Platform, but also by the wider PHP community.
>
> Additionally, with the current Platform, it's a take it all or nothing
> situation. With this new approach, everyone will be able to choose the
> bits
> they actually need. It's a move away from the monolithic stack. A
> component
> based framework (in the sense of Symfony Components, not what the CMS
> historically refers to as "components") allows new code can be added and
> tested and easily integrated by downstream users. It would make it much
> more simple for the CMS to integrate things like Diana's OAuth work as
> well
> as JTwitter / JFacebook.
>
>

> *Does this mean that the Platform will get absorbed back into the CMS?*

> It means that all the work that's been done up till now, excluding the
> namespacing, can be absorbed back into the CMS's control. That's good for
> the CMS because it cuts down on the double handling they currently have
> fixing bugs.
>
>

> *Does this mean that extensions will break, or need to be rewritten, in
> the
> next version of the CMS?*

> No, in fact the change will prevent this from happening. The CMS will be
> at
> liberty to introduce parts of the new Joomla Framework as it needs to, and
> in a way that present no compatibility issues with existing extensions.
>
> However, it is important to note we are not making the Joomla Framework
> backward compatible with the Joomla Platform. We are cleaning up all
> deprecated code in the process, as well as removing any remaining CMS code
> or poorly maintained packages. We feel this is a good strategy as the
> shift
> to namespacing is pretty big (you have to change your code) and also
> shifting to composer mean developers will have to start fresh anyway.
>

> *
> *
> *Why create another repository for this when there is already one for the
> Platform? Won't that confuse everyone?*

> Basically, the reason is that it was much easier to start a new repository
> to do all the prep work in. We had extensive discussions and it would seem
> that referring to things as the "old Platform" and the "new Platform"
> would
> get very confusing. Changing the name, and the repository, allows us to
> very clearly delineate between the monolithic stack that is Joomla
> Platform, and the new, namespaced, Composer aware code that is the Joomla
> Framework.
>
> We are also breaking out each of the packages into their own repository so
> that they can be installed via composer in any environment that needs
> them.
> For example, someone coding with Laravel might want to use our Github code
> (since it's AWESOME). Currently, with the Platform, that's not possible.
> With the Framework, it is possible, because it's been decoupled from the
> other classes in the platform and is able to be used with few other
> requirements.
>
>

> *Okay, sounds great. When will it be ready? What version of the CMS will
> it
> be in?*

> Good question! Our goal is to at least put "Humpty back together" and get
> things working again, but also in a way that you can install individual
> packages and composer works out all the dependencies.
>
> The CMS won't have any of the new Framework in it. It will sync whatever
> it
> can from the current Joomla Platform and then we'll more than likely
> retire
> the Joomla Platform as a separately maintained entity. All new work will
> go
> directly into the CMS or the Joomla Framework.
>
>

> *Does this mean that we will be able to use Composer and Packagist with
> the
> Framework?*

> Composer, and its companion Packagist, have become the defacto standard
> for
> integrating PHP libraries into your applications. The new Joomla Platform
> (a.k.a. the Joomla Framework) needs to fit more easily into this paradigm
> as well as making it easier for people building Joomla application to be
> able to leverage other libraries available through Composer more easily.
> Therefore, with all the work that is going on with namespacing, the
> current
> platform is being broken up into individual packages that can be published
> to Composer and installed with Packagist.
>
> There is also the opportunity to clean up any package (removing legacy
> code), or even dropping existing packages (like JFile, etc).
>
>

> *What opportunities and challenges does this create for the project?*

> Opportunities:
>
> 1. Delegates management away from a small group of platform maintainers
> that can easily become a bottleneck for accepting or reviewing
> contributions on the platform as a whole. It is much easier for people to
> focus on approving code for smaller chunks of code.
>
> 2. Allows developers to pick-and-choose what they need to build
> applications regardless of what core library those applications are built
> on.
>
> 3. Still maintains the Joomla �brand�
>
> 4. Allows for packages that fall into disrepair or just hold no interest
> to
> be easily retired.
>
> 5. The Joomla leadership just has to be responsible for providing the
> right
> tools and for guiding policy.
>
> Challenges:
>
> 1. There is some new overhead in creating repositories and maintaining
> access control lists. We've sorted some of this out with git sub-split.
> Still other details to sort out.
>
> 2. We�d have to work out how to approve new packages, something we have
> yet
> to tackle.
>
> 3. Probably a host of others we haven't thought about yet.
>

> *
> Where can I find the Framework?*

> Head on over to https://github.com/joomla and you'll see a few
> repositories
> named starting with joomla-framework
>
>

> *Sounds cool! How can I get involved?*

> We have a to-do list for what needs to be accomplished to get the
> Framework
> to version 1.0. We might be missing a few things but there's quite a bit
> to
> do. You can see the list at
> https://github.com/joomla/joomla-framework/issues?state=open
>
>

> *I have more questions, where is the best place to ask them?*
> The Joomla Platform Development
> list<https://groups.google.com/forum/?fromgroups#!forum/joomla-dev-platform>is

> the best place for now.
>
>
> Best,
>
> Matt Thomas

> Founder betweenbrain <http://betweenbrain.com/>�

> Lead Developer Construct Template Development

> Framework<http://construct-framework.com/>

> Phone: 203.632.9322
> Twitter: @betweenbrain
> Github: https://github.com/betweenbrain
>

[Matt Thomas]

Thanks everyone! Shipping it now.

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

[Amy Stephen]

Impressed. Not to detract from anyone's involvement (Andrew's input was obviously critical), but Way. To. Go. Matt.

[Dmitry Rekun]

Thank you Matt. I am going to translate it to Russian, when JCM will come out.

[piotr_cz]

What about creating new Organisation 'Joomla Framework', so the will
be

github.com/joomla-framework/ view
github.com/joomla-framework/ registry

and framework packages don't mix with cms, docs etc.

On Feb 28, 10:57 pm, Michael Babker <michael.bab...@gmail.com> wrote:
> On GitHub, we can't order the repos.  They are automatically ordered by the
> latest updates.
>
>
>
>
>
>
>
>
>
> On Thursday, February 28, 2013, Nick Savov wrote:
> > The JCM is going out tomorrow most likely and their deadline is usually
> > around the 22nd, however I can check for you.  It's worth a try.
>
> > Also, could someone please move the github experimental framework repo
> > below the CMS one and also below the stable platform one?  Thanks in
> > advance!
>
> > Kind regards,
> > Nick
>
> > > Is it too late to get that little interview into this months JCM? This is
> > > a
> > > question that is going to be asked a lot.
>
> > > Matt, what sort of resources do you think we need to help people to
> > > connect
> > > the dots and see the potential in what we are doing? A powerpoint,
> > regular
> > > blogs, video someone doing a short talk at their JUG? And from an outside
> > > perspective, what other questions do you think people are going to need
> > > answering?
>
> > > Regards,
> > > Andrew Eddie

> > >http://learn.theartofjoomla.com- free tutorials and videos on Joomla
> > > development
>
> > > On 1 March 2013 06:18, Matt Thomas <m...@betweenbrain.com <javascript:;>>

> > wrote:
>
> > >> That sounds fantastic! Thanks for taking the time to explain it. I look
> > >> forward to seeing more greatness come about.
>
> > >> Best,
>
> > >> Matt Thomas
> > >> Founder betweenbrain <http://betweenbrain.com/>™
> > >> Lead Developer Construct Template Development
> > >> Framework<http://construct-framework.com/>
> > >> Phone: 203.632.9322
> > >> Twitter: @betweenbrain
> > >> Github:https://github.com/betweenbrain
>
> > >> On Thu, Feb 28, 2013 at 3:03 PM, Donald Gilbert

> > >> <dilbert4l...@gmail.com <javascript:;>>wrote:

>
> > >>> Yes, that would be a good assessment. We are breaking out each of the
> > >>> packages into their own repo so that they can be installed via composer
> > >>> in
> > >>> any environment that needs them. Someone coding with Laravel might want
> > >>> to
> > >>> use our Github code (since it's AWESOME) but with the platform, that's
> > >>> not
> > >>> possible. With the framework, it is possible, because it's been
> > >>> decoupled
> > >>> from the other classes in the platform and is able to be used with few
> > >>> other requirements.
>
> > >>> On Thu, Feb 28, 2013 at 1:59 PM, Matt Thomas

> > >>> <m...@betweenbrain.com <javascript:;>>wrote:

>
> > >>>> Thanks Don! In essence, would it be safe to say that the Joomla
> > >>>> "Framework on Github is basically a drastically newer version of the
> > >>>> Joomla
> > >>>> Platform? That is, it's not a new project with new goals or serves a
> > >>>> new
> > >>>> purpose. Correct?
>
> > >>>> Best,
>
> > >>>> Matt Thomas
> > >>>> Founder betweenbrain <http://betweenbrain.com/>™
> > >>>> Lead Developer Construct Template Development
> > >>>> Framework<http://construct-framework.com/>
> > >>>> Phone: 203.632.9322
> > >>>> Twitter: @betweenbrain
> > >>>> Github:https://github.com/betweenbrain
>
> > >>>> On Thu, Feb 28, 2013 at 2:19 PM, Donald Gilbert

> > >>>> <dilbert4l...@gmail.com>wrote:

>
> > >>>>> The massive changes required to introduce namespacing to the platform
> > >>>>> would have huge backwards compatibility issues with the CMS, and
> > >>>>> would
> > >>>>> basically lock the CMS into the version it is using right now. So, we
> > >>>>> created the framework repo where we can make these changes and not
> > >>>>> worry
> > >>>>> about potential backlash from the CMS development community possibly
> > >>>>> mis-understanding the purpose of the change before it was ready to be
> > >>>>> presented.
>
> > >>>>> On Thu, Feb 28, 2013 at 1:06 PM, Matt Thomas

> > >>>>> <m...@betweenbrain.com>wrote:

>
> > >>>>>> Hi all,
>
> > >>>>>> This may be a rather naive question, but what is the difference
> > >>>>>> between the Joomla Framework & Joomla Platform? I do see the Joomla
> > >>>>>> Framework as being described as being experimental, and Joomla being
> > >>>>>> a
> > >>>>>> Vendor in the framework. Is this just where the namespacing and the
> > >>>>>> new MVC
> > >>>>>> might happen, or is there more to it?
>
> > >>>>>> Thanks for any and all insight!
>
> > >>>>>> Best,
>
> > >>>>>> Matt
>
> > >>>>>> --
> > >>>>>> You received this message because you are subscribed to the Google
> > >>>>>> Groups "Joomla! Platform Development" group.
> > >>>>>> To unsubscribe from this group and stop receiving emails from it,
> > >>>>>> send
> > >>>>>> an email to joomla-dev-plat...@googlegroups.com.

> > >>>>>> For more options, visithttps://groups.google.com/groups/opt_out.

>
> > >>>>>  --
> > >>>>> You received this message because you are subscribed to the Google
> > >>>>> Groups "Joomla! Platform Development" group.
> > >>>>> To unsubscribe from this group and stop receiving emails from it,
> > >>>>> send
> > >>>>> an email to joomla-dev-plat...@googlegroups.com.

> > >>>>> For more options, visithttps://groups.google.com/groups/opt_out.

>
> > >>>>  --
> > >>>> You received this message because you are subscribed to the Google
> > >>>> Groups "Joomla! Platform Development" group.
> > >>>> To unsubscribe from this group and stop receiving emails from it, send
> > >>>> an email to joomla-dev-plat...@googlegroups.com.

> > >>>> For more options, visithttps://groups.google.com/groups/opt_out.

[Andrew Eddie]

On 1 March 2013 19:36, piotr_cz <pkoni...@hotmail.com> wrote:

What about creating new Organisation 'Joomla Framework', so the will
be

github.com/joomla-framework/ view
github.com/joomla-framework/ registry

and framework packages don't mix with cms, docs etc.

I think there's merit in asking the question - I'll put it on my list to follow up. Though you might argue the CMS should change to  github.com/joomla-cms/ to be consistent.

Regards,

Andrew Eddie

[Ian]

I will once again state my belief that even if we do create a new organisation the repos should still be called f.e. joomla-framework-view and joomla-framework-registry.

Ian

[Matt Thomas]

Amy,

You're too kind. Everyone on this thread has been generous by answering my questions and helping to making this happen. Writing it up for JCM was the least I could do to help pay forward the generosity of everyone. Thank you all!

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

--

[Matt Thomas]

Dmitry,

That would be fantastic. Thank you!

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

On Fri, Mar 1, 2013 at 1:17 AM, Dmitry Rekun <bzz...@gmail.com> wrote:

Thank you Matt. I am going to translate it to Russian, when JCM will come out.

[Matt Thomas]

One benefit of having different organizations is that each could have different sets of maintainers. That might be a good way of balancing the work load. Seems worth investigating.

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

--

[Matt Thomas]

Ian,

Why is that? A scheme like github.com/joomla-framework/view would create a clean structure. Are there deeper technical reasons for having more verbose names?

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

On Fri, Mar 1, 2013 at 9:14 AM, Ian <ianl...@gmail.com> wrote:

--

[Ian]

Because you potentially end up with collisions when you are working with multiple repositories.  This happens at work where we have two orgs, each with a repo called Services.  So I go and fork them, and obviously one has to be renamed.  That's annoying, but not necessarily the end of the world.  It is also confusing now, because I don't know which Services is the one that I want.

What is more problematic though is when you start to use CI tools to do work with your repos.  So we have Jenkins jobs that allow you to do deployments to development servers.  These generally hinge off of the repo name.  Now I can no longer use that Jenkins job and it increases the complexity because the Jenkins job is looking for the repo called Services and is going to deploy it.  uh oh.  I've now deployed the wrong codebase to the server and I have no way of using the Jenkins job to do it, which makes things difficult (if there is an alternative way to deploy) or impossible (if there aren't for security reasons).

Additionally, if those repos only ever existed under the joomla-framework org, it would be fine.  But github is, by its nature, a collaborative environment.  What happens when we get to something like cache?  or controller?

Ian

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

[Matt Thomas]

Thanks for explanation, that really helps and makes allot of sense. I definitely see where unique names are needed and where https://github.com/joomla-framework/view could cause issues.

Would pre-fixing everything with something like a J (i.e. https://github.com/joomla-framework/jview) help or are we just getting too cute for our own good?

Thanks again!

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

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

[Don]

IMO the repo names don't matter. What really matters are the names in Packagist, which they are the short names we are all asking for. 

http://packagist.org/packages/joomla

Sent from my iPhone

[Amy Stephen]

I think this would be a mistake.

Now that the PLT has decided each of these projects, the framework and the CMS, can innovate in different directions, it will be important to help everyone understand, it's still one community, and the work the platform team is doing can be back under the CMS when it's complete and they are ready.

Everyone knows there are problems in the platform code, in fact, that's why the FoF is being considered. But, that's only a temporary solution. It's another layer, on a layer, on a layer. That structure is less than ideal and the work the platform team is doing is the ultimate solution.

The benefit to untying the bonds between the projects is that they can each freely move. The danger is that nothing is forcing collaboration. There have been many frustrated with change, so, that adds to the risk. Starting to hear comments about the dilution of the brand, and unless there is data or examples that someone can share where fixing your code and making it available in other forms hurt a brand, I'd say people should be more careful not to create fear where it's not needed.

The work the platform team is doing will offer the CMS the benefits everyone has been asking for. People understand there are problems and while solutions like FoF can offer some short term release, fixing the actual problem is always going to be better than adding another layer on a layer on a layer to override tricky spots.

Things as simple and as innocent as creating new github organizations, combined with natural confusion and questions people have on the impact on changed, combined with fear, and it starts to look like a split.

The Joomla project needs to be careful to show unity and to help people understand how important this is to the CMS, too, understanding they don't have to choose it, but in all honesty, they will be impatient to get their hands on the code when it's more obvious to everyone what this means.

Sorry for the long comment and I don't want to be overly dramatic, there have been so many "crises" over the years where Joomla is going to die this time, it's laughable. But, I do believe clarity that this is still one project, one community, "All Together", right? It'll make things easier for everyone.

The way to create your own list of github repo's is to use the Joomla.github.com website resource. Lots of ways to customize what information is shown in what format. Might even provide a way for the PLT to help assure people of the unity between these efforts.

[Amy Stephen]

 If github were configured so the joomla organization was the "front" (github.com/joomla) and it provided some basic, overall info, and linked to two others organizations, github.com/joomla_cms and github.com/joomla_platform, equal footing, that would clearly unite the overall project.

Symfony has the same problem, but backwards. Recently, they added their CMF to their official product line. http://symfony.com/doc/master/cmf/index.html  So, they have components (packages), distro's, a CMS, lots of utilities that make it easier to take advantage of this uncoupled code, have as much as you need, no more (yes, I stole that from Andrew). 

It's not easy to navigate on github https://github.com/symfony/ but if you have spent anytime on their site http://symfony.com/ you might agree, they've done a pretty good job of making information easy to find.

That list from Symfony - components, distro's, a CMS, flexibility in rolling your own - that the same thing this community has been asking for -- and it's only possible for the Joomla project if the platform team is able to do what the Symfony team did - and that is the uncoupling and packaging work they are doing. The Symfony CMF shows you can take uncoupled code and easily pull it into something less technical people can use - and it's lean, more flexible, etc..

Symfony is only one example. There are many other compelling options out there right now and this list is growing. The days of a monolithic CMS are coming to an end. The platform team is on the right track, still working for the CMS, too, (if the CMS chooses to take the code, and of course they will).

So important to keep showing unity until others understand where this is all leading.

[Andrew Eddie]

I think it's very important that people feel enabled to ask questions about this if I want.

Unfortunately, Nic D's (author of FoF) *single* twitter remark is being given more weight than it should - it's his opinion but he doesn't speak for the whole Joomla community. It's very difficult to discuss matters properly on twitter so I hope people act responsibly with their 140 characters. 

I personally don't use anything that's said on twitter to influence how I should make decisions. Feedback on list is what counts and so far, I've been pleased that the discussion is overwhelming positive. BUT if you do have questions, and I know they are out there, please ask - we'll do our best to fill in the gaps because even we realise there are many.

Regards,
Andrew Eddie

[Paul Orwig]

Thanks Amy.

I saw OSM mentioned in a few tweets over the weekend about this subject, so I'll use that as an excuse to respond.

The short version from me is I am really happy at the direction that I see things going in, for the Framework as well as the CMS. I see a strong vision and a lot of enthusiasm from the Framework contributors, and that's the whole point, right? And I think the change will make things simpler and easier for the CMS contributors as well.

I think, as Amy mentions, that as a project we do have some work to do to, to more fully explain more about the direction(s) things are headed. That will take some time but that will all get done. Thanks a lot to Matt Thomas for getting that communication/education process off to a really good (and quick) JCM article that explains more about what's going on with the Platform and Framework.

2013 is going to be a really good year for Joomla - the CMS and the Framework. Thanks to everyone here who is making that happen!

Best,

paul

--

[Andrew Eddie]

On 4 March 2013 13:45, Amy Stephen <amyst...@gmail.com> wrote:

 If github were configured so the joomla organization was the "front" (github.com/joomla) and it provided some basic, overall info, and linked to two others organizations, github.com/joomla_cms and github.com/joomla_platform, equal footing, that would clearly unite the overall project. 

We'd be happy to entertain any changes to the text, but I think any expressions of "unity" are several orders of magnitude more forceful on the joomla.org family of websites. It's good to be consistent but if someone is evaluating the whole of the Joomla project by the description on Github and coming to the conclusion that the platform and the CMS are lacking unity, I don't think that's a persona we'd give the highest priority to channel effort.

Regards,

Andrew Eddie

[Amy Stephen]

Paul - +1, thanks for always promoting collaboration and the positive things going on. It's good for people to understand OSM is responsible for the brand, your visibility in the development area helps reinforce involvement and support too.

Andrew - unfortunately, that's not the first time I heard that, the first time was a concern expressed in the FoF list by a very well known community member. The idea is getting circulation and, as a result, some are worried. Yours and Paul's comments will help reassure people, too.

We should challenge one another too, ask for data, examples, some basis for concern, maybe someone is on to something, but if they are, they'll have links, articles, examples, a secretly recorded surveillance tape, etc., that illustrate the concern beyond a nagging feeling. Agree to encouraging people to just ask on list all the questions, especially rumors, get 'em in the open where they stand the test of sunlight.

Not trying to point fingers, just the need to show the project is one. As dumb as it may sound (or be), thinking about reaction to something as simple as a github presence can lend itself to those worries. 

[Andrew Eddie]

On 4 March 2013 20:51, Amy Stephen <amyst...@gmail.com> wrote:

Not trying to point fingers, just the need to show the project is one.

Sure, but since you mentioned it, if you cobble together some data that's demonstrating that https://github.com/joomla is falling short on demonstrating unity, I take a look :)

 

As dumb as it may sound (or be), thinking about reaction to something as simple as a github presence can lend itself to those worries.  

But, I've just checked - there is no description available for an organisation. In terms of the repo list, the order changes constantly based on the most recent activity. We've made that page as good as we can (I think).

I think a much better ROI would be gained from a refresh of developer.joomla.org myself. We now have three projects (CMS, Framework and Tracker) to funnel people to and I think that site could do a better job at doing that.

Regards,

Andrew Eddie

[Amy Stephen]

Andrew, if it's best to do it, by all means do it.

Maybe, Paul, you can arrange a photo-op for Andrew and Mark to stand in front of the new repo in a sign of unity for the grand opening. If you throw your arms of each, wouldn't hurt.

There, problem solved. ;-)

[Andrew Eddie]

On 4 March 2013 22:16, Amy Stephen <amyst...@gmail.com> wrote:

Andrew, if it's best to do it, by all means do it.

Maybe, Paul, you can arrange a photo-op for Andrew and Mark to stand in front of the new repo in a sign of unity for the grand opening. If you throw your arms of each, wouldn't hurt.

There, problem solved. ;-)

Heh - I think that will scare people away :)

Regards,

Andrew Eddie 

[Andrew Eddie]

So, I'm just wondering how we can keep this part of the coal face fresh. What's the next steps for honing the message / how should we best collaborate? I'm really felling we need something visual? And I think the Framework needs a landing page on developer.joomla.org so some UX-included people might be able to help us work out the best way to present that (the whole site needs a spring clean really).

Another point that just struck me is that one of the other pain points between the CMS and the Platform is that the CMS always had to take all of the Platform all of the time, and there is no opportunity to, for example, upgrade 2.5 and 3.0 to the same version of the entire platform. Chopping the Framework up allows a future CMS to upgrade the parts in all versions that won't introduce backward compatibility issues.

Thanks in advance.

Regards,

Andrew Eddie

[Andrew Eddie]

I shared this with the LT today - it might be helpful here too.

The impacts on the project as we see it distill to this:

1. The CMS will maintain its own copy of the platform.

Currently the CMS has to patch bugs in it's own repo and in the platform which is double handling. This is the only impact on day-to-day operations of the CMS. Developers that work on the CMS will still continue to work on the CMS. At a future time, the CMS will be able to upgrade it's code to include just the parts of the Framework it needs and have a much easier time of keeping those parts synchronised across versions of the CMS.

2. The Platform is being renamed to Framework

The renaming is because of a major architectural change called namespacing. We didn't want to confuse the non-namespaced platform that the CMS is using with the new namespaced code. It's a big change but the nature of the change is very geeky, but that's nothing to be concerned about.

3. All work on the Framework will happen in new repository.

It's just easier that way because the Platform is still being maintained for a short time. It would be a big mess to be working on both in the one repository.

4. The Framework will be activity distributed via a tool called Composer with uses a site called Packagist.org.

This is a major change. We currently don't "distribute" the platform, not actively anyway. We tag it and people can clone the repository, but that's it. Composer and Packagist are to the Framework what the downloads page is to the CMS. We are saying to the whole PHP community, not just those using Joomla, here is our code for you to use. It's sort of like being included on Fantastico where you can choose to install Joomla, Drupal, Wordpress, etc. It's huge deal in the PHP community at the moment and it's a massive opportunity for us to raise awareness of Joomla as something more than just a CMS.

Regards,
Andrew Eddie

[Donald Gilbert]

+1000

[Amy Stephen]

Excellent, clear note.

On Tuesday, March 5, 2013 4:54:13 PM UTC-6, Andrew Eddie wrote:

1. The CMS will maintain its own copy of the platform.

Currently the CMS has to patch bugs in it's own repo and in the platform which is double handling. This is the only impact on day-to-day operations of the CMS. Developers that work on the CMS will still continue to work on the CMS. At a future time, the CMS will be able to upgrade it's code to include just the parts of the Framework it needs and have a much easier time of keeping those parts synchronised across versions of the CMS.

Just for emphasis. There is a wild misunderstanding about that point that I hope your post will clarify.

In time, people will understand the significance of this to the survival of this project.

Best I have felt about Joomla's future since the (unfortunate?) day I walked into the Joomla forum and bought my first copy of Joomla.

You guys are on the right track. Bravo. Don's pluses cubed.

 

 

[Andrew Eddie]

I've knocked the following slides up - just thinking out loud for the moment:

https://docs.google.com/presentation/d/16KubTVSPf6JAAW0H5NXD_2CsfbnL2IAbcsTHkIdXjW0/edit?usp=sharing

Just trying to show there's nothing to panic about, and we've actually covered some of this ground before :)

The target audience for this set would be extension developers, application developers and site builders with a bit of development awareness.

Comments welcome.

Regards,
Andrew Eddie

[Donald Gilbert]

Anibal, that's the gist of it, but there are a few other changes as well. One is that the view has direct access to the model via $this->model, so you have access to all the public methods of the model. Previously, you only had direct access via the $this->get() method of the view and it only gave access to the get** methods of the model - Like getItems(), getPagination(), getState().

On Thu, Mar 7, 2013 at 6:14 AM, Anibal <anibal....@gmail.com> wrote:

Hi Andrew,

Very clear presentation. Just to be sure:

JView -> JViewLegacy -> Joomla\View\Html ?

$view->display() x $view->render() ?

Regards,

Anibal

--

[Ian]

Well that's not entirely true.  We've had the getModel method from pretty much the beginning:

https://github.com/joomla/joomla-platform/blob/11.1/libraries/joomla/application/component/view.php#L360

The major difference is that we are no longer encouraging the magic get proxy from the view to the model.  IMO the primary benefit of this is code clarity:

$this->model->getItems() is much clearer in what it is doing than $this->get('items').

Additionally, it is marginally lighter from a code execution point of view.

Ian

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

[Anibal]

Hi Donal and Ian,

Thank you for your response. I've just wanted to confirm the class hierarchy.

Now, to my mental notebook:

$this->get('items') --> $this->model->getItems()

This Wiki page is very handy for J3 Migration "Potential backward compatibility issues in Joomla 3.0 and Joomla Platform 12.1"... I imagine a new "Potential backward compatibility issues in Joomla x.x and Joomla Framework" ;-)

Regards,

Anibal

[Donald Gilbert]

It should be "Definite BC Issues between the CMS and Framework"

But, to be honest, I don't see the CMS using these classes as is. When they adopt the framework, they'll probably have their own namespacing etc, so, you may or may not be using the Joomla\View\Html class. (Well, Views, are simple enough the CMS could probably use them, but for sure not Joomla\Model\* classes as is.)

I would envision extension developers would extend Joomla\Cms\View\Html or something like that, which would allow the CMS to add in the code specific to their application.

Does that help any?

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

[Anibal]

Do you mean there's going to be middle layer (namespace) between the Framework and the CMS/Extensions to easy the transitions?

Thanks,

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

For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Donald Gilbert]

That's what I would like to see. The CMS has a lot of requirements that are not required at the Framework level. 

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