The key features are that JModel, JView and JController are now interfaces. This would normally cause a backward compatibility problem but the existing MVC classes have been moved to the /legacy/ tree, so the CMS will still use the old classes for the next two years (at least). New platform applications can, however, take advantage of the new packages which are much cleaner and lighter.
If you have any questions about this pull, don't hesitate to ask.
Please, everybody read this pull request. It has the potential of killing this project and everybody should be aware of the discussion that has been happening over there. I for one wasn't aware of this.
In the last two major releases, Joomla did everything to tell me to go away and look for a different project to invest my and my customers time into. This is yet another big incentive for me to go away. I doubt this is the right place for me to bring up all the issues that I see, so I shut up here.
> The key features are that JModel, JView and JController are now > interfaces. This would normally cause a backward compatibility > problem but the existing MVC classes have been moved to the /legacy/ > tree, so the CMS will still use the old classes for the next two years > (at least). New platform applications can, however, take advantage of > the new packages which are much cleaner and lighter.
> If you have any questions about this pull, don't hesitate to ask.
> I doubt this > is the right place for me to bring up all the issues that I see, so I > shut up here.
Hannes, if you do have issues with the proposed code beyond those already named and you don't actually submit them as feedback than your mail was possibly the most unhelpful mail I read in quite some time (und das obwohl ich auf dem LAT Veteiler stehe).
Rouven
PS: Those of you who don't speak german, Hannes will understand what the message means. Just be assured it's not something rude.
On 7 April 2012 08:59, Hannes Papenberg <hackwa...@googlemail.com> wrote:
> Please, everybody read this pull request. It has the potential of > killing this project and everybody should be aware of the discussion > that has been happening over there.
Would you care to elaborate on how you think it's going to kill this project? It's hard to respond to such a broad-brush statement.
> I for one wasn't aware of this.
Well, the pull request was only made 2 days ago, and since there is obviously some debate about it, I raised it here so you would be aware of it. Mission accomplished and you are welcome :)
The threat with the greatest potential to kill this project is our inability to *rationally* discuss *code*, our unwillingness as individuals to quickly adapt, to search high and low for ways to meet our own needs without forcing everyone to do things our way, and to celebrate the contributions of others.
On Friday, April 6, 2012 5:59:20 PM UTC-5, Hannes Papenberg wrote:Please,
everybody read this pull request. It has the potential of killing this project and everybody should be aware of the discussion that has been happening over there. I for one wasn't aware of this.
In the last two major releases, Joomla did everything to tell me to go away and look for a different project to invest my and my customers time into. This is yet another big incentive for me to go away. I doubt this is the right place for me to bring up all the issues that I see, so I shut up here.
Hello Andrew, there are several technical issues that I see, which Nicholas already pointed out in the pull request. Besides that, this is a good example how changes are made in Joomla. In a perfect world, Louis would have gone to the mailinglist and written "I see this problem with JController, etc. and would like to propose to do X." Then there could have been a (quick) discussion on the list and at the end there would be a "Sounds good" or "Sounds bad" and in the first case Louis would have started working on this. Then he would have created a pull request and in that pull request we could speak solely about technical issues.
Instead, we are talking about politics again. I claim that having this discussion is mostly futile, because the decision has already been made before Louis even made the pull request. Please don't get me wrong, I don't think you have made this decision conciously like "Ok guys, huddle, this is the plan, lets do it like this." But I think that the people arguing pro this change are working to close together to judge this proposal unbiased. Right now 11 people are contributing to the pull discussion and 6 of those 11 are either sceptic or openly against this. The other 5 are the platform maintainers...
I feel bad for bringing this up again, but when I did my first pull requests, you asked me to get support from the community and then we could have a look at my proposals. I did that and quite frankly, am still waiting for the platform maintainers to give me their judgement on stuff like the router. (Yes, I gave up on keeping the code up to speed, since its been a year since my first proposal) I'm simply expecting the same from you guys.
After this long prologue: Why should this kill Joomla? This alone of course does not kill Joomla, its simply another piece in the puzzle. The short point is, that contributing to Joomla is extremely difficult and it drives away contributors. This lets us fall behind other competing systems even further and will eventually reduce our user base.
If you really want to get people involved, do what lots of experts will tell you: Let maintainers only review the code, but not write it themselfs. As a coder you are to much involved to judge it unbiased. That prevents discussions like this and for example makes sure that the maintainer reviews all peoples contributions and is not knee deep in his own code that he is writing.
> On 7 April 2012 08:59, Hannes Papenberg <hackwa...@googlemail.com> wrote: >> Please, everybody read this pull request. It has the potential of >> killing this project and everybody should be aware of the discussion >> that has been happening over there. > Would you care to elaborate on how you think it's going to kill this > project? It's hard to respond to such a broad-brush statement.
>> I for one wasn't aware of this. > Well, the pull request was only made 2 days ago, and since there is > obviously some debate about it, I raised it here so you would be aware > of it. Mission accomplished and you are welcome :)
You know you're right Hannes. When someone contributes something out to the open source community and someone says that your contribution to the enhancement of the project will kill the project, I guess that you'd definitely not want to contribute any more to the project and that'd make it hard to contribute. I congratulate you for wanting to improve contribution to the project but an outsider merely reading this thread would likely be heavily dissuaded from contributing because they probably don't want to be blamed for killing the Joomla! project.
I'm not sure if I've ever had a contribution that I've been told will kill the project, but I bet it'd be awfully demoralising. Just imagine, you personally killing a project with over 30 million downloads (not counting international versions or versions distributed through Fantastico).
Near as I can tell there is still mostly positive two way communications on that thread. Let's keep it positive.
<hackwa...@googlemail.com> wrote: > Hello Andrew, > there are several technical issues that I see, which Nicholas already > pointed out in the pull request. Besides that, this is a good example > how changes are made in Joomla. In a perfect world, Louis would have > gone to the mailinglist and written "I see this problem with > JController, etc. and would like to propose to do X." Then there could > have been a (quick) discussion on the list and at the end there would be > a "Sounds good" or "Sounds bad" and in the first case Louis would have > started working on this. Then he would have created a pull request and > in that pull request we could speak solely about technical issues.
> Instead, we are talking about politics again. I claim that having this > discussion is mostly futile, because the decision has already been made > before Louis even made the pull request. Please don't get me wrong, I > don't think you have made this decision conciously like "Ok guys, > huddle, this is the plan, lets do it like this." But I think that the > people arguing pro this change are working to close together to judge > this proposal unbiased. Right now 11 people are contributing to the pull > discussion and 6 of those 11 are either sceptic or openly against this. > The other 5 are the platform maintainers...
> I feel bad for bringing this up again, but when I did my first pull > requests, you asked me to get support from the community and then we > could have a look at my proposals. I did that and quite frankly, am > still waiting for the platform maintainers to give me their judgement on > stuff like the router. (Yes, I gave up on keeping the code up to speed, > since its been a year since my first proposal) I'm simply expecting the > same from you guys.
> After this long prologue: Why should this kill Joomla? This alone of > course does not kill Joomla, its simply another piece in the puzzle. The > short point is, that contributing to Joomla is extremely difficult and > it drives away contributors. This lets us fall behind other competing > systems even further and will eventually reduce our user base.
> If you really want to get people involved, do what lots of experts will > tell you: Let maintainers only review the code, but not write it > themselfs. As a coder you are to much involved to judge it unbiased. > That prevents discussions like this and for example makes sure that the > maintainer reviews all peoples contributions and is not knee deep in his > own code that he is writing.
> Hannes
> Am 07.04.2012 01:19, schrieb Andrew Eddie: >> On 7 April 2012 08:59, Hannes Papenberg <hackwa...@googlemail.com> wrote: >>> Please, everybody read this pull request. It has the potential of >>> killing this project and everybody should be aware of the discussion >>> that has been happening over there. >> Would you care to elaborate on how you think it's going to kill this >> project? It's hard to respond to such a broad-brush statement.
>>> I for one wasn't aware of this. >> Well, the pull request was only made 2 days ago, and since there is >> obviously some debate about it, I raised it here so you would be aware >> of it. Mission accomplished and you are welcome :)
It would have been nice if you had said something about the issue or my proposal, instead of just picking out one phrase that suits your goal to divert attention away from my criticism.
> You know you're right Hannes. When someone contributes something out > to the open source community and someone says that your contribution > to the enhancement of the project will kill the project, I guess that > you'd definitely not want to contribute any more to the project and > that'd make it hard to contribute. I congratulate you for wanting to > improve contribution to the project but an outsider merely reading > this thread would likely be heavily dissuaded from contributing > because they probably don't want to be blamed for killing the Joomla! > project.
> I'm not sure if I've ever had a contribution that I've been told will > kill the project, but I bet it'd be awfully demoralising. Just > imagine, you personally killing a project with over 30 million > downloads (not counting international versions or versions distributed > through Fantastico).
> Near as I can tell there is still mostly positive two way > communications on that thread. Let's keep it positive.
> On Fri, Apr 6, 2012 at 5:35 PM, Hannes Papenberg > <hackwa...@googlemail.com> wrote: >> Hello Andrew, >> there are several technical issues that I see, which Nicholas already >> pointed out in the pull request. Besides that, this is a good example >> how changes are made in Joomla. In a perfect world, Louis would have >> gone to the mailinglist and written "I see this problem with >> JController, etc. and would like to propose to do X." Then there could >> have been a (quick) discussion on the list and at the end there would be >> a "Sounds good" or "Sounds bad" and in the first case Louis would have >> started working on this. Then he would have created a pull request and >> in that pull request we could speak solely about technical issues.
>> Instead, we are talking about politics again. I claim that having this >> discussion is mostly futile, because the decision has already been made >> before Louis even made the pull request. Please don't get me wrong, I >> don't think you have made this decision conciously like "Ok guys, >> huddle, this is the plan, lets do it like this." But I think that the >> people arguing pro this change are working to close together to judge >> this proposal unbiased. Right now 11 people are contributing to the pull >> discussion and 6 of those 11 are either sceptic or openly against this. >> The other 5 are the platform maintainers...
>> I feel bad for bringing this up again, but when I did my first pull >> requests, you asked me to get support from the community and then we >> could have a look at my proposals. I did that and quite frankly, am >> still waiting for the platform maintainers to give me their judgement on >> stuff like the router. (Yes, I gave up on keeping the code up to speed, >> since its been a year since my first proposal) I'm simply expecting the >> same from you guys.
>> After this long prologue: Why should this kill Joomla? This alone of >> course does not kill Joomla, its simply another piece in the puzzle. The >> short point is, that contributing to Joomla is extremely difficult and >> it drives away contributors. This lets us fall behind other competing >> systems even further and will eventually reduce our user base.
>> If you really want to get people involved, do what lots of experts will >> tell you: Let maintainers only review the code, but not write it >> themselfs. As a coder you are to much involved to judge it unbiased. >> That prevents discussions like this and for example makes sure that the >> maintainer reviews all peoples contributions and is not knee deep in his >> own code that he is writing.
>> Hannes
>> Am 07.04.2012 01:19, schrieb Andrew Eddie: >>> On 7 April 2012 08:59, Hannes Papenberg <hackwa...@googlemail.com> wrote: >>>> Please, everybody read this pull request. It has the potential of >>>> killing this project and everybody should be aware of the discussion >>>> that has been happening over there. >>> Would you care to elaborate on how you think it's going to kill this >>> project? It's hard to respond to such a broad-brush statement.
>>>> I for one wasn't aware of this. >>> Well, the pull request was only made 2 days ago, and since there is >>> obviously some debate about it, I raised it here so you would be aware >>> of it. Mission accomplished and you are welcome :)
On 7 April 2012 10:35, Hannes Papenberg <hackwa...@googlemail.com> wrote:
> Hello Andrew, > there are several technical issues that I see, which Nicholas already > pointed out in the pull request.
And I've responded to those. Nic is entitled to his opinion and so am I. However, the fact that I disagree with Nic does not equate to the fact I'm not listening to him. Given that, the only technical issue Nic is worried about is the name of the interfaces. As far as I'm aware he's supportive, if only tepidly, of the proposed design.
> Besides that, this is a good example > how changes are made in Joomla.
Yes it is.
> In a perfect world, Louis would have > gone to the mailinglist and written "I see this problem with > JController, etc. and would like to propose to do X." Then there could > have been a (quick) discussion on the list and at the end there would be > a "Sounds good" or "Sounds bad" and in the first case Louis would have > started working on this. Then he would have created a pull request and > in that pull request we could speak solely about technical issues.
Perfect according to who's rules? There is no rule for the order in which you do things and Louis most certain does favour making pull requests then talking about the pro's and con's. I prefer gauging the temperature first, but I must admit that is more tedious because people go off on tangents. Whatever the case, this is not a reason to assess the merit of the pull request or not. It may be how you feel, and I respect it, but I don't have to agree that is the definition of the "perfect" world. Everything is public - that is sufficient.
> Instead, we are talking about politics again.
Indeed I think we are.
> I claim that having this > discussion is mostly futile, because the decision has already been made > before Louis even made the pull request.
It most certainly hasn't.
> Please don't get me wrong, I > don't think you have made this decision conciously like "Ok guys, > huddle, this is the plan, lets do it like this."
Well that's something I guess.
> But I think that the > people arguing pro this change are working to close together to judge > this proposal unbiased.
Um, hang on. So you are saying that if you issue a pull request, you can't speak in favour of it because it's your work? That's a bit over the top and something you don't practice yourself. Regardless, we have an in-house rule that you can't approve your own pull request. Seeing as Louis, Rob, Sam and myself have all contributed to this code, it excludes us from approving it. I judge the work as "very good", but I don't have the authority to push the merge button.
> Right now 11 people are contributing to the pull > discussion and 6 of those 11 are either sceptic or openly against this. > The other 5 are the platform maintainers…
Actually I count only 1 person still vehemently against, but that reason has more to do with change management in the CMS which is a conversation that should be had with the CMS. The rest seem satisfied with our answers to their questions.
> I feel bad for bringing this up again, but when I did my first pull > requests, you asked me to get support from the community and then we > could have a look at my proposals. I did that and quite frankly, am > still waiting for the platform maintainers to give me their judgement on > stuff like the router. (Yes, I gave up on keeping the code up to speed, > since its been a year since my first proposal) I'm simply expecting the > same from you guys.
And likewise, I'm sure you don't expect the maintainers to tell you that the sky is going to fall if they merge your code. It, indeed cuts both ways. For example, I've put 9 years of myself into this project. For you to suggest I want to kill the project with this pull request is less than complimentary.
> After this long prologue: Why should this kill Joomla? This alone of > course does not kill Joomla, its simply another piece in the puzzle. The > short point is, that contributing to Joomla is extremely difficult and > it drives away contributors. This lets us fall behind other competing > systems even further and will eventually reduce our user base.
I think you have had a particularly difficult road, but that's not necessarily been all "our" fault and many others seem to navigate it with success. It's certainly much easier to contribute to the platform than it is to contribute to the CMS and whether you approve or not, I think we do the best we can given the time we have available to do it. You also have no idea what is going on in people's lives, but let's just say there's been a spike in personal matters for several maintainers that have otherwise occupied their time.
> If you really want to get people involved, do what lots of experts will > tell you: Let maintainers only review the code, but not write it > themselfs.
That is what happens now. The person who reviews the code does not write it. In terms of lobbying, Ian, Chistophe and Rouven are your guys. However, if the will of the group is that I only maintain and not contribute, or only contribute and not maintain, I will comply.
> As a coder you are to much involved to judge it unbiased.
Correct, that's why we don't merge our own pull requests as maintainers and make sure pull requests like this are advertised (nothing to hide Hannes - we want people to discuss things). However, we have the right to speak for our own ideas and you don't have the right to take that away from anyone.
> That prevents discussions like this and for example makes sure that the > maintainer reviews all peoples contributions and is not knee deep in his > own code that he is writing.
I sincerely doubt that. But if the rest of the people that contribute code to the platform feel the same way, I will most happily change my standing. Maybe you should start a petition.
As Amy suggests - let's review the code. It speaks for itself. It's beautiful, clean and a pleasure to use. If we park the interface name debate for now, is there anything technically wrong with the refactor itself? JViewHtml is particularly nice and probably my favourite but JController also has a wonderfully elegant way of handling input and configuration.
Note there are full docs in the /docs/ directory under the developer manual for all the packages (yes, you heard it right, full developer documentation! you don't see that every day). I have on my list to do some examples but I've just not had time yet. It seems that I need to up the priority of those because I think seeing some examples will increase the "wow" factor.
The main thing to remember is this is a format for platform applications (CLI's, web portals, web service platforms) - it's not intended to be something a CMS extension developer will pick up immediately (maybe down the road, maybe never). These extra applications are just as much the future of this project as is the CMS, so it's very important we get this right and we have an opportunity to do that with this pull request.
To get back to the code -- First let me say that i think the new code for MVC looks great, and look forward to working with it. The main issue raised as far as i can see is the naming of classes ( i agree with some of the concerns about using the same name that the cms already using --- an interface should have interface in its class name imho ). As for Hannes comments and sam`s reply --- yes there have been millions of downloads of Joomla --- THE CMS --- and frankly to hear some of the main contributers to the platform saying that they do not care if the cms adopts the platform code or not is a concern. The cms is the main application that uses the platform, and should be the top consideration when any code changes proposed. Joomla as a CMS could survive ( even using another platform/ framework as Drupal is proposing ) , but the Joomla platform NEEDS the cms , a fact that i fear some may have forgotten.
> The key features are that JModel, JView and JController are now > interfaces. This would normally cause a backward compatibility > problem but the existing MVC classes have been moved to the /legacy/ > tree, so the CMS will still use the old classes for the next two years > (at least). New platform applications can, however, take advantage of > the new packages which are much cleaner and lighter.
> If you have any questions about this pull, don't hesitate to ask.
> The key features are that JModel, JView and JController are now
> interfaces. This would normally cause a backward compatibility
> problem but the existing MVC classes have been moved to the /legacy/
> tree, so the CMS will still use the old classes for the next two years
> (at least). New platform applications can, however, take advantage of
> the new packages which are much cleaner and lighter.
> If you have any questions about this pull, don't hesitate to ask.
I think the simple reality is that if the CMS ever feels that the platform has diverged too far from what it can support, it can fork the platform back into itself. In a sense this is the case already that the CMS and platform get out of sync and then they get themselves back in sync with each other. This will happen on an on going basis.
The simple reality is that the reverse is in fact more true. The CMS needs the platform but the platform project could live happily on it's own without the CMS. If that wasn't the case we wouldn't all be having this issue about problems with entirely CMS related code on the platform list and platform pull requests.
<wr.richard...@btinternet.com> wrote: > To get back to the code -- First let me say that i think the new code for > MVC looks great, and look > forward to working with it. > The main issue raised as far as i can see is the naming of classes ( i agree > with some of the concerns about using the same name > that the cms already using --- an interface should have interface in its > class name imho ). > As for Hannes comments and sam`s reply --- yes there have been millions of > downloads of Joomla --- THE CMS --- and frankly to hear > some of the main contributers to the platform saying that they do not care > if the cms adopts the platform code or not is a concern. > The cms is the main application that uses the platform, and should be the > top consideration when any code changes proposed. > Joomla as a CMS could survive ( even using another platform/ framework as > Drupal is proposing ) , but the Joomla platform NEEDS the cms , > a fact that i fear some may have forgotten.
> Regards > Bill Richardson
> On Friday, 6 April 2012 23:34:39 UTC+1, Andrew Eddie wrote:
>> Just wanting to draw everyone's attention to this important pull request:
>> The key features are that JModel, JView and JController are now >> interfaces. This would normally cause a backward compatibility >> problem but the existing MVC classes have been moved to the /legacy/ >> tree, so the CMS will still use the old classes for the next two years >> (at least). New platform applications can, however, take advantage of >> the new packages which are much cleaner and lighter.
>> If you have any questions about this pull, don't hesitate to ask.
You don't feel this documentation is sufficient? I'll grant you it need to be run through docbook to be readable to those who can't parse XML directly but I'm sure everyone on this list can at least skim it.
Surely you will agree compared with the existing unit tests for the existing JController, JView and JModel that the added documentation and tests are very much an improvement upon what is there. If anything the code itself is smaller (682 additions; about a third) compared to the documentation (447 additions) and tests (901 additions).
>> The key features are that JModel, JView and JController are now >> interfaces. This would normally cause a backward compatibility >> problem but the existing MVC classes have been moved to the /legacy/ >> tree, so the CMS will still use the old classes for the next two years >> (at least). New platform applications can, however, take advantage of >> the new packages which are much cleaner and lighter.
>> If you have any questions about this pull, don't hesitate to ask.
"The CMS needs the platform but the platform project could live happily on it's own without the CMS " quote from sam Yes - thats true - but is anyone going to use it - there are better , more mature frameworks out there that can be used by developers to develop standalone applications ( eg Codeigniter, Zend, Symfony.) People use Joomla because of the CMS , the platform it uses is immaterial -- i want to see the CMS improve, use the latest developments in php,etc --- the CMS needs as much attention , if not more than the platform from the core contributers and i do not think wise to ignore it when changes proposed in the platform without demonstrating with code the advantages to the CMS.
On Saturday, 7 April 2012 08:40:11 UTC+1, Samuel Moffatt wrote:
> I think the simple reality is that if the CMS ever feels that the > platform has diverged too far from what it can support, it can fork > the platform back into itself. In a sense this is the case already > that the CMS and platform get out of sync and then they get themselves > back in sync with each other. This will happen on an on going basis.
> The simple reality is that the reverse is in fact more true. The CMS > needs the platform but the platform project could live happily on it's > own without the CMS. If that wasn't the case we wouldn't all be having > this issue about problems with entirely CMS related code on the > platform list and platform pull requests.
> On Sat, Apr 7, 2012 at 12:11 AM, bill richardson > <wr.richard...@btinternet.com> wrote: > > To get back to the code -- First let me say that i think the new code for > > MVC looks great, and look > > forward to working with it. > > The main issue raised as far as i can see is the naming of classes ( i > agree > > with some of the concerns about using the same name > > that the cms already using --- an interface should have interface in its > > class name imho ). > > As for Hannes comments and sam`s reply --- yes there have been millions > of > > downloads of Joomla --- THE CMS --- and frankly to hear > > some of the main contributers to the platform saying that they do not > care > > if the cms adopts the platform code or not is a concern. > > The cms is the main application that uses the platform, and should be the > > top consideration when any code changes proposed. > > Joomla as a CMS could survive ( even using another platform/ framework as > > Drupal is proposing ) , but the Joomla platform NEEDS the cms , > > a fact that i fear some may have forgotten.
> > Regards > > Bill Richardson
> > On Friday, 6 April 2012 23:34:39 UTC+1, Andrew Eddie wrote:
> >> Just wanting to draw everyone's attention to this important pull > request:
> >> The key features are that JModel, JView and JController are now > >> interfaces. This would normally cause a backward compatibility > >> problem but the existing MVC classes have been moved to the /legacy/ > >> tree, so the CMS will still use the old classes for the next two years > >> (at least). New platform applications can, however, take advantage of > >> the new packages which are much cleaner and lighter.
> >> If you have any questions about this pull, don't hesitate to ask.
On 7 April 2012 17:11, bill richardson <wr.richard...@btinternet.com> wrote:
> an interface should have interface in its class name imho
Louis has already pointed out in the pull request comments that at least one "expert" promotes natural naming (Martin Fowler), and also, most of PHP follows that convention as well (it uses Iterator or ArrayAccess, not IteratorInterface nor ArrayAccessInterface). The "I" prefix is another common method (for .NET devotees <cough>), but that collides with our "J" convention. Another for not include "I" or "Interface" in the name is that you are embedding implementation details in the name itself, which is generally frowned upon. Zend Framework makes it "optional" (but recommend) to include the Interface suffix.
It should also be noted we don't have the practice of adding "Abstract" to the name of abstract classes. Exceptions do contain "exception" in the name, but an exception is a concrete class and we commonly include the base "type" in the name (e.g., models have "model" in the name).
In my own experience, I've found the segregation of interfaces (or abstract classes) distracting and would much prefer to think in terms of is this class a "model", a "date", an "object". When checking types in the code, it's much easier (for me) to think in those terms. So for example, most developers in Joomla will extend from JModelDatabase, e.g.:
class MyModel extends JModelDatabase
But, to check if something is a model, all you need to do is:
if ($model instance of JModel)
and then you are done (it's very simple to remember). You don't have to remember that JModel is an interface (most developers won't care and those that do know what they are doing anyway).
At least that's my reasoning for it anyway. I accept that other people have different views but my take is if PHP's not doing it, it's not unreasonable to follow suit (it certainly won't cause the end of the world either way).
> As for Hannes comments and sam`s reply --- yes there have been millions of > downloads of Joomla --- THE CMS --- and frankly to hear > some of the main contributers to the platform saying that they do not care > if the cms adopts the platform code or not is a concern.
If I happen to have also given that impression, I apologise. I would like nothing more for the CMS to adopt newer versions of the platform when it is practical, and I'm also very conscious of not causing it, and other downstream users, grief. Personally I think 2 years notice for a potential backward incompatible change is fair :)
On 7 April 2012 19:18, bill richardson <wr.richard...@btinternet.com> wrote:
> "The CMS needs the platform but the platform project could live happily on > it's > own without the CMS " quote from sam > Yes - thats true - but is anyone going to use it - there are better , more > mature frameworks out there > that can be used by developers to develop standalone applications ( eg > Codeigniter, Zend, Symfony.)
Well, that's debatable (more natural maybe, better, ehum). Whatever the case, it's a chicken and egg argument. One needs the other for the moment. Down the track, I would hope there is a next-generation Joomla "thingy" that offers more choice. This pull request is a step closed to making that new breed of Joomla applications really hum.
@eddie .. Nobody says that the code isn.t fine or something. I love the idea of a unified content model and many other things in the newer plattform, but as bill already told you the joomla cms is the thing we should concentrate on. Joomla is known as the cms and it hopefully always be.
At this time the plattform isn't working for the cms, it's working for ebay. Maybe we should split it and get our own cms-plattform which works better together with the cms. For my opinion the current plattform doesn't deserve the name "joomla". But that's it, isn't it ? If the plattform doesn't use "joomla" to get popular nobody will ever know/use it (except ebay)...
Where is the philosophy "all together" ? For now we are spending more time against eachother than together. And this can't be the way.
Hello Andrew, regarding the technical issues: For me, the backwards compatibility is an issue, as well as the missing naming convention.
regarding the futility of this discussion: If this discussion is not futile, then please tell me how many people it requires for the naming of the classes to be revised. Is there a fixed number of people that have to be against it? A ratio? What if in the coming two days, for every proponent to name the interface JView, we have 2 opponents? Is this a democracy, a dictatorship or simply anarchy? I ask this without intending insult. I simply want to know which standards are put forward. For example, my JView proposal was opposed by you, but "upvoted" by three other people and didn't make it in. If you say, the vote of a platform maintainer counts as much as 5 community members, that is okay with me, likewise when you say "decisions fully depend on the maintainers and the community input has no guaranteed effect." If you want, you can simply say that I'm disgruntled, because my proposals are constantly rejected, I don't care, but when you want people to contribute, you have to give them a process that subjectively does not depend on the daily mood or personal history of the platform maintainers with the contributor.
regarding supporting Pulls: No, I'm not saying that you can't speak for your own pull request. I'm saying that in the "perfect" world, we would have a group of maintainers that don't write code and thus are not emotionally involved in the code in any way. These maintainers can judge proposed code free from bias of earlier times, like "I wrote the code that this guy wants to change." or "His code might be ok, but I have ideas for a way better solution that I'm going to code soon (tm)". They also would not be biased by following the development from the early idea to the final pull request, overlooking the point where something might have gone wrong.
You say that maintainers will not approve their own pull requests. That is a given for me. As I wrote, I think the best way would be if maintainers didn't write any code at all.
Last but not least about the standalone-character of the platform in regards to the CMS: The platform is a spin-off from the CMS. 99.9% of the people using the platform are using the CMS. Those 99.9% are the userbase of the platform. If you break it for those 99.9%, the CMS has two possibilities: Fork the platform and develop it further themselfs, effectively taking 99.9% of the users of the platform with them. Or adapt to the change and hope that all CMS users "give in" and follow en suite. Considering the difficult adoption of new versions from Joomla 1.5 to 2.5, the CMS would loose quite a lot of customers. (Yes, we already have lots of other backwards compatibility issues. That however doesn't make it any better.) As much as you dislike it, the usage of the platform not as part of the Joomla CMS is negligible and you don't simply f**k your biggest customer. Conclusion: The platform has to heavily take into account the impact on the CMS. The other way around is practically unimportant.
> On 7 April 2012 10:35, Hannes Papenberg <hackwa...@googlemail.com> wrote: >> Hello Andrew, >> there are several technical issues that I see, which Nicholas already >> pointed out in the pull request. > And I've responded to those. Nic is entitled to his opinion and so am > I. However, the fact that I disagree with Nic does not equate to the > fact I'm not listening to him. Given that, the only technical issue > Nic is worried about is the name of the interfaces. As far as I'm > aware he's supportive, if only tepidly, of the proposed design.
>> Besides that, this is a good example >> how changes are made in Joomla. > Yes it is.
>> In a perfect world, Louis would have >> gone to the mailinglist and written "I see this problem with >> JController, etc. and would like to propose to do X." Then there could >> have been a (quick) discussion on the list and at the end there would be >> a "Sounds good" or "Sounds bad" and in the first case Louis would have >> started working on this. Then he would have created a pull request and >> in that pull request we could speak solely about technical issues. > Perfect according to who's rules? There is no rule for the order in > which you do things and Louis most certain does favour making pull > requests then talking about the pro's and con's. I prefer gauging the > temperature first, but I must admit that is more tedious because > people go off on tangents. Whatever the case, this is not a reason to > assess the merit of the pull request or not. It may be how you feel, > and I respect it, but I don't have to agree that is the definition of > the "perfect" world. Everything is public - that is sufficient.
>> Instead, we are talking about politics again. > Indeed I think we are.
>> I claim that having this >> discussion is mostly futile, because the decision has already been made >> before Louis even made the pull request. > It most certainly hasn't.
>> Please don't get me wrong, I >> don't think you have made this decision conciously like "Ok guys, >> huddle, this is the plan, lets do it like this." > Well that's something I guess.
>> But I think that the >> people arguing pro this change are working to close together to judge >> this proposal unbiased. > Um, hang on. So you are saying that if you issue a pull request, you > can't speak in favour of it because it's your work? That's a bit over > the top and something you don't practice yourself. Regardless, we > have an in-house rule that you can't approve your own pull request. > Seeing as Louis, Rob, Sam and myself have all contributed to this > code, it excludes us from approving it. I judge the work as "very > good", but I don't have the authority to push the merge button.
>> Right now 11 people are contributing to the pull >> discussion and 6 of those 11 are either sceptic or openly against this. >> The other 5 are the platform maintainers > Actually I count only 1 person still vehemently against, but that > reason has more to do with change management in the CMS which is a > conversation that should be had with the CMS. The rest seem satisfied > with our answers to their questions.
>> I feel bad for bringing this up again, but when I did my first pull >> requests, you asked me to get support from the community and then we >> could have a look at my proposals. I did that and quite frankly, am >> still waiting for the platform maintainers to give me their judgement on >> stuff like the router. (Yes, I gave up on keeping the code up to speed, >> since its been a year since my first proposal) I'm simply expecting the >> same from you guys. > And likewise, I'm sure you don't expect the maintainers to tell you > that the sky is going to fall if they merge your code. It, indeed > cuts both ways. For example, I've put 9 years of myself into this > project. For you to suggest I want to kill the project with this pull > request is less than complimentary.
>> After this long prologue: Why should this kill Joomla? This alone of >> course does not kill Joomla, its simply another piece in the puzzle. The >> short point is, that contributing to Joomla is extremely difficult and >> it drives away contributors. This lets us fall behind other competing >> systems even further and will eventually reduce our user base. > I think you have had a particularly difficult road, but that's not > necessarily been all "our" fault and many others seem to navigate it > with success. It's certainly much easier to contribute to the > platform than it is to contribute to the CMS and whether you approve > or not, I think we do the best we can given the time we have available > to do it. You also have no idea what is going on in people's lives, > but let's just say there's been a spike in personal matters for > several maintainers that have otherwise occupied their time.
>> If you really want to get people involved, do what lots of experts will >> tell you: Let maintainers only review the code, but not write it >> themselfs. > That is what happens now. The person who reviews the code does not > write it. In terms of lobbying, Ian, Chistophe and Rouven are your > guys. However, if the will of the group is that I only maintain and > not contribute, or only contribute and not maintain, I will comply.
>> As a coder you are to much involved to judge it unbiased. > Correct, that's why we don't merge our own pull requests as > maintainers and make sure pull requests like this are advertised > (nothing to hide Hannes - we want people to discuss things). However, > we have the right to speak for our own ideas and you don't have the > right to take that away from anyone.
>> That prevents discussions like this and for example makes sure that the >> maintainer reviews all peoples contributions and is not knee deep in his >> own code that he is writing. > I sincerely doubt that. But if the rest of the people that contribute > code to the platform feel the same way, I will most happily change my > standing. Maybe you should start a petition.
> As Amy suggests - let's review the code. It speaks for itself. It's > beautiful, clean and a pleasure to use. If we park the interface name > debate for now, is there anything technically wrong with the refactor > itself? JViewHtml is particularly nice and probably my favourite but > JController also has a wonderfully elegant way of handling input and > configuration.
> Note there are full docs in the /docs/ directory under the developer > manual for all the packages (yes, you heard it right, full developer > documentation! you don't see that every day). I have on my list to do > some examples but I've just not had time yet. It seems that I need to > up the priority of those because I think seeing some examples will > increase the "wow" factor.
> The main issue raised as far as i can see is the naming of classes ( i > agree with some of the concerns about using the same name > that the cms already using --- an interface should have interface in its > class name imho ).
Well, I see the beauty in the original proposal. Nevertheless, a naming convention like adding 'Interface' to interface names will be more practical, since it avoids BC issues. That would not change anything technically on the proposal, and not force CMS and in consequence more than 9000 extensions to be re-written. The energy can then be used to improve them, which IMO is of much higher value for Joomla!.
Our policy should be not to break anything, if it can be avoided. If that means to go another way than just the pure academic one, it is ok for me.
If you see the platform as a separate project (which I don't), you should at least always have your greatest customer in mind: the CMS. The platform has to provide improvements in way, that does not add avoidable work to the CMS and its extensions.
The goal for both platform and CMS should be to get rid of the legacy library. It is needed to get around unavoidable BC issues, but it is not an invitation to break things, where it can be avoided. One single issue with that legacy library is that it prevents code completion from working properly, because duplicate class names add ambiguosity, which can't be resolved by an IDE (that problem exists in some other places, too, but that should rather be fixed than be used as an excusion).
So, just name the interfaces JModelInterface, JViewInterface and JControllerInterface, and there abstract counterparts JModelBase, JViewBase and JControllerBase. Each application (like the CMS) is then able to provide their own base classes called JModel, JView and JController. The CMS will just have to refactor their own three base classes, and every existing extension will work *unchanged*. That's what I'd call responsible improvement.
> @eddie .. Nobody says that the code isn.t fine or something.
Thankyou.
> I love the idea > of a unified content model and many other things in the newer plattform,
Well, this isn't strictly a pull for UCM, though it is a dependency.
> but > as bill already told you the joomla cms is the thing we should concentrate > on. Joomla is known as the cms and it hopefully always be.
I actually hope it won't always be known for the CMS ;) That's a very specific implementation that has a fixed market. You can't make a command line application with the CMS. You can't really make a good web services platform with the CMS (you can try, but you'll hit very high brick walls very quickly).
> At this time the plattform isn't working for the cms,
The CMS still uses the platform last I looked and is planning to upgrade in 3.0.
> it's working for ebay.
Well, yes it is, just as it's working for many other individuals and organisations. However, the idea of platform separation is not new and not owned by eBay. It's been talked about since the birth of 1.5. Of the 700 or so accepted pull requests, this is the first "official" one from eBay, so I'm not sure what point you are trying to make. Besides, I think it's highly discriminatory to criticise someone's contribution because of where they work.
> Maybe we should split it and get our own cms-plattform which works better > together with the cms. For my opinion the current plattform doesn't deserve > the name "joomla". But that's it, isn't it ? If the plattform doesn't use > "joomla" to get popular nobody will ever know/use it (except ebay)…
I'm sorry you feel that way. It's not a view I share.
> Where is the philosophy "all together" ? For now we are spending more time > against eachother than together. And this can't be the way.
I doubt that's really the case. I think it's more that a small minority of people perceive disagreement as rejection. That's unfortunate but there's not much I can do about that.
On 7 April 2012 19:04, Niels Braczek <nbrac...@bsds.de> wrote:
> Well, I see the beauty in the original proposal. Nevertheless, a naming > convention like adding 'Interface' to interface names will be more > practical, since it avoids BC issues. That would not change anything > technically on the proposal, and not force CMS and in consequence more > than 9000 extensions to be re-written. The energy can then be used to > improve them, which IMO is of much higher value for Joomla!.
It won't be that many and it won't have to happen for at least 2 years and that's only if the CMS decides to drop the current MVC implementation. Even if it doesn't, I would hope that deprecates much of the existing package, which will ultimately mean you are back to rewriting 9,000 extensions (but nobody really knows how many it will be).
> Our policy should be not to break anything, if it can be avoided.
No, that's actually not our policy. The development strategy allows for breaking changes when the major version number changes in the CMS. If you don't like that policy, then that's something you need to lobby the CMS to change. In the platform we do try to maintain a high level of b/c, but the MVC refactor was just too difficult to maintain the old 1.5 baggage that's in those classes. Now, if you like the classes, but not the interface, we still have major b/c issues.
> If > that means to go another way than just the pure academic one, it is ok > for me.
I think we've established it's more than just academic.
> If you see the platform as a separate project (which I don't),
I do, but under the unified "brand" of Joomla.
> you > should at least always have your greatest customer in mind: the CMS.
And we do.
> The > platform has to provide improvements in way, that does not add avoidable > work to the CMS and its extensions.
And that's why the legacy tree was added.
> The goal for both platform and CMS should be to get rid of the legacy > library.
Well, yes and no. I think the name "legacy" is being misunderstood. Maybe a better name is "transitional". It's not that the code is no good, but some of it is just not relevant to anything but the CMS. We've had the CMS decoupling campaign going for quite some time now. I'm a bit surprised at the negative reactions all of a sudden and, indeed, the legacy tree was heavily advertised at the time we switched over. Why all the complaints about it all of a sudden?
> It is needed to get around unavoidable BC issues, but it is not > an invitation to break things, where it can be avoided.
I think we are all good enough developers to acknowledge that and respect that we would judge such situations professionally. There seems to be the perception evolving that Louis, Rob, Sam and I don't know what we are doing and couldn't care two hoots about the impact on downstream users just because we work at the same place. That's a pretty bitter pill to swallow given our combined years of service.
> One single issue > with that legacy library is that it prevents code completion from > working properly, because duplicate class names add ambiguosity, which > can't be resolved by an IDE (that problem exists in some other places, > too, but that should rather be fixed than be used as an excision).
That's actually a fair comment - not enough to move me, but fair.
> So, just name the interfaces JModelInterface, JViewInterface and > JControllerInterface, and there abstract counterparts JModelBase, > JViewBase and JControllerBase. Each application (like the CMS) is then > able to provide their own base classes called JModel, JView and > JController. The CMS will just have to refactor their own three base > classes, and every existing extension will work *unchanged*. That's what > I'd call responsible improvement.
And Rouven proposed a very simple forward compatibility strategy to do that.
I may ultimately loose this battle, but I really dislike the *Interface naming because it's not the lead PHP takes itself, nor leading pattern architects like Martin Fowler and others I'm sure. We don't do it for abstract classes and everyone seems to survive quite nicely. The issue is, what we do for interfaces here, we set as the standard.
At any rate, even if the interface names didn't collide, we still need the legacy tree to buffer the changes in the CMS till at least 4.0 (2 years away). So I'm taking it that even if you think the code is good, the whole pull is a -1? To me that's disappointing because it is a good refactor (in my opinion). The platform simply doesn't need the current, very heavy and CMS centric MVC classes.
I've been following this discussion with interest. I've been an application architect and developer for a long time; I've done framework development and wrestled with the problems of design improvements vs. breaking changes; I've done these things in .net, JavaScript, php, and java; I hold software patents. I just want you all to know where I'm coming from when I say this: I think Andrew and company are absolutely on the right track with this pull request. It's not a simple choice; valid concerns on both sides must be balanced; and I think Andrew and company have done an admirable job of finding that balance. If we want Joomla to continue to evolve into a robust next-generation platform we have to continue down this path, separating the platform from implementations. Breaking changes are inevitable. If we really want to darken Joomla's future, limiting it to CMS is a good way to accomplish that.
__________________________ Gary Glass
On Apr 7, 2012, at 8:27, Andrew Eddie <mambob...@gmail.com> wrote:
On 7 April 2012 19:04, Niels Braczek <nbrac...@bsds.de> wrote:
> Well, I see the beauty in the original proposal. Nevertheless, a naming > convention like adding 'Interface' to interface names will be more > practical, since it avoids BC issues. That would not change anything > technically on the proposal, and not force CMS and in consequence more > than 9000 extensions to be re-written. The energy can then be used to > improve them, which IMO is of much higher value for Joomla!.
It won't be that many and it won't have to happen for at least 2 years and that's only if the CMS decides to drop the current MVC implementation. Even if it doesn't, I would hope that deprecates much of the existing package, which will ultimately mean you are back to rewriting 9,000 extensions (but nobody really knows how many it will be).
> Our policy should be not to break anything, if it can be avoided.
No, that's actually not our policy. The development strategy allows for breaking changes when the major version number changes in the CMS. If you don't like that policy, then that's something you need to lobby the CMS to change. In the platform we do try to maintain a high level of b/c, but the MVC refactor was just too difficult to maintain the old 1.5 baggage that's in those classes. Now, if you like the classes, but not the interface, we still have major b/c issues.
> If > that means to go another way than just the pure academic one, it is ok > for me.
I think we've established it's more than just academic.
> If you see the platform as a separate project (which I don't),
I do, but under the unified "brand" of Joomla.
> you > should at least always have your greatest customer in mind: the CMS.
And we do.
> The > platform has to provide improvements in way, that does not add avoidable > work to the CMS and its extensions.
And that's why the legacy tree was added.
> The goal for both platform and CMS should be to get rid of the legacy > library.
Well, yes and no. I think the name "legacy" is being misunderstood. Maybe a better name is "transitional". It's not that the code is no good, but some of it is just not relevant to anything but the CMS. We've had the CMS decoupling campaign going for quite some time now. I'm a bit surprised at the negative reactions all of a sudden and, indeed, the legacy tree was heavily advertised at the time we switched over. Why all the complaints about it all of a sudden?
> It is needed to get around unavoidable BC issues, but it is not > an invitation to break things, where it can be avoided.
I think we are all good enough developers to acknowledge that and respect that we would judge such situations professionally. There seems to be the perception evolving that Louis, Rob, Sam and I don't know what we are doing and couldn't care two hoots about the impact on downstream users just because we work at the same place. That's a pretty bitter pill to swallow given our combined years of service.
> One single issue > with that legacy library is that it prevents code completion from > working properly, because duplicate class names add ambiguosity, which > can't be resolved by an IDE (that problem exists in some other places, > too, but that should rather be fixed than be used as an excision).
That's actually a fair comment - not enough to move me, but fair.
> So, just name the interfaces JModelInterface, JViewInterface and > JControllerInterface, and there abstract counterparts JModelBase, > JViewBase and JControllerBase. Each application (like the CMS) is then > able to provide their own base classes called JModel, JView and > JController. The CMS will just have to refactor their own three base > classes, and every existing extension will work *unchanged*. That's what > I'd call responsible improvement.
And Rouven proposed a very simple forward compatibility strategy to do that.
I may ultimately loose this battle, but I really dislike the *Interface naming because it's not the lead PHP takes itself, nor leading pattern architects like Martin Fowler and others I'm sure. We don't do it for abstract classes and everyone seems to survive quite nicely. The issue is, what we do for interfaces here, we set as the standard.
At any rate, even if the interface names didn't collide, we still need the legacy tree to buffer the changes in the CMS till at least 4.0 (2 years away). So I'm taking it that even if you think the code is good, the whole pull is a -1? To me that's disappointing because it is a good refactor (in my opinion). The platform simply doesn't need the current, very heavy and CMS centric MVC classes.
@Adam The documentation happens to be terrific as is the documentation for UCM.
@you know who you are
Class names? We are personally attacking people and calling them names and embarrassing them at their work places over class names? How about if everyone takes an hour to look over what they are posting before posting it? How about considering that what you post on the web lives forever?
@All
It seems to me that people have not really been thinking deeply enough about what the platform means, what UCM means, and what the changing web means. In the context of UCM lots of extensions are going to be reconceived in all or part as content types. The old ones might still work but no new users are going to want to use them when the new ones are lighter and more flexible. And just look the the APIs that are being proposed for gsoc and on the ideas list for gsoc, tons of extension are going to want to take advantage of them. Either old extensions will be rewritten or new ones will replace them. Other extensions really perhaps should not be extensions at all, they should be platform applications. We've already see some announce that they are going that way, and I'd assume that every smart developer with a complex extension is thinking about that. None of this is a bad thing, this is a path to survival and more than survival, to thriving. The path to failure is to fail to continuously improve and adapt.
And 9000 extensions include a lot of extensions that exist to solve specific problems caused by limitations in the architecture of the current CMS and of the 1.5 CMS. Of course those limitation are being addressed. They are limitations that we all know about, and addressing them is called progress. New extensions are going to come in that deal with new limitations. And people are going to push things in all kinds of unexpected and powerful ways, just like they did with 1.0 and 1.5 and are doing with 2.5.
The real question on the CMS side (and not the platform side) is whether we plan to have a CMS in two years that is competitive with (and ideally superior to) other options that new users have. Narrow, short term, what does it mean for me today thinking is not going to make that true.
> On Fri, Apr 6, 2012 at 9:44 PM, Adam Stephen Docherty > <adam.doche...@gmail.com> wrote: > > Hello there,
> > I have confidence in Andrew and Louis, these fellows obviously know > > what they are doing... but for god's sake please provide > > documentation!
> You don't feel this documentation is sufficient? I'll grant you it > need to be run through docbook to be readable to those who can't parse > XML directly but I'm sure everyone on this list can at least skim it.
> Surely you will agree compared with the existing unit tests for the > existing JController, JView and JModel that the added documentation > and tests are very much an improvement upon what is there. If anything > the code itself is smaller (682 additions; about a third) compared to > the documentation (447 additions) and tests (901 additions).
> Cheers,
> Sam
> > On Apr 6, 7:34 pm, Andrew Eddie <mambob...@gmail.com> wrote: > >> Just wanting to draw everyone's attention to this important pull > request:
> >> The key features are that JModel, JView and JController are now > >> interfaces. This would normally cause a backward compatibility > >> problem but the existing MVC classes have been moved to the /legacy/ > >> tree, so the CMS will still use the old classes for the next two years > >> (at least). New platform applications can, however, take advantage of > >> the new packages which are much cleaner and lighter.
> >> If you have any questions about this pull, don't hesitate to ask.
> >> Regards, > >> Andrew Eddie
On Saturday, April 7, 2012 3:49:15 AM UTC-4, Samuel Moffatt wrote:
> On Fri, Apr 6, 2012 at 9:44 PM, Adam Stephen Docherty > <adam.doche...@gmail.com> wrote: > > Hello there,
> > I have confidence in Andrew and Louis, these fellows obviously know > > what they are doing... but for god's sake please provide > > documentation!
> You don't feel this documentation is sufficient? I'll grant you it > need to be run through docbook to be readable to those who can't parse > XML directly but I'm sure everyone on this list can at least skim it.
> Surely you will agree compared with the existing unit tests for the > existing JController, JView and JModel that the added documentation > and tests are very much an improvement upon what is there. If anything > the code itself is smaller (682 additions; about a third) compared to > the documentation (447 additions) and tests (901 additions).
> Cheers,
> Sam
> > On Apr 6, 7:34 pm, Andrew Eddie <mambob...@gmail.com> wrote: > >> Just wanting to draw everyone's attention to this important pull > request:
> >> The key features are that JModel, JView and JController are now > >> interfaces. This would normally cause a backward compatibility > >> problem but the existing MVC classes have been moved to the /legacy/ > >> tree, so the CMS will still use the old classes for the next two years > >> (at least). New platform applications can, however, take advantage of > >> the new packages which are much cleaner and lighter.
> >> If you have any questions about this pull, don't hesitate to ask.
> >> Regards, > >> Andrew Eddie
On Saturday, April 7, 2012 3:49:15 AM UTC-4, Samuel Moffatt wrote:
> On Fri, Apr 6, 2012 at 9:44 PM, Adam Stephen Docherty > <adam.doche...@gmail.com> wrote: > > Hello there,
> > I have confidence in Andrew and Louis, these fellows obviously know > > what they are doing... but for god's sake please provide > > documentation!
> > I have confidence in Andrew and Louis, these fellows obviously know
> > what they are doing... but for god's sake please provide
> > documentation!
> You don't feel this documentation is sufficient? I'll grant you it
> need to be run through docbook to be readable to those who can't parse
> XML directly but I'm sure everyone on this list can at least skim it.
> Surely you will agree compared with the existing unit tests for the
> existing JController, JView and JModel that the added documentation
> and tests are very much an improvement upon what is there. If anything
> the code itself is smaller (682 additions; about a third) compared to
> the documentation (447 additions) and tests (901 additions).
> Cheers,
> Sam
> > On Apr 6, 7:34 pm, Andrew Eddie <mambob...@gmail.com> wrote:
> >> Just wanting to draw everyone's attention to this important pull request:
> >> The key features are that JModel, JView and JController are now
> >> interfaces. This would normally cause a backward compatibility
> >> problem but the existing MVC classes have been moved to the /legacy/
> >> tree, so the CMS will still use the old classes for the next two years
> >> (at least). New platform applications can, however, take advantage of
> >> the new packages which are much cleaner and lighter.
> >> If you have any questions about this pull, don't hesitate to ask.
On 8 April 2012 15:14, Adam Stephen Docherty <adam.doche...@gmail.com> wrote:
> Ok Gotcha, I guess I should have looked up the documentation on where > to find the documentation first lol...
I've made a very ugly but functional copy of the docs and attached it. I should say that following some very good constructive criticism (I'll ignore the unconstructive, hehe) I probably need to provide a few more code examples and shore up a bit of the text a bit. But, for now, this is where it's at but it's a good start.
I'll just draw your attention to one point and that's about controllers. They are intended to start life as atomic units supporting just one action. This is deliberate but there is nothing preventing you from designing a multitask controller that mirrors what JController currently does (it just needs to be done a lot better if you want to do it). So rather than execute taking a task passed to the execute method and looking up a task map, the execute method *is* that task at the most basic level (it makes designing web services really clean, but I admit it's a "whoa" moment - don't worry, I had the same reaction initially).
I'll make a note to tweak the docs to make it sound less forceful in this aspect. I'm also not doing the JViewHtml class justice, particularly with regard to the layout override priority queue so I'll need to do some more work on that.
