Jump to content

Thoughts/advice on Markup Regions approach please....


Recommended Posts

Hi all,

Just embarking on a new web app project that I'm planning to use Markup Regions for. I've experimented with Markup regions before and am happy with the syntax and coding but wondering on the overall approach.

The project will have a simple user dashboard with various typical web app views for account management, settings etc etc... I'm wondering am I better having one 'dashboard.php' template with PHP routing/conditions/includes to determine the content each page feeds into the _main.php file.

Or is it better to have a seperate template for every page in my dashboard? I could end up with quite a lot of templates to realise my final functionality this way and pretty sure I've seen posts that PW is intended to have a vast number of templates. However routing all the views with new code could also get quite complex quite quickly too.

Wondering what thoughts/experiences others have had - I hope this questions makes some sense!

Link to comment
Share on other sites

I typically start with the raw HTML output design and as I work I notice elements that I use often and break those into partials. In my _main I typically have the spacing and grid scaffolding for most items with the understanding I may embed nested structure as part of my individual page template, and then I will load includes into those embedded areas as needed.

I see _main as the foundation and outer walls of the house. I see the page templates with their regions as different layouts of walls/rooms within that house. I see the furniture and features of the rooms of the house as partial includes.

Whether you choose for the rooms themselves to be adaptable or not is really up to you. It isn't necessary to use partials at all, but I find it cuts down a little bit on the template counts.

A common tradeoff seems to be between the amount of code you put into your template file region replacements/append/prepend etc vs the number of different templates you have, and whether you want the presentation routing to be directed more by the selection of the templates or programmatic responses to data in the fields your templates use.

It is possible to have very few template files that reroute and alter the display based on tons of selections made on the pages themselves, or it is possible to have individual templates for all of the different scenarios you may want to come up with - but for complicated sites I tend to prefer fewer templates, more function controls.

I would say that for the end user having lots of templates and transparent choices/structure on the pw backend is safer with clients. Because you can control a lot of things about adding new content, etc. it is less likely that the user may alter some value and cause some other glitches on the site that you don't expect unless you are pretty strict with your unit testing.

But if you have code content that is really never anything the client is going to have to be actively involved in, bringing stuff like that into the code side keeps down the clutter.

Hanna code sits somewhere in the middle and I always feel like it is playing with fire but that's a pretty happy bridge between the two worlds if you want to try to give placement control to the client but want to maintain logic control.

 

  • Like 3
Link to comment
Share on other sites

Thanks for the detailed response. This basically summarises exactly the choice in front of me...

I'm pretty sure I can dramatically reduce the amount of code by using a new template for every view or configurable feature of my app and feeding it into my _main.php.

But I'm not sure if creating loads of templates (I would estimate this will end up being around 10 to create the product MVP) is bad idea or particularly inefficient approach in terms of performance and database?

 

Link to comment
Share on other sites

My stuff is typically not that dynamic on the front side of things but I believe there are a number of users who have put together some pretty sophisticated partial loading methods with vue.js and other things that would probably cut back on the overhead if you are seriously concerned. I would think that the apps bringing in data to your dashboard probably have more overhead than pw, but I haven't built anything huge with it yet.

Just digging around my links, it is old but you might consider looking at this for some ideas:

https://github.com/microcipcip/processvue

 

Link to comment
Share on other sites

1 hour ago, Guy Incognito said:

But I'm not sure if creating loads of templates (I would estimate this will end up being around 10 to create the product MVP) is bad idea

10 templates is definitely not going to be a problem. There's no particular number of templates that you should never go above, but I've asked Ryan about this topic in a Pro module forum and he said:

Quote

That's true that templates won't scale infinitely in the same way that fields won't. But I've never come across an installation where too-many-templates was an issue, whereas I have seen a couple instances where the quantity of fields was potentially adding some overhead. 

...and in reply to my proposal of a strategy to reduce the number of templates needed in a project...

Quote

I personally think that going from 80 to 40 templates would be worthwhile, as 80 templates is a lot to manage for the web developer (even 40 is a lot to manage). But I don't know if it will matter in terms of performance or overhead, as 80 templates isn't necessarily a large quantity from the technical perspective.

On that particular project I currently have 51 templates and there are no noticeable performance issues.

  • Like 4
Link to comment
Share on other sites

@Robin S Thanks for this - really useful and puts my fears to rest. @gornycreative Thanks also for sharing info.

I can't see I'll need anything like 50 of templates (famous last words 🤣) and TBH what I'm building is should have pretty low demands in terms of resources anyway - for the end user its more of a set-and-forget scenario. So demands should only increase with a significant number of users... but hey that's a good problem to have eh!

  • Like 1
Link to comment
Share on other sites

I have a web app with over 50 templates and over 150 fields (holiday cottage booking system). I don’t find that a problem, although there are not many users. I use page classes extensively with the templates as I find that is the best way of handling the business logic. Process modules for most of the admin user views. This is mostly a back-end admin system. The front-end public website is a separate PW instance with its own (smaller number) of templates and fields, interfacing the admin system via an availability calendar. There may have been better ways of doing it, as I am still learning about PW, but I find this a manageable approach. 

  • Like 1
Link to comment
Share on other sites

On 7/10/2021 at 8:08 AM, MarkE said:

I have a web app with over 50 templates and over 150 fields (holiday cottage booking system). I don’t find that a problem, although there are not many users. I use page classes extensively with the templates as I find that is the best way of handling the business logic. Process modules for most of the admin user views. This is mostly a back-end admin system. The front-end public website is a separate PW instance with its own (smaller number) of templates and fields, interfacing the admin system via an availability calendar. There may have been better ways of doing it, as I am still learning about PW, but I find this a manageable approach. 

That's an interesting way of doing it. Have you used the FieldtypeSelectExtOption module at all? Seems like it would be useful in that scenario.

Only other thing I considered, as I thought about the original question, I find that when I want to to pass information to an include, I usually end up setting up a function to handle it. The _uikit.php file in the coffee site template made a lot more sense to me. I started out writing more includes but then realized setting up functions that I could pass arrays to made more sense and was a bit easier to work with once the functions themselves were done.

Link to comment
Share on other sites

11 hours ago, gornycreative said:

That's an interesting way of doing it

The approach I actually use for a web app is to start with a class diagram. The classes, properties and methods then become the templates, fields and methods (roughly speaking) in PW, where the methods are added to the TemplatenamePage class. For many<->many relationships which don’t hold data, I often use ConnectPageFields by @Robin S - it’s a really useful module. 
Looking at the app, I see that of the approximately 50 templates, around 30 have associated Page Classes, so I don’t think that number could be reduced much. I could probably have got away with fewer fields by more intelligent re-use or if I had purchased ProFields. 

11 hours ago, gornycreative said:

Have you used the FieldtypeSelectExtOption module at all

No. I wasn’t aware of it when I built that app. I did spot it later and looking at it again now, I realise that it may have wider application than I first thought. I’m not sure it would have saved a lot for the app in question, though. 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...