Getting my head around the intermediate default profile

Russell · September 28, 2014

So I've been mulling over the tutorial on the intermediate default site profile today (http://processwire.com/docs/tutorials/default-site-profile/page3).

I just want to clarify some things when comparing to the basic profile.

Because there is only one _main.php for the whole site, it would need to contain the code for ever different section on any page in the site, wouldn't it? I can see how this is all fine is every page has the same structure, but if you wanted many different and varied page structures that didn't overlap much, wouldn't this mean there is a lot of redundent code being loaded each time?

It would seem the basic structure would have an advantage in smaller and easier to read code for each template page, although admittedly each template would have to be bigger and have possible duplicate code from other pages, in this case.

I can see the advantages of the intermediate format, but I'm just concerned that in a site that has many different structures across it's pages, that the _main.php could become rather large and hard to read?

Or have I misunderstood something?

Thanks.

Russell.

Martijn Geerts · September 28, 2014

Because there is only one _main.php for the whole site, it would need to contain the code for ever different section on any page in the site, wouldn't it?

The idea behind this concept is that _main.php would NOT contain any logic at all. The only thing that _main.php will do is echo out the variables & markup. Default variables are created in the _init, if needed, those variables can be overwritten in the template.

+----------+
| _init    | $title   = "<h1>$page->title</h1>";
|          | $content = "<div class='seventy-five_percent_wide'>$page->body</div>";
|          | $sidebar = "<div class='twenty-five_percent_wide'>$page->sidebar</div>";
|          |
|          |
+----------+
     |
+----------+
| template | Contains Logic. 
|          | 
|          | $title   = "<h2>$page->title</h2>";
|          | $content = "<div class='fifty_percent_wide'>$page->body</div>";
|          | $sidebar = "<div class='fifty_percent_percent_wide'>$page->sidebar</div>";
+----------+
     |
+----------+
| _main    | This file only outputs Markup. There's no 'logic' here (read no if statements and stuff) 
|          | And the variables ($title, $content & $sidebar) will will be echoed here.
|          | 
|          | 
|          |
+----------+

In the code block, you can see that the variables $title, $content & $sidebar are first setup in _init. We see the following:

The title is a <h1> header.
The content is markup with a column of 75% wide
The sidebar is markup with a column of 75% wide

This are nice defaults as most of our pages are structured like this. When we want these defaults, the template file can be empty.

But if we need a page with 2 columns equal wide and have a H2 header instead of the H1, we could overwrite the variables in the template file.

As you could see in the code block, we overwrite $title, $content & $sidebar.

The main file could simply look like this:

<!doctype html>
<html lang=en>
<head>
<meta charset=utf-8>
<title><?= $page->headline; ?></title>
</head>
<body>
<?= $page->title; ?>
<?= $page->content; ?>
<?= $page->sidebar; ?>
</body>
</html>

mr-fan · September 28, 2014

this template approach is more like one step further to a template engine (or even call it a template engine)...

You complete separete the logic from the code.

the advantage could be that a desinger could use the given vars $title, $content, $sidebar and change the main layout with this vars.....but you are right it is not the reall holy grail....since some html tags in the pagetemplates, too.....

it's just a other logic behind - you could choose what fits for you best.

some like to have split in logical parts like header - content - footer - and some wanna have the main logic together and the content logic separate - it's up to you -

regards mr-fan

(Martijn was faster and more proper )

Russell · September 28, 2014

I'm afraid that doesn't clarify anything for me.

Here's a section of code from the main.php

	<div id='main'>

		<!-- main content -->
		<div id='content'>
			<h1><?php echo $title; ?></h1>
			<?php echo $content; ?>
		</div>

		<!-- sidebar content -->
		<?php if($sidebar): ?>
		<div id='sidebar'>
			<?php echo $sidebar; ?>
		</div>
		<?php endif; ?>

	</div>

Looking at that, if I wanted to have multiple different formatted pages, I'd have to do things like "if ($sidebar2)", "if ($table-of-content)", "if ($alternate-header)" etc, wouldn't I?

*edit*

I posted this before seeing mr-fan's reply, but still, do you agree with me?

kongondo · September 28, 2014

Russell,

Have a read here: http://processwire.com/docs/tutorials/how-to-structure-your-template-files/page4

Whether or not you should use automatic inclusions kind of depends on the situation. If you are working with a site that has various output needs, some direct and some delayed, then automatic inclusions may get in the way. Likewise, if you have more than one main.inc file (perhaps representing different layouts) then it might be preferable toinclude() whatever output file you desire at the end of each template file. You may find in some cases that you'll use $config->prependTemplateFile, but not $config->appendTemplateFile. Again, it really just depends on the situation. However, now that you know about automatic inclusions, we think you'll find them very useful in many instances.

Also, in the tutorial you referred to, it says:

In this default site, our needs are simple so we've defined placeholders for just 3 regions on the page.

So, there will be cases where you might need more than one 'main.inc'....of course they would have different names. But, the idea is to try and reduce these to as few as possible so that you can reuse code/markup as much as you can....

mr-fan · September 28, 2014

	<div id='main'>
		<!-- main content -->
			<?php echo $content; ?>
		<!-- sidebar content -->
			<?php echo $sidebar; ?>
	</div>

this would be the main.php and the basic logic would be in the _init.php like this:

// if the current page has a populated 'sidebar' field, then print it,
// otherwise print the sidebar from the homepage
$homepage = $pages->get('/');

if($page->sidebar) echo '<div class="mydiv">'.$page->sidebar.'</div>';
else echo '<div class="mydiv">'.$homepage->sidebar.'</div>';

and in a pagetemplate you could overwrite the $sidebar or extend it! so all logic is in the _init.php (basic output) or the template for the pagetype!

example special-page.php

//overwrite it
$sibebar = $page->specialField;

//extend it
$sidebar .=$page->specialField;

just written fast written in the browser....

Martijn Geerts · September 28, 2014

For me there's too much logic in the main template in the example ryan has given. (if statements)
I prefer to build the variable Markup in the template. Not in the _main.php

<!doctype html>
<html lang=en>
<head>
<meta charset=utf-8>
<title><?= $page->headline; ?></title>
</head>
<body>

  <header><?= $header; ?></header>
  <nav><?= $nav; ?></nav>

  <div id='content'>
    <?= $page->content; ?>
    <?= $page->sidebar; ?>
  </div>

  <footer><?= $footer; ?></footer>

</body>
</html>

I almost always use this approach, except that I do not use the automatic prepend and append functions from ProcessWire.
I use a include(./_init.inc) and a include(./_main.inc) in the template file.

template file
+---------------------+
|include(./init.php); | 
|                     |
|$title = "<h1>...etc.|
|$content = "<div>... |
|                     |
|                     |
|                     |
|include(./main.php); | <-- could be changed, maybe we want to include ./special-main.php
+---------------------+

When I need a major change how the page should look like, I could decide to include an other 'view' page in the bottom.

Russell · September 28, 2014

OK thanks for the feedback guys. I'll have to mull it over during the night, and hopefully my sub-conscience will have a EUREKA! moment

I just don't want to start down one track and find I have to re-write it all. The problem is, my "clients" (i.e. the people who asked me to re-launch our community website) have only basic requirement at the moment, but I can see them wanting to add more & more as they start to use it.

ryan · September 28, 2014

For me there's too much logic in the main template in the example ryan has given. (if statements)

Logic is too broad a term. There is presentational logic and there is application logic. IMO the logic you want to keep out of the main template is application logic, not presentational logic. If there is presentational logic that applies to most pages in the site, then I really prefer to have it in the main template, or at least include()'d from the main template. It comes down to what's going to simplest to maintain long term. If something presentational needs to be manipulatable by other templates, then of course it should go in it's own placeholder variable. But if it's not, then delaying that output or moving it somewhere else is just more overhead and things to keep track of.

I prefer to build the variable Markup in the template. Not in the _main.php

This is of course just fine, and everyone's got different methods that work best for them. But I would also suggest that the more markup you can keep in your main template (that's common to most pages) then easier it is to maintain over time. Easy to maintain means different things to different people, so I should qualify that to me "easy to maintain" is when the site-wide markup is in fewer places, fewer files to update, etc.

...but you are right it is not the reall holy grail....since some html tags in the pagetemplates, too.....

I don't think the holy grail is necessarily eliminating html tags from your template files. That's what I did with the blog profile, sticking to an MVC approach. But I don't find it as maintainable as default site profile intermediate method (maybe for a team, but not for an individual developer). Further, and somewhat to my disappointment, I think most find the blog profile (sticking to an MVC approach) difficult to understand. The fact is that this approach means more files, more things to keep track of. It's the right solution for some cases, but it's no holy grail. I think instead the holy grail is KISS + DRY (keep it simple stupid + do not repeat yourself).

If you've got markup going in a template file where the same markup is going in another template file, then put it in a shared function, include file, template/view file or a class/hook or something (I prefer functions myself). If you've got to change something, make sure you only have to change it on 1 place. The end result ends up being most template files have little or no markup, not unlike the MVC blog profile… but a whole lot easier to understand and maintain– you've KISS'd it, minimizing the number of places where markup appears and not adding extra unnecessary overhead and files.

The benefits of going further MVC become apparent when you work in a team where the concerns are split along the same lines as the files. In that case, more files is beneficial. The front-end markup girl/guy focuses purely on the view files, and the back-end developer focuses purely on application logic. But if it's not a team project like that, and isn't going to be, then following that approach is kind of like trying to avoid stepping on the seams in a tile floor as you walk across it…

Because there is only one _main.php for the whole site, it would need to contain the code for ever different section on any page in the site, wouldn't it?

Think of "main" as meaning "main" (like primary), not "all". One example of different layouts can be seen in the intermediate profile's _main.php where it adds a has-sidebar class to the body tag when a $sidebar variable has something in it. But there's no requirement that _main.php be used by every template file. You can disable the $config->appendTemplateFile in your /site/config.php and include your own, like Martijn outlined above. Or you can edit your template in the admin: Setup > Templates > [your-template] > Files. Check the box to disable auto-inclusion of _main.php, or specify what file you want it to include instead.

Joss · September 28, 2014

The vital thing for you to do is to construct your files in such a way as you find easy to maintain and work with.

For myself, I take a pretty non-techy approach, which probably means it is far from the best. But it works for my sort of head.

I am a composer and when I compose music I start with a melody and then I build the rest of the arrangement around it on different tracks - different parts of the score. The main melody is the constant. I write the same way.

So with ProcessWire I do the same thing.

I start with a huge great DIV that will contain most of my look and feel.

In the middle of that I will put my main theme. "Hello, this is my website"

Then I add the arrangement around it - a header, footer information, and so on.

When it comes to making changes in the arrangement, I will have a functions file with lots of goodies - listing of child pages, news listing, galleries and so on. These get pulled in by the conductor when and if needed.

So, at the end of the day, most of my pages are probably based on one template file, with other files included - head, foot, functions, end page scripts, whatever.

I know having a head and foot is terribly old fashioned, but it works fine for me. And if I do need other templates that are working in radically different ways, then I just copy and paste my includes over and off I go again.

In a way, looking at any existing profile and using it as a starting point can be confusing and misleading. ProcessWire doesn't care which way you work, after all.

So, install the blank template and just get writing some good old fashioned html.

There you go - a sunny Sunday afternoon magazine style comment.

Joss

mr-fan · September 28, 2014

The holy grail thing......I'm not a real fan of the real mvc approach, too. But I thought that Russell looks for more dividing code from HTML....

For me I use functions, too and I like the _main.php approach....

Russell · September 28, 2014

Think of "main" as meaning "main" (like primary), not "all". One example of different layouts can be seen in the intermediate profile's _main.php where it adds a has-sidebar class to the body tag when a $sidebar variable has something in it. But there's no requirement that _main.php be used by every template file. You can disable the $config->appendTemplateFile in your /site/config.php and include your own, like Martijn outlined above. Or you can edit your template in the admin: Setup > Templates > [your-template] > Files. Check the box to disable auto-inclusion of _main.php, or specify what file you want it to include instead.

This is pretty much the answer I was looking for. I guess the thing I was concerned with was that splitting the page appends into multiple separate files creates more complexity in the site. Many moons ago when i was making a site based on Zurb Foundation it became very difficult tracing through the many sub-layers of code to find bugs or just even understand what was going on. I like the idea of having less files to look at. I was just worried that the structure may not be flexible enough for more complex sites. I think I see now that its safe to start this way but easily expandable if needed.

Thanks for the explanations.

cstevensjr · September 28, 2014

The great thing I like about PW is that you never are forced to do something in a particular way on the front-end. You actually have many choices on how your website is gonna be structured. I haven't found any other platform that gives you that amount of freedom to develop your website or application.

That can lead to problems, because people are used to being told (forced) to develop or create a certain way. Once you start working with PW, you are left to decide for yourself. I believe that can be intimidating to some, because they never had the freedom to choose before. Over time, the light goes on in their head when they finally understand and realize that what gets created is whatever they want to be created. I believe it's very hard to settle upon the fact that you can design or develop with no limits to your creativity.

PW is constantly improving with documentation and videos (and that is wonderful). The real truth is that PW is such an open platform that we could never cover or teach all the different possible ways of working with it. There really is no right or correct way to do things. If a certain way works for you -- that's great. If you change your mind and want to do it another way --- you can. What you ultimately end up with is a website based on your needs, crafted based on what you know how to do.

Russell · September 28, 2014

Yeah I think you've hit the nail on the head. Being a programmer, but not a web developer or designer, I'm left with the freedom to do what I want, but the dilemma of not know how to go about it from scratch. Other CMS's give you no freedom, but a very simple ruleset to follow if you want to make canned changes within their frameworks.

jordanlev · September 29, 2014

I am a newbie to ProcessWire, but a very experienced web developer (using a variety of other CMS's and frameworks). I think the big picture here, as others have stated, is that PW doesn't really dictate any particular style for structuring your templates -- what you're seeing in the intermediate profile is just an example of how some people choose to do it.

I personally do not like that method at all, because I build a lot of sites with very custom designs, so the markup I get from designers is very important and usually I like to keep my CMS templates as close to the original markup as possible. I do not like putting html into variables, and I do not like treating my template output as some kind of machine that generates markup. On the contrary, I like to take the markup I'm given and intersperse content variables in the slots they belong.

But I understand that a lot of other developers are not as design- or markup-focused, and instead prefer to treat the html as just something outputted from their own system. My least-favorite CMS I've ever used is Drupal, because the whole thing is based on this mindset of contorting your markup to work within its system of outputting stuff. My most-favorite CMS's are ones that just give you the data and let you output it any way you want (CMS Made Simple, Concrete5, ProcessWire, etc.).

So I don't really have a point here, other than wanting to pipe in and let you know that you are *not* doing anything wrong or thinking about anything the wrong way! You should just ignore the way things are done in the intermediate profile (what the PW folks are calling the "delayed output method") and instead stick to the way things are done in the basic profile (what the PW folks are calling the "direct output method"). There is no "eureka" moment really, other than understanding that some people see the world in different ways

So if there were one thing I'd want to change about how these profiles are done, it's just that I think calling one "basic" and another "intermediate" gives the wrong impression -- I think it would be better to refer to them as "simple" versus "concentrated", or "designer-focused" versus "programmer-focused", or "markup-oriented" versus "architecture-oriented" -- some way to indicate that they are two different ways to do things and one is not more "advanced" or "better" or "farther along the path of learning" than the other. Just my two cents though.

Joss · September 29, 2014

Just one other thing:

I don't think one method is any more efficient than another from the point of view of load times and so on - at least, not by very much.

So, it really is down to how you like to organise your head!

diogo · September 29, 2014

I also tend to the "direct output". If I'm writing HTML, I prefer to see the HTML. On the other side, one day I want to build an entire website only by using PHPs DOMDocument http://runnable.com/VCkzbk2_lq8s39vR/domtest-for-php

By the way, that runnable.com site is great!

Sign In

Getting my head around the intermediate default profile

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Create an account or sign in to comment

Create an account

Sign in

Recently Browsing 0 members