Blog Example / Superb Personal Site

[JuggerJase]

Hi Vance,

I'm interested in exploring the Alloy framework some. I'm intrigued by
the
HMVC / REST / PHP5.3_leveraging feature set.

Is there anything special configuration-wise that I need to know about
the BLOG module example you posted in February? Did you ever complete
the tutorial?

It doesn't appear to include any db schema, but I did find the
post.php file which lists the db fields of the one 'blog_posts' table,
so I'll create that table and the db user/access etc.

Thanks for any set-up info you can provide!

----------

Also, for all you life puppies or pure techie_geeks out there without
business sense (which is quite common and perfectly okay), check out
Vance's personal business/blog site at http://www.vancelucas.com

It's one of the best-executed, straightforward personal business sites
you'll ever see. From large font, large buttons, large personal pic to
the simple, compelling verbiage he uses. That is EXACTLY how it should
be done.

Nice Job! Vance.

I hope the framework is equally-well executed. :)

-Jason

[JuggerJase]

SELF-FOLLOWUP

The blog example module worked just fine. Below is the DB schema / SQL
command one will
need. Just a single blog_posts table.


// load/run below SQL schema into your alloy database (assuming you
have already created it)

CREATE TABLE IF NOT EXISTS `blog_posts` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`title` mediumtext NOT NULL,
`body` text NOT NULL,
`status` int(11) unsigned NOT NULL default '0',
`date_published` datetime default NULL,
`date_created` datetime NOT NULL,
`date_modified` datetime NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 ROW_FORMAT=COMPACT COMMENT='sole
table of alloy blog example module';


// update BELOW PHP info in either: "{my_alloy_dir}/app/config/
app.php" .. OR "{my_alloy_dir}/app/config/{machine_host_name}/
app.php" file

$cfg['database']['master'] = array(
'adapter' => 'mysql',
'host' => 'localhost',
'username' => '{my_dbuser}',
'password' => '{my_dbpass}',
'database' => '{my_db}',
'options' => array(
PDO::ERRMODE_EXCEPTION => true,
PDO::ATTR_PERSISTENT => false,
PDO::ATTR_EMULATE_PREPARES => true
)
);

-Jason

[Vance Lucas]

Jason -

Thanks for the questions and the compliments. I've always had a blend of business and geek in me, and it has worked well for me so far.

To answer your questions about Alloy, I made the initial Blog example, but it is currently not updated to the current Alloy release after I changed the folder structure. I'll make a note to do that soon.

As for the db schema, Spot includes a "migrate" method that automatically sets up all the tables for you, so there is no SQL schema to distribute. It's part of the beauty of the system.

Take a look here at the Controller:

https://github.com/alloyphp/alloy-example-blog/blob/master/app/Module/Blog/Controller.php#L206

Here's how it works:

1) User hits "indexAction" or other method

2) Query generates a PDOException or Spot_Exception_Datasource_Missing

3) The Spot plugin hooks the "dispatch_exception" event and if the above Exceptions are passed, it does an HMVC dispatch to the last called module's "install" method.

4) That install method then does the auto-migration, which creates the db tables for you

No schema to mess with, and completely portable to any database type there is a Spot adapter for.

--
Vance Lucas
http://vancelucas.com

[JuggerJase]

Good stuff! Thanks for the response.

On May 5, 12:09 pm, Vance Lucas <va...@vancelucas.com> wrote:
> Jason -
>
> Thanks for the questions and the compliments. I've always had a blend of
> business and geek in me, and it has worked well for me so far.
>
> To answer your questions about Alloy, I made the initial Blog example, but
> it is currently not updated to the current Alloy release after I changed the
> folder structure. I'll make a note to do that soon.
>
> As for the db schema, Spot includes a "migrate" method that automatically
> sets up all the tables for you, so there is no SQL schema to distribute.
> It's part of the beauty of the system.
>

> Take a look here at the Controller:https://github.com/alloyphp/alloy-example-blog/blob/master/app/Module...

>
> Here's how it works:
> 1) User hits "indexAction" or other method
> 2) Query generates a PDOException or Spot_Exception_Datasource_Missing
> 3) The Spot plugin hooks the "dispatch_exception" event and if the above
> Exceptions are passed, it does an HMVC dispatch to the last called module's
> "install" method.
> 4) That install method then does the auto-migration, which creates the db
> tables for you
>
> No schema to mess with, and completely portable to any database type there
> is a Spot adapter for.
>
> --

> Vance Lucashttp://vancelucas.com

>
> On Thu, May 5, 2011 at 8:04 AM, JuggerJase <jugge...@gmail.com> wrote:
> > Hi Vance,
>
> > I'm interested in exploring the Alloy framework some. I'm intrigued by
> > the
> > HMVC / REST / PHP5.3_leveraging feature set.
>
> > Is there anything special configuration-wise that I need to know about
> > the BLOG module example you posted in February? Did you ever complete
> > the tutorial?
>
> > It doesn't appear to include any db schema, but I did find the
> > post.php file which lists the db fields of the one 'blog_posts' table,
> > so I'll create that table and the db user/access etc.
>
> > Thanks for any set-up info you can provide!
>
> > ----------
>
> > Also, for all you life puppies or pure techie_geeks out there without
> > business sense (which is quite common and perfectly okay), check out

> > Vance's personal business/blog site athttp://www.vancelucas.com

[Vance Lucas]

Jason -

I went ahead and took some time today to update the Alloy Blog example app to the latest version of Alloy that reflects the new folder structure and configuration changes:

https://github.com/alloyphp/alloy-example-blog

The REST style is reflected in the Module\Blog\Controller and determined by the default URL routing:

https://github.com/alloyphp/alloy-example-blog/blob/master/app/Module/Blog/Controller.php

Basically, any GET request is mapped to <module>::<action>Action, and POST, PUT, and DELETE requests are mapped to "postMethod", "putMethod", and "deleteMethod", respectively. This is because the URL routes determine this behavior:

$router->route('module_item', '/<:module>/<#item>(.<:format>)') // :format optional

    ->defaults(array('action' => 'view', 'format' => 'html'))

    ->get(array('action' => 'view'))

    ->put(array('action' => 'put'))

    ->delete(array('action' => 'delete'));

$router->route('module_action', '/<:module>/<:action>(.<:format>)') // :format optional

    ->defaults(array('format' => 'html'))

    ->post(array('action' => 'post'));

The only thing Alloy does internally is map all GET requests to <action>Action, and everything else to <action>Method. This is mainly to prevent data destruction through link crawling (i.e. a GET request to /blog/5/delete will not delete the resource, because it requires a DELETE method to access it (or POST-emulated with _method=DELETE)). This doesn't prevent you from actually putting delete code in a method named "deleteAction" and still using it that way via a GET request, but it does create a standard to use that conforms to REST principles by not encouraging that. The blog example uses both "deleteAction" and "deleteMethod" together, with the "deleteAction" method presenting a confirmation form that makes a DELETE request on submit.

As for PHP5.3 features, the most practical and convenient use of them is for view generics ( http://alloyframework.org/manual/views/generics/ ). You can see the "datagrid" and "form" generic views in use in the Blog example application.

Here is the "datagrid" view generic in use:

https://github.com/alloyphp/alloy-example-blog/blob/master/app/Module/Blog/views/indexAction.html.php

No HMVC features are used in the blog example right now, but a good use of them would probably be to display something like a tag cloud or post comments. This would enable me to make them as separate modules or controller methods and just dispatch to them for display anywhere I want them. That way, if they are displayed in multiple areas on different pages, no code is repeated and everything stays isolated to its own module/realm of responsibility.

I posted a fairly lengthy explanation on what HMVC is and why you want to use it in response to a question on Stackoverflow:

http://stackoverflow.com/questions/2263416/what-is-the-hmvc-pattern/5736164#5736164

Hope that helps, and let me know if you have any more questions. I will continue to develop Alloy and this example project as time goes on.

--
Vance Lucas
http://vancelucas.com

[JuggerJase]

Vance-

(Sorry for late response.. just saw this as I was offline for a few
days)

Thanks for the additional info! I'm definitely not done exploring
Alloy, so the info should prove quite useful, once
I get back to working with it next week sometime.

Off the top of my head right now (if it hasn't been discussed yet -
and excuse my ignorance) , would you mind expanding possibly
on the advantages of Spot vs. a more mature and feature-rich ORM like
Doctrine2, for example??

There's still a Spot dependency in there (somewhere :) at the moment,
right?

Thanks much.

-Jason

On May 10, 4:59 pm, Vance Lucas <va...@vancelucas.com> wrote:
> Jason -
>

> I went ahead and took some time today to update the Alloy Blog example app
> to the latest version of Alloy that reflects the new folder structure and
> configuration changes:https://github.com/alloyphp/alloy-example-blog
>
> The REST style is reflected in the Module\Blog\Controller and determined by

> the default URL routing:https://github.com/alloyphp/alloy-example-blog/blob/master/app/Module...

> view generics (http://alloyframework.org/manual/views/generics/). You can

> see the "datagrid" and "form" generic views in use in the Blog example
> application.
>

> Here is the "datagrid" view generic in use:https://github.com/alloyphp/alloy-example-blog/blob/master/app/Module...

>
> No HMVC features are used in the blog example right now, but a good use of
> them would probably be to display something like a tag cloud or post
> comments. This would enable me to make them as separate modules or
> controller methods and just dispatch to them for display anywhere I want
> them. That way, if they are displayed in multiple areas on different pages,
> no code is repeated and everything stays isolated to its own module/realm of
> responsibility.
>
> I posted a fairly lengthy explanation on what HMVC is and why you want to

> use it in response to a question on Stackoverflow:http://stackoverflow.com/questions/2263416/what-is-the-hmvc-pattern/5...

>
> Hope that helps, and let me know if you have any more questions. I will
> continue to develop Alloy and this example project as time goes on.
>
> --

> Vance Lucashttp://vancelucas.com

[Vance Lucas]

Spot is distributed with Alloy as a Plugin, and enabled by default in
the app/config/app.php 'plugins' config key. If you don't want to use
it, just disable the plugin by removing it from the plugins array, and
it won't load or be used at all.

There are no dependencies on Spot in Alloy - Alloy can run without any
ORM at all and you can just use custom classes with PDO or mysql_query
if you want to :). The calls you see from the Kernel like "$kernel-
>mapper()" are actually mixin methods added by the Spot plugin at
runtime (proxied through the Kernel's __call magic method):
https://github.com/alloyphp/alloy/blob/master/alloy/Plugin/Spot/Plugin.php#L27

And the Kernel methods that enable the callbacks:
https://github.com/alloyphp/alloy/blob/master/alloy/lib/Alloy/Kernel.php#L782

You can absolutely use Doctrine2 or any other ORM you want. It's just
a matter of creating a plugin and enabling it. I would be happy to
help you make a Doctrine2 plugin if you want to use it - it has been
requested a few times before by other people as well, and it would be
a great addition to Alloy as an optional plugin to download.

Spot is the PHP 5.3 version of phpDataMapper. The main advantage with
Spot is just that it's lighter, smaller, simpler, and easier to work
with than a more robust solution like Doctrine2. Like Alloy itself,
Spot just does the bare minimum stuff required for 80% of users to
make life simpler, while trying to not cross the complexity line most
developers are not comfortable going beyond. My personal beliefs
regarding ORMs is that they're great for simplifying all the CRUD
stuff and table relations (the 80%), but generally suck at joins and
more complex queries (the 20%). As a result, Spot doesn't have any
support for joins or subqueries at all in the query builder like most
other ORMs do. I believe that if these are required in your code, they
should be done using hand-written SQL for maximum efficiency and
readability. It's really just a matter of taste, preferences, and
personal programming style more than anything else.

--
Vance Lucas
http://vancelucas.com

[JuggerJase]

Your informative response is much appreciated.

While I don't necessarily disagree with your (general) assessment of
ORMs
(and I like your bias towards bare-bones efficiency & simplicity),
people
come at projects with different intentions, goals, and motivations -
and I know
there are many PHP developers who'll ultimately want to use Doctrine
2.. for any number of reasons.

Personally, (if I get the chance in the near future), I'll try to
build this Alloy Doctrine 2 plug-in myself so I can get
more familiar with both Alloy and Doctrine 2.

Any additional general / contextual info you can provide on Alloy plug-
in development (or really
just some basic plug-in development documentation) will be welcomed.

If this is already available somewhere, then I'm sure I'll be able to
find it.

Thanks.

Jason

On May 14, 10:53 am, Vance Lucas <czar...@gmail.com> wrote:
> Spot is distributed with Alloy as a Plugin, and enabled by default in
> the app/config/app.php 'plugins' config key. If you don't want to use
> it, just disable the plugin by removing it from the plugins array, and
> it won't load or be used at all.
>
> There are no dependencies on Spot in Alloy - Alloy can run without any
> ORM at all and you can just use custom classes with PDO or mysql_query
> if you want to :). The calls you see from the Kernel like "$kernel->mapper()" are actually mixin methods added by the Spot plugin at
>

> runtime (proxied through the Kernel's __call magic method):https://github.com/alloyphp/alloy/blob/master/alloy/Plugin/Spot/Plugi...
>
> And the Kernel methods that enable the callbacks:https://github.com/alloyphp/alloy/blob/master/alloy/lib/Alloy/Kernel....

>
> You can absolutely use Doctrine2 or any other ORM you want. It's just
> a matter of creating a plugin and enabling it. I would be happy to
> help you make a Doctrine2 plugin if you want to use it - it has been
> requested a few times before by other people as well, and it would be
> a great addition to Alloy as an optional plugin to download.
>
> Spot is the PHP 5.3 version of phpDataMapper. The main advantage with
> Spot is just that it's lighter, smaller, simpler, and easier to work
> with than a more robust solution like Doctrine2. Like Alloy itself,
> Spot just does the bare minimum stuff required for 80% of users to
> make life simpler, while trying to not cross the complexity line most
> developers are not comfortable going beyond. My personal beliefs
> regarding ORMs is that they're great for simplifying all the CRUD
> stuff and table relations (the 80%), but generally suck at joins and
> more complex queries (the 20%). As a result, Spot doesn't have any
> support for joins or subqueries at all in the query builder like most
> other ORMs do. I believe that if these are required in your code, they
> should be done using hand-written SQL for maximum efficiency and
> readability. It's really just a matter of taste, preferences, and
> personal programming style more than anything else.
>
> --

> Vance Lucashttp://vancelucas.com