purplecat (
purplecat) wrote in
dw_dev_training2012-08-11 05:55 pm
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
![[site community profile]](https://www.dreamwidth.org/img/comm_staff.png)
Entry tags:
Metadata in Entry.pm
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
or
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.
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.
no subject
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.
no subject
$req == form request
$props == this entry's properties