I am +1 on the addition of a static template. This could make a number  
of tasks less tedious in the future. There is always someone who wants  
to display static content via a dynamically generated system.

Chris

On Jan 12, 2009, at 9:41 AM, ringmaster wrote:

>
> On Jan 12, 8:59 am, "Scott Merrill" <[email protected]> wrote:
> ...
>>
>> $post->info->{$comment->email} = 'SUBSCRIBE';
>> $post->info->update(); // this is what commits your changes to the DB
>
> And all of that code looks fine.
>
> What I would suggest, though, is what Arthus was talking about in his
> prior message.  Habari has a commentinfo table that allows you to
> store metadata with each comment, just like you can with each post.
> So while you're subscribing to a post, your comment is actually
> attached to the post, and the comment has info on it saying that
> you're subscribed.  This is better for a couple of reasons.
>
> The first reason has to do with a limitation of postinfo.  As you
> noticed, postinfo keys (like commentinfo keys) are unique.  So you
> can't have multiple "subscribed" values unless they're stored in an
> array in a single key.
>
> You can do this:
> $post->info->subscribed = array('[email protected]',
> '[email protected]');
>
> But then you can't easily query for posts to which [email protected]
> is subscribed because the array value is serialized into the table.
>
> You've also noticed that using the email address as the key works, but
> it's messy, since you can't easily query for all of the subscribers to
> a single post.
>
> If you instead store subscription status in commentinfo, things become
> a bit easier.
>
> To enable a subscription via comment:
> $comment->info->subscribed = true;
>
> And then when you want a list of users who are subscribed to a post
> (for when a new comment is added):
> $cc = array();
> foreach($post->comments as $comment) {
>  if($comment->info->subscribed) {
>    $cc[] = $comment;
>  }
> }
>
> And you're mostly done.  To unsubscribe, you'd need to unset (or set
> to false) the subscribed value for every comment belonging to a
> commenter with a specific email address on a specific post.
>
> This might work, and if not, it's close:
> $comments = Comments::get(array('email'=>$unsub_email, 'post_id'=>
> $post_id));
> foreach($comments as $comment) {
>  unset($comment->info->subscribed);
>  $comment->info->commit();
> }
>
> Some of this could be made more efficient via direct queries, but the
> API makes it easy.  And we could expand on this API in the future, for
> example, to make it easy to find posts where the comments have a
> specific value for a commentinfo key.  (In other words, a Posts::get()
> that returns posts to which an email address has subscribed.)
>
>>> 3. There is no way to unsubscribe. Anyone have suggestions for
>>> implementing this?
>>
>> There is a way, but it's not very classy. Essentially, you need to
>> create an empty post, and then have a handler to generate your  
>> content
>> when that post is requested. It's not entirely intuitive.
>
> I'm not sure if you're talking about UI or logic here, but I'll take
> on logic for a moment.
>
> It's possible to grab the rewrite rule for posts and add a thing to
> the end so that you can take a couple of arguments.
> This is the default rule regex:
> %^(?P<slug>[^/]+)(?:/page/(?P<page>\d+))?/?$%i
>
> And you'd create a new rule that uses parts of it to create this:
> %^(?P<slug>[^/]+)/unsubscribe/(?P<emailhash>[\da-f]+)/?$%i
>
> The new rule responds to URLs that look like this:
> /my-post-slug/unsubscribe/38f1ac6
>
> You can dispatch URLs that match the new rule to a handler in your
> plugin.  If the hash is included (it's optional), code would search
> for an email in the comments that matched the hash.  If it doesn't
> find a matching address, it displays an error.  If it does find a
> matching address, it displays a confirmation form.  Upon confirming
> that the user really wanted to unsubscribe, unsubscribe that address.
> This format of URL (with the hash) would be useful for including in
> the sent emails, so that users could two-click their way to
> unsubscription.
>
> If no hash accompanies the URL, the plugin could instead display a
> template with a form that allowed the user to enter their email
> address to unsubscribe, and then do the search that way.  This format
> would be useful for adding a link near the comment form to
> unsubscribe.
>
> I think the actual display of the form is what skippy's talking
> about.  What he's saying (it took me a minute to figure out) is that
> you can't easily create a template that fits into a site layout to
> display only static content.  Here's what he proposes...
>
> When you handle the request, you create a new post, fill it with your
> static content, and then send it to display like it was any other
> post.
>
> Perhaps it would look something like this:
> $form = $this->get_unsub_confirmation_form(); // Returns FormUI
> $post = new Post();
> $post->title = 'Unsubscribe to ' . $orig_post_title;
> $post->content = $form->get();
> $post->type = Post::type('page');
> $theme->post = $post;
> $theme->act_display_post();
> exit;
>
> As an aside:  There definitely needs to be a better way to do this.
> Should we perhaps institute some template like "static.php" that
> outputs generic content?  A full implementation of this template may
> look like this:
>
> <?php $theme->display('header'); ?>
> <?php echo $content; ?>
> <?php $theme->display('footer'); ?>
>
> I digress.
>
>>> 4. Any other comments or pointers would be helpful. :)
>
> I haven't looked to see if you have, but if you have not and are
> interested, sharing your work via the -extras repository is an easy
> way to get collaborative help on your plugin.  It also automatically
> creates builds for distribution on habariproject.org.  Or not, it's
> entirely up to you.
>
> Owen
>
> >


--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to