Bingo!!! Perfect. Thanks Owen.
Some useful information about the options storing too. I'll have to dabble
with that and see what I can use.
Thanks for the great response.
Colin
On Sun, Dec 7, 2008 at 12:03 AM, ringmaster <[EMAIL PROTECTED]> wrote:
>
> On Dec 6, 3:41 pm, Colin <[EMAIL PROTECTED]> wrote:
> >
> > I've encountered a bit of a situation where Options::get(), as used with
> > plugins, is drawing from a cached source, and I need to force it not to.
>
> FormUI doesn't actually process the posted form data until ->out() is
> called on the object.
>
> If you want the results of the form to be stored before attempting to
> read them, you'll need to force FormUI to process the form first.
>
> So, try:
> $ui= new FormUI( strtolower( get_class( $this ) ) );
> ...create form controls...
> $form_output = $ui->get(); // Process and return the form content
> with ->get()
> echo '<div style="width: 300px; float: right; margin: 10px
> 25px;">Preview:'.$this->get_flashcode(TRUE).'</div>';
> echo $form_output;
>
> It's also worth noting that FormUI has features that allow you to save
> per-user settings in the user metadata, rather than the options table,
> so I don't know if your serializeNStoreOpts() function is required for
> what you want to do.
>
> Such a form control definition would look like this (note 'null:null' -
> > 'user:trans'):
> $ui->append( 'checkbox', 'options_trans', 'user:trans', _t('Use
> Transparent Mode'), 'optionscontrol_checkbox');
>
> And you would retrieve the stored value using:
> User::identify()->info->trans
>
> The above retrieves the current user object, and then fetches the
> value stored for the "trans" metadata stored in that object. You
> probably wouldn't need the special on_success handler at all, and all
> of the data you'd want to retrieve would be more easily available to
> you than having to pull serialized data from specially indexed options
> table rows.
>
> There's a reference for FormUI's capabilities that covers these
> details at:
> http://wiki.habariproject.org/en/FormUI
>
> Finally, it's never necessary to serialize values when calling
> Options::set(). Habari has native code to handle serialization/
> unserialization of objects. There is actually an extra field in the
> database to manage the conversion of data properly.
>
> One nice additional thing this alternative does that you might not be
> aware of (although this might not be appropriate for your plugin in
> specific, but might help others) is that it could potentially allow
> you to select a subset of users who have set a property a certain
> way. This is possible because of how the data is stored with the User
> object and not in the Options. Since each discrete chunk of data
> would essentially be a separate row in the userinfo table, keyed to a
> user, it's a pretty trivial query to get a list of users who have set
> a specific value for a specific info key. Might come in handy in the
> future.
>
> Hope that helps.
>
> Owen
>
>
>
> >
>
--
Colin Seymour
Blog: http://www.colinseymour.co.uk
Tech Stuff: http://www.lildude.co.uk
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/habari-dev
-~----------~----~----~----~------~----~------~--~---
