see whatever…

jump to menu

December 17, 2007

Django…

Filed under: Web,XSLT — see @ 11:22 pm

Noticing the the Django book is final I began reading it today (I wanted to look into Django for some time now but never really came to it). Anyway the book is quite nice, easy reading with simple examples (a bit too targeted to beginners which I guess I am not really anymore).

To try the examples I downloaded the newest Django release (0.96.1 I think), untared it and started setup.py. Funny enough this simple step failed… After looking into the source of setup.py I noticed this line: package = dirpath[len_root_dir:].lstrip('/').replace('/', '.'). Being on Windows this of course failed and I changed it to ‘\\’. I guess one should use os.path.sep in this case so I decided to add a proper bug report to the Django Trac. Again this simple idea failed as my short post was not allowed as the system thought of it as spam :(

So I gave up on this. Two simple things failing does demotivate me…

But I started reading the book anyway and tried the examples too (after the hacked install ;) ). Until Chapter 4 where I am currently it all makes sense (should do with Djangos good reputation). I am not quite sure if another templating system was needed though. I still prefer XSLT for templating as it gives me total freedom about the HTML and if the source XML is based on XHTML it is not even difficult to write or understand. A few well-placed added elements (in another namespace) do all what I want in theses cases (e.g. a menu renderer). Anyway Djangos templating and its philosophical background seem to make sense but look like JATS in the end.

As a side note, I use web.py at work for a small project at the moment. It works very well and XSLT usage was very simple to add. I guess Django is better for more complex apps but web.py is fine for simple stuff. Documentation is lacking though and I don’t think there will be any “web.pybook” soon ;)

Another side note: Another project at work uses Wicket (Java Framework) which is not too nice for/to web developers, too difficult to really control HTML and Javascript. I do not have to do the backend here so that’s ok but still web.py and also Django look much much nicer and easier (no surprise really but anyway…).

April 19, 2007

beautiful XML

Filed under: RelaxNG,XML,XSLT — see @ 8:37 pm

Completely my view too: beautiful XML. Maybe XQuery is not ugly either, but I do not know enough to judge this one.

March 3, 2007

Ajax history

Filed under: Javascript,Programming,XML,XSLT — see @ 12:10 pm

I added Ajax functionality to parts of my showcase website cdot.de namely to most of the galleries (like the photo or portrait gallery) a while ago. The galleries are build using a simple homegrown gallery XML format which is rendered with XSLT. Adding the Ajax functionality was not very difficult, I use the fine JQuery library for that. (I still have to migrate my own scripts of the past years to use JQuery which should make most of them obsolete but also easier to use and also much shorter ;) .

Adding a working browser history to it was not as easy as expected though. I simply did not understand how to bring the available JQuery history plugins to work. The whole matter is not easy but not too difficult and to better understand what is going on I decided to build my own history (but still using JQuery of course).

First try was to use the URL hash method which does work perfectly on Firefox, but not on IE (for reasons query Google for “ajax history”, several interesting sites describe the problems much better than I can). The “hack” using dynamic built iframes does work xbrowser (at least Firefox and IE, Safari is a different beast [as far as I understand no working possibility yet at all], I did not test Opera yet) so I changed the implementation to use iframes instead.

It does work now, only missing bit is bookmarking which would be possible if I added the URL hash in addition to the iframe hacking. I may add it in the future, it is not a very important issue for the use case on the galleries though as they are too simple to actually need bookmarking on single works in one gallery (there is always an overview). More applicationary sites would need that though.

BTW, during testing I found a bug (at least I think it is one) in JQuery which was very hard to track down. Most people probably won’t be affected by it but for people using REST it might be quite relevant.

Basically IE below version 7 seems to use POST for all Ajax requests if initialized with the wrong ActiveX control. The servlet I wrote for my galleries implements GET only so it resulted in a “Method not implemented” HTTP error which I never saw before (as most servlets use the same implementation for GET and POST, which is even recommended by most books but maybe it is not too intelligent anymore) and did not know where it may came from. Tracking it down was not easy as I normally use all the fine Firefox plugins like Firebug or LiveHTTPheaders which simple are of no use debugging IE ;)
But I came accross Fiddler some time ago which actually tracks all HTTP traffic on a PC. So after checking that I saw that IE used POST for its Ajax requests which of course failed on a servlet implementing GET only…

May 17, 2006

DSL

Filed under: XML,XSLT — see @ 8:55 pm

I guess I use XML as a domain specific language in most cases. Processing with XSLT simply is very convinient. The topic came to my attention while reading an article about DSL (processed by Java) in german Java magazine.
Not specific to DSL but I wonder where the advantages of using Java generally are, I speculate hardly anyone will be using Java in 5 years anymore? All seems to be complicated as Java is still growing from a huge thing to a giant mass…

March 13, 2006

XSLT simple pipelining

Filed under: Python,XSLT — see @ 10:21 pm

Another migration project at work came up which mainly is a migration of XML files from one format to another. Of course best fit for XSLT and maybe the best: free whatever technology to use. I wanted to try XSLT 2.0 for a while but still sticked to 1.0 for this one due to Pyana’s (Python Xalan bridge) very easy integration of custom XSLT extension functions written in Python. String handling is rather nasty in XSLT 1.0 (I think much better in 2.0 but I guess still not as easy as Python’s) so writing all not real XML transformation work but actual string conversion in Python.

And this time (contrary to the first big complex migration) I did split the process in lots of small steps in a simple XSLT pipeline. Eventually I may add a schema validation (RelaxNG) to it but that may even better fit into a Selenium based test as I built this functionality with a simple webapp anyway.
Currently 7 steps of quite small and therefor quite simple to handle units makes this into quite a nice work actually. Not as unwieldy and errorprone as one big, massive and quite mazelike monolith XSLT stylesheet…
I don’t know really why I like XSLT so much being quite different (sometimes mindboggling, very verbose as XML programming can be etc) to my other favourite language which is Python. That I like for its sheer “niceness” meaning clean design both in the language itself, the libs and even the simple “niceness” of the source code (maybe I like it because I am basically a designer). So I would assume I would like one or the other and not both. But they just fit together really well, at least for XML processing.

February 22, 2006

table to table

Filed under: Python,XML,XSLT — see @ 9:45 pm

While trying out Selenium and it’s just refreshed Selenium IDE I thought writing the tests in HTML or even the IDE is not the easiest when having large lists of tests.
So I was looking for the easiest way to write a simple HTML table and assumed it would be someting like Excel (or in my case OpenOfficeCalc) which have autofilter etc. and even people with no programming abilities should be able to fill these…
Problem is how to convert a spreadsheet table to a HTML table? HTML export from OpenOffice is horrible so I thought CSV. Problem is then that Python’s CSV module is not unicode enabled and therefore pretty useless… So I guess whether I write an XSLT to convert OpenOffice XML (quite verbose and in this case I am interested in about 5% of the XML…) to HTML or write a custom HTML filter in Python to extract the stuff I need from OpenOffice HTML export.

Both seem not too complicated but not the simplest to do so I rather wait till I really need it. Writing HTML tables is tedious but ok for short ones. I just thought there should even be easier ways to convert this stuff with my chosen tools Python or XSLT (which I am using for most stuff nowadays).
I noticed conversion of formats (not just these here) became almost my main area of work (at work but also at home)…

October 12, 2005

plans…

Filed under: cssutils,XSLT — see @ 6:08 pm

I wanted to continue working on cssutils but have more important stuff to do first. There are a few smaller projects (mostly websites) I need to do and plan to add multilangual support (english and german at least) to my own site as one of the small projects would actually be a website in english, german and japanese anyway so nice to do that at the same time.

Also for some time now I was planning to automate changes to this site. Currently (and somewhat embarrisingly) I write all pages by hand without even SSI or other helpful stuff (which I use heavily on cdot.de which is already partly based on XML/XSLT). I would be tempted to use something like TurboGears but would like to be independent of any server side technology. My current ISP does not have Python support anyway. So I guess I build a basic XSLT publishing “framework” (nasty word). This way I could add a simple XML CMS later which I wanted to do for some time now anyway.

Problem with most CMS systems seems to be that they are just huge with hundreds of functions. I was looking for a simple CMS (almost something like this blog) but found nothing really interesting. An AJAX based CMS which holds all content in XML (could internally be XML in a database, which still is a bit overkill without real XMLDBs which support at least XPath) and editing capabilities for basic stuff like structured text, tables and maybe images would be sufficient. Most CMS systems I saw so far (open source but also expensive ones) are just quite slow and just not usable enough for my taste. A CMS which only needs to support a small range of browsers (IE6, Firefox, Safari and maybe Opera 8) for its editing could then use all advanced new possibilites that e.g. AJAX presents without the need to use still somewhat and problematic stuff like Applets or the like.

Well, I hope I don’t have only plans but no time for their realization…

A new version of the cssutils parser definitely needs to be done too as I realized the current one is somewhat limited what it accepts…

July 12, 2005

pyXSLdoc bugfix release

Filed under: pyxsldoc,XSLT — see @ 11:24 pm

while using my own tool after almost a year again I noticed a few small bugs. Fixed them and also set the --verbose option to always on as I had problems myself even remembering it… I also noticed that messages might be better but I’ll probably won’t bother redoing the thing as it works quite well (at least for my taste). I might redo some parts if I ever add XSLT 2.0 support to it but I am still trying to finish Michael Kays book about 2.0 which is absolutely great in any sense of the word (ok, lets say massive…). also I cannot use 2.0 during work currently as we have to stick to Xalan (implemening only 1.0) for a while. I was tempted during a migration of complex XML files to a new format but got perfectly maybe even better through it using Pyanas simple Python extension possibilities.

June 12, 2005

XSL template patterns

Filed under: XML,XSLT — see @ 12:57 pm

I only realized a few days ago that pattern matches of xsl:template are not XPath patterns at all.

While reading the new edition of Michael Kay’s great (again) book about XSLT – this time 2.0 – it paid off to read through all introducing chapters which contents I should have known anyway. I knew before that match patterns cannot contain variable references (at least in XSLT 1.0) which I found odd (and which has changed in XSLT 2.0) but I always thought I could use any axis in patterns. I think I tried to match something on the preceding-sibling:: axis some time ago which of course did not work at that time but thought I made a mistake somewhere else. Now I realize that this is not even supposed to work…
After 3 years working with XSLT the problem never really have made me stumbled (apart from the 1 or 2 occations where I found another solution) so it seems not a big issue but at least worth knowing.

I guess that’s the finer stuff to really let you write stylesheets which do work and let you realize why they work (or don’t)…
A pity XSLT 2.0 is so much bigger than 1.0 that knowing everything is so much difficult…

Powered by WordPress