Quick search:

Property options for primitive types

2006-10-18 20:25:26
For this project I wanted an easy way to define a property having just a few options. The "official" way to do this, IIRC, was defining a subclass of PntObject containing the values and use this as a type.

I was looking for something easier that this. I reckoned just defining a property of a primitive type (such as string) and adding a getPropertynameOptions() method returning an array of options (such as plain strings) should do the trick. When this did not work, I implemented this feature into peanuts.

You can find my patch here, its only a couple of lines: http://katherina.student.utwente.nl/~matthijs/PrimitiveOptions.diff

Note that I've not extensively tested this yet (haven't really tested it at all for other types than string, though it should just work). Also, I'm not really sure if there any other places this should require updating apart from the EditDetailsPage. The search pages, perhaps?
2006-10-19 23:17:34

I used the get<Propertyname>Options() method only a month ago in an application, and it worked just fine!

//in initPropertyDescriptors
$prop =& $this->addFieldProp('mapBrNs', 'string', false, null, null, 0, 1);

function getMapBrNsOptions() {
    return array('N', 'S');

The user interface produces a dropdown list with '', 'N' and 'S' so the user can select wheather the coordinates he just entered are Noth or south breadth.

I really see no reason to push this into the framework.

BTW, yeah, it would be great to have the searchpage understand about options and offer a list of options if the user selects a property that has options in the advanced search. But did you see the amount of HTML it is already producing for the advanced search? Maybe a place for AJAX?


2006-10-19 23:36:36
That's weird...

This is what I have:
// in initPropertyDescriptors
$this->addFieldProp('status', 'string')->setMinLength(1);

function getStatusOptions() {
         return array('Ingeschreven', 'Betaald', 'Afgezegd', 'Reservelijst');

Which is basically what you just mentioned. Only, I needed to patch the framework to make this work. Also, when creating this patch, I did not find any support for this kind of construction. Are you sure this worked for you? Could you look at my patch and perhaps tell me what I'm missing here?
2006-10-20 00:45:01
Oops, it looks like this is one of those changes i still have in store to be released with next version of phpPeanuts. These small changes are included, listed and from then on i tend to take them for granted until i get to assembling the final changes list for a new release ;-). Sorry!

I could post my version of this getFormWidget method, but yours looks just fine. Mine also has a change to support boolean properties that are not compulsory: checkboxes can not make a difference between false and null, so the UI will use a dropdown list with true, false and en empty string. But i don't think it will work properly without some of the other changes, so it will have to wait until next release.

2006-10-20 01:24:04

Well. since the behaviour we implemented is pretty much the same, I'll have no trouble updating to your version once it gets released. So, no need to post your code.
2006-10-20 10:10:06
After a good night sleep it seems like a good idea for me to take some time next week to get this version out as a beta release, so that you (and others) can work with near-newest code. It's stable enough, it's already in production in several commercial sites. It's mostly a matter of packaging, documenting to get it released. I'll keep you informed.
Add a Reply
Loading form, please wait
The website will not send you an e-mail when a reply is added to this topic

Back to Topics List