Jump to content

Suggestion: Pages Improvement


Recommended Posts

Alright, we all love pages, well, mostly.

I have clients that use pages heavily, almost ungodly so, and they are always like "we want to use pages to do this really really complicated thing". they love the custom building of the form, that is like the biggest thing they love about it, but they are always wanting a little more than pages can offer. so on some of their complex things, they have to either have me make hooks for them or actually build an app.

so here are my glorious suggestions for pages:

  1. Adding a Pseudo Hook system:
    1. when creating/editing a database, if i am using categories or turn on reviews/comments, have a tab appear where i can override methods/props for that class. you guys already introduce the records/category/review/comments classes for pages thru eval in the application.php of cms, this would just be the next logical step.
    2. while in dev mode, write these to disk, like hooks are written, and use the real class names, so i can use my IDE and all the gooey features it has (eg: class Records1 extends \IPS\cms\Records {}):
    3. Pseudo classes: this was something that was talked about way back in the day of 4, but i haven't heard or seen any progress on this. and this is more of a feature for the plugin/hook system, than it is specifically for pages. but basically, allow us to introduce new class's thru a hook (and potentially this for pages). 
  2. Improved custom fields
    1. more types, like adding in nodes, give us an option to tell it what class to parse, easy peasy.
    2. custom data formatting on save. when the custom field gets saved, give us a CM to add in some code that will be executed for the value.
    3. custom data formatting preDisplay, like the one above, when the field is called for display, preDisplay gets called before it. this way we can separate business logic from template logic.
    4. better default value/content options. for example, take select, lets say i need it to go from 1 to 10. if i was writing this out, i would just do something like $options = range(1,10); or if i wanted to pull the options from somewhere else, say a setting or build them from a database. there are a lot of reasons why one would need/want the ability to reuse data from other apps/parts of the suite.


Now, i know yall are probably thinking, why you complaining, just make a hooks and templates like you normally do or that this would some how overly complicated pages. there are a few problems with making hooks. the first one, i loose all portability. those mentioned classes are all created with the database ID. so for articles, it would be Records1, for the next db you create it would be Records2, and so on. so the hooks i create, would either be useless or at worst, be acting on the wrong database for you. second is, lack of self containment. install database, then have to go install hooks on each update, have to do that. i know it doesn't sound like a big deal, but in my experience, the less steps involved higher chance of success and less support. 

this would turn an already pretty powerful app, into an extremely powerful app. i mean i always joke, i could probably duplicate almost every IPS app in pages, with this system, I'd prolly could. 

Link to comment
Share on other sites


This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

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