Rick -

I'm working with the wwUserSecurity class which renders the views/_login.wcs file. At the top of that file is the following..

<% Layout="~/views/_layoutpage.wcs" %>

As you know, the _layoutpage.wcs file contains the full HTML header section, plus RenderContent() and then the full footer section. I had already personalized the _pageheadertemplate.html and _pagefootertemplate.html files, and wanted to use those for the _login.wcs file.

I replaced `<% Layout="~/views/_layoutpage.wcs" %> with..

<%= RenderPartial("~/views/_pageheadertemplate.html") %>

..and added..

<%= RenderPartial("~/views/_pagefootertemplate.html") %>

..to the bottom of _login.wcs.

This seems to work exactly as I wanted, but I'm just wondering if that is really correct, or if there is something different to do which is the "proper way" to handle this?

- Mike McDonald

You can certainly do that, but what you're doing is essentially what the Layout page is meant to accomplish. I would move the content form the _PageHeader.html and _PageFooter.html into _layout.wcs so you have a Layout page you can use everywhere. There should be very little reason to use the _PageHeader.html and _PageFooter.html pages. Those are meant mainly for coded pages, and they are there primarily for non-script related features - code and error and status pages.

One thing you can't do with the partials is handle Section logic if you need to inject content from the content page into the partials, but you can with content pages. This is not really obvious at first, but is pretty important if content pages need to add scripts to the current page. There are other scenarios where that matters too, but the scripts and headers sections are the most common scenarios.

One thing you can do if you want to reuse is to pull the _Pageheader.html and _PageFooter.html pages into your _Layout.wcs page via RenderPartial() and then add sections and any other dynamic stuff. I didn't do this in the stock templates, because that tends to be more confusing for people getting started, but it's a good strategy as long as you have no logic in these templates. The layout page does have dynamic headers like the title which is something you can't really do with the static HTML pages (well you can but that's not what they are there for).

+++ Rick ---

Rick -

Thanks for the clarification. I wasn't sure if it was 'right' even though it worked as expected for my simple test.

How would I use _layoutpage.wcs for purely code-generated content? I expect to have WCS files for certain pages, and other pages which are fully generated by various process methods (just the 'content', not including HTML headers & footers).

The goal is to only have to update the _pageheadertemplate.wcs & _pagefootertemplate.wcs files OR the _layoutpage.wcs file, regardless of whether the content comes from a WCS file or VFP code.

Is that possible, or do I just need to keep the files in sync when changes are made to the layout?

Another question - is views\_pagetemplate.html actually used anywhere? I see wwProcess::PageTemplate() which loads it up, but that doesn't seem to be called from anywhere.

That method also caches the page after the <%= RenderContent() %> section has been replaced, which doesn't seem right. The <title></title> section is replaced after getting the file from the cache.

- Mike McDonald

A few things. I'm not sure what you're doing, but I would highly discourage purely data driven pages. There are very few use cases where this makes sense unless your interface is very dynamic (ie. you're building a sort of framework). For Application level HTML it's almost cleaner to use script pages to render your HTML, if for nothing else that you can easily tweak the HTML without having to recompile and redeploy the entire application.

Yeah all those files are for specific purposes that have lots of overlap but there's no good way to share the content.

• _layout.wcs - for script pages
• _pageheader.html/_pagefooter.html - for code foxpro pages
• _pagetemplate.html - for the Web Connection DLLs (Web Connection .NET Module/ISAPI)

The .html means these are meant to be static pages (ie. no script in there). All wcs are scripable and are driven through the Script engine. What you do with the HTML pages is really up to you, but they are meant to be just place holders for the quick and dirty functions. I can see that stuff be used for simple data browsers that don't do anything custom but just generically browse data using HtmlDataGrid() and HtmlDataRecord() for example (like the first couple of samples in wwdemo.prg).

For applications 90% of the time you'll want to use _layout.wcs or RenderPartial() reusable components.

+++ Rick ---