Doggetto.com » symfony Framework http://blog.doggetto.com Just another WordPress weblog Fri, 22 Apr 2011 05:30:15 +0000 en hourly 1 http://wordpress.org/?v=3.1.3 Faux-WordPress Plugin Note II http://blog.doggetto.com/2010/03/faux-wordpress-note-ii/ http://blog.doggetto.com/2010/03/faux-wordpress-note-ii/#comments Fri, 05 Mar 2010 19:02:10 +0000 NoCoolName_Tom http://blog.doggetto.com/?p=593 Okay, I think I’ve got the repository nonsense worked out.

Feel free to checkout or browse the code at:
https://svn.xp-dev.com/svn/tpdFauxWPPlugin/trunk/

As I said, I’m still working on this, so be careful: the code might not actually be working all the time. Feel free to read the logs for more info, I try to at least type something when I commit.

For those who are interested in how to convert your project into a plugin, it’s actually quite simple. A plugin is like a little mini-application: it holds a lib directory for filters, forms, and models; it holds a modules directory for modules (these have to be explicitly activated in each application); and it can hold other directories like web and config. Each of these directories functions the same as in a full application. One nice thing a lot of plugin developers will do is to add a third layer of inheritance above the plugin model classes so that future developers can extend the plugin without having to muck about inside of the plugin code (You might have seen this if you’ve played around with sfGuard: the normal model classes are all empty and extend the Plugin classes which extend the base classes).

Anyways, gather all of that together, and you have the directory structure of a plugin, ready to be used in Symfony. As for the actually business of packaging I’ll have to leave that for later. It can be very simple, but to pull off some really cool things requires a bit of work.

]]> http://blog.doggetto.com/2010/03/faux-wordpress-note-ii/feed/ 0 Producing a Faux-WordPress Plugin for Symfony, Part IV http://blog.doggetto.com/2010/03/producing-a-faux-wordpress-plugin-for-symfony-part-iv/ http://blog.doggetto.com/2010/03/producing-a-faux-wordpress-plugin-for-symfony-part-iv/#comments Fri, 05 Mar 2010 17:27:04 +0000 NoCoolName_Tom http://blog.doggetto.com/?p=589 For this fourth part of my post on my FauxWordPress plugin I am changing tack. Previously I’ve actually been developing at the exact same time as writing. This meant that, in essense, I was writing everything twice, then testing, then writing everything twice again, then testing, and finally writing everything twice again. I guess this was really fun for people who were trying to follow along from scratch, but there’s already plenty of good tutorials that help in the development of a full application (Askeet, Jobeet). Besides, while there are aspects of plugin development that I had to somewhat struggle with, it was better for me to struggle because I think I’ve learned more that way (still learning).

I really want to finish this plugin. I’m getting a little tired of using two solutions for my website and I want to get back to working on other things I’ve planned. So instead of giving everyone the play-by-play for the application (which has been taking FOREVER), I’m going to give status updates on the project, open up a subversion repository, and just start building the applicaiton. At certain points along the way I’ll give posts about certain aspects of the development process that you should keep in mind for application development.

I’ve been swaped the past month with work and school so development on this plugin was somewhat slow. I have finished up my plans for spam checking, however. Considering that this is, basically, version 1 I’ve not written it very well in terms of adding additional spam solutions, but for now there is a Spam class that contains some abstracted functions for spam checking. These functions basically run other functions within the class based upon config variables. Currently there are functions to handle either Akismet or TypePad AntiSPam; I cheated because technically TypePad uses the same API calls as Akismet. Two for the price of one! If no spam solution is specified in the app.yml config file, then all comments are automatically approved. I have still not added Mollum spam checking because it doesn’t return a straight-up boolean response but will, if unsure of the comment’s status after an initial check, present the user with a CAPTCHA field. This sort of two-step process will be a little more involved and I’ll need to see about implementing it later. For now, however, spam collection with two different checking solutions is finished.

Next to work on is the Show View for posts. I want, as stated before, to allow the displaying and listing of posts (basically the entire post module for the frontend) to use any sort of WordPress theme. I will be continuing to push for this goal after cleaning up the subversion repository.

Which brings me to my final bit of news. I suck at subversion; I may use the CLI for it, but it you were to ask me to merge two branches to the trunk or something standard like that, I’d say get someone else. I’m good at checking code out and checking code in. Producing branches and trunks? Not so good at that, but I need to learn. To do so, I’ll be spending a bit of time today cleaning up my project repository and working copy in case anybody wants to check anything out. Currently I’m still developing a full-blown application and not a plugin; converting from a project to a plugin isn’t that hard, so I’ll probably spend some time converting it and continue development as a plugin. The benefit is that if anyone wants to try out this unfinished plugin, or offer any suggestions, they’ll be able to checkout code themselves. I’ll post the URL of the repository as soon as I get it all figured out.

]]> http://blog.doggetto.com/2010/03/producing-a-faux-wordpress-plugin-for-symfony-part-iv/feed/ 0 Producing a Faux-WordPress Plugin for Symfony, Part III http://blog.doggetto.com/2010/02/producing-a-faux-wordpress-plugin-for-symfony-part-iii/ http://blog.doggetto.com/2010/02/producing-a-faux-wordpress-plugin-for-symfony-part-iii/#comments Sat, 06 Feb 2010 19:30:24 +0000 NoCoolName_Tom http://blog.doggetto.com/?p=555 To build this plugin I’m going to start with a new project, entirely from scratch. This means that I will be initially developing a normal application. Once we’re nearing the end, we’ll package the project up into a plugin. This post will cover the development of basic CRUD functionality so we can actually do something if we want.

To start off, we’ll need our database and web server set up and ready to go. I won’t go into that now and will just assume that you have config/databases.yml and config/propel.ini both set up and ready to go. I also enjoy setting a VirtualHost in apache to handle the application, but that sort of choice is up to you. It won’t matter to the packaged plugin in the end what you name the development database or how to configure your server.

We’ll need to have sfGuardUserPlugin installed because there are a few references to it in the schema of the previous post. Let’s install it now before we set up the database tables.

symfony plugin:install sfGuardPlugin;

Now that we have sfGuard installed, we should be ready to build the application.

symfony propel:build-all --no-confirmation;

The schema is established in the database and we’re ready to go.

Let’s establish a few generators to take care of data entry. For now, let’s establish one for managing posts and managing comments.

symfony propel:generate-admin --module="post" frontend sfFauxWPPost;
symfony propel:generate-admin --module="comment" frontend sfFauxWPComment;

Next let’s set up the post module as the default module (for now) for the frontend, and set up links to the two modules in the template.

/apps/frontend/config/routing.yml:
...
# default rules
homepage:
  url: /
  param: { module: post, action: index }
...
/apps/frontend/templates/layout.php:
...
  <body>
    <ul>
      <li><?php echo link_to('Posts', '@sf_faux_wp_post') ?></li>
      <li><?php echo link_to('Comments', '@sf_faux_wp_comment')?></li>
    </ul>
    <?php echo $sf_content ?>
  </body>
...

Now, after cleaing the cache (symfony cc;) we should be able to load the application and see the Post module. It’s rather messy, however, since there is a large fitler box on the side and no default data to look at. Also, if we try to click on the “Comments” link we’ll get a failure because there is no “__toString” function for Posts. Let’s fix this first of all since we’ll be needing to echo objects a lot in this project.

The following are the objects that we’d expect to produce a string when echoed. As for the others, feel free to add a __toString if you want. We’ll probably address these objects later. I am including phpDoc documentation in the functions because I want to have a correctly defined tooltip in NetBeans whne I reference this function.

/lib/model/sfFauxWPCategory.php:
<?php

class sfFauxWPCategory extends BasesfFauxWPCategory
{
  /**
   * Echos the name of the category.
   *
   * @return string
   */
  public function __toString()
  {
    $this->getName();
  }
}

/lib/model/sfFauxWPComment.php:
class sfFauxWPComment extends BasesfFauxWPComment
{
  /**
   * Echos the content of the comment.
   *
   * @return string
   */
  public function __toString()
  {
    $this->getContent();
  }
}
/lib/model/sfFauxWPPost.php:
<?php

class sfFauxWPPost extends BasesfFauxWPPost
{
  /**
   * Echos the title of the post.
   *
   * @return string
   */
  public function __toString()
  {
    $this->getTitle();
  }
}

/lib/model/sfFauxWPTag.php:
<?php

class sfFauxWPTag extends BasesfFauxWPTag
{
  /**
   * Echos the name of the tag.
   *
   * @return string
   */
  public function __toString()
  {
    return $this->getName();
  }
}

Now the basic CRUD functions for both Posts and Comments should be working. Finally, before we end for now, let’s establish a “show” view for posts.

/apps/frontend/modules/post/actions/actions.class.php:
<?php

/**
 * post actions.
 *
 * @package PhpProject1
 * @subpackage post
 * @author Your name here
 * @version SVN: $Id: actions.class.php 12474 2008-10-31 10:41:27Z fabien $
 */
class postActions extends autoPostActions
{
  public function executeShow(sfWebRequest $request)
  {
    $this->sf_faux_wp_post = $this->getRoute()->getObject();
  }
}

/apps/frontend/modules/post/templates/showSuccess.php:
<?php use_helper('I18N', 'Date') ?>
<?php include_partial('post/assets') ?>

<div id="sf_admin_container">
  <h1><?php echo __($sf_faux_wp_post->getTitle(), array(), 'messages') ?></h1>

  <div id="sf_admin_content">
    <div id="sf_faux_wp_published_at">
      <?php echo $sf_faux_wp_post->getPublishedAt(); ?>
    </div>
    <div id="sf_faux_wp_content">
      <?php echo __(nl2br($sf_faux_wp_post->getContent())); ?>
    </div>
    <hr/>
    <div id="comments">
      <div id="comment_count">
        <?php echo ($sf_faux_wp_post->countsfFauxWPComments() ? $sf_faux_wp_post->countsfFauxWPComments() : "No") ?> Comment<?php echo ($sf_faux_wp_post->countsfFauxWPComments() != 1 ? 's' : '') ?>
      </div>
     <?php foreach($sf_faux_wp_post->getsfFauxWPComments() as $id => $comment):?>
        <div id="comment_<?php echo $id ?>">
          <div id="comment_name_<?php echo $id ?>">
            <?php echo __($comment->getWebsite() ? link_to($comment->getAuthor(), $comment->getWebsite()) : $comment->getAuthor()) ?>
          </div>
          <div id="comment_content_<?php echo $id ?>">
            <?php echo __($comment->getContent()) ?>
          </div>
        </div>
      <?php endforeach; ?>
    </div>
  </div>
</div>

That’s enough for today. Dang, I never expected that writing these posts would slow down the development so much.

]]> http://blog.doggetto.com/2010/02/producing-a-faux-wordpress-plugin-for-symfony-part-iii/feed/ 0 Producing a Faux-WordPress Plugin for Symfony, Part II http://blog.doggetto.com/2010/02/producing-a-faux-wordpress-plugin-for-symfony-part-ii/ http://blog.doggetto.com/2010/02/producing-a-faux-wordpress-plugin-for-symfony-part-ii/#comments Tue, 02 Feb 2010 00:00:06 +0000 NoCoolName_Tom http://blog.doggetto.com/?p=524 blogging aspects of Wordpress; for the other features that a user or developer might want you'll need to address those through the framework itself.]]> Working on the Foundations

WordPress is, by far, the most popular blogging framework on the Internet today and that popularity is not undeserved. It has an easy installation and is set up to cater to non-technical people. After installation, it simply works and people are up and running quickly. It has an active plugin community to extend it in any direction a user might need. In short, it’s a great solution to use pretty much anywhere.

However, it’s also not very nice to play with as a developer. The code is mostly based around PHP 4 (although that will probably change when 3.0 is released) and writing plugins and themes can occasionally be a nightmare. Security is, unfortunately, a constant problem since the ease-of-use is occasionally in tension with secure practices. Finally, while the self-contained aspect of WordPress is great for a typical user who pretty much runs their entire site through WordPress, integrating a WordPress installation with an existing applicaiton — especially an application that has its own extensive user-management solution — is a daunting task. WordPress is a streamlined applicaiton, but trying to bend it in ways it wasn’t meant to bend (fiddling with database schemas, login and session management, etc) often breaks either WordPress or the developer.

The symfony plugin I am trying to write is NOT to somehow replace WordPress. That is a large project that would be nearly impossible for myself. I have no idea how I’d ever compete against the easiness of a WordPress installation. The Symfony framework is awesome (and well-suited, I’d argue, for such an endeavor whenever someone wishes to attempt it), but it is meant for PHP developers, not for somebody who just wants to host a blog. So, my plugin will approach the issue from the PHP developer’s point of view. WordPress plugins extend WordPress to act however the developer wants; with a WordPress installation all functions of the website are meant to be handled by WordPress. With my plugin, it is just a plugin to handle and emulate the blogging aspects of WordPress; for the other features that a user or developer might want you’ll need to address those through the framework itself. Anything that isn’t the job of a blogging solution (e.g., a contact page) isn’t done by the blogging solution.

So, with that out of the way, on to building the plugin (which, until I think of a better name, is called sfFauxWP).

The foundation of any blogging solution revolves around the basic idea of posts and comments. The following schema (adapted from the already excellent sfSimpleBlogPlugin) allows for posts, comments, tags (non-self-referential post attributes), categories (self-referential post attributes), and user ratings. There are a number of booleans which hold post-specific settings regarding user interaction. While allowing some room for possible modification in the future, this schema is probably more than enough for our needs.

schema.yml

propel:
  _attributes:
    package: lib.model
    defaultIdMethod: native

## Posts ##
  sf_faux_wp_posts:
    _attributes:
      phpName: sfFauxWPPost
    id:
      type: integer
      primaryKey: true
      autoIncrement: true
      required: true
    author_id:
      type: integer
      required: true
      foreignTable: sf_guard_user
      foreignReference: id
      onDelete: cascade
    title:
      type: varchar
      size: 255
    short_title:
      type: varchar
      size: 255
    summary:
      type: longvarchar
    content:
      type: longvarchar
    is_published:
      type: boolean
      default: false
    restrict_comments:
      type: boolean
      default: false
    rate_comments:
      type: boolean
      default: false
    rate_posts:
      type: boolean
      default: false
    published_at:
      type: date
    created_at: ~
    updated_at: ~
    _uniques:
      short_title_published_at: [short_title, published_at]

## Comments ##
  sf_faux_wp_comments:
    _attributes:
      phpName: sfFauxWPComment
    id:
      type: integer
      primaryKey: true
      autoIncrement: true
      required: true
    sf_faux_wp_post_id:
      type: integer
      required: true
      foreignTable: sf_faux_wp_posts
      foreignReference: id
      onDelete: cascade
    sf_guard_user_id:
      type: integer
      required: false
      foreignTable: sf_guard_user
      foreignReference: id
      onDelete: cascade
    author:
      type: varchar
      size: 255
    email:
      type: varchar
      size: 255
    website:
      type: varchar
      size: 255
    content:
      type: longvarchar
    is_moderated:
      type: boolean
      default: false
    created_at: ~
    updated_at: ~

## Tags ##
  sf_faux_wp_tags:
    _attributes:
      phpName: sfFauxWPTag
    id:
      type: integer
      primaryKey: true
      autoIncrement: true
      required: true
    name:
      type: varchar
      size: 255
      index: unique
    created_at: ~
    updated_at: ~

## Categories ##
  sf_faux_wp_categories:
    _attributes:
      phpName: sfFauxWPCategory
    id:
      type: integer
      primaryKey: true
      autoIncrement: true
      required: true
    parent_id:
      type: integer
      required: false
      foreignTable: sf_faux_wp_posts
      foreignReference: id
      onDelete: set null
    name:
      type: varchar
      size: 255
      index: unique
    created_at: ~
    updated_at: ~

## The Post<=>Tag Relationship ##
  sf_faux_wp_post_tags:
    _attributes:
      phpName: sfFauxWPPostTag
    id:
      type: integer
      primaryKey: true
      autoIncrement: true
      required: true
    post_id:
      type: integer
      required: true
      foreignTable: sf_faux_wp_posts
      foreignReference: id
      onDelete: cascade
    tag_id:
      type: integer
      required: true
      foreignTable: sf_faux_wp_tags
      foreignReference: id
      onDelete: cascade
    _uniques:
      post_tag: [post_id, tag_id]
    created_at: ~
    updated_at: ~

## The Post<=>Category Relationship ##
  sf_faux_wp_post_categories:
    _attributes:
      phpName: sfFauxWPPostCategory
    id:
      type: integer
      primaryKey: true
      autoIncrement: true
      required: true
    post_id:
      type: integer
      required: true
      foreignTable: sf_faux_wp_posts
      foreignReference: id
      onDelete: cascade
    category_id:
      type: integer
      required: false
      foreignTable: sf_faux_wp_tags
      foreignReference: id
      onDelete: set null
    _uniques:
      post_category: [post_id, category_id]
    created_at: ~
    updated_at: ~

## The Post Group Controls - Who Can Comment? ##
  sf_faux_wp_post_groups:
    _attributes:
      phpName: sfFauxWPPostGroup
    id:
      type: integer
      primaryKey: true
      autoIncrement: true
      required: true
    post_id:
      type: integer
      required: true
      foreignTable: sf_faux_wp_posts
      foreignReference: id
      onDelete: cascade
    group_id:
      type: integer
      required: true
      foreignTable: sf_guard_group
      foreignReference: id
      onDelete: cascade
    created_at: ~
    updated_at: ~

## The Category Group Controls - Who Can Create? ##
  sf_faux_wp_category_groups:
    _attributes:
      phpName: sfFauxWPCategoryGroup
    id:
      type: integer
      primaryKey: true
      autoIncrement: true
      required: true
    category_id:
      type: integer
      required: false
      foreignTable: sf_faux_wp_tags
      foreignReference: id
      onDelete: cascade
    group_id:
      type: integer
      required: true
      foreignTable: sf_guard_group
      foreignReference: id
      onDelete: cascade
    created_at: ~
    updated_at: ~

## The User Ratings for Comments ##
  sf_faux_wp_comment_user_ratings:
    _attributes:
      phpName: sfFauxWPCommentUserRating
    id:
      type: integer
      primaryKey: true
      autoIncrement: true
      required: true
    comment_id:
      type: integer
      required: true
      foreignTable: sf_faux_wp_comments
      foreignReference: id
      onDelete: cascade
    user_id:
      type: integer
      required: true
      foreignTable: sf_guard_user
      foreignReference: id
      onDelete: cascade
    rating:
      type: tinyint
      default: 1
    created_at: ~
    updated_at: ~

## The User Ratings for Posts ##
  sf_faux_wp_post_user_ratings:
    _attributes:
      phpName: sfFauxWPPostUserRating
    id:
      type: integer
      primaryKey: true
      autoIncrement: true
      required: true
    post_id:
      type: integer
      required: true
      foreignTable: sf_faux_wp_posts
      foreignReference: id
      onDelete: cascade
    user_id:
      type: integer
      required: true
      foreignTable: sf_guard_user
      foreignReference: id
      onDelete: cascade
    rating:
      type: tinyint
      default: 1
    created_at: ~
    updated_at: ~

]]> http://blog.doggetto.com/2010/02/producing-a-faux-wordpress-plugin-for-symfony-part-ii/feed/ 3 Producing a Faux-WordPress Plugin for Symfony, Part I http://blog.doggetto.com/2010/01/producing-a-faux-wordpress-plugin-for-symfony-pat-i/ http://blog.doggetto.com/2010/01/producing-a-faux-wordpress-plugin-for-symfony-pat-i/#comments Sun, 31 Jan 2010 01:30:01 +0000 NoCoolName_Tom http://blog.doggetto.com/?p=485 Printing Press

So, for the past year or so I have struggled in trying to figure out how best to incorporate WordPress into a Symfony application. The conclusion I have come to? I’m really starting to wonder if it’s worth any of the trouble. So, I’m trying to figure out, for myself at least, what aspects of WordPress I really appreciate; of those features, I really wonder whether or not building a new plugin (or extending sfSimpleBlogPlugin/sfBlogsPlugin) would not be a better idea.

I have not yet started on this project, so to decide whether it’s worthwhile, what are the aspects of WordPress (or just blog administration in general) that I really enjoy and would like to see in any other solution?

  1. Themes
    The multiplicity of WordPress themes is a great example of how extendible the blogging framework is. Just download it, select it, and you’re good to go. I would love, with a Symfony solution, to be able to define a theme in a config file (or even in the admin backend, as is done with WordPress) and have it display. Or choose to use the application template default instead. Whatever solution I come up with, I would love for it to be able to accomodate existing WordPress themes without any extensive reworkings (plug and play would be ideal).

  2. Spam Collection/Akismet
    WordPress makes good use of the Akismet spam prevention filters. My solution would have to make use of these prevention techniques as well. It’d be great to figure out how to make use of ReCAPTCHA, but your avergae blog nowadays usually depends upon active filtering and I want my solution to seem like any other typical blog.

  3. Scheduling and Drafting of Posts
    I love the ability in WordPress of drafting and publishing against a future date. The ability to view these drafts or, if logged in, to see to-be-published posts is needed.

  4. Pingbacks
    It’s just good blogging ettiquete to pingback to other blogs. My pingback solution should work correctly with existing blogging frameworks.

  5. RSS Feeds
    I’d like to deliver post/comment feeds for the entire blog as well as individual posts.

  6. Media Library
    Having pictures and audio (and YouTube code) available for blog posts is made much easier when you’re confident that they are on the server and available for use. An effective Media Library would be nice. On the frontend, it might even be cool to put together some sort of slide-show option (although that might be more work than I need right now).

  7. Twitter Integration
    I haven’t yet figured out the best way to use Twitter, but it’d be nice to be able to simul-publish a post along with a custom/default Twitter announcement and link. Perhaps it’d also be cool to pull in Twitter posts as a sort of specialized blogroll.

  8. Categories/Tags
    Having a branching tree of categories is a very nice aspect of modern blog frameworks. I would love to be able to filter the posts based on multiple categories (not that I actually plan on writing so many posts to make that particular feature needful, but it’d be nice to have). Deleting a category should, in my mind, simply move all of the posts up to belong to the category parent (if it exists).

  9. Wysiwyg Editor
    The user should be able to set whether they wish to have the Wysiwyg editor or the source editor as their default – I use source almost all of the time and to have that be default for myself would be great. The Wysiwyg Editor should be fast and user-friendly.

  10. Gravatars
    If allowed by the theme, the use of gravatars would be very nice indeed. I always enjoy having my avatar at a blog be personalized without me having to do anything.

  11. Word Count
    I like knowing how many words are on a post, or a post summary.

  12. Reddit-style Like/Dislike
    I absolutely hate having trolls on some of the blogs I go to, but it’s too easy to feed to trolls when all you want to do is get rid of them. Being able to both like and dislike posts and comments would be a great way to users to be involved both with the blog and with each other (obviously, this should be restricted on a post-by-post basis to view-by-all, by-specified-groups, or by-none; or you could just turn the feature off on some posts).

  13. Protected Posts and Access Control
    Yeah, this starts to blur the line between forum and blog, but to be honest, there are some blog posts where I’d love to prevent the entire Internet from looking at them. I’d love to protect posts either by a defined password or even by user levels (sfGuard would work great for this). Perhaps even apply these permissions to the categories/tags to automatically assign protection to posts.

  14. Ajax
    In another word: bling. I want the backend and the frontend to be a little easier to use by default and look nice. Symfony includes support for a number of good Javascript libraries.

  15. Configuration
    There are two levels of configuration that would be available to this solution: there would be the administrative options like themes, spam control, and others. However there are application options that are also important: use ajax or not? use feeds or not? These are things that are likely just set once and never set again. As such, who cares if they are removed from the user and are placed into a symfony configuration file? Simplifying the backend by not placing EVERYTHING in it would go a long way in my opinion, so I will need to define what I feel should be configurable by the user and I will also need to define WHERE they can configure it.

Things I do not need:

  1. Pages
    Since we’re NOT using WordPress to handle everything, any other pages could be handled by adding a module to the application.

  2. Cache
    I know that symfony caching could be a lot better, but it’s still pretty good and it’s standard in the framework. I don’t see a need to add it.

  3. Contact Forms
    We’re working with an entire framework here, complete with the idea that we’ll be delivering other content besides a blog. If I were going to provide a complete blogging solution simply based on symfony (instead of a plugin), then this would make sense. But in regards to this plugin, if you want a contact page, build it yourself!

Things I think would be plain awesome but have no clue how:

  1. Gears or HTML5
    Using Google Gears is an awesome way of interacting with a web application. WordPress has the ability to interact with Gears for the backend area – this speeds things up IMMENSELY. However, Google has publicly announced with the advent of Google Wave that they really don’t see a future for Gears when all of their needs can be handled with tools in HTML5. It would be awesome to beat WordPress to the gate by somehow implementing HTML5 tools to help speed up the backend (or possibly even the frontend).

  2. Alternate Login Options for Admin and Comments
    This is more of an issue regarding sfGuardUser, but it would be fantastic to allow a user to log into the site using FacebookConnect or OpenId. If anything, it would allow for specific user preferences regarding comments. This may be a bit of overkill for my own needs, but if I ever planned on opening a multi-user (or even, perhaps, a multi-blog) plugin I think this would be a great selling point.

  3. Mobile Solution
    Again, this may not be a strictly blogging feature, but it’d be nice to figure out how to deliver the application in a mobile format for Androids and iPhones.

  4. PHP Code within the Post
    This maye be the worst idea in the history of the world – to be honest it’s a security nightmare. However, it’d be pretty awesome sometimes to not just dynamically serve posts, but to have the post content be dynamic. It’d be fun to look further into this.

  5. Detailed Stats
    Keeping track of detailed visitor statistics would help in building some fun features (most/least popular posts, most/least popular comments, etc).

  6. iTunes/Podcasting Help
    It’d be great to ensure that you can deliver an accurate iTunes podcasting feed from the app without devoting every post to the podcast.

In looking at this closely, almost all of it could be handled VERY easily by existing symfony plugins or could be created very easily. There are a few difficulties, however, the largest of which is obviously the theme integration. However, if I could get it to work (and I have a few ideas) then the largest reason for me to use WordPress goes away and I can be happy in having a tightly integrated blogging solution available for my projects.

Over the next few weeks I will be working on trying to create this solution using the symfony framework. I’ll try to document my progress and, hopefully, my success.

]]> http://blog.doggetto.com/2010/01/producing-a-faux-wordpress-plugin-for-symfony-pat-i/feed/ 0 How I Use Netbeans 6.8 and Symfony 1.2 http://blog.doggetto.com/2010/01/how-i-use-netbeans-6-8-and-symfony-1-2/ http://blog.doggetto.com/2010/01/how-i-use-netbeans-6-8-and-symfony-1-2/#comments Mon, 04 Jan 2010 19:02:08 +0000 NoCoolName_Tom http://blog.doggetto.com/?p=473 Beans

I am expirementing with using a full-fledged IDE for web development at work. Until recently I used gEdit; most people don’t know that gEdit can be extended via plugins to become a fantastic development environment. However, one thing I could never get to work was auto-completion based upon functions and classes in PHP. However, the speed of using gEdit, as opposed to Eclipse, was amazing and I never could quite get the hang of editors like Aptana and Eclipse. Recently, I found that Sun’s Java-based IDE, NetBeans, had added symfony support and I wondered how useful that might be. I tried it and loved it. Using NetBeans is not without issues, however. It’s still a bit buggy (that might be because I’m using the development code) and memory usage is about what you’d expect from a Java-based editor (ie, sometimes really, really high). Still, it’s worked out quite well and I’d recommend giving it a try.

Here’s how I set up my installation of NetBeans. I am running Ubuntu Karmic Koala (9.10).

1. Download Netbeans 6.8 for PHP from netbeans.org
2. Install to /opt/NetBeans
Run the following code to prep the installation directory:

sudo mkdir /opt/NetBeans;
sudo chmod 777 /opt/NetBeans;

Then run the following from a terminal wherever you saved the NetBeans installation file:

chmod +x <netbeans_file>.download;
./<netbeans_file>.download;

This will begin the installation.

Be certain to change the installation from your home directory to /opt/NetBeans!

NetBeans should install itself to the desktop as an icon and to the menu under “Programming”. To uninstall it at any later time simply run:

sh /opt/NetBeans/uninstall.sh;

This will remove the program. To fully remove it, also remove the configuration directories at: ~/.netbeans, ~/.netbeans-registration, and ~/NetBeansProjects.

3.Configure NetBeans.
symfony functionality was included in NetBeans 6.8 so it doesn’t require a plugin in this or later versions. However, it does require some setup to work correctly. Run Netbeans, and go to the Options dialogue (Tools > Options). In the PHP section, go to the Symfony tab. In the Symfony script field, find or enter the path for the symfony script in your local framework installation; don’t refrence the batch file, but rather the one without an extension. Mine is installed at: /usr/share/php/symfony/symfony12/data/bin/symfony

Since we’re likely to be in the middle of a project we’ll set up NetBeans to use this project. In the future, you can set up a symfony project from NetBeans (which will run commands such as “symfony generate:project” and “symfony generate:app” for you).

Start a new project (File > New Project). Choose to create a “PHP Application with Existing Sources”. Click “Next”. Set the source folder to the project’s root folder. It’s best to place the NetBeans metadata in a seperate folder outside of the project. The default for this is within your home directory and will work fine. Click “Next”. If you wish you can set up the accesible URL for your project here (or you can do so as part of the full project configuration later).

NetBeans will, upon analyzing the project, determine that it is a symfony project. However, to have full symfony help, you’ll need to add the framework to the Project Include Path for the project and the project cache. (Yes, this is kinda stupid at first, but it will be a lifesaver!) To add to the Include Path, right-click on the Include Path in the Project Display Pane (should be, by default, the pane in the upper-left; the Include Path should be at the bottom of the list.) I add the cache directory of the project and the lib directory of the framework (for me, this is: /usr/share/php/symfony/symfony12/lib). Once these are added and scanned, their functions should be available in the on-screen tooltips as you type. The reason to add these directories (especially the framework) are because it is expected that we might be editing non-Symfony files with the editor and we don’t want functions and classes that are not accessible to the script to be displayed.

Once you have the project up, to finish your configuration, right click on the project name in the Project Display Pane and select “Properties”. On “Sources” make sure that the Source Folder is the root of the symfony project. You can change the “Test Folder” to the test folder within the project. Set the web root to the web folder within the project. Go to the “Run Configuration” bullet point. Ensure that the Project URL is correct for accessing the application. Once the URL path is set, choose one of the application_dev.php files within the web directory of the project for the “Index File”.

Some of the fun aspects of the new IDE: besides having accurate tooltips about variables and functions, you have the ability to jump (via a right-click) between actions and views. This can be very useful at times when you are trying to track down a particular bug. Another fun trick is to Ctrl-click on a function or a class name: you will jump to that item’s declaration.

That should do it for you! If you have xdebug installed, you should also be able to use the build-in debugger (I haven’t really used it yet, but can already tell just how useful it will be).

]]> http://blog.doggetto.com/2010/01/how-i-use-netbeans-6-8-and-symfony-1-2/feed/ 6 Symfony sfConfig Variables http://blog.doggetto.com/2009/06/symfony-sfconfig-variables/ http://blog.doggetto.com/2009/06/symfony-sfconfig-variables/#comments Tue, 02 Jun 2009 23:37:37 +0000 NoCoolName_Tom http://blog.doggetto.com/?p=3 Variables

I keep trying to figure out how to reference the sfConfig variables.  I also often forget what variables are available to me through the symfony framework.  So, for my own benefit and anyone else’s who might be looking for that as well, here it is: as many of the sfConfig variables as I could find. In grabbing all of these I found a few that I never knew existed.  Most of these are to aid symfony in finding all of those extra classes you’ve made in your application but they’re still available to you in your application to use however you wish.

Reference to Config Variables

  • Be careful in referencing any app-specific variables in the model in a multi-app project.  If they are not available in the app you are using the model function in you will have problems.
sfConfig::get('sf_config_variable', 'The default value'); // The default is optional.

Symfony Framework

sf_symfony_lib_dir

The real path to the framework’s lib directory
(/usr/share/php/symfony/symfony12/lib)

Project Structure and Layout

sf_root_dir

The path to the project root
(/var/www/project_name)

sf_apps_dir

The path to the project’s apps folder
(/var/www/project_name/apps)

sf_lib_dir

The path to the project’s lib folder
(/var/www/project_name/lib)

sf_log_dir

The path to the project’s log folder
(/var/www/project_name/log)

sf_data_dir

The path to the project’s data folder
(/var/www/project_name/data)

sf_config_dir

The path to the project’s config folder
(/var/www/project_name/config)

sf_test_dir

The path to the project’s test folder
(/var/www/project_name/test)

sf_doc_dir

The path to the project’s doc folder
(/var/www/project_name/doc)

sf_plugins_dir

The path to the project’s plugins folder
(/var/www/project_name/plugins)

sf_cache_dir

The path to the project’s plugins folder
(/var/www/project_name/cache)

sf_web_dir

The path to the project’s plugins folder
(/var/www/project_name/web)

sf_upload_dir

The path to the project’s upload folder
(/var/www/project_name/web/uploads)

Application Information

sf_app

The current application
(backend)

sf_environment

The current environment
(dev)

sf_debug

Whether debugging is enabled
(1)

Application Structure and Layout

sf_app_dir

The path to the current application
(/var/www/project_name/apps/backend)

sf_app_config_dir

The path to the current application’s config directory
(/var/www/project_name/apps/backend/config)

sf_app_lib_dir

The path to the current application’s lib directory
(/var/www/project_name/apps/backend/lib)

sf_app_module_dir

The path to the current application’s module directory
(/var/www/project_name/apps/backend/modules)

sf_app_template_dir

The path to the current application’s template directory
(/var/www/project_name/apps/backend/templates)

sf_app_i18n_dir

The path to the current application’s i18n directory
(/var/www/project_name/apps/backend/i18n)

Cache Structure and Layout

sf_app_base_cache_dir

The path to the current application’s directory in the cache
(/var/www/project_name/cache/backend)

sf_app_cache_dir

The path to the current application’s directory in the cache by current environment
(/var/www/project_name/cache/backend/dev)

sf_template_cache_dir

The path to the current application’s templates directory in the cache by current environment
(/var/www/project_name/cache/backend/dev/template)

sf_i18n_cache_dir

The path to the current application’s i18n directory in the cache by current environment
(/var/www/project_name/cache/backend/dev/i18n)

sf_config_cache_dir

The path to the current application’s config directory in the cache by current environment
(/var/www/project_name/cache/backend/dev/config)

sf_test_cache_dir

The path to the current application’s test directory in the cache by current environment
(/var/www/project_name/cache/backend/dev/test)

sf_module_cache_dir

The path to the current application’s modules directory in the cache by current environment
(/var/www/project_name/cache/backend/dev/modules)

Application Settings

You can access any value in settings.yml by prepending “sf_” to the value.

sf_error_404_module

The module that contains the 404 action (default)

sf_error_404_action

The action that displays the 404 error (error404)

sf_logging_enabled

Boolean for whether logging is currently enabled (1)

sf_escaping_strategy

Whether the sfView class is using the Escaping Strategy (1)

sf_no_script_name

Whether the application is requiring the script name. (1)

sf_csrf_secret

The CSRF secret (UniqueSecret)

Also:

You can grab some information from the current context (usually in templates, but should work well enough in actions – I’d be very cautious about using these in models):

sfContext::getInstance()->getActionName();

The name of the current action.  Can also be called by $this->getActionName() in templates.
(my_awesome_action)

sfContext::getInstance()->getModuleName();

The name of the current module.  Can also be called by $this->getModuleName() in templates.
(my_awesome_module)

sfContext::getInstance()->getModuleDirectory();

The path to the current module’s directory
(/var/www/project_name/apps/backend/modules/my_awesome_module)

]]> http://blog.doggetto.com/2009/06/symfony-sfconfig-variables/feed/ 6