on release or sometime in the future?
Caught my interest in the RLM forum!
Thanks!

Hiya SmaLakes2,

If it's anything like the current RLM, there will not really be a need for a masterpage feature.

The reason I am on that way of thinking is because with RLM you create all of your CSS and ID's (if you need to) as you go along or the program has default ones that it refernces. It's extremely easy to duplicate a page and rename it to a new page which makes it wonderful for keeping main structure intact of your Header, Footer, Side Bars etc, and whatever else you want to keep the same. Unlike VSD where you have to copy everything from one page to the next, this program just duplicates the entire page intact as is. No fuss, no muss.

Why does that matter? Well because it does it this way, the need for a master page is pretty much eliminated because "all" pages become master pages in a sense. The main thing to do would be:

1. Create your first page, get it as complete as possible and be sure you name all your pertinent classes so they make sense to you.

2. Once you have that page completed you should now have your entire Header area for your Logo, Menu, etc. all intact and set exactly where and how you want it, your footer built to your needs, as well as any side bars you want on each page.

3. From here, duplicate that page and alter to your hearts content all the areas of the main content area. This keeps your entire Header and Footer and Sidebars intact while giving you full reign to alter the structure of your main content areas any way you like.
Rinse and Repeat.

That's pretty much how it works in a nutshell (granted it's not that easy to learn it as it sounds, but it's not that hard either once you get the hang of it). That's how it is for RLM anyways, and I'm going to guess that the new program will have all that and more so I think our days of "master pages" are numbered.

Hope that helps!

"Hiya SmaLakes2,

"....
That's pretty much how it works in a nutshell (granted it's not that easy to learn it as it sounds, but it's not that hard either once you get the hang of it). That's how it is for RLM anyways, and I'm going to guess that the new program will have all that and more so I think our days of "master pages" are numbered
...."

Hi Jo Ann.. For overall content and site structure/format, I agree with you. But with all due respect, not so sure "master pages" are numbered just yet..

When one is designing their own website, your post makes sense, basically because you will know ahead of time what kind of site you want, what it's content will be, and will make provisions accordingly at time of "design" for future updates.

However when doing a customer site, that's not always the case.. Not a big deal if the site only has a few pages. Real life example (and if someone can explain to me how to do this in RLM Pro, I'd be very appreciated..) I do a 15+ page website for a customer who is constantly asking me to "add a link to the nnn page in the menu", where nnn might be a new event coming up, as an example.

Using RLM Pro, I would have to update 15+ pages, adding the new menu item, link, etc... Then when the event is over, I have to go back and update those 15+ pages again to remove it..

Using a "master page", I make TWO updates (one to add and one to remove), refresh, upload and I'm done. It would take me less time to update an entire site this way, then using RLM Pro just doing the first 5 pages..

I understand that RLM Pro is not structured for this and that's ok. It's still a great product. But unfortunately for very large websites with frequent updates, I don't see how using this is a benefit - except for the responsive layout - but that goes without saying...

RLM doesn't restrict your content, it allows you to plan where it will be and how it will display at different screen sizes; you're still going to need to add the actual items to the layout back in the Editor, whether it's a video, calendar, slideshow, blog... So you could create a section in your layout for the menu and use a PHP include for the menu files. Even an Iframe would work, though they're a bit tricky in responsive designs.

I would also look at using a CMS (content management system) for sites that need frequent updates and content changes. Some, like Perch let you make certain areas of the page editable so the client could update his own events or news as needed. From the Perch site, here's a responsive site using the Bootstrap framework (which is included in RLM) and Perch: http://okcms.org/

Ok whats up with the 2 accounts posting in different areas the exact same posts????

You need to start wielding that frying pan, Jo Ann.

I'll suggest that future versions of RLMP take a harder look at the master page concept as it's called in MS Visual Studio ASPX pages. In the newer MS MVC model it's called a "Shared" file and usually named _Layout.cshtml. Although Bootstrap is the default CSS package for MS MVC, I really like the control one gets with RLMP. However, the master page concept is an integral part of the whole Microsoft scheme of doing web development and I doubt that CoffeeCup just wants to ignore that little group of developers.

I'm just now learning MS MVC and the "master page" or "shared layout" thing was a real problem for me using RLMP. And, I just don't think the suggestions made here about how to get around the problem are going to cut it with MS developers. What I've done so far is a kind of clumsy work around:

- I created and exported the layout I wanted for my common head and foot areas (logo, menu, graphics, logon, etc) and copied the folders/ files into my Visual Studio project to create the _layout.cshtml file
- ASPX and MVC both have standard ways of using the shared html and that is beyond this discussion and probably not all that important for here.
- Then I created and exported a layout for each web page that was unique in some way and was careful to give every element a unique class name - every row, column, image, etc
- Then I set up two CSS folders (css1, css2) and put multiple "main.css" (main1, main2, etc) for each layout into the second one (css2)
- So, the shared part used the regular grinder, wireframe, and main files and the unique pages added a unique "main" to override the original one
- In most cases, the "main" file was sufficient to take care of a unique page - that also used the shared layout. However, in some cases I had to include the unique coffeegrinder and wireframe-theme files for the unique page. This was the awkward part.

So, it works but it's not ideal. What would be a heck of a lot better is if the "main.css" file could be counted on to hold all the unique info. As an example of where it did not was when I tried to change a row of images from 4 columns to 2 columns to 1 column as the size went from desktop to tablet to phone. I had unique class names on everything I could imagine and the html also look like it had the right tags - but it would not change from 4 columns unless I included the grinder and wireframe files to the unique page to effectively override the ones used by the shared part - lots of duplication.

This may be a bit hard to visualize unless you're a Microsoft developer.

The idea of Master Page / Template / Shared Layout or help with page replication is handled well by content management systems because their users desperately need something like that in order to handle potentially thousands of possible pages. I suggest a Google deep dive order to learn about CMS benefits.

Ok once again I'm going to ask the obvious questions lol.

What's wrong with the ability to duplicate pages as it is right now? You can rename a page to be anything you want so if you create a page and you want it to be a master layout then name it Master-Layout-2-column and Master-Layout-3-column etc. Create your master pages all in one project even, then..... open the project and save it as your new project and you now have pages that are 3/4 finished with various layouts for them. It's not that hard to do and it's actually quite a good setup for it.

Better yet, create separate master projects for various layout designs and choose from your own variety each time you create a new site.

Want to use a specific page again, just duplicate it and alter your content accordingly. Pretty simple if you ask me, but then...

My point is that the master page concept is a reality in the Microsoft world and I'm not about to suggest they should adopt a different methodology - I'm just a lowly programmer trying my best to use their tool set. Which I happen to like very much for many reasons.

However, that aside, I wouldn't be at all eager to adopt your suggestion for any kind of medium or large sized project. With no intent to be argumentative , it seems you're missing the real benefits of the master page concept. Here are just a couple of thoughts:

- The master page (and even multiple layers of master pages) are blended together at run time - there is no duplication of code. The act of duplicating pages creates both an unnecessary maintenance chore and also invites inconsistency if the changes are not replicated completely and accurately. Duplication is just not realistic for many projects.

- The master page concept also provides for dynamic content between a master page and a child page. This is an often used technique.

- Master pages often contain links to external scripts and style sheets that require updating and doing this one place is far more efficient and less error prone than doing this in multiple duplicated pages.

As I said, I'm not really the right person to justify Microsoft's architecture. If you want a meaningful discussion about this I suggest posting on http://forums.asp.net/

My basic point is that the master page concept is a reality in the Microsoft world and no amount of suggesting otherwise is going to change that. Further, I think that CoffeeCup could take a big step into that market by trying to work with the concept and not try to simply suggest a different approach.

I've been thinking about making a fresh post related to this topic that focuses on main.css and how some small changes could help this problem quite a lot.