[PR2] Page Manager and Content Manager Dichotomy


Jobe Fri Sep 18, 2015 1:47 pm

[PR2] Page Manager and Content Manager Dichotomy

Hello,

I've been following Nova NextGen with great interest—the "My Vision for Nova NextGen" articles have me very excited—and have been poking around in the preview releases. In PR2, there's the Page Manager and the Content Manager. When first looking at these pages, I couldn't really get my head around the purpose of the Content Manager; it just seemed like another, less explicable way to manage pages.

The only reference to the Content Manager in the Pages "Vision" article is:

If a page doesn't have a resource (controller) attached to it, you'll still be able to use the content section to put all your information in.


I'm not sure what that means in practice. For what purpose would a user create a page without a controller? (I'm thinking about how I would present the Content Manager differently to make its purpose more clear.)

Thanks for your time.

Posts: 9


AgentPhoenix Fri Sep 18, 2015 9:57 pm

Re: [PR2] Page Manager and Content Manager Dichotomy

That's actually a really good question, though you could be asking one of two questions, so I'll actually answer both questions just to cover everything.

You're correct that every page needs to have a controller, but the difference with the Page Manager is that a basic page doesn't require _you_ to create the controller or do anything in code. Instead, in the background, Nova has a specific controller method that it uses to render everything. That way you just need to supply a URI and the content and Nova does the rest. It's really great for simple pages that don't need to hit the database or anything.

That being said, the page compilers do allow you to pull some basic information back from the database. There are a few in there now and more will come. The hope too is that third-party developers will create compilers for their own stuff as well as any spots where Anodyne doesn't create a compiler.

As for the content stuff...

Every page has 3 pieces of content by default: a title, a header, and a message. Sometimes those items are blank, but they're there behind the scenes. Those are stored in a content table in the database. The idea about the content manager is that you can add other pieces of content there and pull it out with a page compiler (the page content compiler isn't in PR 2, but will be in PR 3). For example, you could store the year your sim takes places in and then in any basic page's chunk of text (like the home page or a sim page or a fleet page or whatever), you could do {% content:year %} and Nova will throw that content right into the block of text. Change the text in the content manager and it changes everywhere.

Now, that makes sense in my own head, but other people may read that and still not understand why there's a need for a content manager. Totally fair. That's the whole point of these preview releases, for people to see what's coming and be like "wait a second, this doesn't make sense" or "why do we need something like this."

Your feedback is incredibly valuable, especially at this stage. Great topic!
User avatar

Posts: 7561


Jobe Fri Sep 18, 2015 11:28 pm

Re: [PR2] Page Manager and Content Manager Dichotomy

Thanks for getting back to me on this.

I guess one thing I should be asking is what exactly is a controller? (I thought I had a handle on it, but...) Your reply makes it sound like something akin to a template; that is, it dictates the markup used to render the page. Is that right?

Also, could you clarify the distinction between “Content” and “Compiler” in your second answer? Is “{% content:year %}” a compiler that points to a piece of content in the Content Manager that is simply “2267” (for instance)?

That would make sense to me, but looking at the Content Manager in my PR2 installation, it doesn’t seem to be the case… In fact, because the Content Manager largely seems to reiterate the Page Manager’s content, but with the compilers made apparent (for example the default home page header reads “Welcome to the {% setting:sim_name %}!” in the Content Manager and “Welcome to the Enterprise!” in the Page Manager), it seems like the Content Manager is only a proverbial middleman between compilers and the Page Manager.

That can’t be right. What am I not getting about the purpose of the Content Manager?

Posts: 9


AgentPhoenix Sat Sep 19, 2015 3:11 pm

Re: [PR2] Page Manager and Content Manager Dichotomy

So when you request a specific URI, Nova's foundation (Laravel) looks up what resource should be called to render that URI. (A resource is the controller and a method in that PHP class.) So when you hit the home page, Nova knows that it needs to grab the MainController file and call the page() method. Once that's called, all the magic happens so that the page gets rendered to the browser. That's the same process for any basic page. It means you can create basic pages without having to touch any code.

On the flip side, if you wanted to do something more advanced or customize some stuff or hit the database or whatever, you'd have to create an extension with your own controller(s) and then tell Nova that when a specific URI is requested, to use that resource. (You can see some examples of this in the Page Manager if you look at some of the admin pages.) This is sort of the same process as Nova 2 is today. If you want to create a new page, you've gotta dig into the code, no matter how simple. The Page Manager, and basic pages in general, allow for those same simple pages but just with a few clicks.

Make more sense?

Correct, the content manager is re-displaying stuff that you already see on the page manager. It might make more sense if anything that's directly tied to a page isn't displayed there. So by default, you'd see an empty list there and then you'd be able to add stuff to it if you want. I'll have to work on an intro paragraph too that explains that a little more. Do you think that might make the whole thing make more sense and seem more intuitive if you aren't see all the content from pages already in the page manager?
User avatar

Posts: 7561


Jobe Sat Sep 19, 2015 6:56 pm

Re: [PR2] Page Manager and Content Manager Dichotomy

Okay, I think I understand now. You need a controller no matter what. You just don't necessarily need the page controller; you could use a controller of your own design. How about this:

What if on the Page Manager, there was another attribute for each page: controller (maybe call it something more accessible, but for now let's just call it a controller). Those of the default pages would be simply "page."

When creating (or editing) a page, the controller in use would be visible as a select menu. By default, "page" would be the only option, but developers who create their own controllers would register those controllers and they would appear in the select menu when the controller was added. Selecting one would change the Page form from the default fields to those specified by the new controller. (Destructively, maybe. I don't know if there's a good way around that.) In this system, "Page" now refers to any assemblage of content with a URI, not just assemblages of content that use the default controller.

I think the best use experience would be to treat pages and custom controllers as similarly as possible. If I understand what you've said, a "page type" selection option might eliminate the need for the Content Manager in it's current form altogether!

EDIT: Custom controller creators would have to create the creation form (equivalent to the Page creation form) for their controllers though. I don't know how much of an added burden that is.

I really hope what I just said makes sense. Let me know.

EDIT Again: If the above is no good, then yes, not duplicating content from the Page Manager in the Content Manager would help.

Posts: 9


AgentPhoenix Sun Sep 20, 2015 12:57 am

Re: [PR2] Page Manager and Content Manager Dichotomy

I think there are 2 totally separate conversations going on and the signals are getting a little crossed.

The Content Manager piece of the conversation revolves around it being a duplication of much of the information found in the Page Manager. I couldn't agree more and I'm gonna look at narrowing down what's shown in the Content Manager so that duplication doesn't exist and it's clearer what the Content Manager is for. Game, set, match.

For the Page Manager conversation though, admittedly I'm totally lost at what you're talking about. From what you're saying, I'm not sure you understand the whole idea of pages and how those are put together... If you can provide a little more clarity around what you mean, that might help...

I'd definitely encourage you to look through the controllers in the core to understand those classes a little better and how they're used. Flipping through the database tables that control pages and content might help too. Finally, check out the differences between basic and advanced pages by changing the page type when you create a page as you'll see the differences afforded someone when they create an advanced page versus a basic page.

It should be noted that for most people, they'll never touch that page... developers will have the tools to create the page records when an extension is installed so the developers who know the paths and everything and how their extension is set up will be able to do all that legwork for general users instead of the users needing to do anything with that.
User avatar

Posts: 7561


Jobe Sun Sep 20, 2015 3:14 am

Re: [PR2] Page Manager and Content Manager Dichotomy

Okay, so an equivalent to the select menu I proposed in my previous post is actually already present in PR2; I just missed it before: it's the "Resource" field in Advanced Page Creation. I suggested a select menu instead of an input field thinking that a list of available class names could be automatically generated by looking at the installed extensions (thus avoiding the possibility of mistyping a class name), but that may not be feasible.

That covers the first half of my previous post; I was asking for something that was already there. As for better explaining the second half of that post, first I have to check whether or not I understand the purpose of the Content Manager:

If I installed an extension, created an advanced page to make use of it, entered the appropriate class name in the Resource field, and created the Page, I would then have to go to the Content Manager to create any blocks of content (other than the standard title/header/content trifecta) that were called for by that extension, right?

AgentPhoenix wrote:It should be noted that for most people, they'll never touch that page... developers will have the tools to create the page records when an extension is installed so the developers who know the paths and everything and how their extension is set up will be able to do all that legwork for general users instead of the users needing to do anything with that.

Here's an alternate version of my last question with this in mind: if I installed an extension, it created a new page for me, and I wanted to edit a non-title/header/content block associated with that page (presuming the extension created that as well), I would find that block in the Content Manager?

Posts: 9


AgentPhoenix Sun Sep 20, 2015 10:11 am

Re: [PR2] Page Manager and Content Manager Dichotomy

Correct. The resource field is what determines the PHP class and method that are used for that particular page. It would be possible to generate a dropdown menu, but the issue there is that it's highly inefficient and expensive to do so since it would need to use PHP's Reflection class, so you'd end up sitting there for a bit while it tries to find everything. And really, you'd be talking about 2 dropdowns: one for the class, then after the class is selected, another call to Reflection to find the public methods for that class. I just think it could create a negative experience with the Page Manager if you're constantly waiting for the server to look up information on a majority of the classes that exist.

I'll look into whether I can build a validation rule that checks to see if the supplied class exists to capture for a situation where a user mis-types the class name (though that will only apply when creating the page manually... when developers use migrations, they'll have to check that stuff themselves).

As for the second part... yes and no.

For an advanced page, you don't have to use the Content Manager at all. Advanced pages need to have their own views (whereas the basic page skirts around that issue in some creative ways), so you really could just put any content you want right in the view file... you wouldn't even need to use a header or message. (While the title can be done in the controller, it's easier to just let Nova handle that piece for you.) Yes, you can put additional content in their, but you'd have to query for it out of the table yourself since the page compilers can't be used in view files, only in content blocks that are stored in the Content Manager.
User avatar

Posts: 7561


Jobe Sun Sep 20, 2015 11:11 am

Re: [PR2] Page Manager and Content Manager Dichotomy

AgentPhoenix wrote:I just think it could create a negative experience with the Page Manager if you're constantly waiting for the server to look up information on a majority of the classes that exist.

That's true.


AgentPhoenix wrote:For an advanced page, you don't have to use the Content Manager at all. Advanced pages need to have their own views (whereas the basic page skirts around that issue in some creative ways), so you really could just put any content you want right in the view file... you wouldn't even need to use a header or message. (While the title can be done in the controller, it's easier to just let Nova handle that piece for you.) Yes, you can put additional content in their, but you'd have to query for it out of the table yourself since the page compilers can't be used in view files, only in content blocks that are stored in the Content Manager.

I was thinking more about a situation where additional material would need to be added by the user instead of directly in the view file by the extension writer. More accurately, I was picturing (and trying to describe) a page creation system where selecting the page resource would immediately switch the page creation blade to a view defined by the extension creator. (The flow might be something like "Add a New Page" -> "Page Type: Advanced Page" -> "Enter Resource Name" -> Show a custom page creation view if the resource points to one, otherwise show the default page creation view.)

Posts: 9


AgentPhoenix Sun Sep 20, 2015 1:19 pm

Re: [PR2] Page Manager and Content Manager Dichotomy

I think the better question is why would an extension have a need to change the way pages are created?
User avatar

Posts: 7561


Jobe Sun Sep 20, 2015 1:28 pm

Re: [PR2] Page Manager and Content Manager Dichotomy

You might want multiple content areas in a page rendered distinctly from one another (and don't want the user to have to write the HTML distinguishing the two areas)?

Posts: 9


AgentPhoenix Sun Sep 20, 2015 1:49 pm

Re: [PR2] Page Manager and Content Manager Dichotomy

If someone wants to do something like that, they need to create a controller and view for that. The whole reason advanced pages exist is for stuff like that.
User avatar

Posts: 7561


Jobe Sun Sep 20, 2015 1:53 pm

Re: [PR2] Page Manager and Content Manager Dichotomy

I understand that. But if a particular kind of advanced page needs its own view to display properly, doesn't it also need (or shouldn't it also have) a custom view for being created and populated properly?

Posts: 9


AgentPhoenix Sun Sep 20, 2015 2:45 pm

Re: [PR2] Page Manager and Content Manager Dichotomy

A basic page utilizes regions within the templates to render the title, header, and message without needing a view file. So in reality, there is a controller method behind the scenes that's hit when you access a basic page, but nothing actually happens in that method... it's completely empty. The base controller class has some post controller method processing code that then grabs all the pieces it needs and pulls them together and sends that response object back to the browser as the page you see. Because the templates have regions for title, header, and message, basic pages can look and act like static pages without a user needing to do any kind of code work. That really was the point of the Page Manager because creating pages in Nova 2 is a major pain point. Safe to say, mission accomplished.

For an advanced page, the exact same thing is happening, the only difference is that the details are exposed for developers to have total control over what's happening (defining the HTTP verb, the resource, routing conditions, etc.). Advanced pages aren't meant to operate like basic pages in the sense of click-click-click and you've got a page (what you're referring to as creation and population). The developer is responsible for everything at that point (save for the title, header, and message which can, but don't necessarily have to be, populated from the content table). The developer creates the resource and points the page record toward that resource and then that resource takes over for everything... hitting the database, displaying the view, Javascript, styling, the works. (Developers can leverage a base controller class for rendering and lower level stuff, but they're also free to do that themselves if they really want.) Like I said, the same thing happens for a basic page, it's just that those details are obscured for simplicity.

In the scenario you're talking about, the advanced page isn't editable like a basic page is. (You can see that if you edit any of Nova's core pages, save for the homepage which is a basic page.) There's not a whole lot to edit because all that work is handled in code. If I want a form or whatever, I have to build that form into the view file; if I want other content available, I need to build that into the view; if I want to pull content in from the Content Manager, I have to use the content repository to grab that content by its key to display. Ultimately, it's my responsibility to do all of that... the Page Manager won't do any of that for me.

For what you're talking about, allowing developers to change the process of creating a page, a concept that's central to how Nova is routed for the underlying framework, would create a terrible user experience in my opinion. Users would end up confused why they can do something for one page but not for another or why X works differently than Y.

That being said, this is still an open source project, so if it's something you feel incredibly passionate about, then I'd encourage you to submit a pull request or send some mocked-up images showing what you're trying to articulate. I'm really not understanding what you're getting at or what the purpose would be, but maybe seeing some kind of implementation of it would make it make more sense to me.
User avatar

Posts: 7561


Jobe Sun Sep 20, 2015 2:54 pm

Re: [PR2] Page Manager and Content Manager Dichotomy

AgentPhoenix wrote:For what you're talking about, allowing developers to change the process of creating a page, a concept that's central to how Nova is routed for the underlying framework, would create a terrible user experience in my opinion. Users would end up confused why they can do something for one page but not for another or why X works differently than Y.

I don't know. "Custom Post Types" in Wordpress operate along these lines and were (as far as I know) pretty well received. It would be up to the developer changing the page creation process to smooth out the user experience, though.

AgentPhoenix wrote:That being said, this is still an open source project, so if it's something you feel incredibly passionate about, then I'd encourage you to submit a pull request or send some mocked-up images showing what you're trying to articulate. I'm really not understanding what you're getting at or what the purpose would be, but maybe seeing some kind of implementation of it would make it make more sense to me.

Mockups sound like a good idea. I'll see what I can whip up.

Posts: 9


Next

Return to Nova NextGen

Who is online

Users browsing this forum: No registered users and 2 guests

cron