ver 3.0 vision

[bill richardson]

As i was refused membership to the general development group, i could
not comment on an issue raised about removal of some components,etc
for the 3.0 version.
I think the discussion should be about what should be retained - if
ucm is adopted, there is an opportunity to dismiss backward
compatability and just provide one content component to demonstrate an
application based on the platform.
If you look at the bug lists and the number of issues open or
confirmed , is it not the time to adopt the KISS approach and simplify
the cms application.
I agree with Michael that the com media component needs updated and
there are plenty of extensions available that show a better way to
handle images.
The one content component should have the abilities of a cck
( examples are k2 and yootheme zoo ) as this is one of the most
requested features on the wish list.
Another desirable feature would be the ability to easily create your
own component,module or plugin.
Extra feature that where introduced in 2.5 like user notes , smart
search do not belong in the core but should be available as extensions
for those users who require them and flawed implementions like user
profiles should be removed.
One other big issue remains is the seperation of the platform from the
application(cms ) layer that has not been started, or the possibility
to abstract the mvc to reduce the amount of duplicate code. Does j
content not belong in the application layer ? , anything that mentions
tables or contains specific queries belongs in the application and not
the platform.

Regards
Bill

[Rouven Weßling]

Please excuse the late reply. Somehow I forgot to answer your e-mail Bill but I didn't wanna leave it unanswered since it raises some important concerns.

On 26.01.2012, at 15:42, bill richardson wrote:

> I think the discussion should be about what should be retained - if
> ucm is adopted, there is an opportunity to dismiss backward
> compatability and just provide one content component to demonstrate an
> application based on the platform.
> If you look at the bug lists and the number of issues open or
> confirmed , is it not the time to adopt the KISS approach and simplify
> the cms application.

> The one content component should have the abilities of a cck

> ( examples are k2 and yootheme zoo ) as this is one of the most
> requested features on the wish list.

A CCK would be nice and would definitively remove the need for quite some stuff. However I don't realistically see us getting there with 3.0. I'd be happy with just getting our content components to use the UCM internally.

> Another desirable feature would be the ability to easily create your
> own component,module or plugin.

You mean something like com_jfoobar?

> Extra feature that where introduced in 2.5 like user notes , smart
> search do not belong in the core but should be available as extensions
> for those users who require them and flawed implementions like user
> profiles should be removed.

I'm indifferent to user notes but I really think search is a core concern. Extensions will only provide the adapter for so and so many solutions. A strong search is, in my opinion, very important for a content management system.

> One other big issue remains is the seperation of the platform from the
> application(cms ) layer that has not been started, or the possibility
> to abstract the mvc to reduce the amount of duplicate code. Does j
> content not belong in the application layer ? , anything that mentions
> tables or contains specific queries belongs in the application and not
> the platform.

The platform recently started identifying classes that will be moved out of the platform with the next major release (12.1/3.0). This process will probably take a long time since many classes a coupled surprisingly strong.

JContent is a pretty generic implementation that can hold a lot of different data, I think it's fine keeping it inside the platform.

Rouven

[Andrew Eddie]

On Friday, 27 January 2012 00:42:07 UTC+10, bill richardson wrote:

I think the discussion should be about what should be retained - if
ucm is adopted, there is an opportunity to dismiss backward
compatability and just provide one content component to demonstrate an
application based on the platform.

Just a note.  Firstly, and laying my cards on the table, I'm totally agnostic about whether the CMS adopts the UCM package.  It doesn't matter to me if it goes in or not, but I'm happy to help if it does, and I'll continue to work on it if it doesn't :)

Secondly, adopting UCM and dropping backward compatibility are two different approaches, possibly combined, but possibly separate.  UCM can be adopted parallel to the existing com_content either forever or replacing it in the next version (this is the way Finder/Smart Search has been introduced because, and let's not be in denial about this, com_search does not cut the mustard).  Another option is, as suggested, to leverage an opportunity to break things and just replace com_content with UCM.  Either option is acceptable but that's your first decision to make.  However, a precedence has already tepidly been set with how search is being upgraded so, to be honest, if it was up to me I'd go with a parallel approach in 3.0 and be in a position to drop the old com_content in 4.0.

 

If you look at the bug lists and the number of issues open or
confirmed , is it not the time to adopt the KISS approach and simplify
the cms application.

I would agree, but, that means different things to different people.

 

I agree with Michael that the com media component needs updated and
there are plenty of extensions available that show a better way to
handle images.
The one content component should have the abilities of a cck
( examples are k2 and yootheme zoo ) as this is one of the most
requested features on the wish list.

In terms of CCK I agree that the CMS should have this, but my suggestion is to bring it in gradually.  Don't try to bite off the super-one-size-fits-all-CKK in the first version.  My suggestion would be to approach it in this way:

a. Have a team research and develop mocks for how a CCK looks and works from a UX point of view.

b. Phase 1 is to implement a simple content type editor that allows you to add new types, picking from existing tables for the extra field support but leaving remaining customisation to the developer.

c. Phase 2+ is to progressively add richer elements to the CCK "editor".

One has to consider that, currently, UCM is a developer tool for custom site implementations.  Turning that into something which can be easily and intuitively used for an end user is not something that should happen in one huge step.  My recommendation is to use several point releases to do it.

The other side of the coin is UCM potentially kills a lot of the extension market that currently exists, in the long term.  UCM can immediately roll weblinks, newsfeeds, contact and probably even banners into the one central content location (how do you start to manage that in one interface?).  Long term though, UCM in the core could replace every other CCK extension (not to mention forums, social networks, directories and others) out there if done well.  Not judging whether that's right or wrong but it's going to have implications no matter how you slice it.  What's left for the custom extension market after UCM is the norm?  Will it have a positive or negative effect on the Joomla culture?  Interesting questions to ponder.

Another desirable feature would be the ability to easily create your
own component,module or plugin.

Here's where different people have different opinions about things.  I don't think this should be in the default download that someone wanting a website needs or even wants (I'd go so far as to say 99% of site implementors would disable it with extreme predudice so their clients can't mess with it). But that's just my opinion.  So, to get around having to have the arguments about what goes in and out of the core distro, I suggest that people look at how to support a completely stripped down Joomla core CMS, and then look at how different extensions, or suites of extensions can be maintained in one or more different repos.  That's part 1.

Part 2 is then to be able to build a multitude of different distro's of Joomla from the core repo, and optional elements from other repo's (much like what Eclipse does).  For example, something like com_jfoobar could be in an official "place" but maintained completely separately from the core CMS.  Come build time though, there's a distro called the "Developer Build" which includes it (but it's not part of the core CMS distro).

Advantages are that bugs can be passed on to a smaller group of more focussed maintainers and the JBS can concentrate on the core features (which, in my view are just user management and UCM).

Another option is to still rip the guts out of the core CMS distro, and integrate it more tightly with the JED so people can select extensions to install, much like mobile device app stores, or even install collections that people have saved and published for others to consider (that would be pretty cool).

 

Extra feature that where introduced in 2.5 like user notes , smart
search do not belong in the core but should be available as extensions
for those users who require them and flawed implementions like user
profiles should be removed.

I accept your opinion that they don't belong in the core, but I don't agree with you.  As it stand com_search is an ancient and hopeless search mechanism (it's virtually the same as Mambo 3 used).  In my view it's what should be dropped in 3.0 allow for it's successor, Smart Search, to be the only option.  Search needs to be in the core so let's get rid of the right one :) (i.e., the one that doesn't perform).

On user notes, meh, people need to watch the development process more closely or fork Joomla and tune their own distro to what they think users actually want (cf, Square One).  My only concern is that over the last few years the project has done a lot to lower the barriers of contribution but the fire storm over this tiny little feature seemed to want to put all the walls back up again.  Go figure.  Conversely though, I would have implemented user notes as a custom extension if Joomla provided hooks to allow me to add stuff to lists :)

On [custom] user profiles, I don't think it's flawed but only from the context that it was never supposed to amount to anything anyway.  It was a technology demonstrator, nothing more.  There are a number of options to replace it using UCM anyway.  The problem is what didn't happen - developers didn't take that example and run with it to make it better (unless you count UCM).

 

One other big issue remains is the seperation of the platform from the
application(cms )  layer that has not been started, or the possibility
to abstract the mvc to reduce the amount of duplicate code. Does j
content not belong in the application layer ? , anything that mentions
tables or contains specific queries belongs in the application and not
the platform.

Actually the separation has been started (iirc I posted that news on a number of lists) as Rouven mentions.  The current procedure is to move "stuff" that's CMS centric into a /cms/ folder in the platform (you can see quite a bit in there at the moment).  Just prior to the release of platform 12.1 we'll tag the repo and then remove that folder.  So 12.1 will come with a reduced CMS payload but the tag will help you work out what we moved.

A review of the MVC is underway and hopefully we can start talking about that later this month on the platform list.  However, I believe the code reduction will come from throwing away extensions in favour of just using UCM if that's the way the CMS wants to head :)

Content doesn't belong in the application layer but in it's own package (that's the approach we've taken with UCM).  Not all applications, CLI or even Web, need to deal with content like the CMS deals with it.  Now, as for anything that mentions tables, I'm actually working on a new Data Mapper pattern that separates that quite nicely.  That work should dovetail nicely with the new (and really slick and simple) MVC ... but more on that when I've got something to show for it.  That work will all be tied up in the UCM package eventually.

 

Regards
Bill

Despite that fact that I disagree with a bit of what you said, I'm glad someone is wanting to talk about it :)  At the end of the day I don't really care how the cards fall, as long as the right stakeholders are in on the discussion.

I do want to stress, and repeat, that I think we really need to look at multiple distro's for the CMS that scale features vertically and horizontally (and also internationally).  We have already passed the stage where one-size-fits all is a good way to distribute Joomla.  If we have a way of doing that, then we can short circuit a lot of these "I don't think this belongs" discussions that will only get worse and worse if we stick with the one distro path.

I also want to encourage those involved in the future of the Joomla CMS to make sure that graphic mocks are a core part of how the vision is sold and enacted.  Not that they should be cast in stone, but I think it helps everyone set a course more or less in the same direction.

But getting back to the question of the "vision" :)  I think it's time for the Administrator to be reinvented, for massive improvements to be made in the way media (images, files, videos, etc) is managed and displayed, look at tighter integration with the social sphere and to rethink how content providers interact with content (e.g., maybe more emphasis for editing content in context from the frontend and leave the administrator for, gosh, just administration of the site).

Regards,

Andrew Eddie

[bill richardson]

Thank you for responding - i also agree with some of your ideas ( slim
core - alternative distros)
At the moment smart search does not work with some other languages -
so the old search needs to stay imho.
More information is needed on ucm ( what is happening to
categories,user groups ) and does assets / acl need updated.
Will the cms use the ucm as exists in framework or will/can they
extend to suit their needs.
Andrew you mentioned table mapping - has Doctrine been considered ?


Regards Bill

> content in context from the frontend...
>
> read more »

[Andrew Eddie]

On 6 February 2012 21:00, bill richardson <wr.ric...@btinternet.com> wrote:
> Thank you for responding - i also agree with some of your ideas ( slim
> core - alternative distros)
> At the moment smart search does not work with some other languages -
> so the old search needs to stay imho.

Bummer, though there's a good case for a distro that handles the
exception, not the rule :)

> More information is needed on ucm ( what is happening to
> categories,user groups ) and does assets / acl need updated.

For what I'm working on at work, it's likely the assets table won't be
required anymore, at least not in custom apps that I'll be supporting.
The ACL is still based on the JSON rules, but I've devised a better
API in the authorisation package. There was some concern during the
initial talks about make the ACL pluggable and the authorisation
package opens that door.

User groups would still form part of the user management system, but
user profiles would/should be covered in the UCM.

Categories are still a bit up in the air but there will probably be
some "equivalent" - jury is still out on that one.

> Will the cms use the ucm as exists in framework or will/can  they
> extend to suit their needs.
> Andrew you mentioned table mapping - has Doctrine been considered ?

So, with a Data Mapper, you can do whatever you want. You can have a
mapper that connects to the database in home grown way, or you could
use one based on Doctrine or similar (though, I have a passionate
dislike for the ORM frameworks that define their relationships in the
docblocks). That's one of the beauties of the Data Mapper pattern and
the way I've built it so far allows for interchangeable connectors
between the value objects and the data source. It's still got a ways
to go but hopefully something can be presented before 12.1 is out the
door.

Regards,
Andrew Eddie

> --
> You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
> 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.
>

[elin]

It's always fun to speculate about what you would do if you had never released and were starting from scratch. And it's not a bad hypothetical exercise at all.

However, realistically, in terms of what we have learned about how Joomla development works and what real world experience in general with writing new code is, the idea that we would be able to throw out much before 3.0 is just not anything to do with how things actually happen. At best 3.0 will be a baseline implementation of UCM. Who even knows if opt in migration will be ready not to mention a type editor. We don't even know yet if (or when) the platform maintainers are going to accept the JContent proposal or if that does happen, if the CMS team will choose to go with it assuming someone has proposed code to do so. What if the platform people don't decide until May? What if they say no to all or part?  If that happens it's not realistic at all to expect anything related to that in 3.0.  I'd really encourage people to go and play with it the way Rouven and I have been and see what you think and if you think it makes sense for the CMS. And then give the platform team your feed back on if it should be accepted or not. The sooner we know that the sooner we can start realistically thinking. In fact, I'd really encourage people to build out a model that only uses UCM and then we can see what people come up with.

I think we have learned hard lessons about making any promises about features both in terms of whether and when. For all we know 3.0 won't have any new features. It could just be focused on optimizing queries or abstracting layouts or a new admin ui or feature improvements may focus on the media manager or multisite.  This is the thing about time based release cycles. Steady improvement, stable trunk, the work that gets in is the work that gets done, and then like clockwork do the releases in a calm manner.

If you have a vision, start working on building it out. Share it on list and on the feature tracker. Work to convince people of your ideas and build consensus by being willing to compromise. Really listen to what others have to say and try to respond to it. See if you can find solutions that please many people with different perspectives. See if you get buy in. Don't make ad hominem comments.  And always keep in mind that in the end it is writing the code that will make things happen and speaks louder than anything. If you don't get people to agree with you and don't like the direction you see, build a new application on our fabulous platform, with UCM and the separate availability of the platform that's all so much easier. I hope we'll see dozens of real (not demo) platform applications in the next year and if you want radical change with no backward looking issues that is completely the way to go.

I will say that I would never favor abandoning millions of webmasters, however, and never again should we put them through what we did with 1.5 to 1.6. Nothing should be removed without a clear, seamless migration path that involves no more than one or two clicks by an average site administrator. So if you really do want to rip stuff out you may want to concentrate on building that part of it. I've already shown what a rebuilt database might look like.  So you may want to concentrate your efforts on building out the application for that.

This is a mature project, abandoning users or treating them as though they or their sites do not matter is not  an option in my view.

Elin

[Karlos Rikáryo]

I believe that this version 3.0 should be thought a character counter to
the blog format, it would be a feature that despensaria the read more
line and would be much more practical for lay users.

Another interesting functionality would be to think of a standard
miniature �pluguin without many features other than the decrease of
images. This functionality exists already for a long time in Wordpress
and Joomla! whenever we talk about this possibility of guy is always
highlighted, why?

Greetings brothers Joomla!

hugs

Karlos Rik�ryo
Joomla! Brazil
www.rikaryo.com.br