Piranha.core: Include of pages in razor views to make a single page website

[xxcrystalcat]

Include of pages in razor views to make a single page website, @html.Action(“mypiranhapageorpost”)

[tidyui]

Just so I understand you right. Do you want to iterate over some kind of collection in your model and then have a Razor helper to execute the page and print out it's .cshtml?

@model MyMainPage
<div>
  @foreach (var page in Model.SubPages) {
      @Html.RenderPiranha(page.Id)
  }
</div>

Or am I totally misunderstanding you?

[xxcrystalcat]

Absolutely perfectly understood 😊

Kind regards,
Christine Ollewagen
079 884 0630

On 04 Mar 2018, at 17:13, Håkan Edling <[email protected][e-mail]> wrote:

Just so I understand you right. Do you want to iterate over some kind of collection in your model and then have a Razor helper to execute the page and print out it's .cshtml?

@model MyMainPage

@foreach (var page in Model.SubPages) { @Html.RenderPiranha(page.Id) }

Or am I totally misunderstanding you?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/PiranhaCMS/piranha.core/issues/202#issuecomment-370236686, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AFhURPSnYgaDvAXLgGhiWhn8kR0WgOTSks5tbAShgaJpZM4SbRiv.

[tidyui]

Actually, I would say, depending on how #191 is implemented that a better solution would be to actually have a single page with an abstract list region holding the data of the blocks. This would make it much easier to handle caching and see when the page as a whole gets updated. This would give you something like:

public class MyMainPage : Page<MyMainPage> {
  [Region]
  public IList<MyBaseBlock> Blocks { get; set; }
}

And in .cshtml

@model MyMainPage
<div>
  @Html.DisplayFor(m => m.Blocks)
</div>

What do you think?

[xxcrystalcat]

I’m not really sure I understand that. I think I like the first solution better. Less complicated.
Kind Regards,
Christine Ollewagen
[phone]
www.crystalcat.co.zahttp://www.crystalcat.co.za/
[MCSD]

From: Håkan Edling [e-mail]
Sent: Sunday, March 4, 2018 5:31 PM
To: PiranhaCMS/piranha.core [e-mail]
Cc: Christine Ollewagen [e-mail]; Author [e-mail]
Subject: Re: [PiranhaCMS/piranha.core] Include of pages in razor views to make a single page website (#202)

Actually, I would say, depending on how #191https://github.com/PiranhaCMS/piranha.core/issues/191 is implemented that a better solution would be to actually have a single page with an abstract list region holding the data of the blocks. This would make it much easier to handle caching and see when the page as a whole gets updated. This would give you something like:

public class MyMainPage : Page {

[Region]

public IList Blocks { get; set; }

}

And in .cshtml

@model MyMainPage

@Html.DisplayFor(m => m.Blocks)

What do you think?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/PiranhaCMS/piranha.core/issues/202#issuecomment-370238002, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AFhURDmoeesqvvQ8ixxl7Ot1ER41wdGSks5tbAjNgaJpZM4SbRiv.

[tidyui]

I’m fully aware that building SPA’s from multiple pages is a common approach, one that I’ve used many times myself, but there are a number of benefits of doing it the other way. As it probably needs some in depth explaining I’ll write a full article on it that we use for discussion!

Regards

[tidyui]

A middleway would be to re-introduce the block concept of the old Piranha CMS version but make it a bit more complete. A block would have the same template features as a page but can only be a part of a page and not be routed to directly. Also by building it into the core it could be fetched together with the page in the same query, stored in the same cache entity and share the same last modification and cache invalidation rules as it’s page.

[xxcrystalcat]

An article sounds great! Thank you!

Kind regards,
Christine Ollewagen
079 884 0630

On 05 Mar 2018, at 09:24, Håkan Edling <[email protected][e-mail]> wrote:

I’m fully aware that building SPA’s from multiple pages is a common approach, one that I’ve used many times myself, but there are a number of benefits of doing it the other way. As it probably needs some in depth explaining I’ll write a full article on it that we use for discussion!

Regards

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/PiranhaCMS/piranha.core/issues/202#issuecomment-370331126, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AFhURDxElXkhii3a4EOVSrdySqAnIb_Nks5tbOgdgaJpZM4SbRiv.

[tidyui]

I've given this a lot of thought and I think that PageBlocks would be the way to go. Like I mentioned before a block would have the same templating features as a PageModel, but would reside under the page, not be visible in the sitemap and not be accessible directly from the site. Just like BlogPages, my idea is that pages that support Blocks would get a new region just like BlogPages where the current blocks are listed and you can add new blocks. Clicking on a block will bring you to its edit view.

This gives a number of benefits over working with regular subpages:

• It's more intuitive to content managers what the block actually is.
• Clicking preview while editing a block would open the preview link of the page the block belongs to.
• Saving a block can update LastModified of the parent page & invalidate it from the cache.
• As the block is a part of the page, the page and its blocks can be fetched in a single query, as opposed to one query per page.
• As the block is a part of the page, the blocks can be cached together with the page just like the other regions are.

All in all it would give the same benefits as working with subpages but eliminate a lot of pitfalls when working with SPA's and composite pages.

If there's any apparent reason why regular pages would be better to solve the job please let me know!

[LucGosso]

Blocks are a great approach, but then, let them also reside in a global block lib, so you can reuse them on many pages, like images. And then have a drag n drop ui to your block region on page.

Btw images should also have dnd ui.

[psijkof]

Great discussion. We would definitely need a blocked/componentized/modular approach in building pages and presenting it via the manager for the end user (where they can change the order, add blocks and update the content of the blocks).
Is there any relationship to DynamicPage?

[tidyui]

We have discussed this thoroughly and it looks like an EPI inspired approach is favorable.

• Blocks are a completely new content type
• Blocks can be created as shared, or be private to the page.
• Shared blocks can be reused on several pages and are also visible in the manager in its own list view.
• Blocks will have the same template features as pages & posts.
• Pages with Blocks will have a special region which shows the list of Blocks in a sortable list.
• Each Blocks will have a published date (from - to) on a per page basis.
• On a page that supports Blocks you will have the option to add a new, or an existing block.
• On each PageType you specify which BlockTypes are available for the page to use.

Let me know what you think about this!

[tidyui]

Basic functionality for Page & Post Blocks is completed in 5.0. Reusable Blocks & Block Groups has been moved to 5.1