Master web page

I am still trying to get my head around this OOPs thing so I thought that it should be possible to create a web page in my project called “frmMasterActionPage” with all of the standard stuff on it and then in Super of a new page I could point it to the “frmMasterActionPage” and all of the controls etc would become part of the new page but I cant seem to get this to work as the master page is not an option in the list. Is it possible to do this or am I asking too much?

I’ve found the best thing to do for web apps is to have one page. I just dynamically load a remove WebContainers to do everything I want. It works amazingly well.

I have started to think that might be the best option but it is a pain now to convert as I have over 90 pages. It does seem to go against the idea of Xojo to be able to have multiple pages but I cant think of any other way to make a master page. Thanks for the suggestion.

I believe if you create a page as a master page it only passes over the methods, properties, event handlers, and event implementations. You could create a parent page and subclass your other pages but have the parent page controls loaded dynamically from web containers :slight_smile:

Now that is a sneaky idea, will have a think about that but need to get my head around subclasses and stuff first :wink: Xojo is such a new learning curve and just as I think I get close I realise that a whole new load of options become available :wink:

Do you know, if you have a single page with 10 container parts that you hide and show (to look like different pages) are the containers loaded a page load or as they are shown?

They must be loaded in one piece, because they’re only hidden.

If that is true then it would mean that the page download time and bandwidth used would be greater and front loaded, is that correct?

No, don’t think so. The application still runs on the server and is executing the code there. It then renders the output and sends this stuff over the Internet. But I guess that your application will consume more memory per session on the server, because it has to maintain all that stuff and you could not close objects to release memory.

Ok, thanks for the explanation.

Brock N I am rying to make web page master and container page. I have successfully added the webContainer but at same position unable to remove earlier webContainer control can you help me to remove earlier one.

while subclassing WebViews and inheriting their controls does in fact work, this is not supported by Xojo. See: <https://xojo.com/issue/30642>

Guys. Please don’t subclass WebPages, WebDialogs and WebContainers with controls on them. It’s not supported, we consider it a bug and when it gets fixed your projects are probably going to have issues.

What? Why? I have dozens of pages designed this way:

  • Page (super: Webpage) contains variables and methods common to all pages.

  • LoginPageController (super: Page) contains specific variables and methods to this page

  • LoginPage (super: LoginPageController) contains only those controls, events, and some display methods.

  • FormPageController (super: Page) contains specific variables and methods to this page

  • FormPage (super: FormPageController) contains only those controls, events, and some display methods.

[quote=88187:@Greg O’Lone]Guys. Please don’t subclass WebPages, WebDialogs and WebContainers. It’s not supported, we consider it a bug and when it gets fixed your projects are probably going to have issues.
[/quote]

Hopefully you mean “please don’t create intermediate classes with controls on them”. If subclassing to pool common methods is not supported, well, that’s gonna leave a mark.

No, I’m certain he means that subclassing objects with layouts will not work out in your favor.

NJP EDITED : IDE internal details should NOT be discussed

How things make their way to the compiler isn’t really relevant to why layout can’t be inherited.

But layout can’t be inherited

Create all of the WebContainerControls you want, put controls on them and embed them in other containers. Just don’t subclass your containers/pages/dialogs that have controls on them.

I’ve edited my original response because I left out the “with controls on them” part. That’s the part of this that we don’t support.

[quote=88196:@olivier vidal]What? Why? I have dozens of pages designed this way:

  • Page (super: Webpage) contains variables and methods common to all pages.

  • LoginPageController (super: Page) contains specific variables and methods to this page

  • LoginPage (super: LoginPageController) contains only those controls, events, and some display methods.

  • FormPageController (super: Page) contains specific variables and methods to this page

  • FormPage (super: FormPageController) contains only those controls, events, and some display methods.

  • …[/quote]

If your supers have no controls this should be OK
If you have controls on your supers that is a bug that it works at all and when it is fixed then any such configurations will break

[quote=88243:@Norman Palardy]If your supers have no controls this should be OK
If you have controls on your supers that is a bug that it works at all and when it is fixed then any such configurations will break
[/quote]

Ok, while I still think, inheriting controls would be (are) a nice thing, I can accept this clear statement. So in the end, you are planning to change the IDE / Compiler behavior for the Web to match the one on the Desktop?