Re: [jcms] Lets talk about the futrure

[Mark Dexter]

Hi Nils. As far as I know, the big-picture changes for the CMS that we have discussed for the next 1-2 years include: (a) unified content (which will hopefully include some flavor of CCK); (b) multisite capability, including a staging site capability; (c) site backup built into the core; (d) perhaps content versioning (maybe included in (a) -- dunno); (e) continued multi-language improvements in core. There are probably others that I can't think of at present.

Many of these -- if not all -- will be related to improvements in the platform. Of course the issue is, as always, that people have to step up and actually write the code and do the work.

Personally, I don't get too worried about whether the platform improvements are targeted for the CMS or are done just to improve the platform. For example, PHP didn't make improvements (for example, better OOP support) to benefit Joomla. However, Joomla certainly has benefited from them. Similarly, it doesn't matter what the motivation is for the platform to add UCM or improved MVC support. As long as the CMS can leverage these improvements to add great new functionality, it all works.

The plan from the beginning was to turn the platform project lose and allow it to evolve at a fast pace, knowing that the CMS will have to be more cautious about how quickly these changes are adopted. As far as I can see, that is exactly what is occurring. If the CMS uses some type of legacy mode for version 3.x (which seems likely) and perhaps 4.0 (who knows??), that seems fine to me. If we can provide 3pd's the option of using either the legacy platform classes or the more state-of-the-art classes, that would be cool too. In any case, I think we are all interested in a smooth transition for Joomla core and 3pd extensions as we move forward -- as much as that is possible.

Maybe it will make sense to have Joomla 4.x or 5.x be radically different from the prior version and require a major migration. Then again, maybe it won't. It doesn't seem productive to debate something so far off when no one has any real idea what the situation will be then. At this point, we are reasonably sure that 3.0 will not require any major migration or re-working of 3pd extensions. But hopefully it will include some great new features, if people step up and write the code - hint, hint...

Mark

On Fri, Apr 13, 2012 at 3:21 AM, Nils Rückmann <in...@nils-rueckmann.de> wrote:

I'm tired of reading things like "that belongs to cms" and sentences like "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" shows that there is a lot more than little divergences.

When the news comes out that Joomla splits to Plattform and CMS i thought it would be a good way to improve the code base and give us the ability to bring the CMS to the next levels. But it seems like im wrong and the Plattform not only goes their own way, but also (sry for ordinary language) does not give any shit about the CMS.

So i'm asking now: What's about the future of Joomla CMS ?

I'm thinking we should find a course (with or without the Plattform) and hold on it, because i'm not the only one who stands beside and can not find an end to shake my head. In fact it's the first time i really have to think about the using of Joomla for customers projects.

To make it clear: I like many changes in the current Plattform. But without the ability to use it in our CMS it's not worth it. It's a really cool thing to use Joomla to build an application, but Joomla (in my opinion) signifies for the CMS. Which brings me to me last consider: If we are moving on like now and seperate the CMS and Plattform completly, we should think about the label Joomla!, because it can't be used for two competing projects.

What do you think ? What's the future ? Is there a future for Joomla CMS ? Let's make decissions and don't go around in a circle... Even if the decission is like "we don't know, we only want wo keep afloat", because this could be an honest answer and the whole community (not only developers) finally has a statement which can be used to make personal decissions.

NR

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/ajtzrm7lP1cJ.
To post to this group, send an email to joomla-...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-cm...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.

[Gary Mort]

On 4/13/2012 6:21 AM, Nils R�ckmann wrote:
> I'm tired of reading things like "that belongs to cms" and sentences
> like "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"
> shows that there is a lot more than little divergences.

I personally think the main issue is that there are a lot of changes
people want to make in the CMS which seemingly requires a change to the
platform - so there is a lot of push back and forth from people using
the platform not wanting to add bloat there, and people with the cms
needing a change to accommodate them.

In my opinion, the answer is to stop waiting on changes to the Platform
and accept the fact that sometimes the CMS must override the platform.
That way the CMS can experiment, and experiments that prove worthwhile
can be pushed back to the platform.

Keep in mind that this is /already/ done in some cases. Example:

includes\application.php
includes\menu.php
includes\pathway.php
includes\router.php

These files all /extend/ the platform for CMS specific functionality.

However, there are times when you need to completely replace a platform
class because there is no clean method to extend it and still have all
the existing calls to JClassname::getInstance() work.

This is easy to do using autoloaders.

libraries/cms/cmsloader.php
spl_autoload_register(array('JCmsLoader', '_autoload'));

That is the wrong way to do it. That makes the CMS loader come in
/last/ in the chain since the platform loader registered first.

spl_autoload_register(array('JCmsLoader', '_autoload'), true, true);

Now the cms Loader gets called before the platform loader. So if
someone wants to change, for example, the cache system.
copy joomla/cache/cache.php to platform/cache/cache.php
copy platform/cache/cache.php to cms/cache/cache.php

In platform/cache/cache.php and rename the class as JCachePlatform
In cms/cache/cache.php change the extend from JObject to JCachePlatform

The benefit of doing it this way, assuming you do those copies via git,
is that now the history of JCache follows along with the new objects,
and you can use git functions to detect when there are changes to the
core joomla/cache/cache.php file and merge them into your platform copy.

This is what I am doing with my personal CMS. There are features I
want that are unlikely to ever get into Joomla!. Some of them have been
outstanding for over half a decade[for example, Joomla! forces a session
cookie on every visitor. Since this is possibly illegal in Europe, and
the issue has been raised for years on the forum - it's clear there is
no interest in disabling it...probably because it's a minor change that
has major implications to things like forms and such.]

By cleanly overriding the core code, I can experiment in the wild, and
if things work it can always be pushed back to the CMS...which can then
push it back to the Platform.

The main thing is that while I'll submit pull requests for my changes to
the CMS, I truly don't care what happens to them afterwards. Use the
code or not. Try to convince the Platform folks to accept it, or use it
in the CMS and override the platform.

That is what I think the attitude for the CMS should be...never say
"this is a platform issue", deal with it in the CMS and if it works out,
THEN ask for it to go to the platform.

-Gary

[elin]

I think most of the time it's a decision. If something is not going to be of use in the core cms most likely we will ask the platform team to decide about it first, then if they don't take it the CMS would consider. If it is something for the core CMS one of the GREAT things about the separation is that we can do it. In the past it was always "that's not appropriate for the framework" but now we have our own libraries, we can add our own form fields, we can make admin libraries, we can do whatever makes sense.  For 2.5 I worked a lot on cleaning up some of  the edge case ACL issues and ended up replacing the category field with something that works a lot better for the CMS (because it checks complex permissions, state and so on). It would make no sense at all to have that in the platform.

Elin

On Friday, April 13, 2012 2:33:29 PM UTC-4, garyamort wrote:

[Nils Rückmann]

For some reason we have duplicated threads .. let's focus: https://groups.google.com/forum/?fromgroups#!topic/joomla-dev-cms/wq8jC-VeDHc