Krasse Java Script Kartendarstellung

Posted on 2009-09-16

Seit gestern gibt’s mal wieder was neues bei Karopapier, das zumindest so auch mal sichtbar ist -wenn auch nur als Prototyp.

Unter Zuhilfenahme der sehr hübschen JavaScript Graphics Library wz_jsgraphics (http://www.walterzorn.com/jsgraphics/jsgraphics_e.htm) hab ich die Karokarten bzw. die Züge der User KOMPLETT in JavaScript zeichnen können.

Die Vision, dass man dem User/Client prinzipiell nur die rohen Zugdaten liefert und er sich seine Kartenansicht selber baut, gibt’s schon länger. Denn Karten Zeichnen braucht ja doch ne gewisse Performance auf dem Webserver.

Mit dieser Library scheint es aber zumindest in gewissem Maße möglich zu sein, dies auszulagern. Einen Prototyp davon hab ich schon seit einem Jahr oder länger schimmelnd rumliegen gehabt, ihn aber gestern wieder ausgegraben und mit meinem etwas gewachsenen JS-Wissen der letzten Monate weiter ausgebaut.

Somit war es dann sogar möglich, pro Spieler eine Ebene mit den Zuglinien (Canvas) zu erzeugen, die dann natürlich auch einfach mal schnell ein- oder ausgeblendet werden können. Somit ließe sich auch ganz praktisch ein “Wo war ich schon” schnell auf der gesamten Karte anzeigen lassen.

Evtl. ließe sich damit auch ein JS-basiertes Replay (à la KaroTools, einfach genial, aber wg. SVG halt nur bedingt populär) umsetzen… aber mit dem window.setTimeout bin ich bisher noch nicht ganz warm geworden bzw. es führt mit der Library zu Problemen (this-bind-Problem)

Wie auch immer, ich hab’s mal eingebunden und als Alpha-Version verlinkt, wenn es auch bei manchen Spielen einfach mal kommentarlos abfackelt… aber is ja Alpha, nich mal Beta 😀

Criteria -> DQL

Posted on 2009-09-11

So, now I have some new classes that use doctrine to acces my DB and the move went quite smoothly.

However, I had some methods that – of course – used propel criteria to create special queries… those times are gone. What’s it like in doctrine?

But first, I had to add a Behaviour Timestampable to my schema to make sure good old updated_at and created_at still work. They have to be removed from the schema.yml, though and be replaced by

Zip:
actAs: [Timestampable]

Hope, that works…

Regarding my criteria: For example, I had the quite simple case:

$c=new Criteria();
$c->setLimit(20);
$this->zip_list = ZipPeer::doSelect($c);

Now, this obviouls needs to become a DQL something.

$q = Doctrine::getTable(‘Zip’)->createQuery(‘z’)
->limit(20);
$this->zip_list = $q->fetchArray();

Honestly, I have no clue right now what the parameter of the create is supposed to do – the documentation does not really explain it… and the fetchArray() returns an array – and all my getMethods fail… *hmpf* I thought there was object hydration?

Aaaha!

$user = new User();
$user->username = 'jwage';        // Object
$user['username'] = 'jwage';      // Array
$user->set('username', 'jwage');  // Function
$user->setUsername('jwage');      // Propel access
$user->save();

But why does “getId() fail then?

Maan, it took quite some reading through the docs to find out that the doctrine examples like the array representation and always use fetchArray, while for retrieveing the results as hydrated objects, you need to simply ->execute()

so:

$q = Doctrine::getTable(‘Zip’)->createQuery(‘z’)
->limit(20);
$this->zip_list = $q->execute();

Now, it looks quite good…

As far as standard methods go, I had to replace

$zip = ZipPeer::retrieveByPk($request->getParameter(‘id’))

by

$zip = Doctrine::getTable(‘Zip’)->findOneById($request->getParameter(‘id’)

using magic finders, which seems to be quite easy – but I remember John Wage say, that magic finders should not be used in final production environments… well, for the time being I’ll keep it…

Move from Propel to doctrine

Original Date: 2009-09-11

Big day today!

My plan is to dive into doctrine today by converting a small application. I have been using propel all the time and now it looks like I need to change something, because doctrine will be the path forward for symfony.

BTW, I’ll write this one in English, because it might help some people out there (and not only Germans…)

So, first stop:

The symfony and Doctrine Book

http://www.symfony-project.org/doctrine/1_2/en/

So I ran

./symfony configure:database --name=doctrine --class=sfDoctrineDatabase "mysql:host=localhost;dbname=dbname" user secret

to get the basic connection set up. Afterwards, I needed to clean some old Propel line removed from the database.yml

My Database is alread existing, so I can recreate the schema from the DB.

php symfony doctrine:build-schema

et voilà – I have a subfolder doctrine with the schema.yml

Hmm, first question now: Where did the _attribute: { phpname: .. } go?

Looking at the schema, the big difference between propel and doctrine seems to be: doctrine specifies a tablename for a parent element called like the table, but propel specifies a phpname for a parent that IS the table…

In my example I have a mysql table called “plz” but the phpname was “Zip”.

So, doctrine created a classname “Plz:” with tableName: plz – I try to change “Plz:” into “Zip:” … keep your fingers crossed

The doc talks about multiple connectiosn and attributes now, I’ll skip that for now, got no clue what the attributes mean and I only need one connection.

BUILD!! Thats what I want to do!!!

I don’t want to erase the table, so I only

php symfony doctrine:build-model

and YES, as hoped, it created a “Zip.class.php”. COOL!

add some

php symfony doctrine:build-forms
php symfony doctrine:build-filters
php symfony doctrine:build-sql

and now we should be fine, right?

Mein erster Symfony-[PATCH]

Original Date: 2009-09-11

Ich habe mich zum ersten mal durch die tiefen Innereien von symfony gewühlt, um herauszufinden, warum propel:data-dump bei mir einfach Spalten verschluckt hat bzw. bei manchen Tabellen nur einen (den letzten) Datensatz geliefert hat.

Dabei wollte ich doch voller Begeisterung nen Unit-Test mit eigenen Daten schreiben – und bleib an einem Bug hängen.

Jedenfalls konnte ich’s lösen und hoffe, der Patch finden seinen Weg in den offiziellen Release.

Patch siehe hier: http://trac.symfony-project.org/ticket/7126

Mein erster Unit Test

Original Date: 2009-09-08

Peinlich, oder??

Da entwickel ich seit Jahren so vor mich hin, aber heut hab ich zum ersten mal bewusst einen Unit Test für symfony mit lime geschrieben. Und das krasse: DAS MACHT SOGAR SPASS.

Es ist echt toll zu sehen, wie schön das ist, wenn ne Funktion das tut was sie soll bzw. kann auch echt hilfreich sein, um Fehler zu finden – wenn etwas nicht so is, wie’s sein sollte.

Albern, oder? Und doch so klar?

Aber ich vermute, ich bin nicht der einzige da draußen, der sich für einen tollen Programmierer hält, aber auch noch nie ordentlich was mit “richtigem” Testen gemacht hat… probieren – und wenn’s tut, tut’s… Denkste…

Wie dem auch sei, ich bin zufrieden. Hab erst mal nur eine Klasse getestet, aber is ja immer so: Erst das Prinzip verstehen, verbessern, und dann geht’s richtig los.

So, und mit dem neugeweonnenen Selbstvertrauen in meine Funktion für den Karo-Chat 2.0 hab ich den jetzt sogar auf das ECHTE Chatfile losgelassen. Und siehe da – es klappt!

Der neue Chat kann jetzt richtig schön AJAXen, neue Nachrichten faden ein, alte raus – herrlich…

Mal sehen, was als nächstes kommt. Vermutlich sollte ich mal eine ganze Ladung an statischen Testdaten für die Karo-Datenbank zusammenstellen, um da auchne zuverlässige basis für Tests zu haben?

Jaa, das sollte mal her.

Ach, nebenbei hab ich den von Quabla gemeldeten Bug gefixt: Bei Spielen “mit Checkpoints” aber keinen Checkpoints auf der Karte konnte man gleich ins Ziel – soll ja nich, geht jetzt auch nich mehr…

Nächste Ziele

Original Date: 2009-09-07

Was mir seit dem Wochenden bzw. dem symfony day in Köln klar geworden ist: Applikationen testen kann man auch einfacher haben, indem man sich halt mal hinsetzt und Unit/Functional tests schreibt.

Das heißt für mich: Bei meinem karopapier 2.0 werde ich jetzt mal ein paar Fälle bzw. Testdaten generieren und mir ein paar ordentliche Tests schreiben. Und wenn die in den verschiedenen Kombinationen das tun, was sie sollen, dann kann ich ja sogar mal die “KaroMAMA” (“Multiple Automatische Müll Aufräumer”) live schalten.

Die tut ja schon seit einiger Zeit, aber ich trau ihr noch nicht so richtig, um sie auf’s Produktivsystem zu lassen. Aber danach vielleicht?

Und das zweite Ziel wird dann evtl. sein, Karo2 von propel auf doctrine umzustellen. Muss ja eh irgendwann…

Ach ja, und den Ajax-Chat für Karo, der unter karo2 schon läuft, müsst ich auch noch fertig machen, so dass man auch mal was eingeben kann. Das Problem, dass mir die RegExp von “Botrix, was verstehst Du” die JSON-Daten zerschießen, werd ich mit ganz viel en- und decoding schon irgendwie hinbekommen *hoff*

Repost: Ich hab’s:

Original Date: 2009-09-07

Ich benutz das Ding Blog vielleicht einfach als mein persönliches Dokumentations-Tagebuch, was ich bei karopapier.de geändert oder bei karopapier 2.0 neues gebaut habe. Dann hab ich nachher was zum nachlesen, falls ich vergessen habe, wann und warum ich was getan hab – und evtl. interessiert’s ja dann vielleicht doch nen Karopapierler.

Und da ich ja seit meinem gestrigen Besuch beim Symfony Day in Köln erfahren habe, dass ich von Propel auf Doctrine umsteigen muss und evtl. symfony 1.3 auch schon tut, könnte ich ja auch die Dinge reinschreiben, die mir so beim Ein- und Umstieg auf Doctrine ein-/auffallen. Vielleicht hilft dass ja auch irgendwann mal einem anderen Umsteiger von Propel.

Ja, genau, das werde ich tun. Und gleich morgen fange ich an. Oder… vielleicht nächste Woche? Na, mal sehen.

Erster Eintrag

Original Date: 2009-09-06

So, gerade eben hab ich – nach dem Entschluss, vom WordPress auf den eigenen Server zu ziehen – das neue, eigene Blogsystem fertig zum laufen gebracht. Basierend auf dem sfSimpleBlog, will ich doch mal sehen, ob das nicht einfach reicht.

Meinen “alten Blog” http://xosofox.wordpress.com/ – mit sage und schreibe 2 Einträgen – hab ich somit als veraltet abgestempelt. Dafür werd ich dann halt jetzt hier mit symfony Bordmitteln rumwurschdeln.

Und ich bin echt begeistert darüber, mit

  • sfGuard
  • sfSimpleBlogPlugin
  • TinyMCE

innerhalb kürzester Zeit dieses Blog zum laufen gebraucht zu haben. Hach, symfony rulez!!!

A New Hope

Hope… I hope George Lucas and Darth Vader won’t sue me for this title…

This new hope is: My own custom wordpress installation will give mewhat I want and what I need.

I found WordPress quite fancy to use when I created xosofox.wordpress.com – but I wanted to have my stuff on my machine on my domain. So I moved my Blog from WP to symfony and the sfBlogPlugin.

Unfortunatley, the plugin was not really maintained, I had problems with spam… and I did not want to spend too much time into fixing everything.

So I decided to give WordPress another try, installing it on my own machine/server. Somtehing new to learn and use…

However, I will copy/move/recreate all old posts that I did into this new blog so they do not get lost… might confuse the date, but who cares…

So, let’s see how this works out.