WSE Status - Free public release
We're proud to annonce that we freely release the Status extension !
So enjoy and feed us back so we can improve it !
We're proud to annonce that we freely release the Status extension !
So enjoy and feed us back so we can improve it !
This is the second part of this former post : Some points about what we think about CMS.
After few projects and few architecture designs, we're up to deliver the second part of our mastering of content management with eZPublish.
Here are the following concepts you should know about before going on.
eZPublih as all kind of software is made to store a lot of information regarding its source. We can distinguish several types of information :
Those types structure each website and each type must keep its original aim.
Use context are very important in a solution. The aim of a context is to ensure that users can do only what is coherent to do. It's a main principle that must be declared during the design phasis of any product and it allows the mapping between events and actions. More information about this on the spectacular book The Psychology of Everyday Things by Donald A. Norman.
In eZPublish, such contexts are defined inside the back office : browse, edit, search... For example, if you are editing a content, you cannot edit another content or browse something. However, it's possible to switch from one context to another with a controlled input (Online Editor dialog box, for example).
The closest thing in eZPublish could be the navigation part used in menu.ini.
As explained in the former post, the aggregate is the concept that allows you to use different contents so it can be mashed up in one page. The edit of this kind of content has to respect the aggregate context : if you are aggregating, you can not edit a content. It also means that you have to prepare all the content you want to aggregate before aggregate it.
The composition action relies on several axis :
Currently, this is mostly implemented in ezflow's eZPublish extension.
Now that we're equipped with some concepts, we can approach complex needs of our customers.
The rule of thumb that should be learned is the following : each use context deserves a separate content structure. Currently eZPublish is coming with already set content structures (Content Structure, Media, Users and Settings) that could be extended so you can provide your own. As a matter of fact, we should always try to keep the solution genuine and only add things to it. We should also try to not replicate old ways of thinking like those used in DBMS but rely on what the software can do.
The case : your business team would like to manage some of the message shown on the website, for example, the small explanation on the confirm page of the shop or the next steps on the zero result search page. Their aim is to be self-sufficient on this part.
The solution : you can just do a smart class to store your messages and then organize it in one of the provided content structure. The point is to define a sub content structure dedicated to a use context, it's still not following the rule of thumb entirely but it's ok.
You can create a folder and set its visibility to hidden. Then create a class called Message containing 2 fields : id (Text Line) and description (Text Block).
In your different templates or modules, just fetch the object of the class Message with the corresponding id.
You create the folder like in the solution 1.1 but in the Media content structure. The benefit is that the Media content structure is visible but not simply reachable. Ok, you may access it by typing it's url directly.
We could also store all the messages using other storage facilities like the translation file or a specific database table. We can reach the same goal but with a lot of development or worse, strong constraints for the user. I strongly think than using a content is still more efficient than modifying an XML and cleaning caches...
The case : your business team would like to make links between pages and mutualized contents. The aim is to manage reference data that don't need a page (reference to the one node = one page rule) but that is not changing very often. To be closer to reality, let's take a real example. We have a company with a lot of departments. A department is just a part of a corporate body, so it doesn't really need a page for itself but it stores some typical data (address, logo, boss, etc.). In other pages, you will have to specify a department among the full list of departments.
In a typical application server based solution, you would use some reference tables declared as application variables, but with PHP, you don't have application variables. Instead we will use INI files that will be called from a specific datatype to generate a specific list.
The main limits are that you are limited to the INI file way of storing data. It means that you could not store complex objects but just key / value elements. The value must also be text based (no pictures or other media).
The Selection datatype is very powerful and should be used very often to solve this kind of need. In our case, you can create a class department with all the required attributes. Then you create a folder called Administration (not in the sense of Set up, in a business way), and eventually sub folders if needed. In a folder, you create all the departments you need. In your other content class, you set the Selection attribute to use : the Administration sub folder previously created. That's done.
In order to have a clear back office interface, you way want to distinguish your use contexts. This can be done by adding specific RootNode and block settings to the menu.ini file.
The case : your business team would like to organize a reference, like a catalog of product, and in the meantime have the flexibility to organize pages of the website. Their aim is to be flexible and shorten the time to market for the product marketing materials. We're talking of a lot of products, let's say 20k so the list approach described above is not useful).
The solution : Follow the rule of thumb by defining two use contexts : the first is obviously contribution for all the content you've already set. The second use context, less obvious, is the aggregation. It means that people would like to change some things that are not pages, because in eZPublish, each node is a page.
If you have just installed a fresh install of eZPublish, you will see the original content structure provided by eZSystems. Their main approach is to demonstrate the power of their solution so they have mixed contexts. eZFlow, an extension of eZPublish, allows you to aggregate content through the selection of already filled contents.
The content structure is designed so the FrontPage used by eZFlow contains classic content (Folders, articles, Galleries...).
This structure is efficient enough if you don't have so much content but has some limits. Indeed, the parent-child relation implies a 1-to-n relation between the main parent FrontPage and its children (understood that you will aggregate only content that are under the FrontPage).
To go further, you may organize strictly your content structure to have two content structures :
By this way, you will have a n-to-m relation between your aggregation content and your classical content. You also separate totally your use contexts by telling user that if they want to put content in the system, they have to use the first content structure and if they want to compose pages, they use the second one. Then, it's easy to set up rights, sections, workflows and so on.
We have seen different cases with different solutions all implying content and content, respecting or not the rule of use context separation. My recommendation is to carelly design you content structure before implementing it in eZPublish (or other systems by the way).
Hi there,
Long time since the last blog post. Time to have an idea, to make it mature and then prototype it.
So, the next extension after WSE Status we're working on concerns the developer ability to easily modify templates and make overrides in eZ Publish's back office.
In last version of eZPublish, developers have been prejudiced due to focus on high value added features. This is mainly linked to the emergence of the eZ Market place that provided packaged extension to companies.
By the way, our extension provides a new menu in the back office allowing you to do the followings :
This extension is still in progress and may be out at the end of January.
Eclipse PDT is one of the most powerfull IDE for PHP developpers, even if some prefer to use more classical editors (vim).
When developping your extensions or websites, you might want to have access to all the API of eZ publish, Drupal or other libraries.
To do so, we used to create separate PHP project with the different sources. Let say we want to develop an eZPublish extension. We create the following projects :
Now, in your project, right click on the project, choose Include Path > Configure Include Path.
Then go in the Projects tab, click on Add, select the project with your eZ publish bundle. You will have something like that :
PDT - Include Path
Click OK to save.
If you got some troubles, don't forget that you may not have the last version of PDT (even if downloaded from the website).
You can check updates by Help > Check for updates.
Now, some shortcuts to go faster in your development tasks :
And autocomplete feature on words, for example, in a PHP file, do CTRL + SPACE :
You can use CTRL and ALT with arrows, tab and Page Down and Page up.
Working on one of my projects with eZ Systems French consultant Jérôme Cohonner, we got an excellent conversation on how users were handled in eZPublish and how sometimes this could lead to some troubles. This post will give you some clues on how important users management can be, what are the limits and some common solutions to get the best way of doing things. I will not talk about SSO or procurement systems as I have already dealt with or as it's out of the scope.
Let's get back to the roots and have a look on principle concepts of AAA :
Generally, in all IT systems, these concepts are implemented in different ways, together or alone, merged with other systems or not. When an IT solution becomes complex, you will need to provide a strong user management strategy to be sure that all will work together. The strategy is defined by combining different approaches that could be listed like this :
Moreover, all those approaches are submitted to the centralization dilemma : do we need to centralize all those things in one service or not ? If one of these approach is not centralized, do all the software of our solution are able to do the job ?
On each IT projects, choices are done, sometimes depending on the software capabilities, sometimes not. The most important is to know where you want to get the maximum flexibility.
In eZ Publish, users are stored and considered as content objects which is a choice in itself. It means that the accent has been set on data management before everything. The cool thing with that is that you can handle your users as pages (as they are nodes) and that you can add and remove attributes as you want. Best, data can be versionned. The only thing you have to do is to ensure that the user content class gets the User account datatype.
You can also plug the LDAP Login Handler to access a remote directory. The mechanic is quite good. At the authentication, the user provides its login and password. eZ Publish will try to log this user in the LDAP and if it succeeds, eZ Publish will create an eZ user or update it if it does not exist. Then the user is authenticated and receive eZ Publish credentials.
It's also possible to use the multi locations mechanism to get some flexibility on the role assignment. For example, as you can set a user in several groups, you can give each group a different role so multi located users will inherit all the roles from all their parents. You can look at one of my former post about content design, it explains how to organize your content in eZPublish.
The limits of this model are :
Some examples :
eZ Systems is refactoring, time after time eZ Publish's model so everything is split and highly efficient little by little.
It can give you some troubles on performance when you reached high number of users. The main issue is that user data are in eZ Publish and not away. The first point is to know if you need some customization or finally if you just need the user to be logged in to just access some private area.
Make a datatype or extend the eZ User type to only let eZ Publish manage what it needs to authenticate the user, I mean the eZ User Account. Ok, it's cool to have users as pages but in real life, customers don't really want a picture directory of the whole members of the web site. It's not done today in eZ but the global approach of un-content-ization has began. More recently, the eZ Comments extension provides comments for everything in eZPublish but is not set with the classic content mechanism.
The approach of the datatype may not be the right one. You may except some troubles, depending on your storage mechanism. I was thinking about several containers, like LDAP (of course), a custom SQL table, even a file (XML or whatever).
Sometimes troubles are coming from a bad interpretation of the customers need. Sometimes, people don't want data to be hold by the system, it's just an helper for them and avoid to get information elsewhere. Sometimes, people, I mean the main population of the website, doesn't know that there are data about them loaded in the system. The point is that finally you don't need the data, you can do without it.
An example : your customer is telling you that their eZ Publish instance is holding 400K users with a lot of data. This data is not shown on the front side because it's an institutional web site with a poor logged in section. The data is shown in the back office to the webmaster in the user section (so for 1 guy).
One good approach is the following : ask why customer needs all these data and try to figure out if the data is stored elsewhere and if it can be accessed in a asynchronous way, by requesting a LDAP or other external data source.
The solution that will work is to set up a meta user by big business role you are using. For example, define an HR user, IT user, a Board user and so on. When people are logging in, check access against the source and then log the user with eZ Meta User predefined. You will get a severe reduction of your members count : 400K to 4 !
The second point is the way you can share users between different application of your IT system. We can think of it on two aspects : the fact to share data (first name, last name and so on) and the fact to authenticate people. It's different and this could be implemented in different ways.
The most important thing in your IT system is to define an architecture block that will handle a centralized reference of user data, both for the data and the authentication. From a strict architecture point of view, directories can provide both features and that's not good. However, as the password is generally the cheapest and easiest way to authenticate people, architects do not recommend two services and prefer to have only layer for this.
So, the most important thing is to use an external service to hold the data and the password mechanism.
Sometimes, it's a bit difficult to find the allocation of your data between the remote (I mean the reference users data) and the local (data from your application). At this point, you may have three choices with drawbacks and advantages :
As your system needs some consistency, you have the choice to centralized everything at the remote reference but this is implying a bottleneck. Moreover, you will have to get a fine strategy to synchronize remote and local, replicate data from one to the other.
Questions to ask yourself :
For eZ Publish, it's quite simple as the User mechanism is not so efficient with a lot of users. So the best way, if possible, is to
Users management is not so easy, there's a lot of thing to think and some merged concepts that make us difficult to take decisions about how to manage the users in an IT system. This is a common issue that is shared by all companies aver the world and leads to interesting solutions like oAuth or OpenID.
Regarding to eZ publish, the difficulty is coming from the technical lock inferred by the eZ User Account type that forces you to have a data user instance in eZ Publish. My recommendation is to quickly kick out the user account (login, email and password) from the user class. This will lead to the division between data and authentication and then it will be possible to authenticate someone without any data inside eZ publish. Then if we actually need a node, we can make a synchronization or an after account creation trigger to generate the node. This mechanism has to be disengageable.
WSE Status has been enhanced to be compliant with eZPublish 4.5 Community 2011.7.
This major update contains the following :
Moreover, this product is now automatically tested with Selenium scripts ( around 20 tests now and still increasing ).
Next step is implementing new features. If not not already done, help us choosing the right features.
Thank's a lot for beta testers helping us to fix the bugs.
The demo will be maintained, just get an account on it to try it.
To get this extension, you can contact us directly with the contact form.
The next step is to choose next features to implement amid this ones :
If you have other ideas, let us know, we will add it to the list.
Let a comment to this post so we can know what is the most important.
Another delivery that is correcting several issues, notably on the direct messages feature.
The search is also working back to the normal with @person searches.
Register on the demo instance : http://wsest.demo.wascou.org/user/register
Try WSE - Status on the demo instance : http://wsest.demo.wascou.org/status/profile
Thank's for Nicolas, Damien, Lars, Carlos and Ana helping me to identify bugs.
Any feedback is welcome !
| #71 | [Status] Change the form that allow to send status |
| #70 | Searching for people using @<personname> reports no result |
| #65 | [Mail] New response mail |
| #63 | [Mails] Check that mails are sent |
| #69 | [Direct Messages] List of discussions are not good |
| #68 | [Direct Messages] Number of messages is not good |
| #67 | [Direct Messages] List of receivers is not good |
| #66 | [Ajax] Update the numbers after doing something |
Thanks to people helping us to test WSE - Status.
We have made a first bunch of correction which are the following :
Another delivery is planned for Monday.
Keep it in touch.
The WSE Status extension is nearly complete and we need some help to beta test the product !
The full description of the features are in the related description page.
If you want to participate to this beta, fill the contact form indicating your email, I will create you an account.
There's only 40 seats so, don't hesitate !