Twoday Dev


We are back

Gerade einer twoday Userin versucht zu erklären, was wir in den letzten Tagen versucht haben um die Probleme zu beheben. Also so wars:

Alles begann damit, dass der Patient den langen Winter nicht so gut vertragen hat und über eine ständig rinnende Nase und zeitweise Hustenanfälle klagte. Wir habe es einmal mit schwachen Mitteln, Vitaminen und Homäopathie versucht. Konkret wurde die Datenbank optimiert.

In der letzten Woche lag unser Patient dann jedoch endgültig darnieder, und konnte nicht zur Arbeit kommen. Die Bettruhe war jedoch wie immer zu kurz und schon am nächsten Tag ging es ein bisschen besser ohne die Krankheit jedoch wirklich geheilt zu haben. So ist das nun mal wenn man krank ist, aber nicht krank sein will.

Am Wochenende, obwohl der Arbeitsstress eigentlich nachgelassen hatte, wurde es immer schlimmer. Kopfweh, Hustenanfälle bis zum Totalverlust der Stimme. Hilft nichts - am Montag am Abend gings zum Doktor. Vitamine waren zu wenig, also wurden alle möglichen anderen Medikamente hinterhergeschoben. Diesmal die richtigen Hämmer, alles was man halt so bei Grippe bekommt. Wie das mit Medikamenten jedoch so ist, muß man immer erst ein bisschen warten bis die Wirkung eintritt und man feststellt obs was geholfen hat. Also mit dem Patienten ab ins Bett und hoffen, dass es besser wird.

Am nächsten Morgen aufgewacht. Die Stimme war wieder da, der Pateient fühlte sich schon viel besser drei mal im Zimmer im Kreis gedreht, in die Küche einen Tee kochen - ach vor dem Fernseher ist es doch viel netter als im Bett. Autsch - war wohl doch nichts - die Schmerzen werden wieder schlimmer und unser Patient musste zurück ins Bett. Mehr Medikamente hinterher und weiter hoffen.

Nachdem auch nach der zweiten Nacht (Essigpatscherln inklusive) sich die Lage nicht besserte gabs nur noch eine Möglichkeit: Ab ins Spital.

Dort wurden die besten Ärzte versammelt die aufzubieten waren und die Krankengeschichte wurde noch mals detailliert analysiert. Hierbei kam heraus, dass die Probleme nicht erst letzte Woche begannen, sondern sich langsam aufgeschaukelt haben. Der viele Stress und das kalte Wetter waren einfach zu viel. Der Entschluß stand fest: Antibiotika und morgen den OP reservieren. Mehr RAM muß her.

Also da liegt er nun unser Patient. Vom Antibitotika am Leben erhalten auf die endgültige Heilung wartend. Die Spender RAM sind schon aus Deutschland unterwegs und dem Patienten wurde Ruhe verordnet. Suchen darf er in der Zwischenzeit nicht - will er auch gar nicht - hauptsache wieder gesund werden.

Und der Arzt denkt sich: "Ich geh' mich jetzt ansaufen" - und in meinem nächsten Leben werde ich Lokomotivführer bei der ÖBB, so wie man sich das als Kind gewünscht hat.


Browser Share on (Jan 06)

MSIE      58.8 %
Firefox   26.8 %
Safari     3.2 %
Opera      2.7 %
Mozilla    2.5 %
Netscape   1.9 %
Unknown  3.1 %
compared to twoday July 2005
MSIE -2,9%
Firefox +3.3%
Unknown +1.2%
Safari -0.2%


Where is twoday going?

With this posting i want to response to some discussions at antville-dev concerning some thoughts from tobi and our announcment from michi and bring in my thoughts about the future development of twoday.

The current release of twoday is based on the state of the twoday software as we use it on and some other projects. This is stable and proofen software, and for everybody the right choice for intranets, small commuities and everything where there is more than 1 blogger involved. But the world doesn't stand still and the discussion what blogging software is about is ongoing.

In the past we tried to be as close to the antville codebase as possible - just to make it possible to merge our development back to antville [1]. And so we just had the same problems and needs as Tobi lists them in his posting. I want to give a quick glimpse on where the current development state of twoday is and where we will go in the next months. The software i'm talking about here is not released yet but already in use. I always like to reference to it as twoday 2.0, but that is not common sense.

Here is Tobis list and my comments:

* unify text, files and images to one hybrid content structure. this way, any new item can be added without patching the database.

That was also our first thought, but we decided to keep Text and Media seperated. Why? They are just too different to unify them. Or the price of unifiying them is higher than the convinience of having them in the same table.


* simplify access control by providing convenience methods that sort out a user by verifying the necessary permissions with the actual role privileges. a developer should be able to do this with one or at most two function calls from an arbitrary action.

We still have seperated security functions from actions. That should provide the possibility for a sub-implementation to override the security check without altering the action. But we dropped the have all checks for a prototype within a single checkAccess function.

function main_action() {
function checkAccessMain(usr) {
   if (this.blocked) {
      throw new DenyException("siteBlocked");
   if (! {
      if (this.hasRole(usr, "VIEWER") == false) {
         throw new DenyException("siteView");

Pretty simple and readable. Isn't it! And as an addition you have to implement a corresponding checkAccessFoo function for every action you provide. This forces the developer not to forget about securing actions.

* rework the whole internationalisation engine. here too, a developer should only need to call a simple message funktion. and user's probably should be able to edit message files from within their site environment.

Finally we kicked out translated skins again, and just provide translated strings. A modTranslator takes care about translating, so the translator doesn't need to take care about .property files. All a developer has to do is:

[% message key="Story.edit.publishButton" 
de="Veröffentlichen" %];

The modTranslator will collect all "not yet translated" messages in code and skins as good as poosible and will add them too to the property files. The result would be:

[% message key="Story.edit.publishButton" %];
app/locale/en/ Story.edit.publishButton = Publish
app/locale/de/ Story.edit.publishButton = Veröffentlichen

* improve skin handling and editing. as gobi already shows there are ways to shift the input (i.e. editable forms) and output skins towards each other. wouldn't it be amazing to only edit one skin once and both, your text editor masks and the user front-end appear just right and in sync?

We didn't touch that part yet. And i'm not convinced that it's a good idea to merge editing and publishing skins. But i hope that Helma 2.0 skins will bring up the need to refactor all of this and make it a lot easier to provide layouts for blogs.

* delegate the user interface to the client again. client-side javascript has become mature enough to use it for simple tasks like paging and sorting; and as all the web 2.0 hubris and ajax cleansing promise, it even could be used for fancier actions...

Step by Step Ajax and Effects are floating into the application. Commenting is such an example but also various other places. Paggination is not yet.

* while we are at it: of course, antville could do with an appropriate dose of (not so) recent hot web features. well, i did not say "trackbacks" or "tags", but let's see what makes sense, here, anyway. (tags for sure!)

YES: Tags for sure. We implemted tags for everything. Sites, Users, Text, Content. And the good news: they are typed. So an application can use system:tags, person:tags, location:tags or whatever it needs to organize the new world.

* yes, and all the rest (e.g. polls or blogger apis) goes into modules. in fact, in modules every enthusiastic javascript developer should be able to write.

twoday, as published already has more than 20 modules. and we moved even more stuff to modules (apis, rss, polls, etc..). I admit that the current twoday module framework could need some improvement and clean up - that's not done yet.

* while rewriting the code helma 2.0 will evolve and hopefully new accomplishments can be reflected in antville just in time.

We don't wait till Helma 2.0, but we will follow as soon as possible. What we miss the absolutly most: BETTER TEMPLATING ENGINE!!!! PLEASE!!!

But we even have more on our fingertips:

  • Text to Content links, which we just call: Enclosure
    Podcasting, Videocasting, Photocasting - just a tiny step away.
  • Native support for Audio, Video, Images, etc... in a way flickr does it. You may call these media-streams.
  • RSS 2.0 and Atom 1.0 feeds
  • Better and easier to use admin interface for users. No front end editing, accept with AJAX.
  • notification framework
  • .... (ask michi :)

So why is all that not public?
Just because the code needs a major clean up - and we are not done yet.

But will it be public? And when will that be?
I don't want to promisse here anything, don't expect anything earlier than march, and don't even bet on that. But from my point of view the things described here (the core) should get published - sooner than later. So as an antville or twoday user (i mean the guys installing the software, not the bloggers at or or somebody willing to get his hands dirty with code it may be worth waiting over implementing all this on his own based on currently published code (no matter if it's antville or twoday)

And for all those who want a next generation blogging software
as the base of their projects without getting their hands dirty with code. Contact us. We do this for money. And i think we do it good.

[1] The antville project (anybody interessted in it, or using the software) is very welcomed to incorporate whatever we have improved and we will be as supportive as possible. But we wont send patches, write long explanations, start a discussion to finally recive a "let all that think in and wait". It's just true that robert and tobi are not able to provide more extra time for antville, and to be clear that is nothing i'm complaining about - it's just the reason why we split the twoday development from antville.



A Thousand Stories a Day

zu lesen im Knallgrau Weblog


Browser Share on (Juli 2005)

MSIE      61.7 %
Firefox   23.5 %
Safari     3.4 %
Mozilla    3.1 %
Opera      3.0 %
Netscape   1.9 %
Unbekannt  1.9 %
Sonstige   0.9 %
compared to twoday Jan 2005
MSIE -2,9%
Firefox +5,7%
Moz/Netscape -1,3%
Safari +0,5%
also see:


Talented People

need to get mentioned. so i'm proud to link to Jürgen Koller who will script some new cool layouts for twoday.



Opera 8 with some important improvements

Display and scripting:

* Added support for document.selection and document.getSelection in form input fields.
* Added support for TextRange with methods collapse, move, moveStart, and moveEnd, required by Google Suggest.
* Solved issues with XMLHttpRequest. Google Suggest is now fully supported.

[via Opera 8 Changelog]


Helma Macros 2.0

This is a proposal by Hannes, as a result of many discussions in the last year(s):

We use plain HTML/XML syntax and don't introduce
any Helma-specific tags, just three attributes:

* h:macro is used to mark a tag as macro. Any tag containing a h:macro
attribute will be replaced by the output of that macro, with the
contents of the tag passed to the macro function as second argument.

* h:name is used as identifier of subskins within a skin. Any names
can be used, but "prefix", "suffix" and "default" are handled in the
way Helma currently does.

* h:msg is used for automatic translation as proposed 
by Robert and Matthias. Everything within those tags 
would be replaced by a localized message 
(details to be determined).

Put into practice, a simple macro that loops through 
stories in a site object could look like this:

<div h:macro="site.loop">
   <h3 h:name="prefix" h:msg="storylistHeader">Story Listing</h3>
     <li h:name="listitem" h:macro="story.title">Story Title</li>
   <p h:name="default" h:msg="storylistEmpty">No stories</p>

All the macro had to do here is get the "listitem" 
subskin and call it on each story it wants to render. 
prefix and default are handled by Helma. The only 
unsolved piece here is how to render the <ul></ul>,
but I think Helma could do automatic parent element
rendering by using a "skin stack" to know when it
enters/leaves a skin fragment.

So far this looks pretty good to me, but I haven't had
coffee yet today. What do you think?

I AM EXCITED !!! - that's what i think :)

originally i prefered a syntax that goes like this:

<hop:macro name="Page.someMacro">
pass this part as the second parameter (e.g. as a skin)
but the more i think about this, sticking to (x)html, and just extend it by a view attributes is the much better way.

<input h:macro="html" name="foo" type="text" />
could result in:

function html_macro(param, tag, content) {
  case (tag) {
    switch "input":
      if (param.type == "text") {
        Html.input(param, ...)...

Mat's Blog

California Dreaming

Users Status

You are not logged in.



Get Firefox

Get Firefox!

Currently Reading

William Gibson, Jarreth Merz, Matthias Scherwenikas
Neuromancer, 3 Audio-CDs


August 2018

Recent Updates

und wie sieht es mit...
und wie sieht es mit deiner privaten Hochzeit aus? ;-) wünsche...
flog - 23. Oct, 20:49
Danke Matthias für deinen Beitrag zu diesem Schritt....
Sierra - 22. Oct, 12:44
Ja, das Offline Problem...
Ja, das Offline Problem ist auch mein Hauptproblem....
matthias - 23. Sep, 14:36
ich verwende am Mac ausschließlich...
ich verwende am Mac ausschließlich die Browser...
smeidu - 23. Sep, 14:22
Stimmt -
Den Eindruck kann ich nur bestätigen; in der Bedienung...
N_Haase - 29. Jul, 13:24
und da oben am Dach, da sollte doch seit Jahren eine...
Sierra - 12. Jun, 10:47
but yammer accepts
no Austrian mobile numbers :(
cqeb - 15. Dec, 23:45
das verpasse ich leider......
das verpasse ich leider... atus/998712029
flog - 10. Nov, 21:38


Online for 5053 days
Last update: 23. Mar, 12:14


vi knallgrau GmbH

powered by Antville powered by Helma

Creative Commons License

xml version of this page
xml version of this topic AGB