[Xerte] Re: Can't get export to work

[Henk Klopping]

David Goodwin wrote:

> My 'vim' seems to cope ok with the above and doesn't barf. Perhaps it's a .vimrc issue?

I was tongue-in-cheek referring to the problems with whitespace on the 
database.php file. There is no problem, you're right, let's not create one.

> Can you not do (on linux)
> 
> * download .zip
> * unzip whatever.zip in /var/www, chmod -R 777 xertetoolkits
> * point browser at http://localhost/xertetoolkits

Of course, and that is exactly what I have been doing for the last week 
or so.

> * perform XAMMP install - which will work if your MySQL allows you to do 'mysql -u root' with no password on the command line.

This is NOT what I did, as I _do_ have a password on my MySQL root 
account. I do the 'full install' stuff, but in itself it is pretty 
self-explanatory - for folks like us, at least.

But it may be more difficult for teachers. Hence my suggestiond to turn 
the package into an RPM and put it in some repository. Then, whenever a 
newer version appears, we distribute the (tested...) RPM to the 
repository, and subsequently yum (or the debian updater or what-have-you 
installer) will erompt Jane Enduser who simply can click 'update' to get 
the updates installed. As you can include scripts in the RPM to run 
before and/or after the installation, these could check what type of 
installation is required. Could even do the migration stuff (if need be) 
like converting databases etc.

> I personally just point my web server at 'trunk' or 'branches/1.8' depending on what I'm doing.

I haven't checked the svn repository yet, as that typically contains the 
aforementioned 'bleeding edge' bugfilled latest and greatest stuff which 
I typically don't want to run to create LO's - and that is where my 
focus lies right now.

>> Stuff that is not so trivial [.. yaps about version / release management deleted ..]

> Yes, I'm aware. The code base makes it difficult to perform any tests 
 > apart from manual ones and there's a lot of duplicated code within
 > it... and then Javascript and Flash on top which makes it more of a
 > pain.

Well, we could write some test procedures, simple scripts that test for 
stuff we once encountered already, so we won't have to reinvent our 
debugging wheels. E.g. if we know that having zeroes or whitespace at 
the end of files may make the system barf, it's easy to build a check 
for it an have it run on the code before releasing it. You could have a 
scenario which (yes, alas) needs to be executed manually, but at least 
it would eliminate everything we already checked for so we can focus on 
new bugs etc.


> Perhaps I'll sort out selenium + jenkins on it soon, I'm not sure if 

Never heard of it, just googled it. Ah, yes, but then you'd replace your 
worries w/regard to Flash with worries w/regard to Java. Never liked 
that language much, pardon my bias.

I can find the time though

Sounds familiar. I'll focus on what I _CAN_ contribute.

BTW: I like the look-and-feel of XOL, but can't help thinking "this 
could be done with HTML5 too and that would not require all these flashy 
nasty tools". Ah, yes, like you: if I only had time, if I only had time..

Suuuomikkie vinnouuven,
-- 
    Henk Kloepping                         Voice  : +31 598 42 31 31
    European Fortean Foundation            e-mail : henk at fortean.org

    To join ISOC.NL: http://www.isoc.nl