Simplified MVC.
Andrew Eddie
https://github.com/joomla/joomla-platform/pull/1120
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
Hannes Papenberg
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.
Hannes
Rouven Weßling
I doubt this
is the right place for me to bring up all the issues that I see, so I
shut up here.
Andrew Eddie
> 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 :)
Regards,
Andrew Eddie
Amy Stephen
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
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.
Hannes
Hannes Papenberg
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
Sam Moffatt
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.
Cheers,
Sam Moffatt
http://pasamio.id.au
Hannes Papenberg
proposal, instead of just picking out one phrase that suits your goal to
divert attention away from my criticism.
Hannes
Andrew Eddie
> 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.
Regards,
Andrew Eddie
bill richardson
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
Adam Stephen Docherty
I have confidence in Andrew and Louis, these fellows obviously know
what they are doing... but for god's sake please provide
documentation!
Sam Moffatt
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.
Cheers,
Sam Moffatt
http://pasamio.id.au
Sam Moffatt
http://pasamio.id.au
On Fri, Apr 6, 2012 at 9:44 PM, Adam Stephen Docherty
<adam.d...@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 presume you've read:
https://github.com/joomla/joomla-platform/pull/1120/files#diff-0
https://github.com/joomla/joomla-platform/pull/1120/files#diff-1
https://github.com/joomla/joomla-platform/pull/1120/files#diff-2
https://github.com/joomla/joomla-platform/pull/1120/files#diff-3
https://github.com/joomla/joomla-platform/pull/1120/files#diff-4
https://github.com/joomla/joomla-platform/pull/1120/files#diff-5
https://github.com/joomla/joomla-platform/pull/1120/files#diff-6
https://github.com/joomla/joomla-platform/pull/1120/files#diff-7
https://github.com/joomla/joomla-platform/pull/1120/files#diff-9
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.
Plus you've also checked out the additional unit tests added:
https://github.com/joomla/joomla-platform/pull/1120/files#diff-18
https://github.com/joomla/joomla-platform/pull/1120/files#diff-19
https://github.com/joomla/joomla-platform/pull/1120/files#diff-20
https://github.com/joomla/joomla-platform/pull/1120/files#diff-21
https://github.com/joomla/joomla-platform/pull/1120/files#diff-22
https://github.com/joomla/joomla-platform/pull/1120/files#diff-23
https://github.com/joomla/joomla-platform/pull/1120/files#diff-24
https://github.com/joomla/joomla-platform/pull/1120/files#diff-25
https://github.com/joomla/joomla-platform/pull/1120/files#diff-26
https://github.com/joomla/joomla-platform/pull/1120/files#diff-27
https://github.com/joomla/joomla-platform/pull/1120/files#diff-28
https://github.com/joomla/joomla-platform/pull/1120/files#diff-29
https://github.com/joomla/joomla-platform/pull/1120/files#diff-30
https://github.com/joomla/joomla-platform/pull/1120/files#diff-31
https://github.com/joomla/joomla-platform/pull/1120/files#diff-32
https://github.com/joomla/joomla-platform/pull/1120/files#diff-33
https://github.com/joomla/joomla-platform/pull/1120/files#diff-34
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
bill richardson
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.
Regards
Bill Richardson
Andrew Eddie
> 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 :)
Regards,
Andrew Eddie
Andrew Eddie
> "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.
Regards,
Andrew Eddie
Nils Rückmann
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.
Hannes Papenberg
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.
Hannes
>> The other 5 are the platform maintainers�
Niels Braczek
> 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.
Regards,
Niels
--
| http://barcamp-wk.de · 1. Barcamp Westküste 30./31. März 2012 |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
------------------------------------------------------------------
Andrew Eddie
> @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.
Regards,
Andrew Eddie
Andrew Eddie
> 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.
Regards,
Andrew Eddie
Gary Glass
__________________________
Gary Glass
Elin Waring
Adam Stephen Docherty
to find the documentation first lol...
On Apr 7, 4:49 am, Sam Moffatt <pasa...@gmail.com> wrote:
> Sam Moffatthttp://pasamio.id.au
> On Fri, Apr 6, 2012 at 9:44 PM, Adam Stephen Docherty
>
> > 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 presume you've read:
>
> 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.
>
Andrew Eddie
> 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.
Regards,
Andrew Eddie
Adam Stephen Docherty
is a good primer, ie an appropriate description of what this new pull
request will be implementing:
http://techportal.ibuildings.com/2010/02/22/scaling-web-applications-with-hmvc/
If so it looks like a definite step in the right direction (IMHO of
course!)
Anyways thanks again for taking the time to write up those docs.
Happy Easter :)
On Apr 8, 2:46 am, Andrew Eddie <mambob...@gmail.com> wrote:
> 153KViewDownload
Andrew Eddie
>
> If so it looks like a definite step in the right direction (IMHO of
> course!)
The "intention" is that it is a step in the right direction to support
HMVC, but I also suspect there's a bit more work to be done to make it
happen elegantly. I think we'll still need people throwing ideas
around about how best to do HMVC and then we can work out what
additional support we need to make it easy and beautiful :)
> Anyways thanks again for taking the time to write up those docs.
You are welcome.
> Happy Easter :)
And also to you.
Regards,
Andrew Eddie
Andrew Eddie
> regarding the technical issues: For me, the backwards compatibility is
> an issue, as well as the missing naming convention.
I agree and backward compatibility is also a huge issue for me.
That's why we went to great pains working out the legacy tree.
> For example, my JView proposal was opposed by you, but "upvoted" by
> three other people and didn't make it in.
I gave you extensive feedback on that pull
(https://github.com/joomla/joomla-platform/pull/421), as did others,
and my comments still stand. I think the new event belongs in the CMS
(to be honest maybe the controller should be firing it anyway). But
now, the SplPriorityQueue for the layout paths in JViewHtml solves
your common layout problem in a much neater and more flexible way.
You get half way there by supporting this pull request :)
> Conclusion: The platform has to
> heavily take into account the impact on the CMS.
I agree and I think the platform does a very good job of doing that
under some very close scrutiny from the likes of Rouven, Christophe,
Ian, Elin, Michael B, Nikolai … and I could go on (forgive me if I
didn't mention your name directly - you know who you are).
Regards,
Andrew Eddie
Niels Braczek
> On 7 April 2012 19:04, Niels Braczek <nbra...@bsds.de> wrote:
>> 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.
Please understand me right: I'm just talking about the *naming* of the
interfaces. Everything else is just fine for me.
>> The goal for both platform and CMS should be to get rid of the legacy
>> library.
>
> Well, yes and no. [...] Why all the complaints about it all of a sudden?
I surely understand the need of the legacy tree, and what it is good
for, as I stated in my next sentence.
>> 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.
I absolutely agree.
> 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.
I'm sorry, if that is what you read between my lines. That's not what I
tried to communicate.
>> 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).
>
> That's actually a fair comment - not enough to move me, but fair.
I'm sure you'll agree, that duplicate class names should be reduced to a
minimum. It is a requirement of clean code.
>> 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.
Could you point me to that proposal? I must have missed it. The only
thing I found was https://github.com/LouisLandry/plugin-compat, but that
does not solve the problem: If JModelBase implements JModel (an
interface), how can the CMS provide another JModel class which extends
from JModelBase?
> 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.
Well, I'm a fan of Martin Fowler, and he's always been a great
inspiration to me. But in this case, we are not free in our decisions,
since we've got dependencies. In this case, it is just a question of
naming. The 'Interface' suffix is not beautiful, but would allow a
smooth transition to the new MVC by refactoring just 3 classes in the
CMS. Without the suffix, several thousand classes and scripts have to be
changed.
> 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).
Accepted, since it is useful, even if it is not beauty. I guess we'll
always have some kind of a transitional tree, just to decouple
development cycles of CMS and platform. That makes sense.
> So I'm taking it that even if you think the code is
> good, the whole pull is a -1?
Absolutely not. I like the proposal. I'm just unhappy with the
consequences of the suggested naming.
> 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.
FullACK. The CMS should be able to adopt to the new MVC without pain,
and - what IMO is most important - without again forcing extension
developers to rewrite their code just because of naming issues.
Hannes Papenberg
Amen to that.
Elin Waring
Herman Peeren
What I get from it (but please enlighten me if I'm wrong):
- In Joomla 2.5.5 we add aliases for JView, JControler and JModel: JViewLegacy, JControllerLegacy and JModelLegacy. Alias = a new class with a new name that executes the code of the old view, controler and model, first by referring to those existing classes and later, when the new interfaces are in use, by putting the old code into the alias-class itself.
- We probably also have to do that for all current base classes that might be replaced by interfaces with the same name (JDatabase? JInput? JForm? JApplication? J(Database)Table? JUser? JDocument? JGithub? JHtml? JButton? JHttp? JImage? JExtension? JMail? JRegistry? JUpdate? Some more?). ATM to me it is not clear what are the criteria for a Platform base-class to possibly be "interfaced" or not. I'd say: any base class that might have another implementation.
- Then, in the next months we replace all occurrences of JView, JControler and JModel by JViewLegacy, JControllerLegacy and JModelLegacy (and idem for eventually other base-classes that might be "interfaced") in the Joomla core and ask to do the same to all other Joomla! developers (I don't like the name 3PD, for they are an essential part of Joomla's infrastructure). As the new interfaces are used in Joomla CMS 3.0, then all extensions that use replaced classes just stay working, and they will as long as the legacy-classes are supported.
If I see that right, then it is a lot of work. None of this work would have to be done if the old names would not have been replaced by new names. Plus, as a bonus, the extensions that now work in 2.5 (or maybe in 1.5 and 2.5) would continue to work without doing anything concerning those classes. The gain of all the work is however, that we get better, more clear interface names. Finding the balance is asking what are the costs of changing the names compared to the costs of "old fashioned" or otherwise unwanted interface names. The costs of the latter are difficult to calculate, a.o. because they involve taste, which is hard to quantify. So, a comparison is hard and so is a balance. It will always involve subjective arguments.
I'm not saying any strategy is right or wrong, I just want to properly understand what was proposed by Rouven.
Andrew Eddie
> We probably also have to do that for all current base classes that might be
> replaced by interfaces with the same name (JDatabase? JInput? JForm?
The database package has already gone through an **extensive**
refactor. There are no plans to go through that exercise again any
time soon. JInput and JForm are fine as they are.
> JApplication?
Ideally yes, JApplication will be deprecated (replaced by
JApplicationWeb for the CMS) and converted to an interface, but
there's no hurry to do that and it does not affect CMS extension
developers.
> J(Database)Table?
No plans to change in the short term although ultimately
JDatabaseTable will be deprecated to be replaced by a Data Mapper
pattern. There is no hurry to do this.
However, you should consider the fact that "JDatabase" will be dropped
from the CMS at some point and extension developers must change any
hinting to JDatabaseDriver, probably in CMS 4.0. This gives the
extension developers the whole of the 3.x cycle to change over. This
is **exactly the same** issue but everyone seems to have accepted that
without any complaint :)
> JUser?
JUser will probably be extended from a new set of classes and an
interface called JIdentity. No conflict will be introduced.
> JDocument?
JDocument, we think, won't be needed in the long term but we aren't
sure. There are no short term plans to change it anyway.
> JGithub? JHtml? JButton?
> JHttp? JImage? JExtension? JMail? JRegistry? JUpdate? Some more?).
Nope, none of those will suddenly change into interfaces. Their
function is well defined.
> ATM to
> me it is not clear what are the criteria for a Platform base-class to
> possibly be "interfaced" or not. I'd say: any base class that might have
> another implementation.
It's really a case-by-case decision so it's hard to predict. If you
have a look at my new authorisation package work
(https://github.com/eBaySF/joomla-platform/tree/content/libraries/joomla/authorisation)
you'll see it contains a mixed of interfaces and concrete classes.
> Then, in the next months we replace all occurrences of JView, JControler and
> JModel by JViewLegacy, JControllerLegacy and JModelLegacy (and idem for
> eventually other base-classes that might be "interfaced") in the Joomla core
> and ask to do the same to all other Joomla! developers (I don't like the
> name 3PD, for they are an essential part of Joomla's infrastructure). As the
> new interfaces are used in Joomla CMS 3.0, then all extensions that use
> replaced classes just stay working, and they will as long as the
> legacy-classes are supported.
As far as I'm aware the new interfaces won't be activated until CMS
4.0. The JControllerLegacy, etc, are a 'bridge' for forward
compatibility.
> If I see that right, then it is a lot of work.
Fortunately you aren't so I don't believe this aspect will be a lot of
work. However, can we predict how much work *is* going to be
upgrading extensions from 3.0 to 4.0? No, and I would be very
surprised if extensions developers aren't required to "clean up" quite
a lot of code in 2 years time. Additionally, I doubt that much of the
effort will be due necessarily to changes in the platform. It will
probably be due to changes in the way the CMS has chosen to change.
> None of this work would have
> to be done if the old names would not have been replaced by new names. Plus,
> as a bonus, the extensions that now work in 2.5 (or maybe in 1.5 and 2.5)
> would continue to work without doing anything concerning those classes.
I would ask you to consider that in 2 years time, when CMS 4.0 comes
around, an "extension" won't be the only option for a developer to
provide a solution to a client/customer/etc. A developer will be able
to either provide an extension for the CMS, or they will be able to
write a stand-alone Joomla application that does the job. Yes, the
Joomla extension market is the main customer for the platform at the
moment, and that's why we've buffered this one change, but it won't
always be the case.
> The
> gain of all the work is however, that we get better, more clear interface
> names. Finding the balance is asking what are the costs of changing the
> names compared to the costs of "old fashioned" or otherwise unwanted
> interface names. The costs of the latter are difficult to calculate, a.o.
> because they involve taste, which is hard to quantify. So, a comparison is
> hard and so is a balance. It will always involve subjective arguments.
Correct, and as I've said, I am positive there will be other factors
that affect extension developers in 2014. But I am also positive this
will *not* be the most significant factor (for example, if UCM is
adopted in the CMS, that is a monumental game changer - the interface
names are the least of your worries).
I hope that helps make it clearer.
Regards,
Andrew Eddie
Herman Peeren
1. when using the autoloader as is now we would get JMvcModel etc. I would rather call that "clearer class names" than "much uglier class names" as Rouven does.
2. we could also use namespaces for those new classes. Namespaces will be used after the autoloader is fully in use. So, good plan to not use it yet for existing classes. But, we are building for Joomla's future here: we are talking about classes that will be used in CMS 4.0 ... which is in one and a half years. Namespaces will be used everywhere in Joomla! then, won't they? So why not use it for new stuff allready now? Why first do the new things the old way and later refactoring it to namespaces?
a. we could use the class and interface names as proposed now in the pull. So you get, use joomla\mvc: JModelBase implements JModel
b. but we could even leave the J then! So we get even much ;-) nicer classnames, use joomla\mvc: ModelBase implements Model.
I would go for option 2b. When you bake your own model, based on Joomla's base-model, in namespace \myownlibrary\mvc: modelBase extends \joomla\mvc\ModelBase.
It would be future-proof and can be used alongside the current system; so development can go on while existing software can stay unaltered. Everybody happy?
Andrew Eddie
On 11 April 2012 14:56, Herman Peeren <herman...@gmail.com> wrote:
> 1. when using the autoloader as is now we would get JMvcModel etc. I would
> rather call that "clearer class names" than "much uglier class names" as
> Rouven does.
Sort of reminds me of recursive acronyms or people that say that GPL
License (where L already stands for license) :)
Personally I'm not a fan of the "mvc" package (I actually think it's
much uglier), mainly because there are several variants of MVC today
(HMVC, MVCR, and so on) - it's not a stable acronym like XML. We did
look at the single package but only as a means to an end to avoid
compatibility issues, not because we liked the naming convention.
In a platform application would have to following tree:
/source
../mvc
…./model
….../cars.php
….../boats.php
…./controller
……./cars.php
as opposed to:
/source
../model
…./cars.php
…./boats.php
../controller
…./cars.php
I think it's worth saving one level of folders from the outset. I also
can't think of any other major platform API that uses an MVC package
in that way.
http://api.cakephp.org/classes
http://www.symfony-project.org/api/1_0/
http://framework.zend.com/apidoc/core/nav.html
> 2. we could also use namespaces for those new classes.
Yes we can, but we don't want to do that until the whole platform
works with the auto-loader (there's no point in doing it in pieces -
that would be an utter disaster). Yes, it is reasonable to assume
that by 2014, we will have name spacing in place. Having said that,
name spacing will still potentially require code changes for extension
developers. It's useful to be able to use two concurrent API's
without colliding, but I don't believe it will necessarily reduce
change management to zero. It's also a new level of complexity for
extension developers to learn.
> b. but we could even leave the J then! So we get even much ;-) nicer
> classnames, use joomla\mvc: ModelBase implements Model.
I think that's something to discuss when we discuss name spacing
because it will affect far more than just this pull request. I think
you'll run into huge amounts of trouble doing that. I've put on the
roadmap on the wiki that we should aim to have all classes
auto-loading by 12.3 and should aim for name spacing in 13.1 so we've
got the rest of the year to work out the details :)
> It would be future-proof and can be used alongside the current system; so
> development can go on while existing software can stay unaltered. Everybody
> happy?
But it's already future proof to a reasonable degree. New platform
applications can start using the newer, lighter, cleaner MVC today,
unburdened by a lot of the baggage, and really bad habits, from the
CMS. The CMS has a buffer for introducing change until at least 2014
(or any time of its choosing, which could be never). If you want both
in the CMS, you are just going to have to wait until it's realistic to
introduce name spacing, or you change the CMS much faster and convince
the extension developers why they should change early (that's not my
job anymore by the way, hehe).
However, all the push back I've heard is about "breaking" extensions
in the CMS. I'm not hearing any CMS extension developers knocking us
over to change the MVC in 3.0 so I think the "what if they want to use
both" case doesn't have any real-world support (I could be wrong, but
I doubt it). Let's cross that bridge if any extension developer
actually asks for it before 2014. There's also the option of the CMS
never changing away from the current MVC implementation if that is the
wish of the extension developers (for the sake of the alleged 99.99%
of platform users via the CMS) - but that's not our call as platform
contributors to make. Additionally, I'm not hearing any complaints
about deprecations and removals that are going to affect 3.0 and 4.0
of the CMS so my conclusion there is that you assume that the CMS
people are going to look after you (which they already are) and/or
those changes were reasonable to make.
I hope that puts it into perspective because we are really proposing a
change that makes sense for the platform and the new breed of
applications that will be built on it (incidentally, most of the
acceptable GSOC projects this year are platform-centric). The needs
for downstream users that need to buffer breaking changes, most
important of which is the CMS at this time, are taken into account
with the legacy tree but it's not the job of platform to actually
manage the change in the CMS itself which is mostly what I'm hearing
people are concerned about - that's up to those maintaining the CMS.
Regards,
Andrew Eddie
Herman Peeren
(...) namespaces (...) we don't want to do that until the whole platform
works with the auto-loader (there's no point in doing it in pieces -
that would be an utter disaster). (...) we should aim to have all classes
auto-loading by 12.3 and should aim for name spacing in 13.1 (...) you are just going to have to wait until it's realistic to introduce name spacing (...)
BTW, In Dutch we have a similar seemingly recursive expression like "GPL license": "NEN norm". We had some discussions about that. It looks strange, but it is not realy recursive: it is a meta-level in the language. The first word "Licence" is part of the name (hence the capital) and the second "license" (no capital!) says what type of thing it is. You can have a BSD license, an Apache license, a GPL license. See, the better you look at it the less strange it is. With other MVC-implementations I could also imagine they would have there own namespace. \mvc would then be the "official one" but we could also have a \adhd (could be an abbreviation of "Amy's Dotnet Hmvc Derivate" ;-) ) namespace with it's own model, modelview or whatever.
Andrew Eddie
> I myself combine namespaces in Joomla-programs mixed with jimport() and
> autoloader, a.o. when using Doctrine. It doesn't give any problems and it
> doesn't make it more complicated. Just the contrary: it makes it easier and
> avoids disasters. So I think the new framework basics, that you are doing in
> pieces, are perfect cases to introduce them! I'd go for the easy way; the
> way it's done in nowadays PHP.
Yes I understand that and I totally agree. What I meant was that I
think it is unwise to name space part of our platform without a)
having discussed it on list first, which leads to b) having an agreed
upon strategy to do it. That's a wider issue than can be covered by
this pull and when we do name space the platform, I think we should do
all of it at once, not part of it here and there.
> but we could also have a \adhd (could be an abbreviation of "Amy's Dotnet
> Hmvc Derivate" ;-) ) namespace with it's own model, modelview or whatever.
I'm still not convinced ;)
Regards,
Andrew Eddie
Herman Peeren
In a platform application would have to following tree:
/source
../mvc
…./model
….../cars.php
….../boats.php
…./controller
……./cars.phpas opposed to:
/source
../model
…./cars.php
…./boats.php
../controller
…./cars.php
Thanks for all the hard work! Appreciate your postings too.
Herman Peeren
think it is unwise to name space part of our platform without a)
having discussed it on list first, which leads to b) having an agreed
upon strategy to do it.
If used more in Joomla I might be less ashamed to admit I use Joomla when I am on a PHP conference... ;-)
Herman Peeren
On Wednesday, 11 April 2012 09:32:24 UTC+2, Andrew Eddie wrote:
can't think of any other major platform API that uses an MVC package
in that way.http://api.cakephp.org/classes
http://www.symfony-project.org/api/1_0/
http://framework.zend.com/apidoc/core/nav.html
Very interesting what Fabien Potencier (Mr. Symfony) wrote about that: http://fabien.potencier.org/article/49/what-is-symfony2
Fabien: "I really don't care whether Symfony2 is MVC or not. Probably because the MVC word is so overloaded and because nobody implements exactly the same MVC pattern anyway. The separation of concerns is all I care about."
And so we're back to what those new classes in this pull-request were about, I think.
Amy Stephen
I agree that a consistent strategy/approach is important before introducing namespacing. The current plan for implementing autoload first and then next addressing namespaces seems prudent.
However, the timing of this all should work out fine. Extensions wouldn't have to be changed immediately given the legacy folder and aliasing Rouven proposed. By the time the name change will be a requirement, namespacing should be in place. So, your proposal will likely sort of naturally fall into place.
There are a lot of changes coming in right now with the content strategy, these MVC simplifications, the possibility that JDocument could no longer be needed, and so on. All of that means changes to URLs, the possibility that the ItemID will go away, implications for how modules are placed, and so on.
Change is always concerning but I think we all agree that change is needed. If this is done correctly, the gains could be as big and positive as what 1.5 provided. It'll take close review to make certain something important isn't missed so that these changes don't take the architecture backwards. At the platform level right now, we need to be thinking big picture and not fixate on details.
Having said that, I get the point on the implementation of change. For those extension developers who are understandably concerned about the cost of change, please remember, the platform team is not making the calls on the CMS and there is a *definite need* for developer involvement there. From my perspective, it's time to get involved in 3.0 and make certain change is introduced in a sane way. It's a community so we can expect anyone else to take care of our interests - we need to be there and make certain it's done correctly. If there is enough involvement from the extension developers, automated migration tools, etc., can be shared to keep things smooth.
Andrew Eddie
> Symfony 1.... Symfony2 is hot now. But that is "beyond MVC" I would say.
Sorry, you are right. I should have referenced v2.
> And so we're back to what those new classes in this pull-request were about,
> I think.
Very much so. The separation is the most important aspect of it, and
also realizing that the current MVC implementation is so tightly wound
around the CMS that it's not much good for anything else (in other
words, it's too specialized). I think it's probably better that we
let models and views and controllers evolve in their own packages
because, as Fabien implies, "MVC" may not be a buzz word it is today,
but the individual design patterns may remain and you just use the one
that works for you.
Regards,
Andrew Eddie
Adam Stephen Docherty
I hope this is on topic, if not sorry...
Our Company is gearing up to develop a new Component sometime in the
coming weeks and we are a little concerned about the proposed changes
to the MVC and how it will effect us. The main concern bought up is
that if we create the component inline with the current MVC standard
as of J! 2.5 is it may be likely that we will have to completely
refactor the code within a few years. It is understood that upgrades
are a requirement, and small to medium upgrades are not a problem, it
is just that if there is going to be a major change to the MVC we
would like to code to this new standard straight away, even if it
means holding off a little before beginning work on the new Component.
So in regards to the above, is there any specific timeframe as to when
the new MVC standard will be available to use? Should we wait, or
should we just.do.it? The component will be quite a beast, probably
requiring many MVC triads and such and it seems a shame to start
something from scratch using an old standard when a new standard is
just around the corner.
Again my apologies if this is not the correct place to air this
concern.
Thanks!
Elin Waring
Elin
Hannes Papenberg
This is something that I actually didn't think about before. With the interfaces named like the current classes, it is impossible for advanced components to use these new classes until the CMS decides to drop them. So we wont have any possibility to have a smooth transition from 3.0 to maybe 4.0.
I have one issue right now: (without reading the whole thread again) I think no one beides the original authors said "these names are great, lets keep those" We either had opponents like me or people that silently accepted this. That is not a good basis for a decision in this regard. Could we have a voting on this, similar to "I like the names" or "I want the Interface-suffix appended"? If we have a majority for the scheme without Interface I promise to shut up about this and everything else that I criticized lately, including giving an apology for my initial mail regarding this topic.
@Andrew
I'm still hoping for some rules regarding community decision making.
Hannes
Andrew Eddie
> @Andrew
> I'm still hoping for some rules regarding community decision making.
I'm not sure I understand what you mean.
Regards,
Andrew Eddie
Amy Stephen
@AndrewI'm still hoping for some rules regarding community decision making.
Hannes
Amy Stephen
There are 5 months between now and CMS 3.0 shipping. Content is not done. It's a huge job to refactor all those components. I think she's right that the big architectural improvement is the separation of the CMS and framework code.
I would hope the CMS would settle on a platform release and then not change it through the 3.N series. That will allow time for debating the MVC rebuild a lot more deeply than just class name changes -- and do so in away that doesn't impact existing extensions.
The biggest problem I have with the name changes is -- I can't see a real benefit to doing it. The new Controller does nothing more than serialize the input. The new Model doesn't even have any database interaction. All of that is fine, but there is no gain there worth disrupting existing extensions. And, I can't get behind that.
If we leave the MVC alone for the 3.0 series -- maybe until 12.2 -- and the CMS settles on that release -- we can take our time building in minimal CRUD operations, thinking through RESTful approaches -- and then having time to think about how existing extensions could be migrated. By that time, the name issue will at least seem worthwhile or we'll find a way to make this change seamlessly.
It just feels like we are rushing this unnecessarily, and in the process creating a lot of stress. Let's take our time and do this thing right. Let 3.0 pass by - it honestly seems like developers and users would appreciate less change -- so -- letting things happen naturally seems like it's what everyone wants.
Many of us are starting to work with the platform to build applications. I, for one, am willing to help get the platform in good shape over going elsewhere. So, we can prototype these changes and protect the CMS in the process if we don't rush it in.
I really appreciate the platform team. For the first time in a long time, I feel like there is great leadership and vision coming from the development leadership. Let's do it right, build up involvement, not be in a hurry. I think you guys are doing good stuff -- you have coding standards and unit testing in place - vision - no hurry.
Let's hold on the MVC changes, that'd be my recommendation.
Andrew Eddie
> I think Elin's post is right on the money here. Couple of points warrant
> highlighting:
>
> There are 5 months between now and CMS 3.0 shipping. Content is not done.
> It's a huge job to refactor all those components. I think she's right that
> the big architectural improvement is the separation of the CMS and framework
> code.
In all seriousness it would be a lot easier to start a new type of CMS
application from scratch. I actually don't think that's out of the
question. It's way off topic but I maybe we should maybe start
thinking about letting the CMS and let it run its course, and build
UCM into a new, next-gen application (just make a WordPress killer as
an exercise, lol). It's an option.
> The biggest problem I have with the name changes is -- I can't see a real
> benefit to doing it. The new Controller does nothing more than serialize the
> input.
That's actually a huge feature. What you can do is put serialized
controllers into a command queue, or a task scheduler and then fire
them off at will. It's incredibly useful for any sort of batch job
processing and would allow you to build, for example, a very robust
email marketing application.
> The new Model doesn't even have any database interaction.
The base model deliberately doesn't. JModelDatabase adds the coupling
to the database. Existing classes like JModelList should plug into
that without any trouble. Once we push out the data mapper code, and
the revitalized (100% backward compatible <cough />) JObject, you'll
start to see where all this is heading.
> All of that
> is fine, but there is no gain there worth disrupting existing extensions.
> And, I can't get behind that.
Fair point, but the gains aren't necessarily targeted directly at
extension developers, not yet anyway (and I can't honestly see
extension developers wanting to shift off the current CMS
architecture, ever). I mean, we are between a huge rock and a very
hard place. On the one hand you've got extension developers that
don't like change, but on the other hand we desperately need new
architectures to make platforms for web services et al, and that's the
sort of stuff that attracts new talent to the developer community.
The risk in swaying too far in the "don't change" direction is that
all the people that are excited about doing new things on the platform
aren't going to be very excited for much longer because they
continually get blocked. And yes, conversely, too far in the other
direction is bad too. Balance and compromise is required but it has
to be two-way.
> If we leave the MVC alone for the 3.0 series -- maybe until 12.2 -- and the
> CMS settles on that release -- we can take our time building in minimal CRUD
> operations, thinking through RESTful approaches -- and then having time to
> think about how existing extensions could be migrated. By that time, the
> name issue will at least seem worthwhile or we'll find a way to make this
> change seamlessly.
So, the funny thing is, those CRUD operations and the RESTful
approaches, at least that I've been working on, hinge around a better
MVC. Chicken vs egg ...
> It just feels like we are rushing this unnecessarily, and in the process
> creating a lot of stress. Let's take our time and do this thing right. Let
> 3.0 pass by - it honestly seems like developers and users would appreciate
> less change -- so -- letting things happen naturally seems like it's what
> everyone wants.
I understand what you are saying, and I don't disagree it's a valid
argument, but the lessons from Joomla history are that it doesn't
matter how much notice you give, it still hits the fan on the day the
switch is flicked.
> Many of us are starting to work with the platform to build applications. I,
> for one, am willing to help get the platform in good shape over going
> elsewhere. So, we can prototype these changes and protect the CMS in the
> process if we don't rush it in.
So I'm going to be doing some webinars for GSOC about platform
applications. I suspect after a few people have seen those, you may
change your mind (about rushing in) :)
> I really appreciate the platform team. For the first time in a long time, I
> feel like there is great leadership and vision coming from the development
> leadership. Let's do it right, build up involvement, not be in a hurry. I
> think you guys are doing good stuff -- you have coding standards and unit
> testing in place - vision - no hurry.
>
> Let's hold on the MVC changes, that'd be my recommendation.
Appreciate the comments!
Regards,
Andrew Eddie
Ian
Hannes Papenberg
driven and decided by the community, which is why we are supposed to
built support on the mailinglists, so that the community can decide on a
feature. Or did I misunderstand something here? If the community has no
say in the development/pull requests, I don't understand why we should
be "building support" here. In the end it would come down to only
convincing the maintainers and that should normally only be done in the
pull request in order to keep all the strings of a discussion in one
place. In that regard, this mailinglist would only be a medium to inform
people and not discuss/decide anything. Then again we could simply do
that with a newsletter.
If I understood that correctly however, we would have to have some rules
when a proposal is approved or rejected. How many votes do you need at
least for a proposal to be considered? How many have to be upvotes? At
which point are the maintainers supposed to step in and make the
decision? (In cases were the outcome is not clear (enough).) How long is
the voting phase? What constitutes a vote? (Mail on this list, a comment
on the pull request, a new little webapp that tracks the pulls and
allows to vote on something) How do we prevent people from registering
numerous times and skewing the vote? Should they be part of this
mailinglist for at least X weeks and have made at least Y postings
before they are able to vote? When do we need a formal voting on a proposal?
My comment in that last mail was aimed at solving these questions. I
would of course also be happy if the other part of that mail was taken
up and the implicit question answered, how a modern component could
benefit now from these classes.
Hannes
Sam Moffatt
limits the CMS' ability to make firm decisions. The longer we delay
the harder it makes life to effectively build a solid transition.
Presume it gets delayed until after CMS 3.0's release - that means
that CMS 3.0 can't actually plan a transition because realistically at
that point it hasn't been merged (unless it plans on planning against
something that hasn't actually been confirmed as actually merged and
finalised which seems to me a tad risky). Then do you put it in 3.1?
3.5? 4.0? To be honest it makes more sense to me to accept the change
now and spend the next couple of years working on mechanisms to
transition the CMS through the 3.x series towards the implementation
of the change with CMS 4.0's release.
Or does the CMS start trying to build in backwards compatibility? Or
do we not bother and end up with a JMvcController with the inevitable
question why we called it that in another couple of years when the
presently JController is gone. I can just imagine the thread like one
of the many of the other why things are the way they are threads. "Why
didn't you just call it JController?" "Well there already was a
JController and we didn't want to break backwards compatibility but
that's gone now." That won't get old on the mailing list at all! Then
inevitably someone will suggest we rename it back to JController and
then we have this entire discussion again where it'll break everything
again because everyone's now renamed to JMvcController and doesn't
want to shift (again).
In doing it now we make it clear with over a years notice that there
is a backwards incompatible change coming in 4.0 and with the
introduction with the 3.0 series to provide a transition path to
enable 3.x extensions to be forwards compatible to 4.x transition.
However we really need to step back a second and look at this
discussion. It is really amazing to think how far we've come: we're
actually in a position where we're discussing being able to build
forwards compatibility in for breaking change instead of trying to
build limited backwards compatibility (1.5's legacy plugin) or in some
cases absolutely no backwards compatibility (1.6's ACL changes) with a
potential of two years heads up.
Regardless of what ends up happening, I think that's a great sign in
our community that we're having this discussion ahead of a change that
in two years time will pose a backwards compatibility issue.
Cheers,
Sam Moffatt
http://pasamio.id.au
Andrew Eddie
> If I'm not mistaken, it was said numerous times that the development is
> driven and decided by the community, which is why we are supposed to
> built support on the mailinglists, so that the community can decide on a
> feature. Or did I misunderstand something here?
Are you not free to participate in the discussion?
> If the community has no
> say in the development/pull requests, I don't understand why we should
> be "building support" here.
If they have no say, the pull request would already be merged ;) To
be perfectly honest I'd much rather be arguing this case from "it's
already in there and it's not hurting anyone" :P but we didn't do that
because that would be the wrong thing to do.
> In the end it would come down to only
> convincing the maintainers and that should normally only be done in the
> pull request in order to keep all the strings of a discussion in one
> place. In that regard, this mailinglist would only be a medium to inform
> people and not discuss/decide anything. Then again we could simply do
> that with a newsletter.
I don't care where people want to discuss it - why makes up rules for
the sake of making them up? Whatever the case, this mailing list is a
place to discuss things - anything platform related. If you don't
want to use it that way, there are a number of group membership
options Google provides which can help you.
> If I understood that correctly however, we would have to have some rules
> when a proposal is approved or rejected. How many votes do you need at
> least for a proposal to be considered? How many have to be upvotes? At
> which point are the maintainers supposed to step in and make the
> decision? (In cases were the outcome is not clear (enough).) How long is
> the voting phase? What constitutes a vote? (Mail on this list, a comment
> on the pull request, a new little webapp that tracks the pulls and
> allows to vote on something) How do we prevent people from registering
> numerous times and skewing the vote? Should they be part of this
> mailinglist for at least X weeks and have made at least Y postings
> before they are able to vote? When do we need a formal voting on a proposal?
Not my call - convince the PLT (*in another thread*). Can we get back
to discussing PHP now?
> My comment in that last mail was aimed at solving these questions. I
> would of course also be happy if the other part of that mail was taken
> up and the implicit question answered, how a modern component could
> benefit now from these classes.
I wouldn't build a component using these new classes, I would build an
application ;)
Regards,
Andrew Eddie
Hannes Papenberg
maybe I should clarify a bit here. Yes, I sometimes violently defend my
position and not everyone agrees with my choice of words or different
things I do, but in the end, I'm a democratic person. If there is a
controversial topic and there is a democratic voting on the issue at
hand, I'm the first one to bow to the resulting decision and I will
defend it. Right now however, my stomach says something along the lines
of "They proposed something, the community thinks its controversial and
did not really aprove, but they are going to put it in anyway." And if
someone later comes in through one of the many support channels and
complains about this change, I will tell them "Its the maintainers fault."
If you have the community decision however, I will rightfully tell them,
that there was a fair voting involved and that when they think they have
to complain, they would also have to participate in this stuff.
So, yes, I'm free to participate in this discussion, but a discussion
that will not change anything no matter what, is just wasted time. I
mean, we are not really that far apart here. I agree with the proposed
changes, they look good and they are a good step in the right direction.
I maybe wouldn't abstract this too much, but that is something that I
don't really care for. The only thing that I really dislike is the
interface naming. I think it will wreak havoc with extension developers
and CMS users and is something that we should avoid at all costs.
When however there is a majority for this naming, I will instantly shut
up. Maybe I have the wrong perception about this and everybody else
thinks different than me. But without a vote, we wont know.
Hannes
Andrew Eddie
stomachs churn. Probably best not to wake those sleeping dogs ;)
Regards,
Andrew Eddie
Amy Stephen
On 12 April 2012 13:26, Amy Stephen <amyst...@gmail.com> wrote:In all seriousness it would be a lot easier to start a new type of CMS
> I think Elin's post is right on the money here. Couple of points warrant
> highlighting:
>
> There are 5 months between now and CMS 3.0 shipping. Content is not done.
> It's a huge job to refactor all those components. I think she's right that
> the big architectural improvement is the separation of the CMS and framework
> code.
application from scratch. I actually don't think that's out of the
question. It's way off topic but I maybe we should maybe start
thinking about letting the CMS and let it run its course, and build
UCM into a new, next-gen application (just make a WordPress killer as
an exercise, lol). It's an option.
I also don't see the CMS ever going away - it's the Joomla flagship product. Having said that, it is clearly time for the extension developer community to involve in it's development and support. We need some leaders to emerge there and I am confident that will happen.
Amy Stephen
But without a vote, we wont know.
Hannes
Amy Stephen
On Thu, Apr 12, 2012 at 3:23 AM, Sam Moffatt <pas...@gmail.com> wrote:
Part of me wonders if by delaying the move to include this actually
limits the CMS' ability to make firm decisions. The longer we delay
the harder it makes life to effectively build a solid transition.
In all honesty, Sam, if you committed the MVC changes, I don't see a clear path for the CMS right now.
If I were to use the code as it sits to write a new component, I would first have to create a controller for each of the tasks, weave in the ACL, and there are about 20 tasks for a component.
Then, I would have to create a model. Or models(s)? One for each task? one for each table? How will this fit with JTable? How can it be written in such a way that the logic is properly abstracted for reuse by other components.
None of that has been spelled out architecturally and it will require some playing around with it to find the best way to do it.
If a community developer went to all that trouble to build those missing pieces, he or she would have to hope that the project would adopt the work or risk having it all replaced by the code not yet written in the platform.
I don't see that clear path what I see is a concept. Good things start from concepts but they take time to build. That building should take place in the platform -- get nice and solid with lots of community engagement and review -- and then flow into downstream apps like the CMS. Then, there is good direction and understanding.
The CMS has an easy path forward that allows them to maintain the status quo for the 3.0 series. There is no need to hold up the platform for the sake of that.Ian
I think we need a branch for the MVC where we can work together on getting the basic CRUD operations and basic controllers and models built.
From there, a concept component could be developed that would provide that roadmap that Sam is speaking about.
It's going to take while before the CMS and the Platform are truly separated and able to move independently. Until that point, it'll be important to be strategic about change. If that feels like being held back, then I think we just aren't using branches and schedules like we should. We all share this framework so it's only fitting that a little give and take happen.
I love where it's heading, we are in no hurry, good things take time, and the timing of how it's all introduced to the core is important.
CirTap
After the earlier "clash of cultures" here and elsewhere that upset some
people, it's nice to see this "debate" getting back on track to become a
technical and practical *discussion*.
I intend to be optimistic here, so don't worry ;) and just in case ('cos
you never know): what may sound to some as a critique or even a rant is
also not intended to be one.
So allow me to *deliberately over-simplify* what the current
architecture of the "Joomla! 2.5 CMS Application" is today and what it
might turn into using the "Joomla! Platform" *beyond* 12.x.
I'm just thinking out loud and extrapolating my "conclusion" from
various hints and side notes made on this list and @ Github, and
primarily from what Andrew just wrote:
"I wouldn't build *a component* using these new classes,
I would build an *application* ;)"
-- emphasis added.
To me *this* is probably the most important "non statement" made in this
discussion and I'd like to learn whether I'm thinking in the wrong
direction or if the ';)' was a secret handshake that very, very subtle
:) summarizes where the former creators and maintainers of the Joomla
CMS are (also?) heading to with the Platform if they look at the future
of the CMS.
I'd like to stick to the CMS realm for yet another moment, and its
apparent needs (if I may call 'em so) to "paint my picture".
CMS is undoubtly what the majority of users and "code writers" know and
think of it they hear "Joomla!".
That 2 application world where "/libraries/joomla" is just one folder
among many others, that's at best know as part of "The Core" you're told
in the forums not to hack :)
A sort of summary:
Today in our well known CMS we essentially have a boostrap (index.php)
to launch one Application only, JSite or JAdministrator [excl. the
installer].
That application features several components, but runs *one* component
only at a time to have that component eventually render a web page.
Let's put modules and plugins aside to keep this simple.
For the most part components are "fenced gardens" and the data, content,
and information they manage and provide _on their very own_ is virtually
sandboxed. Tough to get over that fence w/o tricky and creative
workarounds, hacking, or even duplicating loads of code.
The historical or technical reasons for this are irrelevant and there
are of course exceptions to the above.
A CMS application essentially create web pages only and while it can
"manage" HTML, this is not entirely true for other contents or media
files sitting there as well, but _un-managed_, easy to be (re-)used, and
"shared" within that very system (in lack of a true "digital assets
manager".)
The Platform's primary intend however is to build Applications, *not*
Components as we know them from the CMS.
It doesn't care what type of app one writes and what content that app
will eventually manage, where that content comes from, or if there's any
content managing involved at all (CLI, deamons).
How that application is bootstraped and configured is more or less left
to the developer.
Wearing a "CMS Hat" and thinking CMS _only_ this looks like applications
may become a new kind of "elevated" components.
Are they... kind of?
A future "CMS stack" built of off many applications would still have one
bootrap in the DocumentRoot, but instead of finding and launching *one
app* only that's trying to find *the one component*, it's main job would
be to initialize some sort of "global" configuration, then fire up the
loader, make way for the platform, and find *any application* to deal
with the incoming request.
Again, this is extremely simplified on purpose, thus the following is
not about file or folder names, let alone class names, but structure
only, or some potential "big picture".
The current scenario in J! 2.5 (and presumably 3.x):
/index.php (CMS frontend/backend bootstrap)
/include/application.php (*the* frontend/backend CMS application)
/components/com_foo/foo.php (*the* thing that makes the web-page)
...
A possible "CMS Stack" however could look like:
/index.php ("system" bootstrap + basic config)
/shop/index.php (MyShop extends JApplicationWeb)
/shop/views/catalog.php
/bar/index.php (YourBar extends JApplicationCli)
/bar/output/log.php
/bat/index.php (XBat extends JApplicationService)
/bat/libraries/**
/cms/index.php (JSite extends JApplicationWeb)
/cms/libraries/**
/cms/components/**
/cms/modules/**
/libraries/joomla/**
...
This is more or less a rough outline of what I conclude from the many,
many mentions of "applications" throughout virtually any thread.
I know it's the CMS team to make the call, but since virtually any
Platform maintainer literaly insisted to make it clear "to take care of
needs of the CMS" (providing the legacy tree) I'm asking _you_ guys:
Is this possibly it?
One possible variation of an "unspoken" vision ... or idea?
A vision that very few of us platform "outsiders" can depict, because
"our" well trained, CMS-centric mindset and thinking is [still] too
focused on the equally well known status quo?
A status quo, where any statement made about the advatages and
flexibility of writing _applications_, just doesn't seem to "make sense"
when you look at it from within that "fenced garden" called Component.
Well, I utterly dislike fences, and it appears that this nice new [X]MVC
architecture will allow the bits and pieces running on a web server
(sometimes aka CMS) to happily and smoothly share their data; finally --
or deliberatly do NOT.
I think I like it B)
Have fun,
CirTap
Since my posts on this list are moderated, the above is based on a
"snapshot" of this thread ~ 15:30h GMT :)
Am 12.04.2012 10:26, schrieb Andrew Eddie:>
Sam Moffatt
introduced here aren't placed into the CMS until 4.0 giving the CMS
and it's community plenty of time to transition and figure out what
best practice looks like.
The timeline as I see it could look like this:
- The pull request in question is merged.
- CMS 3.x series introduces forwards compatible changes with a new
name for the existing series of classes (JControllerLegacy or
JControllerCMS, etc)
- CMS 2.5 could follow in a similar vein from it's next release post
the merge of this pull request.
- CMS 3.x series can also add deprecated notices for using JController
et al for the duration of the series as an extra notice to developers
(e.g. "This usage of JController is presently deprecated, please use
JControllerLegacy/JControllerCMS/JControllerPies. For more information
please see wiki.")
- CMS 3.x series could internally feature a rename to the legacy class
names for the shipped components.
- CMS 3.x extensions could also choose to use the new classes as well
so long as two extensions don't try to load the different copies of
those classes on the same page load. Given they're most used with
components and we only let one component load per page this should be
relatively safe anyway (though potentially a module could use those
classes too which could cause conflicts).
- CMS 4.0 in two years time removes the old class names and we've had
plenty of time to work out how everything works out. The new style can
safely be used by default at this point.
That provides extension developers with a solid pathway for migration.
Once CMS 3.5 is released they can transition to using the renamed
legacy classes which will be at that point supported by the CMS 2.5
release forwards compatibility is introduced and the entire 3.x
series. In 4.0 we can safely make the transition then towards the new
functionality with the entire developer community hopefully by that
having transitioned to the legacy class names. It makes it clear which
version of the classes should be the preferred version ("Should I use
JController or JMvcController? What's the difference?"), or I at least
hope the "legacy" suffix makes it clearer (I prefer legacy over CMS).
This would mean with CMS 4.0 you get the option to pick which set you
wish to use though obviously picking the new style will not work
properly on the older versions - however that's a decision we're left
with all of the time.
I feel that provides a reasonable timeframe (a couple of years) for
developers to transition in such a way that code doesn't break
overnight, would remain compatible in 2.5.n, 3.x series and 4.x series
up until those classes are removed from the CMS. And even if the CMS
removes it as well then you could ship a third party library
separately with that code in it.
To me this seems a reasonably straight forwards migration with plenty
of time to figure how everything will impact from a solid foundation
instead of a series of what if's.
Cheers,
Sam Moffatt
http://pasamio.id.au
P.S. I use JController here but it applies equally to the other new classes.
bill richardson
cms does not have to change names just because new classes are created in the platform. For example the original ?/ still
proposed name for the table in Jcontent was xxx_content which clashed with the table name used by com content.
I appreciate that some people in the platform have expressed opinion that the cms is not their concern - but i do not see
why the platform is making it difficult for the cms to adopt / use the new classes alongside what exists as it will take time to
modify / replace existing components,etc to use the new mvc / ucm classes.
Regards
Biill Richardson
Elin Waring
Andrew Eddie
> Since my posts on this list are moderated, the above is based on a
> "snapshot" of this thread ~ 15:30h GMT :)
I think Google is playing around with groups. There are some people
that are suddenly going into the moderation queue. Apologies if you
are one of them - we aren't doing it deliberately :)
And yes, you are on the right track :)
Regards,
Andrew Eddie
Amy Stephen
I definitely agree there is plenty of time with 2 years for migration. For me, that's not a question.
Here's what I am not getting and maybe you can clear that up for me.
What change do you want the CMS and extension developers to make with their components in 3.0 related to the MVC change? Simply to change the name from JController to JControllerCMS? And if so, what is the benefit to doing that now over waiting for 4.0 when the rewrite is solid and examples are ready?
Beyond making that change, there is nothing else to do at this point that can be done since the Controller and Model are nothing more than a shell.
I assume things are still on track for "radical change" to N.0 followed by stabilization and bug fixes as releases near N.5. So, it's not like the MVC will be implemented in core in +3.0, right?
Thanks.
Amy
Amy Stephen
(I know it is annoying to the maintainers that I say this again and again) is that the most common version of the platform for the foreseeable future, the one that sits on several million servers, is the version the ships with the CMS and for that reason, for the sake of both projects, we should strive to have that be the best, most up to date version of the platform that we can ship and still have the CMS function.
Elin -
I would like to see the CMS pick a release - in this case 12.1 or 12.2, then stick with it throughout the N.x cycle.
If the CMS doesn't do that, then there Ian is right, it *is* holding the platform back and there is no reason *not* to introduce the MVC change.
But if the CMS will take 12.1, that gives the platform 1 1/2 years to get the next generation ready for the CMS while the CMS rolls out the new stuff in a stable fashion.
I think this is really important -- if the CMS keeps taking the latest release of the platform, how do they move forward without impacting the CMS?
Does that make sense?
Andrew Eddie
> In all honesty, Sam, if you committed the MVC changes, I don't see a clear
> path for the CMS right now.
Sorry to butt in, but I'm more or less coming to the same conclusion.
I think the CMS is too entrenched in the current paradigm to shift
(or, rather, the perceived desire of current extension developers
allegedly is not sufficient to shift - nobody really knows for sure).
On the other hand though, developers "copying" from 2.5 components
will likely not have to do much at all, because things like
JModelList, JControllerForm won't be affected.
> If I were to use the code as it sits to write a new component, I would first
> have to create a controller for each of the tasks, weave in the ACL, and
> there are about 20 tasks for a component.
No, you don't have to do that. The first thing I'd do in the CMS is
create JControllerComponent and make it a task mapper just like the
11.4 JController is.
> Then, I would have to create a model. Or models(s)? One for each task?
Model architecture doesn't suddenly change. You'd still aim for one
model per object type (I'd merge the "list" and "item" handling back
into one model).
> one
> for each table? How will this fit with JTable?
JTable isn't even part of this discussion. You'd use it however it
suits you to use it. I think you are assuming that some sort of
implied naming convention rule system is being applied over the top.
It's not. In fact, all those JController::getModel type methods go
away because the auto-loader takes care of it for you.
> How can it be written in such
> a way that the logic is properly abstracted for reuse by other components.
I would very much consider adding JModelComponent, JViewComponent and
JControllerComponent to 3.0 or even 2.5 (that's probably a better name
than J*Legacy). But that's if and only if you the CMS wants to change
the architecture. The CMS might decide not to.
> None of that has been spelled out architecturally and it will require some
> playing around with it to find the best way to do it.
But that's the point. The 11.4 MVC channels you into a particular way
of doing things. This MVC decouples all of those dependencies and
paradigms. Understandably, that leads to some confusion because
people have to go back to first principles and work out how they are
going to design something :)
I'll cover some of your other points in a reply to Bill.
Regards,
Andrew Eddie
Andrew Eddie
> What is reasonable is what is being debated - For the CMS that the new mvc
> classes are named with new names like eg ( emodel or nmodel or imodel ) and
> the
> cms does not have to change names just because new classes are created in
> the platform. For example the original ?/ still
> proposed name for the table in Jcontent was xxx_content which clashed with
> the table name used by com content.
> I appreciate that some people in the platform have expressed opinion that
> the cms is not their concern
Bill, with all due respect, this whole discussion is taking place
because of concern for the CMS. I think you are confusing people that
have no desire to "work" on the CMS with a principle that people don't
care what happens to it. As for me, I have no desire to ever write
another component, but I do have a desire to make sure we see code put
into the platform that allows Joomla developers to do new and amazing
things, whether that's in the CMS or not.
> - but i do not see
> why the platform is making it difficult for the cms to adopt / use the new
> classes alongside what exists as it will take time to
> modify / replace existing components,etc to use the new mvc / ucm classes.
The reason is that the 11.4 MVC is great for making components to a
given, fairly rigid formula. This MVC is about providing new
foundational model, view and controller architectures that will
ultimately lead to you completely rethinking how you design
applications and "whatever extensions will become". The major point
is, it's not for people on the platform to decide what the CMS should
do. However, we have provided a path for migration should you choose
to walk it out of a very deep concern for not making their life
difficult. I, myself, and becoming less convinced that the CMS will
want to, possibly even need to, embrace this style of MVC. However,
for developers considering other solutions outside of the CMS, it's an
absolutely must that this refactor happens and it makes absolutely
sense that they should also own the names.
The very bottom line is nobody is forcing the CMS to change.
That's my take anyway.
Regards,
Andrew Eddie
Amy Stephen
On the other hand though, developers "copying" from 2.5 components
will likely not have to do much at all, because things like
JModelList, JControllerForm won't be affected.
Eureka. Dude. I get it now. How do you put up with us?????
So, if we look at com_content - and assume devs followed the pattern laid out for them and used the 1.6 MVC, as intended:
THERE IS NO CHANGE.
1. Administrator - Single Controller - No change
https://github.com/joomla/joomla-cms/blob/master/administrator/components/com_content/controllers/article.phpclass ContentControllerArticle extends JControllerForm
2. Administrator - Multiple Controller - No change
https://github.com/joomla/joomla-cms/blob/master/administrator/components/com_content/controllers/articles.phpclass ContentControllerArticles extends JControllerAdmin
3. Administrator - Single Model - No change
https://github.com/joomla/joomla-cms/blob/master/administrator/components/com_content/models/articles.phpclass ContentModelArticles extends JModelList
4. Administrator - Multiple Model - No change
https://github.com/joomla/joomla-cms/blob/master/administrator/components/com_content/models/articles.phpclass ContentModelArticles extends JModelList
5. Frontend - Single Controller - No change
https://github.com/joomla/joomla-cms/blob/master/components/com_content/controllers/article.phpclass ContentControllerArticle extends JControllerForm
6. Frontend - Single Model - No change
https://github.com/joomla/joomla-cms/blob/master/components/com_content/models/article.phpclass ContentModelArticle extends JModelItem
7. Frontend - Multiple Model - No change
https://github.com/joomla/joomla-cms/blob/master/components/com_content/models/articles.phpclass ContentModelArticles extends JModelList
The proposed changes are at the framework level and if developers followed the API, then they will not have to change their extensions at all.
If so, goodness gracious. There is absolutely no reason not to implement the change. It'll be a two minute fix in the CMS and it should not impact any core extensions or third party extensions.
Is that correct?
I am sorry I did not research this and simply listened to the concerns about hundreds of extensions impacted.
Amy Stephen
class ContentViewArticle extends JView
https://github.com/joomla/joomla-cms/blob/master/components/com_content/views/article/view.html.php
Need to add a layer of abstraction for future wiggle room.
I think this is just another ridiculous conversation. To be honest, I don't see a big rush in putting it in.
But, if this change is going to create heartache for a developer, then that person needs to switch careers.
This is minor stuff - devs will be much more impacted by the recent PR's with my name on 'em for Exception processing.
30 years in the business, one thing holds true, it's going to change. If you don't like that, get out.
Sorry for being a part of wasting everyone's time.
Andrew Eddie
> I guess Views will be impacted.
>
> class ContentViewArticle extends JView
>
> https://github.com/joomla/joomla-cms/blob/master/components/com_content/views/article/view.html.php
>
> Need to add a layer of abstraction for future wiggle room.
Yes, and I'm not sure we've completely solved how to emulate the
$this->loadTemplate call for sub layouts (but we've solved "common"
layouts really nicely). I'm actually playing with Mustache a bit as a
tempting engine (JViewMustache wink, wink) and I'm hitting that brick
wall, but that's another story for another day :) I really think we
should have a monthly G+ hangout show and tell where we can pick our
idea to bits … sorry, that's now getting way off topic :blush:
Regards,
Andrew Eddie
Sam Moffatt
have explicitly jimport'd the file (which every extension developer
has done to date), it will automatically take precedence anyway. That
is to say when the PHP class autoloader kicks off it will first look
at what has been specifically registered (JLoader::register,
JLoader::import/jimport) and then it will attempt to autoload using
the convention. So the old JController will load regardless while
something occupies application/component/controller.php (legacy,
joomla or cms depending on how things are configured).
The only real complication for the CMS is trying to use both at the
same time. For example a component using the new style (for example)
and a module or plugin using the older style. This is where a name
change removes the possible conflict and lets everything work
together. Developers may choose not to bother with the name change in
the 3.x series and instead do the work with 4.x however if we put the
name we eventually wish to rename the existing classes into CMS 2.5
and 3.x then when 4.x does come along that change is also backwards
compatible. Hence my comment that the sooner we get it in the sooner
we can build forwards compatibility.
As you point out the introduction of exceptions everywhere is going to
be a significant change, I feel a few search and replaceable strings
is not going to be too much to ask with a couple of years warning and
guaranteed backwards compatibility back to CMS 2.5 and 3.x presuming
we do that sort of forwards compatibility work now.
Cheers,
Sam Moffatt
http://pasamio.id.au
Elin Waring
On Thursday, April 12, 2012 5:49:09 PM UTC-4, Andrew Eddie wrote:
On 13 April 2012 00:49, CirTap <c...@webmechanic.biz> wrote:es
Amy Stephen
Sam - enjoy sharing with folks that "Amy did the exceptions." I more than likely have it coming. Karma. ;-)
Elin - Certainly bug fixes and security patches should be applied to the version selected, but the CMS has got to hold on a version in order to help give the platform team room to work. If the CMS tries to keep pace then every little change the platform makes is going to be scrutinized - and rightly so! - for potential impact on the developer and user community.
We moved from three years between releases where developers could work - and where servers sat with the same release - to half that time for CMS releases. But if the CMS picks up the newest release all the time, then the platform team gets about 6 months to introduce new code and stabilize. So, when and where do they work?
In that recent thread "Is three years long enough" on the general list - people were very clear, it's getting to the point where site builders are struggling with justifying using Joomla with their clients. We want it all but most people just want it to work and more mature code tends to be much better for that.
I hope the CMS team really thinks about this and engages the extension development community in helping think about this, too. (And, give those devs work to do ;-) and help them make some decisions and build ownership.)
OK, so, we're all off topic but as it turns out the original topic was really stupid so maybe it doesn't count. ;-)
Sorry, Louis, no flowers, but here is my favorite Pretty Lights just for you. http://www.youtube.com/watch?v=Hruh3sm0tdE Keep floating above it, Louis, you were made for great things. =)
Andrew - thanks for your kindness to everyone.
Will Daniels
Please excuse my butting in. I don't know all that much about Joomla! but like
anyone who has had to manage large software projects where there is a separate
platform team I have come up against this issue a few times. So this is just my
2p from my own similar experiences.
On 13/04/12 03:19, Amy Stephen wrote:
> Elin - Certainly bug fixes and security patches should be applied to the
> version selected, but the CMS has got to hold on a version in order to help
> give the platform team room to work. If the CMS tries to keep pace then
> every little change the platform makes is going to be scrutinized - and
> rightly so! - for potential impact on the developer and user community.
I think you might be overstating the general problem based on the current
context. This only tends to be an issue for major refactoring work, which in
some ways is what the platform is all about, but continual refactoring is likely
to become as much of a problem for the Platform itself as it would be for the CMS.
I would say the key is to hammer out expectations in advance, which seems to be
what is happening here anyway. I understand what you are saying about the
Platform needing room to work, but it needs to find a way to do this while still
feeding the CMS with new features and new versions.
You are assuming the Platform team will have the most inertia for change, but I
would be surprised if that happens, except where it comes to architecture.
Demand for features will never cease within the CMS and better those features be
supplied by the Platform where they fall to that arena.
I have seen Platform teams get left behind fussing over architecture while
Application teams forge ahead implementing everything their clients need in
half-arsed ways that just "get the job done"...even to the point where the
Platform code becomes largely redundant in the Apps, which begin to create
Platform-esque Apps to do things they haven't been able to just merge from the
"real" Platform.
> We moved from three years between releases where developers could work -
> and where servers sat with the same release - to half that time for CMS
> releases. But if the CMS picks up the newest release all the time, then the
> platform team gets about 6 months to introduce new code and stabilize. So,
> when and where do they work?
Create multiple branches where you need room, and even release multiple,
imperfect implementations of the same feature to maintain some amount of
backward-compatibility. Whatever you have to do to keep everything flowing in
both directions, as often as possible, is a price worth paying IMHO.
I believe the single worst result is what will happen if the two sides stop
co-operating and stop syncing.
> In that recent thread "Is three years long enough" on the general list -
> people were very clear, it's getting to the point where site builders are
> struggling with justifying using Joomla with their clients. We want it all
> but most people just want it to work and more mature code tends to be much
> better for that.
Agreed. But that should be motivation for site builders to assist with
sponsoring continued development of extensions they use and QA efforts in the
CMS. Open Source projects rely upon vested interests for quality and interesting
problems for progress. But you need to have both happening at the same time to
keep things moving, it's no use trying to have a two-speed project.
There are some examples in the FLOSS world where multi-speed projects do work,
like the Linux Kernel. Some distros move faster than others, depending on their
purpose. RHEL for example moves slowly, applying mostly security patches and bug
fixes, while focussed on building enterprise apps. It is like the CMS as
site-builders would have it.
Others, like Ubuntu/Fedora, move much faster and integrate new kernels more
quickly. There is market demand for both, as there is in the CMS. The Kernel
moves at it's own pace, which is very fast and they don't care too much about
breaking drivers that don't want to implement revised interfaces. If it's not
maintained, it gets dumped.
But that works for Linux because it is a symbiotic relationship between distros
for different purposes. They all feed off each other through a common conduit -
the Kernel. What Elin keeps pointing out, and I agree with, is that the Joomla!
Platform does not yet have multiple applications of any significance, so there
is only a conflict between real problems and interesting problems, and the split
falls cleanly between Platform and CMS. The result is that the Platform and CMS
stakeholders conflict directly. Until there are other applications to balance
the ecosystem they need to work closely together.
Perhaps there is a need for two CMS applications at different speeds, as I think
was tentatively mentioned a couple of times already? I'm not sure the balance
can be struck more directly. The Platform needs to move fast. The CMS needs to
move both fast and slow at the same time. It seems logical.
-Will
Amy Stephen
First, so glad to have your involvement, given your database and Semantic Web background.
The platform team is definitely working on major refactoring and that's part of the challenge here. If it were simply a matter of minor changes, it might be different, but there are deep architectural changes and plans for more, coming. So, bearing that in mind, imagine dropping in a new foundation that has only been unit tested, into each release of the CMS.
The purpose of the new CMS release schedule is to concentrate major changes in the N.0 release. Developers should expect API changes in that release and they will have to invest time bringing their extensions to spec. But, if the CMS includes the platform in each release, and the platform is in major refactoring, that means the API could (and will) change with minor CMS releases.
If that's the case, how do 3rd party developers keep up?
We've been through the cycle one time and that is what happened. That's also why devs are wound pretty tight and reacted so strongly to what turned out to be a very minor change. They are struggling to keep up.
If the CMS takes a platform release and goes with it for the entire series (updating for major bug issues and security issues), that will help stabilize the API after the 3.x release. The platform team can continue aggressively refactoring packages and refooting the architecture and 3rd party devs can rest assured that they won't have to respond to these changes with each CMS release.
Otherwise, we basically have put the platform team on a six month release schedule -- and you'll see much more of this type of drama from 3rd party developers because it will be impossible to keep up.
Have not even mentioned the impact of change on users.
I've been thinking about ideas for CMS maintainer release teams who can help with change management. It might be a good way to engage site builders and 3rd party devs in leadership and working roles so that they can help manage and communicate the change.
I like the new schedule. I like the direction things are heading. I think we can continue in those directions, better engaging the community, to make certain the platform team has room to innovate while managing the change better when it hits the real world.
Hope that helps explain my perspective on this. Over time, as the platform stabilizes again, the software will be much more like utilities and bringing in new releases will not have the impact it does today.
Amy
Will Daniels
> The purpose of the new CMS release schedule is to concentrate major changes
> in the N.0 release. Developers should expect API changes in that release
> and they will have to invest time bringing their extensions to spec. But,
> if the CMS includes the platform in each release, and the platform is in
> major refactoring, that means the API could (and will) change with minor
> CMS releases.
Major refactoring can't occur in a different branch until after an upcoming sync
with the CMS?
I don't see that the CMS needs to take exactly the latest Platform branch each
time, just to take as much of it as possible to help feed the CMS with new
features and keep a mostly similar codebase for backporting fixes. It's much
easier with distributed SCM systems like git to manage dependencies between
features and merge branches than it used to be with SVN and the like.
I feel like it ought to be possible to release new Platform features, exchange
bug fixes, and generally keep most of the codebase in sync between CMS and
Platform without throwing in disruptive elements at minor release points. It
doesn't seem all that limiting for Platform development to me, nor too much for
the CMS maintainers to ask for that level of co-ordination.
But maybe I'm just not sufficiently involved to understand that issues in full
context?
> If that's the case, how do 3rd party developers keep up?
With some effort no doubt, at least initially. And by merging frequently from
upstream, XP & RERO style. That's the great thing about Open Source :P
Seriously though, how much re-factoring breakage can there be with each release?
If the Platform wants to pick up Application projects, then it can't have a new
API every week anyway.
> We've been through the cycle one time and that is what happened. That's
> also why devs are wound pretty tight and reacted so strongly to what turned
> out to be a very minor change. They are struggling to keep up.
The better abstracted the API becomes, the less extension breakage is
necessitated by refactoring. It seems like mostly a temporary problem. Just keep
going :D
> Otherwise, we basically have put the platform team on a six month release
> schedule -- and you'll see much more of this type of drama from 3rd party
> developers because it will be impossible to keep up.
I know this will be contentious, but my personal opinion, for whatever it may be
worth...release cycles are better fitted to interesting developments than the
other way around. It's important to have milestones and objectives, but dates
and numbers get in the way. Rolling release FTW !!! :)
It's an ongoing argument I have with the investors of software companies, it
seems business people and non-technical users greatly value fixed-period release
cycles and specific feature-to-release-number commitments. It gives them
confidence that they know where they are with everything, even if they don't.
It's inefficient and sometimes superficial. What invariably happens then is that
you waste resources stabilising code that you're about to change or throw out,
and you end up massaging release numbers just so that what happened matches the
original plan.
So I favour a more granular and fluid release style, not worrying about which
version of what is going to happen when. Take what you need and call it what you
want. And break things in a branch.
I'm not trying to sound pretentious and to imply that I have so much experience
and wisdom that I must be right about all this stuff - I seriously doubt there's
much better experience than handling change in the Joomla! project. All I can do
is offer up the lessons that I have learned myself, which may be all the wrong
lessons, or just different problems. But my experience boils down to this: keep
everybody running as much of the same code as much of the time as possible.
There is nothing I have ever done that is more difficult and frustrating than
trying to reconcile two data-driven platforms that have substantially diverged.
Joomla! is not nearly as data-driven (yet) as the platforms I am used to
building, but I see many of the same issues. If the CMS cannot build new
features against the "real" platform, I fear they will likely diverge and never
the twain shall meet. And that IMHO is a wasted opportunity on both sides of the
equation.
Anyway...this is all probably tangential to whatever this thread was originally
about. It sounds like you have a plan and you're happy with it. I'm really just
putting down my thoughts while we're kinda on the subject. I promise I won't say
any more about it :D
-Will
Amy Stephen
All I have ever heard the platform team say on this subject is that the CMS is free to do as they choose. From my perspective, the platform team is very intentionally trying to make it clear that they fully empower the CMS to operate as they feel is best.
Personally (read: selfishly) my interest is in and my willingness to contribute is focused on the platform project. Currently, I am most interested in helping the team in making changes needed so that the platform packages can be separated so that I can use only those packages I need for an application I am building called Molajo.
My interest in the CMS is more limited to a personal loyalty in a project I have contributed to for many years and to help the community figure out ways to make certain both efforts get what is needed to thrive.
At this point in the evolution of Joomla, it is my opinion that the platform needs room to rebuild much of the framework and the CMS needs to restore faith with users and developers that change can be better managed.
I've also managed major projects and big teams and have learned the importance of change management and engaging and empowering all constituents to successfully bring change.
At this point in time, it's fair to say that it is challenging for a third party developer to even know what changes are coming. Most of the time, the way developers learn about change is by installing their extension in a new release and debugging it. It's fair to say that third party developers are not as involved with the bug squad or testing or helping to provide patches or features as one would hope. It's fair to say that some of tried but have reported that they don't feel welcome and that their work is not accepted. There is (and historically has been) a very small group of people who help with the core project activities. It's fair to say that it's their perspective that help is appreciated and welcome but that people don't really want to try.
So, take those cultural divides and move to the new development cycle of a major release every 1 1/2 years with minors in between. Split the platform and the CMS. And, throw in major changes by including the platform revitalization every six months and people who didn't work well together before are now at their wits ends. https://github.com/joomla/joomla-platform/pull/1120
My point is -- either we keep dealing with the drama or we try to implement some change management that provides for all parties to understand how and when change will be introduced and when they can expect changes to stop (so they can do their job).
This is what I hope will eventually happen:
N. 0 Release The CMS introduces big changes in the N.0 release. The new framework release is added to the mix.
N.1 Release Features that almost made N.0 but weren't quite there are added, bug fixes at the CMS and platform level. But, the N.1 release is primarily reserved for extension developers to bring their work to speed.
N.5 Release - a migration is offered for users to seemlessly move from the last to the current release.
N.5+ releases - bug fixes and security patches. Stable.
If we follow a model like that, the CMS and all of its developers, have a stable platform to work on -- documentation and education can take place, extensions can be migrated, and then by the N.5, users can be brought on knowing that "we" (the community of core and extension developers) have done our job and are acting as a team, understanding one another and collaborating with a well defined set of rules.
It will take you some time to learn about the nuances of the Joomla community and you will develop and hold your own point of view about what is right or wrong. The better able you are to listen to others and adapt, the more successful and the less frustrated you will be -- and you'll stand out from the crowd since most of us are drama queens who overreact to small stuff. I guess it shows we care. ;-)
Hope some of that helps - but - that's just my point of view, for what it's worth.
If I offended anyone, it wasn't intentional and I am sorry.
Amy
On Fri, Apr 13, 2012 at 11:50 AM, Will Daniels <ma...@willdaniels.co.uk> wrote:
On 13/04/12 15:21, Amy Stephen wrote:
The purpose of the new CMS release schedule is to concentrate major changes
in the N.0 release. Developers should expect API changes in that release
and they will have to invest time bringing their extensions to spec. But,
if the CMS includes the platform in each release, and the platform is in
major refactoring, that means the API could (and will) change with minor
CMS releases.
Major refactoring can't occur in a different branch until after an upcoming sync with the CMS?
We might get there but we're not there now at the platform level.
Elin Waring
Hey Will -
First, so glad to have your involvement, given your database and Semantic Web background.
The platform team is definitely working on major refactoring and that's part of the challenge here. If it were simply a matter of minor changes, it might be different, but there are deep architectural changes and plans for more, coming. So, bearing that in mind, imagine dropping in a new foundation that has only been unit tested, into each release of the CMS.
The purpose of the new CMS release schedule is to conhease and they will have to invest time bringing their extensions to spec. But, if the CMS includes the platform in each release, and the platform is in major refactoring, that means the API could (and will) change with minor CMS releases.
Amy Stephen
Believe it or not .. there was sometimes breakage between releases in 1.5 and 1.0. It would be interesting for someone to go back and look at that to know if we are doing any worse.
So true, Elin, we need to celebrate our improvements! Those come from a focus on continuous improvement, knowing that we can always do better, welcoming new ideas and involvement, stepping aside when we need to regroup (or being thrown out when we don't see the signs ;-) ) and being careful not to take feedback as a personal attack.
It's a very big community. I often say when I describe for people what it was like working inside of the project as compared to being involved in the broader community, that it's like looking at the mountain from the top and describing it, or looking at the mountain from the bottom. Neither is wrong but how different it can sometimes look. It's hard to embrace all of it at once but important that we keep trying.
Will Daniels
On 13/04/12 18:37, Amy Stephen wrote:
> My interest in the CMS is more limited to a personal loyalty in a project I
> have contributed to for many years and to help the community figure out
> ways to make certain both efforts get what is needed to thrive.
OK, so let me explain my current interests also, since this may offer another
perspective WRT CMS/Platform divergence and disruptive changes.
The Semantic Web, Linked Data Cloud, Web 3.0, whatever you want to call it. It
has some serious problems. Developers don't understand it and users don't think
they need it. There are no simple tools for handling it and no good
demonstrations of it's value. And that is what I hope I might be able to change
using Joomla!
My interest in Joomla! is a different story, but suffice to say I am very fond
of it, ever since Mambo helped me to produce a personal website one night when I
wanted to publish some documentation and changes to a Linux wireless driver. So
I have watched casually from the sidelines for many years, even tried (and
failed, sadly due to lack of ACL) to use Joomla! for some work projects at points.
The issue for me I think is roughly the same as yours. I want to see the core
platform develop quickly. Very quickly. BUT I also need the CMS to come along
for the ride. While I would love to create a whole new Web 3.0 CMS using only
the Platform, I am just one man and I don't have time for that.
So when I saw this separation between Platform and CMS I thought "now is the
time". I can build CMS extensions to handle my SemWeb stuff to quickly get
something off the ground, and eventually extract that as a stand-alone
application, because most of the kinds of extensions that people currently use
in the CMS can be subsumed (eventually) via a core RDF framework (e.g. FOAF for
communities, SIOC for comments, RDFa and other microdata formats for SEO and so on).
It touches UCM, CCK and pretty much every other acronym being bandied around.
But it needs to be grounded at the core...in the Platform. I am beginning to
understand that the Platform I need to use is actually just going to be the CMS,
whichever fork or version of _this_ platform that may or may not end up on.
I confess I'm a little disappointed about that, because I thought the kind of
stuff I wanted to do might be in line with the objectives for the separated
platform here, because I don't actually need or want much of what makes the CMS
great, but I do need a strong, modern Platform. And yet a complete separation
from the start will take me too long to replicate things that are already in the
CMS, and loses the huge market of existing Joomla! CMS users that I was hoping
to leverage to get more Linked Data happening out there.
To be honest, I remain confused about it, and that's why I stuck my oar in,
though I should have known better. Now I think we are mostly wasting each
other's time and cluttering the list, although I do appreciate the social
engagement purely for the purpose of getting to know the people involved here.
I think this is as good a place as any to start finding friends with similar
interests, but I don't want to become disruptive. It is probably about time I
put my website back so that I can publish my musings there instead :D I never
meant to get this sidetracked, but I'm glad I did, I feel like the Joomla!
project is much more open and receptive than it ever used to be (even despite
the occasional drama) and I thank you all for the indulgence.
Cheers!
-Will
Amy Stephen
Rob Stocker
Great post!
I met with the developer of SIOC and have spoken to several open data/linked data specialists here in Ireland over the past few months. It is totally refreshing to read your arguments. I have posted several times about the need for developers to understand the implications of linked data - Web 3.0 and believe the UCM would put Joomla light years ahead of Drupal and bespoke systems when it comes to consumption of this data.
To this end I set up a portal at http://www.scoop.it/t/open-data-development-with-joomla which includes anything I can find on the UCM or the notion of github for data. Your comments would be greatly appreciated.
It touches UCM, CCK and pretty much every other acronym being bandied around.
btw: There are sioc plugins for Drupal Wordpress even phpbb but none for Joomla.
If anyone is interested in knowing more about Linked Open Data or is interested in getting involved, I'm open to dialogue, though I do not consider myself a specialist in any way.
--
Rob & Lisa - EMC23
083 416 0618
in...@emc23.com
www.emc23.com
Rob Schley
Will Daniels
On 14/04/12 14:10, Rob Stocker wrote:
> To this end I set up a portal at
> http://www.scoop.it/t/open-data-development-with-joomla which includes
> anything I can find on the UCM or the notion of github for data. Your
> comments would be greatly appreciated.
Excellent, I'll take a look at it when I get chance! Nice to know I'm not alone.
> *It touches UCM, CCK and pretty much every other acronym being bandied
> around.*
>
> So true
>
> btw: There are sioc plugins for Drupal Wordpress even phpbb but none for
> Joomla.
I did begin working on an RDF component for Joomla! using ARC2 a few years back,
and an RDFa content plugin that went with it. I think I had the only Joomla!
site in existence that was serving pure XHTML+RDFa (using mostly SIOC terms) but
there was never much interest except from one guy wanting to do RDFa in Joomla!
for SEO in the automotive components industry. But my area is more Knowledge
Management than SEO stuff so I "forgot" to follow up with that and it all kinda
fell by the wayside.
Like you say, Drupal is "where it's at" for RDF, always has been, but perhaps
not in the future if we mob up and pool our efforts.
I took down my Joomla! site a few months ago but am currently rebuilding it with
a Virtuoso back-end (hence my recent involvement pushing RDBMS portability
changes to Joomla! CMS), which should make for a much easier path to doing
Linked Data work within Joomla! CMS.
Whether this really fits with the Joomla! Platform though...I'm not sure,
logically yes, but not without more work than I can handle by myself.
> If anyone is interested in knowing more about Linked Open Data or is
> interested in getting involved, I'm open to dialogue, though I do not
> consider myself a specialist in any way.
There's only really a handful of academics who are when it comes to the Semantic
Web. I'm a good technologist, a fair mathematician and I have lots of patience
for picking my way through "heavy" academic documents, but I've still wanted to
boil my head a few times, especially when you start getting into OWL and the
guts of Description Logics.
The theory is much more complex than what people (even most developers) are used
to. But I don't think it needs to be for putting into practice and I have lots
of ideas about how to simplify it all. Sadly, there's just never enough time :D
Let's keep in touch, though this list may not be the most appropriate forum for
any detailed discussion on the topic ;)
Cheers!
-Will
Rob Stocker
I did begin working on an RDF component for Joomla! using ARC2 a few years back, and an RDFa content plugin that went with it. I think I had the only Joomla! site in existence that was serving pure XHTML+RDFa (using mostly SIOC terms) but there was never much interest except from one guy wanting to do RDFa in Joomla! for SEO in the automotive components industry. But my area is more Knowledge Management than SEO stuff so I "forgot" to follow up with that and it all kinda fell by the wayside.
Like you say, Drupal is "where it's at" for RDF, always has been, but perhaps not in the future if we mob up and pool our efforts.
I took down my Joomla! site a few months ago but am currently rebuilding it with a Virtuoso back-end (hence my recent involvement pushing RDBMS portability changes to Joomla! CMS), which should make for a much easier path to doing Linked Data work within Joomla! CMS.
Can I see your code? I am so far behind, I need baby steps. Any code at all would be great.
Whether this really fits with the Joomla! Platform though...I'm not sure, logically yes, but not without more work than I can handle by myself.
Yes it is, even if the platform people don't know it yet. This is just one google thread. I'm sure no one would mind us collating our knowledge here until it is deemed more relevant and warrants a working group or forum section or whatever.
If anyone is interested in knowing more about Linked Open Data or is
interested in getting involved, I'm open to dialogue, though I do not
consider myself a specialist in any way.
There's only really a handful of academics who are when it comes to the Semantic Web. I'm a good technologist, a fair mathematician and I have lots of patience for picking my way through "heavy" academic documents, but I've still wanted to boil my head a few times, especially when you start getting into OWL and the guts of Description Logics.
Best I can say is I'm a good listener. I have made a few friends and I put myself across as Joe Soap. If you can break things down to a level that I can understand , then most developers will understand So I offer myself as a complexity barometer.
The theory is much more complex than what people (even most developers) are used to. But I don't think it needs to be for putting into practice and I have lots of ideas about how to simplify it all. Sadly, there's just never enough time :D
Agreed. I'm thinking I should have been using the phrase Web 3.0 and not linked data or open data or RDF. Web 3.0 is obviously where things are going (it's catchy). All this complex tagging relationships is simply the underbelly.
Let's keep in touch, though this list may not be the most appropriate forum for any detailed discussion on the topic ;)
Agreed
shumisha
@Rob, @Wills: I have changed back this thread name to the original.
It's a pretty important one. Please as per Rob suggestion create your
own thread for unrelated discussions. Thanks
Rgds
Yannick
Will Daniels
> @Rob, @Wills: I have changed back this thread name to the original.
> It's a pretty important one. Please as per Rob suggestion create your
> own thread for unrelated discussions. Thanks
I assumed that is what would happen when I changed the subject before line.
Did it rename the whole thread or something?
Sorry, I don't spend much time on mailing lists...
-Will
Amy Stephen
Amy Stephen
Thanks to Rouven for backporting a change that will allow developers to change "JView" to "JViewLegacy" now. Nicholas agreed that doing so makes this very easy for devs to implement. Glad to see the positive solution and agreement. Well done everyone.