I’m going to post something longer about the cool new things that will be available soon through Five in Zope 3 – but MrTopF has quite a good summary here. More later…
Monthly Archive for April, 2006
A much better day yesterday, with a lot of progress on the UberSelection Widget. Also the whole javascript thing looks like it is panning out OK – we are having some real discussions now, and I am a lot more optimistic that we’ll have a good solution to the many issues in integrating a lot of javascript into something like Plone. Hopefully I’ll have a good report on that tomorrow.
The Selection Widget has mutated into a project to produce a new query architecture for Plone, to support cross-datasource querying in a standard manner. It’s looking pretty good, even though it’s only roughly sketched out, and it could be a useful addition to the core. Alec has some ideas for a more advanced query syntax, supporting various sorts of conjunction across terms, so I’m going to look into how we can generate parse trees useful for real querying, as well as rendering queries as ZCatalog or LDAP queries, as it does now.
I think I’ll probably steal some of the excellent query stuff from Divmod’s Axiom which has a very nice implementation already. Generating parse trees from that should be straightforward, and I think it should be possible to generate ZCatalog queries too, although the existing ZCatalog implementation can be a bit weird.
One of the issues is how to collapse queries that can’t be rendered precisely – a tolerant implementation that does it’s best is probably the most useful.
I spent some time last night with Danny too, looking at refactoring the Sharing page, one of the use cases for mass selection. We iterated over the designs a few times, and managed to make it even simpler than his already very good design. Getting that prototyped is another task for today. I’ve got a very simple implementation of how the widget might work, using the LiveGrid widget from Rico, and we’ll be working on that today to show end-to-end querying of the catalog and of members, integrated with a mockup of the Sharing page.
An interesting article on non-functional testing as part of a test chain.
Automated testing is absolutely core to successful agile deployments, because it gives you the confidence to make changes in the knowledge that breakage will be detected. It’s not 100% perfect of course, since there are some things that can only be tested through the UI, but the more test coverage you have the better it gets. Building an automated load and performance testing farm is a great idea for an application like the one in the article.
Isotoma are now members of the Agile Alliance! We are committed to agile software development and the benefits it brings, and I am hoping our membership will make us more effective at delivering valuable and successful software.
On Norwegian cuisine, fire alarms and maybe a little on AJAX.
I am at the Plone Archipelago Sprint where a lot of work is being done for Plone 3.0, which is the next-release-but-one. I am here ostensibly to help with some AJAX framework decisions, however there doesn’t seem to have been much in the way of actual decision-making, although there has been a lot of heated discussion. I’ve tried to contribute what I can, but it’s very difficult with such an established project which already has a lot of informal structure, especially when some people have already written code. I’m going to keep my head down and try and write some useful code and see what pans out.
The venue is an island called Østre Bolærne. It used to be a military training camp, and we’re staying in the old officers quarters, and working in what I guess was a sort of common room complex for the officers. The facilities are good except we have no internet!. We have Internet here though, on the other part of the island, where the refectory is. The lack of Internet has been a real pain, and has slowed things down quite a bit. We’ve also had a couple of fire alarms, caused by people leaving their bathroom door open. The designers of the quarters thoughtfully put a smoke detector right outside the bathrooms, and didn’t fit an extractor, so any steam at all sets off the alarm. Nice to know the Norwegian military is as competent as everyone else’s.
The food is “interesting”, which apparently is a feature of Norwegian cuisine. Last night we had sweet and sour pasta, which is certainly a first for me at least. Breakfast is continental, with some fried food for the anglo saxons, lunch is like breakfast again, except without the fryup. Dinner is an increasingly random concoction. Some of the locals fear we will be served fish balls or perhaps, if we are very unlucky, fish pudding at some point during our stay. Be prepared for a full report if we do get one of these delicacies.
The move to Zope 3 has been fascinating, and personally my interest really is more in Zope 3 than Javascript. Zope 3 introduces a lot of concepts that I have previously only used in Twisted, and a bunch of interesting new ones, such as Views, Services and Utilities. A lot of these things are available in Zope 2 using “Five” an integration layer. All new code should be done in the new style, which is great – it’s a decent deployment target with support for useful abstractions rather than the horrendous hack that was Zope 2. I’m looking forward to really getting to grips with it over the next few days, and learning what I can.
Oxfam has recently deployed Plone. They, their developers and the Plone Foundation have put together a one day conference on leveraging Plone for NGOs. Some interesting speakers across a range of topics. Definitely looks worth checking out if you can be in Oxford on 25th May.
While Doug is off in Norway on the Plone Archipelago Sprint working on Plone 3 (and therefore Zope 3) I thought it was probably time that I at least started to get to grips with Five – implementing Zope 3 principles within a Zope 2 environment.
For any non-trivial program you need to locate bits of data and code that aren’t . In a “normal” program it’s up to you to work out how to do this. Short programs generally use module level globals to find class definitions (i.e. import statements) and something homegrown for locating data – it might be a handle to a database, or some config file that specifies a directory containing some files or whatever. So far so obvious.
In a framework, however, it all gets far more complex. Your execution environment is expected to be much larger, and there may be many contributors of components. You may wish to switch components without editing code, ideally even at runtime.
To do this you need a mechanism for locating “things”. This is “context”, or at least the part of it generally addressed outside the normal language features. Context is probably the real distinction between a framework and a library (something that has been controversial). When you use libraries you provide your own context – when you use a framework, the framework provides the context.
As an example, imagine you want to provide a form to create a new user for your application. This seemingly simple operation is the kind of thing that gives frameworks a bad name — but this is one of those areas where there is real complexity in the problem space and all abstractions just serve to make the problem less distinct and the solution more baroque.
Just to register a user there are a huge number of knobs any self-respecting framework wants to provide independently of code that uses it:
- What does the form look like?
- What fields does it contain?
- What are the validation rules for the fields?
- Where are the users stored?
- What properties does the user have?
- What happens once you submit the form?
Those who complain about frameworks, I suspect, are people who see all of this and just groan at the unnecessary amount of code that is seemingly unrelated to anything to do with adding a user. Almost all the code involved in solving this generically is logistical stuff – just locating all the things and orchestrating them together is a significant undertaking. Superficially, good solutions to these points are more complicated than the overall problem itself.
Each of the questions above is solved within frameworks using some sort of context. How well components developed separately are capable of orchestration is a key part of a framework’s success or failure.
The benefit in providing generic solutions is a “Total Cost of Ownership” one — over the lifetime of an application, you really do want to vary these things and to be able to do it independently of the codebase, and therefore with less testing, is a massive advantage. We have a number of real-life applications that have been running for many years where we have, for example, switched from ZODB to OpenLDAP to MySQL as a user source without (in theory) needing to change any code.
It’s a bit like the old saw “Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified bug-ridden slow implementation of half of Common Lisp.” – any large program that aspires to long-term maintainability will eventually contain an ad-hoc, informally specified bug-ridden slow implementation of a framework.
A good take on AJAX interface complexity from Sean McGrath, a man whose output I have respected for some time. He is absolutely right – good design is as much about what you leave out as what you put in.
Interface complexity on the microwave is, frankly, pointless toys. It microwaves. That’s it. Search engines are a bit different in some senses – there are additional features in there that might be useful, or vital, if your requirements suit them. Our website search uses google, and we can only do this because of extra features in google.
A key part of UI design hinges on an important distinction in User Interfaces – ease of use versus easy of learning. Web applications, even more than normal desktop apps, have to cater for a world where 99% of their audience will read no instructions. Many of them don’t even know what your application really does. I do this myself – you assess whether you want to use something not by reading the (often lying) website, you just get clicking.
User Interfaces on the web have to be designed primarily for the clueless (and I mean that in a nice way). Everything non-core should be placed somewhere on the interface where it’s clear to advanced users where to get it, and make everything else really really tolerant of user error. This is difficult to do, and requires quite some finesse.
If you want to authenticate as a Plone portal user while running in debug mode you need to do the following:
You need to replace ‘portal’ with the ID of your portal object and replace ‘andy’ with the name of your user, and lo! you will be authenticated.
If you want the work that you’re doing in the debugger to stick remember to commit your transaction:
Recent comments