Multiple Content Areas patch!

[Loban Rahman]

Well, as I mentioned in my last email to the group, I was going to experiment to see if I could add multiple content areas to diem without breaking existing sites. I have to say that it was MUCH EASIER than I had expected, and I did NOT need to change any core diem code either!

I've attached a patch file for anyone interested, or if someone would like to comment or provide constructive criticism. Note that it doesn't allow for customisable content and non-content areas (which was discussed earlier), just hard codes in some more content areas to allow more flexible layouts which have two content areas separated by a common area.

Summary:

lib/model/doctrine/dmCorePlugin/DmArea.class.php
- Overloaded setTableDefinition() to allow more choices for the enum of area type. Formerly only top, bottom, left, right, content; it now includes content1, content2, middle, middle1, and middle2 added. The middle's are layout areas.
- This could have been better done by over-riding the schema for dmArea, but I wasn't sure how to do that.

lib/model/doctrine/dmCorePlugin/DmLayout.class.php
- Added the extra layout area types to the protected variable $areaTypes

lib/model/doctrine/dmCorePlugin/DmPageView.class.php
- Overloaded setup() to make dmPageView have a one-to-many relation with dmArea, rather than a one-to-one. Hence it now has a the properties "Layout" and "Areas" instead of "Layout" and "Area"
- Again this could have been better done by just over-riding the schema, but I wasn't sure how to do that.
- Added some code copied from dmLayout (which already handles multiple areas), and also a method checkMissingAreas() that auto-adds any missing areas to a dmPageView upon saving it.
- This is necessary because I wanted to be able to add this patch to project with already a lot of pages.

lib/model/doctrine/dmCorePlugin/DmPageViewTable.class.php
- Added a method that loads ALL dmPageViews and just resaves them, triggering the checkMissingAreas method above.

lib/model/doctrine/dmCorePlugin/DmPageTable.class.php
- Overloaded the checkBasicPages() method to also call the checkMissingAreas() method above.
- Whenever "symfony dm:setup" task is run, one of the things it does is call checkBasicPages() to ensure that the 3 basic pages (login, error404, and home) exist. Now, it will also automatically upgrade the database to include all the newer areas on existing pages.

apps/front/modules/dmFront/templates/pageSuccess.php
- Add lines to render all the extra areas.
- You will need to add them to all other xxxSuccess.php layout files as well

apps/front/lib/myFrontPageBaseHelper.php
- Overloaded renderArea() and getAreaTypeTagName() to overcome some assumptions that a pageView has only one content area.
- Also set it as the value for "page_helper.class" in apps/front/config/dm/services.yml

The best thing is that the current database layout did not need to be changed at all. So nothing existing has broken - just extra entries for dmAreas added and used. I also changed the CSS so that in edit mode, Layout-Zones are colored differently than Page-Zones, so that one can quickly identify which is which.

I'm wondering if it would be worthwhile packaging this up as a dmAdvancedLayoutPlugin, where you have a config file to define what areas (name and whether its layout or page specific) you want, and the plugin sets things up automatically for you.


Regards,

Loban Amaan Rahman
Project Manager & Technical Lead
HottMedia Limited
loban....@hottmedia.com
+8801611646613
+8801711646613

When the going gets scary, the scared get scarce.

[ornicar]

Ok, this is VERY interresting.
I'll seriously consider using it for Diem 5.1

Thanks

On Mar 6, 5:48 am, Loban Rahman <loban.rah...@gmail.com> wrote:
> Well, as I mentioned in my last email to the group, I was going to
> experiment to see if I could add multiple content areas to diem without
> breaking existing sites. I have to say that it was MUCH EASIER than I had
> expected, and I did NOT need to change any core diem code either!
>
> I've attached a patch file for anyone interested, or if someone would like
> to comment or provide constructive criticism. Note that it doesn't allow for
> customisable content and non-content areas (which was discussed earlier),
> just hard codes in some more content areas to allow more flexible layouts
> which have two content areas separated by a common area.
>
> Summary:

> *
> lib/model/doctrine/dmCorePlugin/DmArea.class.php*

> - Overloaded setTableDefinition() to allow more choices for the enum of area
> type. Formerly only top, bottom, left, right, content; it now includes
> content1, content2, middle, middle1, and middle2 added. The middle's are
> layout areas.
> - This could have been better done by over-riding the schema for dmArea, but
> I wasn't sure how to do that.

> *
> lib/model/doctrine/dmCorePlugin/DmLayout.class.php*

> - Added the extra layout area types to the protected variable $areaTypes
>

> *lib/model/doctrine/dmCorePlugin/DmPageView.class.php*

> - Overloaded setup() to make dmPageView have a one-to-many relation with
> dmArea, rather than a one-to-one. Hence it now has a the properties "Layout"
> and "Areas" instead of "Layout" and "Area"
> - Again this could have been better done by just over-riding the schema, but
> I wasn't sure how to do that.
> - Added some code copied from dmLayout (which already handles multiple
> areas), and also a method checkMissingAreas() that auto-adds any missing
> areas to a dmPageView upon saving it.
> - This is necessary because I wanted to be able to add this patch to project
> with already a lot of pages.

> *
> lib/model/doctrine/dmCorePlugin/DmPageViewTable.class.php*

> - Added a method that loads ALL dmPageViews and just resaves them,
> triggering the checkMissingAreas method above.
>

> *lib/model/doctrine/dmCorePlugin/DmPageTable.class.php*

> - Overloaded the checkBasicPages() method to also call the
> checkMissingAreas() method above.
> - Whenever "symfony dm:setup" task is run, one of the things it does is call
> checkBasicPages() to ensure that the 3 basic pages (login, error404, and
> home) exist. Now, it will also automatically upgrade the database to include
> all the newer areas on existing pages.
>

> *apps/front/modules/dmFront/templates/pageSuccess.php*

> - Add lines to render all the extra areas.
> - You will need to add them to all other xxxSuccess.php layout files as well
>

> *apps/front/lib/myFrontPageBaseHelper.php*

> - Overloaded renderArea() and getAreaTypeTagName() to overcome some
> assumptions that a pageView has only one content area.
> - Also set it as the value for "page_helper.class" in
> apps/front/config/dm/services.yml
>
> The best thing is that the current database layout did not need to be
> changed at all. So nothing existing has broken - just extra entries for
> dmAreas added and used. I also changed the CSS so that in edit mode,
> Layout-Zones are colored differently than Page-Zones, so that one can
> quickly identify which is which.
>
> I'm wondering if it would be worthwhile packaging this up as a
> dmAdvancedLayoutPlugin, where you have a config file to define what areas
> (name and whether its layout or page specific) you want, and the plugin sets
> things up automatically for you.
>
> Regards,
>

> *Loban Amaan Rahman

> Project Manager & Technical Lead

> HottMedia Limited*
> loban.rah...@hottmedia.com

> +8801611646613
> +8801711646613
>
> When the going gets scary, the scared get scarce.
>

>  dmMultipleContentAreas.patch
> 11KViewDownload

[Fotis Paraskevopoulos]

Hello Loban,

I applied your path and I am getting this error

Unknown record property / related component "Layout" on "DmPage"

Do you have an idea as to why this might be.

I am running Symfony 1.4/Diem 5 RC5

Thank you,
Fotis

On Mar 6, 6:48 am, Loban Rahman <loban.rah...@gmail.com> wrote:
> Well, as I mentioned in my last email to the group, I was going to
> experiment to see if I could add multiple content areas to diem without
> breaking existing sites. I have to say that it was MUCH EASIER than I had
> expected, and I did NOT need to change any core diem code either!
>
> I've attached a patch file for anyone interested, or if someone would like
> to comment or provide constructive criticism. Note that it doesn't allow for
> customisable content and non-content areas (which was discussed earlier),
> just hard codes in some more content areas to allow more flexible layouts
> which have two content areas separated by a common area.
>
> Summary:

> *
> lib/model/doctrine/dmCorePlugin/DmArea.class.php*

> - Overloaded setTableDefinition() to allow more choices for the enum of area
> type. Formerly only top, bottom, left, right, content; it now includes
> content1, content2, middle, middle1, and middle2 added. The middle's are
> layout areas.
> - This could have been better done by over-riding the schema for dmArea, but
> I wasn't sure how to do that.

> *
> lib/model/doctrine/dmCorePlugin/DmLayout.class.php*

> - Added the extra layout area types to the protected variable $areaTypes
>

> *lib/model/doctrine/dmCorePlugin/DmPageView.class.php*

> - Overloaded setup() to make dmPageView have a one-to-many relation with
> dmArea, rather than a one-to-one. Hence it now has a the properties "Layout"
> and "Areas" instead of "Layout" and "Area"
> - Again this could have been better done by just over-riding the schema, but
> I wasn't sure how to do that.
> - Added some code copied from dmLayout (which already handles multiple
> areas), and also a method checkMissingAreas() that auto-adds any missing
> areas to a dmPageView upon saving it.
> - This is necessary because I wanted to be able to add this patch to project
> with already a lot of pages.

> *
> lib/model/doctrine/dmCorePlugin/DmPageViewTable.class.php*

> - Added a method that loads ALL dmPageViews and just resaves them,
> triggering the checkMissingAreas method above.
>

> *lib/model/doctrine/dmCorePlugin/DmPageTable.class.php*

> - Overloaded the checkBasicPages() method to also call the
> checkMissingAreas() method above.
> - Whenever "symfony dm:setup" task is run, one of the things it does is call
> checkBasicPages() to ensure that the 3 basic pages (login, error404, and
> home) exist. Now, it will also automatically upgrade the database to include
> all the newer areas on existing pages.
>

> *apps/front/modules/dmFront/templates/pageSuccess.php*

> - Add lines to render all the extra areas.
> - You will need to add them to all other xxxSuccess.php layout files as well
>

> *apps/front/lib/myFrontPageBaseHelper.php*

> - Overloaded renderArea() and getAreaTypeTagName() to overcome some
> assumptions that a pageView has only one content area.
> - Also set it as the value for "page_helper.class" in
> apps/front/config/dm/services.yml
>
> The best thing is that the current database layout did not need to be
> changed at all. So nothing existing has broken - just extra entries for
> dmAreas added and used. I also changed the CSS so that in edit mode,
> Layout-Zones are colored differently than Page-Zones, so that one can
> quickly identify which is which.
>
> I'm wondering if it would be worthwhile packaging this up as a
> dmAdvancedLayoutPlugin, where you have a config file to define what areas
> (name and whether its layout or page specific) you want, and the plugin sets
> things up automatically for you.
>
> Regards,
>

> *Loban Amaan Rahman

> Project Manager & Technical Lead

> HottMedia Limited*
> loban.rah...@hottmedia.com

> +8801611646613
> +8801711646613
>
> When the going gets scary, the scared get scarce.
>

>  dmMultipleContentAreas.patch
> 11KViewDownload

[Fotis Paraskevopoulos]

After studying the patches a bit, the problem is that "services.yml"
seems to have to effect, and myFrontPageBaseHelper is not being used
at all.

Also myFrontPageBaseHelper is abstract, but that may be the DI in play
here.

Any help will be greatly appreciated.

Best Regards,
Fotis

[Fotis Paraskevopoulos]

I am sorry to keep replying, but shouldn't we be replacing
page_helper.view_class instead of page_helper.class ?

[Loban Rahman]

Sorry for the delay in replying Fotis,

I saw this error multiple times while developing the patch, and it was usually because my database was missing something. Could you please attach the _entire_ stacktrace that diem produces? Perhaps I forgot to include something in my patch file.

As for your other question -- there are 3 page_helper classes:

page_helper.class <-- base helper for the 2 below
page_helper.view_class <-- used to render pages when NOT logged in with edit permissions
page_helper.edit_class <-- used to render pages when logged in with edit permissions

Hence i'm overloading the base class, cause those methods are needed in both view and edit situations.


Regards,
Loban Amaan Rahman

When the going gets scary, the scared get scarce.

[Loban Rahman]

Found the bug! And thanks for the heads up. Turns out I was only adding missing custom page-specific areas, and completely forgot to add the missing custom layout-specific areas. I came across the bug myself today.

I've attached a 2nd patch file which you need to apply after the 1st patch. I've also attached the first patch again.

Regards,
Loban Amaan Rahman

When the going gets scary, the scared get scarce.

[Fotis Paraskevopoulos]

Hello Loban,

Yes,late last night I noticed I could add "middle1", "middle2" and so on, to the database dm_layout table and it would work, but once I added another page, I would get the exception again. I will apply the second patch and let you know how it goes.

I looked at your code, and saw that I could add as many "areas" as I needed for my layout. I wonder if this could be done more dynamically, if I come up with something I will let you know.

A bit off-topic, regarding the DI and override of page_helper.class, I would like to take this opportunity and ask some things. My background in OO and patterns is heavily based in Java, which is where my "guru" status stands :-) . I have used Spring's DI extensively, and I don't know if the fact that php is dynamically typed has to do anything with my confusion.

Looking at the code for "dmFrontBaseServiceContainer" I see the following code :

protected function configurePageHelper()

  {

    /*

     * If user can edit front, the page helper service will use the edit class,

     * and it will require the user to check its credentials

     */

    if ($this->getService('user')->can('zone_add, widget_add, widget_edit_fast'))

    {

      $this->setParameter('page_helper.class', $this->getParameter('page_helper.edit_class'));

    }

    /*

     * User can not edit front so we load the view only class

     */

    else

    {

      $this->setParameter('page_helper.class', $this->getParameter('page_helper.view_class'));

    }

  }

without overriding anything, the two classes that will be instantiated are :

dmFrontPageViewHelper

dmFrontPageEditHelper

They both extend "dmFrontPageBaseHelper" and are not "abstract" which means they can be instantiated.

"myFrontPageBaseHelper" extends "dmFrontPageBaseHelper" just as "dmFrontPageViewHelper" and "dmFrontPageEditHelper" do so.

So I am assuming that the DI can inject "myFrontPageBaseHelper" in replacement to either "dmFrontPageViewHelper" or "dmFrontPageEditHelper" but I don't see

how it can magically make "dmFrontPageViewHelper"/"dmFrontPageEditHelper" extend "myFrontPageBaseHelper".

Furthermore, in the Diem documentation it states the following for the "page_helper" service.

Responsible for rendering the front content. Displays Areas, Zones and Widgets. This service has two implementations : page_helper.view_class and page_helper.edit_class. The implementation to use it chosen at runtime depending on the user permissions.

So to summarize, the classes have an inheritance by which the parent class cannot be replaced using DI (at least to my knowledge), but only those that extends "dmFrontPageBaseHelper". The documentation states that there are two services that can be replaced. 

Can you see where my confusion lies. Please if you could shed any light, and I can understand this better I would greatly appreciate it.

Best Regards,

Fotis Paraskevopoulos

<dmMultipleContentAreas1.patch><dmMultipleContentAreas2.patch>

[Fotis Paraskevopoulos]

Hello Again,

I am also trying to apply your patches and I am getting the following

$ patch --dry-run -p0 -i ~/Downloads/Mail/dmMultipleContentAreas1.patch 

patching file apps/front/config/dm/services.yml

patch: **** malformed patch at line 8: Index: apps/front/lib/myFrontPageBaseHelper.php

How did you create the diffs?

Best Regards,

Fotis

On Mar 11, 2010, at 07:25 , Loban Rahman wrote:

<dmMultipleContentAreas1.patch><dmMultipleContentAreas2.patch>

[Loban Rahman]

Not sure of the answer to your question of the top of my head (regarding the page services). Can anyone else shed some light.

I definitely want to make things more dynamic regarding the custom areas. The ultimate goal is to be able to drag in new areas, modify them, and delete them as easily as zones. When I get a chance I'll try and make a plugin out of this.

I made the patch files by doing an "svn diff" of my changes from a fresh diem project. I'll check to see if I screwed up somewhere.

Regards,
Loban Amaan Rahman

When the going gets scary, the scared get scarce.

[Fotis Paraskevopoulos]

Hello Loban,

I would like to help you with the plugin, when I understand exactly what you did :-).

Concerning my DI question, does overriding the page_helper.class work for you? 

I haven't gotten the patch to work yet, I am still working on it.

Hope someone steps up with my DI question.

Thank you,

Fotis