April 23rd, 2008
Posted by: Dietmar Temps at 12:58
Categories: Tiny Marbles, announcements, community, CMS
Yes, our CMS supports now different languages. Basically, the language support is included in the underlying user management system, MUM. By default we provide English, German and - well, Portuguese. But it is very simple to include other languages as well, most difficult part: the translation. By default, you can switch the language of all admin pages or you can save your personal language you prefer to work with. Also the content, like the articles and the categories, now support different languages.
Podcast and video library
Currently we are working on a podcast and video library for the CMS: in the future it will be very easy to include MP3 files like podcasts or flash videos in an article. That means, an online editor is able to create rich media articles in an intuitive way. Podcasts and videos are treated like images, and the editor can include the files in the article with only few clicks. The CMS will come with a basic podcast and flash player, where the layout can be changed very easily, so that the design of the player will fit to the layout design of the complete webpage.
New Tiny Marbles Release
Tiago wrote a patch in January for Tiny Marbles. We are already using this patch, and now it is time to publish the patch with a new Tiny Marbles release. Thanks to the patch, Tiny Marbles now once more supports like in older releases the HSQLDB database. That’s why we are able to provide a standalone version of the CMS. Download, install and run the CMS without any other databases. The easiest way to check it out, and if you are pleased you can start a new project using Tiny Marbles, MUM, Talos and the CMS. It’s worth a try !
2 COMMENTS 
TOP
April 4th, 2008
Posted by: Dietmar Temps at 18:16
Categories: Tiny Marbles, documentation, Talos, CMS
We are providing a small, but powerful Open Source library for authorisation handling: Talos. Our CMS uses Talos and provides a powerful permission management.
Talos works with ’subjects’, ‘categories’, ‘objects’ and ‘permissions’: For a ’subject’ you can grant a ‘Permission Group’ or a set of ‘Single Permission’ on a ‘category’ or an ‘object’. You can pass a list of subjects as well as a list of categories or objects to Talos. A category is a group of objects, for example you combine all articles of a CMS to a category ‘articles’: in this case the single article inherits all permissions of the category.
A typical call to Talos looks like this:
talos.withSubject(subjects).andCategory("articles").isAllowed("create");
It is easy to understand: you ask Talos if a list of subjects are allowed to create articles, and Talos answers with true or false. One important thing: the permission can be anything, you can manage CRUD operations (’create’) as well as the expressions ‘upload images’ or ’show friends of my network’. With Talos we grant or revoke permissions: either Talos finds the permission for example ‘create’ on an object and answers with ‘true’ or otherwise there is no permission ‘create’ on this object, then the answer is ‘false’.
Subjects for user management: zones - groups - users
What exactly is a subject? Well, it depends: basically it can be everything: a user, another application, an ID, whatever. The user management in our CMS uses the entities ‘Zone’, ‘Group’ and ‘User’. Each user belongs to one and only one zone. The zone created at installation time is the “Default Zone”, and it is also the home zone of the administrator. Only members of the default zone can see users or groups or any objects of all zones, members of a new zone can only see what is related to their own zone.
The group management provides a tree for building up hierarchies. Starting with a ‘root group’, which always belongs to one specific zone, the administrator can create and manage a complete group tree. A users can be a member of one or more groups. The user management supports inheritance: when a user is a member of a group, he inherits all permissions of the parent groups.
A typical call to check permissions would look like that:
talos.withSubjectOr("Zone", "Group01",
Group02","Andy").andCategory("article").isAllowed("read");
Because of the inheritance it is enough if Talos finds at least one permission ‘read’ on the subjects “Zone” or “Group01″ or “Group02″ or the user object “Andy”. If you would like to grant the permission ‘read’ an ‘article’ to all members of a zone, it is enough to grant the permission to the zone.
For more information: Security Concept and
Authorization Based on MUM and Talos [PDF, April 2008, 363 KB]
NO COMMENTS
TOP
January 14th, 2008
Posted by: Tiago Silveira at 0:32
Categories: Tiny Marbles, development, performance, architecture, documentation
Last year I had very little time to work on Tiny Marbles. When I came back from vacation last week, I saw the perfect oportunity to work on a very important issue that was not solved completely: sorting. If you’re busy and don’t want to hear the full story, skip to the What’s changed section.
Sorting was first implemented in release 0.9.5. The implementation was a Java sorter, for two reasons:
- our data model confused Hibernate: since all PValue subclasses had a property named “value”, each mapping to a different column in the table, polymorphic queries were as good as broken.
- We wanted to keep using the Criteria API.
Needless to say, this approach had many drawbacks, the most important being the memory footprint required and the CPU required to sort a Java collection. But it fulfilled its main goal, namely having the feature.
Our first implementation was able to expose the API to the outside world, and the use cases we predicted turned out to be the good ones. After we decided that the API needed no big changes, we set out to build the “real thing”. It was a huge change under the sheets, but the API remained the same. Markus and Bruno rewrote the whole Query implementation using HQL instead of Criteria. They were even able to add support for direct HQL and SQL to the Filter. This change made it into Tiny Marbles 1.0.
Because now filters use HQL, many special features are only supported by some databases. We were tricking Hibernate into findind the right column, using the discriminator field. Markus first used “CASE WHEN… END”, which is supported by MySQL, for example, but not HSQLDB. That second solution required different property names for each column type, and that caused one other design issue that took me some sleepless nights: the PValue class had all the properties declared in it. Sigh, so much for extensibility.
I knew there had to be another way, so I ended up with these requirements:
- Hibernate should always know what column to use both in the WHERE clause and the ORDER BY clause.
- Normal usage should not be affected, the Filter API should not be changed.
- Must work across all databases that Hibernate supports.
I had some failing unit and system tests that would tell me when the solution worked. They were created back when the first implementation was written, then adapted to the implementation I was going to change. It was a matter of getting the full green bar for all 500+ tests.
My first approach was to encode all values as a string and store them in the same column. Cool, that would save space, memory footprint and all those cycles Hibernate spends parsing and rebuilding and queries would more than cover for the encode/decode overhead. I was too optimistic. I moved things left and right until I came into a state where everything was broken, and I had more code that what I started with. I enjoy refactorings that end up with less code doing the same. This was wrong.
The false approach was to ditch the raw value columns. That forced me to encode filter parameters, which in turn required the value class of the attribute to be known, leading to a huge if-then-else-else-else switch right there where each filter restriction was created. The sorting thing was easy, because now everything sortable was stored in the “v_encoded” column. And I still had not solved the part where each PValue instance had 16 fields, 15 of which were always empty.
Then I set out to solve this problem. If, instead of using covariant getValue() methods I needed each subclass to have a different property name. And let’s use the name of the field as discriminator value, a nice convention that gives us immediate conflict detection and allows for neat reflection of the property name. It was pretty, clean, and small. Working on this gave me the clue for the final touch: if instead of storing them in a single column we just keep the raw values, we can pass them through to queries.
What’s changed
So here’s how the new data model for Tiny Marbles looks like: the PValue root class is still abstract; it now holds a @Transient property “value”, parameterized. Each subclass defines its own getter with the @Column property which must match the discriminator value. For example, PFloat uses the discriminator value “float” and defines a method getFloat(), while PLocalDate uses the discriminator “date” and defines getDate(). As long as you don’t use a conflicting discriminator, you can write your own PValue subclass with any properties you want. Not that anybody will want to do it… yet.
The PValue class also defines a persistent property “sortKey”, which is a String. To make a value class sortable, all one needs to do is override a method called encode(), returning a string which lexicographically represents the sorting order for your values. The current implementation encodes integers and floats as 4-byte strings, longs and doubles as 8-byte strings. String, Boolean, and the Joda types (LocalDate, LocalTime and LocalDateTime) are also sortable directly. The default implementation the method returns null, which means you can use sort any property in Filter.sortAsc() or sortDesc() and it won’t die miserably (we’re still evaluating if that’s a good choice).
I also decided to use this opportunity to drop the following value classes: PClass, PCurrency and PLocale are too much overhead to have in code and tests, given that they can safely and easily be converted to and from strings. If you’re using them, ask us in the forum and we’ll be happy to show you how to convert them.
The next release of Tiny Marbles will also have much better integration with Hibernate. Our experience and feedback shows most applications that could use Tiny Marbles mix a dynamic model with static, “pure Hibernate” data models. Why shouldn’t they benefit from the nice syntax and easier transaction demarcation?
NO COMMENTS
TOP
November 24th, 2007
Posted by: Dietmar Temps at 11:32
Categories: Tiny Marbles, concepts around Tiny Marbles, announcements, CMS
Yesterday we released our new Content Management System. It enables you to organize and manage content in an easy and intuitive way. Of course there is a documentation and you can try it out (username: cmsguest, password: cmsguest). It provides all features a small but powerful CMS needs:
- manage categories
- organize articles with version control
- organize images in a library
- default templates with RSS
- multi client user management
- authorization and permission management
Well, some features are missing, right? No search for example, but also no workflow for approval, and no user profiles in the user management system. We believe that the final design of a system is individual and part of project work, depending on the specific requirements of a customer. The underlying technology: Tiny Marbles, Talos and a pattern design which altogether we are calling the Marbles Smartware Platform. Using these ideas it is easy to enhance the functionality of the basic Content Management System. To get an idea we provide a tutorial where you can see how easily it is to create new objects, attributes and new features in a Tiny Marbles based environment: the tutorial shows the approach using an older release of the user management system, but the idea is still the same.
New release of MUM
Speaking of user management: we released MUM 1.1 ! The new release comes with a permission management, we changed the authorization, and it has a new design. Go to the download page where you can find the new CMS and MUM 1.1.
MUM provides zone management: each user belongs to one and only one zone. The default zone created at installation time is the “MUM Zone”, and it is also the home zone of the administrator. Only members of the default zone can see users or groups or any objects of all zones, members of a new zone can only see what is related to their own zone.
The group management provides a tree for building up hierarchies. Starting with a ‘root group’, which always belongs to one specific zone, the administrator can create and manage a complete group tree. A user can be a member of one or more groups. In MUM 1.1 we support now inheritance: when a user is a member of a group, the user inherits all permissions of the parent groups.
Next week more information about the security concept and authorization management of MUM based on Talos!
NO COMMENTS
TOP
October 9th, 2007
Posted by: Dietmar Temps at 17:36
Categories: Tiny Marbles, concepts around Tiny Marbles, announcements, community, Talos
It’s not always a bad sign, when for some time no new article appears on this blog - we are still alive! It is usually an indication, that we are very busy, grinding to get the issues out, making things better, and, last not least, publishing new releases.
MUM grows up!
Yes! Finally … but I have to explain a little. MUM basically is a Java library for user management based on Tiny Marbles. Usually we are using MUM in a web application context, therefore we also provide a complete deployment version of MUM, coming with all needed templates, authentication and basic authorization. What we are doing now: a very tight integration of Talos in the MUM web application. Which means: we are able to give any kind of permission for a user, a zone or a group on each entity or object we find in Talos at runtime!
In practice it means a lot, because we can configure the whole application at runtime, starting with only one ’superadmin’, who can do all. And, even better: for each component we might add later to MUM ( for instance a CMS, a discussion form, whatever …) we can manage all permissions at runtime using MUM as long as the new component uses Talos for authorization. This is the next step to our dream: a tool box with a variety of components, which fits together in many ways, and which we can control and manage from one central point of view. The authorization for instance will be managed in MUM: granting or revoking any permission on objects stored in Talos of each component based on the Tiny Marbles repository. That’s huge !!
A picture is worth a thousand words …
When we developed the first beta release of our content management system almost a year ago, the decision was clear: no sloppy implementation of yet another image uploader. But eventually we decided, that it was time getting a decent image library, which is finished now and we’ll release very soon. The components: an uploader, which allows multi selection of image files, and which uploads and resizes all images into the specified sizes. After the upload all images are stored in the image library, of course a component based on Tiny Marbles. And, finally, we can include and resize the images using the HTML editor of the CMS. Only thing which is still missing: a crop feature, where we can cut out any part of the images.
We will publish the new releases very soon, but we are still working on the design of the templates. As soon as we have something new on the server, we’ll let you know…
NO COMMENTS
TOP
Counting 
Você fala português?
Please send us comments, questions, criticism!
