Field values!

Major perceptual breakthrough yesterday: I've got the fields populating from the database, and it's just a clean form.setValues() call. Yay infrastructure work. :)

So I'm adding validation right now, then it's a very similar thing on the next page (general preferences). Then, I can finally add the rss tools!

waste of time

I hate it when I spend a lot of time chasing down a bug that I don't end up fixing. Complete waste of time. I spent most of the morning trying to find the apache dbi bug and trying to figure out why IE's caching policies were screwing up my page. Blah.

Server-side pagination

Also, it's worth noting that while ItemFileReadStore implements client-side paging (i.e. it won't create controls for the data until you want to see them, see the pageSize attribute), it has no effect at all on server-side paging. That means that if you have 50,000 records and you only want to load 100 at a time, you have to implement a new store that passes like start and end parameters to the server. This can be done, and might benefit us here if we have really large record sets. We'll have to see.

See here for some ideas.

Got some stuff done!

So, yesterday I managed to get a good bit done. I've got some database-backed dojo widgets, which is something. Aaron's going to show me how to fix my db pooling issues this morning, which should help the reliability of the ajax calls. I'm still not positive if it's doing exactly what I want, that is loading those fields on-demand (I'm especially concerned about the default dealer list - probably no reason to be, but I would like to know how to avoid loading db stuff if possible).

If I have to, I'll hack in an ajax call that sets the store. In fact, that might be the first thing I work on this morning. First, test to make sure it's getting loaded before the click. If it is, register a click handler that does an XHR call that'll set the store on return. That seems like the best approach.

Anywho, after that it's just a matter of plugging in something similar for the dealers - that can probably be a seperate script, cause there's other places that might benefit from being able to call it. But I won't break it out until I actually run across such a case, cause premature generalization is evil.

Then, we figure out how saving works - it should be as simple as pulling form.get_values and sending the data to the server with an XHR. We'll have a generic POST save handler, and what gets saved will depend on parameters passed (general: {json}, user_info: {json}).

Let's get some stuff done today

Over the weekend I got XP working on my virtual machine, so that's all set to go (no more screwing with the desktop!). So I'm good to go to work on my page. I need to duplicate the functionality of the old preferences page, and then add the new RSS stuff. I've got most of the fields specified, so it's just a matter of working out how the AJAX calls are going to happen.

New macbook!

So I spent the end of yesterday and the beginning of today screwing with my new macbook. I've got it mostly set up the way I want now, except that I don't have an XP install working on it yet. (I did make a nice little Mac OS .app that runs a perl script that connects to windows dev via rdesktop, but that machine has too many connections at the moment, so that's not usable). So, when I get home tonight I'll get XP up and running on my Q vm, and that'll make a good platform from which to test Pro. I think I'll still probably use rdesktop most of the time, but it's often not available and I can't be dependant on it. Also, X is running invisibly and giving me the illusion of nativity for things like rdesktop, and that's super duper.

As far as actually getting any programming done today... I'm gonna do lunch with Aaron in about 15 minutes, I'm thinkin', so it won't be until after lunch. I need an IE to test against, so I'll probably have to (ugh) use the desktop. Oh well. Gotta get some work done today.

It'll be further updating the form and adding more tabs, then figuring out how to make the ajax calls that save the various sections.

oh my god.

So, I figured out today you can shove coderefs right into your object's symbol table at compile time. Like a macro, kinda. You can use this to generate accessor methods, etc.

Did I mention I don't know perl? This kind of hackery seems to be the norm for this silly language...

Gung-ho!

Stayed up too late last night, but here I am, bright eyed and bushy-tailed. I think I will specify the list of things to get, and only send the appropriate data (for wire-size as well as security). I can have the list in one spot, and specify either "simple" (undef) or a handler (for complex fields like address). The handler will be a two-tuple, with one method for getting and another for setting the value.

where I got today

Today has been confusing, and large parts of it felt unproductive. I think I understand the code I'm modifying a lot better though. Anyways, I've started the preliminary work on generating a JSON object to pass to the dojo-page. Note to self: When you update xmldoom object definitions, you may have to restart apache for the changes to stick.

Preliminary thoughts: We may want to specify which fields we want to pass instead of passing everything in _get_attributes. The reason for this being: we don't want the page to be able to modify, say, the session_id. So we may need to be explicit.

Nothing is Xmldoom'd

It's really kinda depressing how very little has been Xmldoom'd. I've made some progress converting the user object, but there's so much extra weird stuff going on all over the place that it's hard to know what will work and what will break. I guess you just keep hacking and fixing.

Anyways, I've got rdesktop now, so I can test Pro from my laptop instead of having to boot up the slow retarded XP box. So that's good. Also, I've...thought a lot more about what user_preferences.pcgi is doing. It's all slowly becoming clear, and I think I have a migration plan, but it's too lengthy to put here. It's in a text file on my laptop.

Note to self...

Never do port upgrade all. All is a good way to get MacPorts to install EVERY PORT. Which is not what you want at all. Unless it is.

But probably, you want...

sudo port sync
sudo port selfupdate
sudo port upgrade outdated

New Thoughts

Okay, so after talking to David and Aaron about JSON/Xmldoom, the idea is that we set up AJAX scripts to load and save the various parts of the user preferences, with JSON as a transport. This page is simple enough that they can all be in one script, I think, with like a load/save function for each tab.

Also, I've started using Blogger to keep track of these to-do list things, although I think I'm still going to compose them in WriteRoom, cause of the cool Matrix-feel. I wonder if there's a Blogger plugin?

JSON, hmm?

Well, I thought about it tonight, and I've decided that one intriguing way to solve this problem would be to write a JSON adapter for Xmldoom objects (if there isn't one already). Then I could Xmldoom-ize the data being talked about in user_preferences.pcgi, serialize it as JSON, pass it to the dojo-page to parse, modify that JSON object, and pass it back to be saved. GET on user_preferences.pcgi would render HTML by default, but if you pass it &json, it will just give you the JSON for the objects being talked about. This will not only make for nicer code in this one spot, it's a good model for modifying existing Xmldoom objects.

If we don't want that whole thing, we could do a comprimise - and just do the JSON handling manually. That wouldn't be too bad, and it's certainly a better structure than what we've got. I like this model...

one. giant. blob. of perl.

Well. Here's the thing. If I make a Dojo UI for the RSS preferences, I really need to make it a Dojo UI for the whole thing, and rewrite user_preferences.pcgi. It's like, there's two options. Either

1. leave it ugly and stupid and just hack in my additions or
   
2. clean it up and bring it into the New Way.
   

Now, I'm all for doing number 2 (lol). But it will take longer and it's more or less a waste of time, and it will probably break something. We could instead do some custom AJAX-y stuff (easy enough) and make everyone just as happy.

It might still make some sense to clean up the perl. Maybe that's just the first thing I'll do. Clean up the retarded perl.

This file is getting kinda long...

I should seriously consider making some sort of simple blogging tool for this, otherwise the file may get long and unmanageable. Or, rather than making one, finding one. Making one would take too long. At any rate, today I'm making a dojo UI for the RSS stuff. *hesitant laugh*

arg!

So, David says that Xmldoom is indeed broken in this respect and that he'll work on fixing it Monday. Till then, I'll content myself with the ugly syntax.

That went surprisingly quickly

So, I got everything on this list done except for one minor hitch: the pretty syntax for adding subscriptions isn't working, and you seem to have to manually create and save a Subscription object. That's silly, so I'm going to spend some time trying to track that down and make the sane-looking call work.

let's get busy...

So, big meeting this morning. Most of it is stuff I can't do anything about, other than trying to take some of the work off of Dave and John where that's possible (exports is probably something I can help with, so I'll get going on that as soon as I get done with RSS). So, for RSS, what are we doing?

• Change all the new Objects() to Objects->new() to make David happy
• Find that goddamn debugging statement in Xmldoom that prints out count()
• Find out why recreate_database() isn't working so I don't have to drop cs_replication
• Fix the unit tests and make sure they pass.
• Give users an ID property so I can use that in the tests...
  

That really should take most of the day. I'll need to talk to David about the unit tests, probably, but I'll try to figure them out on my own first.

What's up today?

What's up today?

I've finished writing CSS::RSS.pm for the most part, and the database objects are all implemented. They do need testing, though. The next thing to do, I suppose, is to write comprehensive unit tests for them. Once they're thoroughly tested and I'm sure that they work, I need to get together with Aaron and have him point me in the correct direction about Dojo. Just an idea of what they're using it for, so I can do things the same way they're doing them rather than being inconsistent.

So, plan for today is:

• Write tests for RSS.pm and Xmldoom objects -- CS3/RSS/test.pl
• Figure out what Aaron's been doing with Dojo
• Write a plan for the Pro stuff.
• Two things:
  • Subscription editing
  • Feed Viewing