An interesting topic emerged among suggestions in the ez.no forum, regarding themes for eZ Publish. I thought it was an interesting theme, so here's the link: http://ez.no/developer/forum/suggestions/provide_new_themes
And here's what I think:
I have to agree that easier theme management and exchange would help to widespread eZ Publish. Personalization seems like the big thing right now and even if it's not about that, ability to implement selected themes easily might be one of the key factors when deciding on a particular CMS.
However, we need to realize what theme engines we're talking about when trying to incorporate that idea into eZ Publish. Most themes that I know of are prepared for systems that have a very isolated and precise functionality due to the kind of system they are (CMS blogs, forums, shops, web galleries, CRMs, or CMSs with preexisting module sets, etc..), and whose content model, internal structure etc. do not change.
Meanwhile, with eZ Publish we have a content engine that makes it possible to handle most of the above functionalities and nearly everything can be customized. With the system we don't have preset roles for a forum, for a blog etc - we have to arrange that ourselves, minding all the implementation details. There's entire list of other dimensions that have to be taken under consideration (sections, access rules, caching, custom overrides, class modifications, structure...). Many of those things are handled or reach to the presentation layer (*.tpl), many of them in a customized way, again.
If some of the themes available for those other, isolated systems, have to be versioned along with the core (for example: theme for version 2.0, theme for version 2.1, etc..), how do we want to handle the change with eZ Publish and its complexity? Would that be possible without limiting of what's one of eZ's key features - extensibility? Wouldn't that concrete the development of the core in some ways?
If I look at ezwebin, I see an intelligent GUI, not a skin. This interface is crucial for developers to ease the learning curve and also pick up some good practices, but with around 40 eZ Publish implementations, we haven't yet had a customer who would fit into ezwebin precisely (or sometimes - at all).
Much as I appreciate the marketing goals, I don't think they are that important for this level of CMS (and ezwebin versions do just fine for that matter), and nowhere near as important as the core of the system. And there's only so much time eZ people have. I believe we're all much better off getting solutions such as eZ toolbar or eZ Flow (or bug-free stability and security) rather than color variations of backgrounds...
To be continued... here:
Just as I'm struggling with cache optimization for one of the current projects, I discovered that it would be great if cache-block functionality had one more parameter - a user-defined and user-readable identifier. Being able to clear all the cache by calling this identifier would be a great enhancement. It would be enough if it was implemented at eZ API level, so that users were able to create their own actions (views) to handle it. This would be especially benefitial for caching of custom modules and views, outside content and content tree itself.
Life example: Imagine expensive custom views that require couple of hundreds of SQL queries per view or view/param combination, and can be accessed/managed by a) the owner (of something), b) all other users. Now, leaving these views uncached would be suicidal, and cache-blocks would be quite handy, and there would be only two cache blocks per view (since you either are the owner or not). Now, the additional expectation is that the owner will always have his view up-to-date, which means we can't really cache it for him. Wouldn't it be great to be able to create a button named "Refresh my view", which would cause one particular cache-block (or cache block group) be cleared? In that way, we could cache the owner's view as well, making it possible to let a manual clear only when needed ;)
Inspired by Bruce Morrison's post in his blog: http://suffandnonsense.blogspot.com/2008/02/is...
I kind of understand the disappointment with minor revolution of the current big version 4.0, although I had known (more or less) what to expect when I was awaiting it few months back. You can ask yourself: was PHP5 more of an improvement, or maybe a necessity? If the latter, the smaller was the step ahead, indeed. Nevertheless, I am very glad this step was made, no matter what the version is called, for reasons that must be obvious. Back to the expectations, I can only imagine how 3.x introduction was different (greater) to 4.x, because I've only known eZ Publish since 3.8.x or so (BTW: have to admit I gave up after several attempts with 3.5... it beat me!).
Bruce's suggestion is to put eZ Publish 4.0 at its rather stable state into feature freeze mode, while concentrating efforts on taking full advantage of the maturing eZ Components to produce the next big version (5.0) from scratch. I have to say that I like this idea for similar reasons:
There's another thing, but it deserves to be covered in its own paragraph.
In my comparatively short experience with eZ Publish, I have already dug deep enough to see its few weaknesses, especially regarding the content and storage models. Don't get me wrong, by no means would I call eZ Publish weak, it's just that it has its limitations defined and there are only so many things you can do with it without hacking or severely extending.
Now, I do understand how big part various "rich" features play in the eZ business model and in those of many eZ partners. For example, extensions such as eZ Flow or Web interfaces that make it possible to have an advanced out-of-the-box product with time required for implementation significantly reduced. Having seen how business-oriented eZ people are, I do not expect this direction to be given up at any stage (and I like that).
However, I hope that that direction does not prevent from improving the application at its core, that is the foundation for all eZ business after all. Unlike presentation layer or even more advanced extensions, which can be developed independently, core upgrades would be rather difficult to be introduced by means of hacking the kernel. I'd like to be optimistic, but don't see alternative storage models or advanced class features coming any time soon. New rebuild could be an ideal opportunity to make eZ Publish even more versatile and fit to solve even more advanced content management tasks (and not only!).
It doesn't seem like this issue is up for a discussion, but I haven't heard anything official on eZ Publish 5.0, yet. So, maybe it is not too late ;)
If you ask me, I think I could live in this 4.0 feature freeze mode... if what I was waiting for was a completely new eZ Publish 5.0 in a year or two, with even greater core features and as few compromises as possible.
I've just noticed that my tag cloud (on the right) changes itself from time to time, even if no new content has been published... This is weird, I'll have to log it ;)
Using keyword attribute is a very convenient method of improving the site's navigation system and leading users to the content of their interest.
If you're planning to use keywords attribute for anything that should behave as managed, then you shouldn't use the datatype for any other purpose within the same eZ Publish installation. Or, on physical level, you shouldn't have more than one keywords-datatype-based attribute per content class.
At this point keywords datatype stores all its values in one flat database model that does not provide any means of grouping or categorization on the attribute level (it is possible to fetch keywords based on the content class, but that's not exactly what's needed).
If in your article class definition you want to have two separate attributes for meta keywords and tag cloud tags respectively, then you should only choose keywords datatype for the tag cloud and another one, for example a text line, to collect data for meta tags. If you choose keywords datatype for both:
That text line is perfectly indexable for search and as long as you don't require any logical operations on the collected data, then it fits most needs just fine.
Now, I've mentioned that it is possible to fetch keywords by content class(es), but that is an answer to "where" question rather than "what question". What if you want to have 5 keywords attributes in your content class, for 5 different purposes?
Solution seems quite simple. Keywords datatype could have an additional ID, that would make it possible to group keywords on attribute level. This could be simply an integer/string typed by the user when defining a content class, or it could easily become a drop-down list of labeled options, if an extremely simple mechanism/manager for managing keyword groups was implemented.