Metadata in Entry.pm

[purplecat]

I'm trying to integrate setting a post as a sticky, and multiple stickies into the new entry form.

I've got the form set up to return whether the post should be a sticky and if so which sticky as a value for "sticky_select",

So in DW::Controller::Entry.pm in the function _decode, the value I want comes in as $post->{sticky_select}

That bit works fine.

But I then want to record the value in $req->{props} in order that it can be passed on to _do_post sensibly and the post set as the correct sticky at that point.

If I attempt to put in


$props->{sticky_select} = $post->{sticky_select};


or


$props->{"sticky_select"} = $post->{sticky_select};


or similar I get the error message

Client error: Unknown metadata: sticky_select

So my question is "How do I define metadata?" for use in this object.

Comments

[purplecat]

A ha! looks like the answer may lie in dw/bin/upgrading/proplists.dat in the logproplist section...

[mark]

Yup, this is it. Properties are defined in that file.

In this particular case, though, you probably don't want it to be a property on the entry. Right now, the sticky_select option is a userprop -- since the user has sticky entries. If you want the update page to toggle sticky entries, you probably want to have the post method set the userprop appropriately.

Do you have a bug reference for this so I can take a peek?

[purplecat]

The Bug is 2152. There's a patch already up which works through Organise->Account Settings->Display but fu asked if I could make it work through the new post page.

So there are also a couple of screenshots up there now for how that might look like (though I was using radio buttons for them and I now think a drop down menu might be better since the option needs to be disabled if the user is posting to a community).

[fu]

This is going to be a bit -- what I was thinking was to still use the userprop (because we have a limited number of entries, and we'll want to be able to grab the list of all entries which are sticky entries on page load), instead of making it a property of the entry (because that would mean that we'd have to search through all the entries to find out which entries are sticky).

Alos, making it a userprop would make it easy to enforce / lookup if they've hit their limit of sticky entries.

Does that make sense?

[purplecat]

Yes, I agree, it definitely is a property of the user not the entry. In fact there already is a user property called sticky (which is an ordered list of the user's stickies in the current state of the implementation and just the number of the sticky the central code base).

Possibly my problem is that I want to process this form value in _do_post not in _decode and the current structure of the two methods means the simplest way to do that seems to be to store the value in the props hash - however props obviously has some connection with the properties.

I _think_ I could still use the sticky userprop for this (since the value never actually gets written to the database, just stored in the hash) but that seems like really bad practice to put a value in the hash which is of a different type (i.e. a number rather than a list of numbers) to the actual value stored in the database.

I suppose the ideal solution is actually _not_ to put the value in props at all, but to process that particular value of the form input separately... hmm... I'd need to look at the code and at the moment that isn't really going to be practical for a few days.

[fu]

I see what you mean to do now. When you get time, look into putting it into $req->{sticky_post} instead of $props->{sticky_post}.

$req == form request
$props == this entry's properties