Jump to content
Mark
 Share


4.0 Developer Center

A few weeks ago, I posted a blog entry mentioning a new feature in 4.0 which aims to make development of applications within the IPS Social Suite (both for us and third party modification authors) easier. We focussed on managing the database schema in that blog entry and I'd now like to take you through the other features.


Modules



Two tabs (one for admin modules and one for front modules) allow you to view all modules and sections in your application. You can add modules (which will both insert it into the database and create the relevant files in the filesystem), change the default section for a module (which previously required a defaultSection.php file) and create new sections.

When you're creating a new section, the form looks like this (this is for creating a section for an admin module):


The "Type" field controls the code that will be placed in the file created for the section - the options are:

  • "Blank" - which will create the class with no other logic, so the section will be blank.
  • "Table" which will create a class with a boilerplate for displaying a table.
  • "Node Controller" - which will create a boilerplate for displaying a tree of containers such as IP.Board forums, IP.Downloads categories, IP.Nexus groups, etc. We've not posted how this class works, but a future blog entry will give more details.

No matter which type you select, the system will automatically generate a file, with a basic class structure already filled in, including ACP restrictions checks, etc.

The "Menu Tab" field is admin specific and controls under which tab in the Admin CP the section should show (for example, we have some stuff from the "core" app under the "Look & Feel" tab). Previously, one would have to edit the menu.xml file for the module to add sections, and making sections appear under tabs other the default application tab was very difficult - the new system does it for you.

The "ACP Restriction" field is also admin specific and allows you to select an existing ACP restriction which will control who can see the section. It also has a special "Create Restriction" option, which will cause the system to create a restriction, and use that. Previously, one would have to edit the permissions.xml file to create restrictions and then assign them in the menu.xml file.

Of course - you can completely bypass this feature and manually create your module folders and section files, but the addition of this feature makes the process much quicker.



Admin CP Menu

This tab contains a graphical representation of the data which was previously stored in menu.xml files.








Admin CP Restrictions

This tab contains a graphical representation of the data which was previously stored in permissions.xml files.





Extensions

Extensions are ways in which applications interact with one another. Previously, you would drop extension files in your applications "/extensions" folder, though there wasn't much reasoning to the structure of the directory, it was difficult to know what extensions were available, and sometimes understanding an extensions requirements was difficult.

In 4.0, the extensions directory is more structured - the format is owner app > extension type > extension file (so admin/group_form.php for example, is now core/GroupForm/*.php) so this tab provides a GUI for managing your applications extensions. Applications can also specify a boilerplate file for an extension, so you can see what extensions are available, and clicking the "add" button will create a file with a basic structure to get you going.





Settings

In 4.0, developers have much more control over how settings are presented, rather than all being dumped in the central "System Settings" table. With this, much of the data that was previously needed in settings.xml is no longer required, so we've simplified the process of creating setting to just providing a key and a default value.





Versions

The versions tab shows all of the application's versions and the database queries that the upgrader will run when upgrading to that version. It's sort of a combination of the versions.xml file and the setup folder.




Queries are automatically added as you modify the database schema. Naturally you can also manually add queries, or specify a custom PHP script to run in that upgrade step.
 Share

Comments

Recommended Comments



Everything looks good but I'm not convinced about that "Setttings" TAB. How does it work exactly? From the look of it it seems we can't define anything like the current description, name (is that lang abstracted based on the key?), raw PHP code, dropdown options, #show_groups#, etc..

Link to comment
Share on other sites

Everything looks good but I'm not convinced about that "Setttings" TAB. How does it work exactly? From the look of it it seems we can't define anything like the current description, name (is that lang abstracted based on the key?), raw PHP code, dropdown options, #show_groups#, etc..

 

You can control the presentation of your settings pages using normal controllers (probably in conjunction with the form helper class).

Link to comment
Share on other sites

While the actual details shared are great, I'm even more excited by the clear, demonstrated focus that is being shown on making the entire system vastly more productive for 3rd party developers.  One of the big drawbacks we keep hearing from our fellow professional community admins is the lack of availability of good developers for hire to develop for IPS.  I have high hopes that the focus on empowering 3rd party devs shown in this blog so far will go a long way to reversing that trend.  Esp with the ever quickening self-destruction of the previous industry leader forum software platform leaving a lot of talent looking for a new home. ;)

 

::doffs hat to IPS dev team and platform steering/management::

 

James 

Link to comment
Share on other sites

A centralized Developer Center is what a great community provider like Invision power was missing.

 

What about the ajax module? Will we have to add it from the developer center or it mustn't be added in the module list (like now)?

Link to comment
Share on other sites

A centralized Developer Center is what a great community provider like Invision power was missing.

 

What about the ajax module? Will we have to add it from the developer center or it mustn't be added in the module list (like now)?

 

 

IPS4 no longer has AJAX modules.

 

Since everything in 4.0 has a fallback if JavaScript is disabled, a lot of the AJAX and non-AJAX calls both go to the same controller with a call to IPSRequest::i()->isAjax() to differentiate the output to show. For things which are distinctively AJAX (like quick search in tables) we're just putting those actions in the normal controllers or creating AJAX controllers within a normal module.

 

 

Could you release a sample application with the documentation to help us get acquainted with this system when 4.0 is ready?

 

Yes.

Link to comment
Share on other sites

 

 

IPS4 no longer has AJAX modules.

 

Since everything in 4.0 has a fallback if JavaScript is disabled, a lot of the AJAX and non-AJAX calls both go to the same controller with a call to IPSRequest::i()->isAjax() to differentiate the output to show. For things which are distinctively AJAX (like quick search in tables) we're just putting those actions in the normal controllers or creating AJAX controllers within a normal module.

What about the only point OF ajax modules?

I do not want the user 'active' somewhere they are not just because these were removed?

Link to comment
Share on other sites

What about the only point OF ajax modules?

I do not want the user 'active' somewhere they are not just because these were removed?

 

The session class won't update the location on an AJAX call. As I say, you can detect if a request is AJAX using IPSRequest::i()->isAjax() (which examine's the HTTP Request headers) - it's quite handy ;)

 

Wait....

All of this will still be able to be done manually outside the ACP.... right?

 

Yes of course. Though why one would would be a mystery to me :p

Link to comment
Share on other sites

The "Type" field controls the code that will be placed in the file created for the section - the options are:

  • "Blank" - which will create the class with no other logic, so the section will be blank.
  • "Table" which will create a class with a boilerplate for displaying a table.
  • "Node Controller" - which will create a boilerplate for displaying a tree of containers such as IP.Board forums, IP.Downloads categories, IP.Nexus groups, etc. We've not posted how this class works, but a future blog entry will give more details.

No matter which type you select, the system will automatically generate a file, with a basic class structure already filled in, including ACP restrictions checks, etc.

 

Will these 'types' be extensible like the extensions(as in could I as the developer add a base 'template' for a section file to reduce rehashing it time and again)?

Link to comment
Share on other sites

 

You can control the presentation of your settings pages using normal controllers (probably in conjunction with the form helper class).

Hook settings? Where do we display configurations for hooks? Manually? Where are these displayed and how if no central settings panel exists?

If I get this right, we have more control for apps but require more code for hooks? Not to mention without any standard for getting to settings globally, you know as well as I do configuration for the user becomes a nightmare as developers litter the landscape with their own settings display for x mod at x url. This is seriously NOT going to be easy on the user, you went from some fair consistency to completely free-form url and display-wise. Every app/hook is going to now have a learning curve for finding 'settings'?

You went from an effortless thing to do settings to mancode to display them? Not being accusatory, just not understanding why you add more boilerplate here in something currently so dead simple to implement. I really don't want to end up with it being like WordPress, where you have to code the settings display before you can even use them. It adds much bulk to the code-base. Where hooks are concerned, this single item, needing a setting, is a kiss of death for it staying a hook with it like this.

The way you present it, why should I as the developer even bother with 'settings'? Why not use rows from my own table/cache? Functionally, it is now the same amount of code?

Worse, it takes MORE code for an app to display it's 'settings' page? This was a 6-liner. Again, why would the dev even bother with 'settings' at all if we have to manually display and save them?

Link to comment
Share on other sites

Will these 'types' be extensible like the extensions(as in could I as the developer add a base 'template' for a section file to reduce rehashing it time and again)?

 

Not presently but that's not set in stone at all. Once you get your hands on 4.0, I'd be really interested to hear about anything you think could make development easier.

 

 


Hook settings? Where do we display configurations for hooks? Manually? Where are these displayed and how if no central settings panel exists?

If I get this right, we have more control for apps but require more code for hooks? Not to mention without any standard for getting to settings globally, you know as well as I do configuration for the user becomes a nightmare as developers litter the landscape with their own settings display for x mod at x url. This is seriously NOT going to be easy on the user, you went from some fair consistency to completely free-form url and display-wise. Every app/hook is going to now have a learning curve for finding 'settings'?

You went from an effortless thing to do settings to mancode to display them? Not being accusatory, just not understanding why you add more boilerplate here in something currently so dead simple to implement. I really don't want to end up with it being like WordPress, where you have to code the settings display before you can even use them. It adds much bulk to the code-base. Where hooks are concerned, this single item, needing a setting, is a kiss of death for it staying a hook with it like this.

The way you present it, why should I as the developer even bother with 'settings'? Why not use rows from my own table/cache? Functionally, it is now the same amount of code?

Worse, it takes MORE code for an app to display it's 'settings' page? This was a 6-liner. Again, why would the dev even bother with 'settings' at all if we have to manually display and save them?

 

 

Trust me, it's so much better :smile: This way you can have upload fields, fields which show/hide in dependance on other settings, custom validation and so much more. You do have to type out the code, but the code for one setting is one line (literally one line, it's definitely not the same amount of code as having your own table by a long shot) - it's much quicker to type it out than it is currently to add a setting, put them in the right order and export. Especially when you start thinking about how difficult it is to delete a setting now - you'll quickly realise the new way is so much faster. After all, we wouldn't make a development change which made our lives more difficult ;)

 

We'll post a separate blog entry about hooks specifically soon, but I assure you it's much easier to find settings in the new layout - in fact, one of the reasons that prompted this change is we kept hearing about people who installed a hook and then complained it didn't work because they hadn't realised the hook has an on/off setting. Just wait until you see it :smile:

 

 

So you now have the ability to edit and change around the ACP menu, what about the frontend? Is it possible to change that from the core instead of a module?

 
We'll have more details about the front-end soon :)
Link to comment
Share on other sites

I think the layout for the Extensions area needs some more work to give it a more shine, looks pretty out of place. Like blue and white like other parts of IPB, it looking all blue make it hard on the eyes.

Link to comment
Share on other sites

I think the layout for the Extensions area needs some more work to give it a more shine, looks pretty out of place. Like blue and white like other parts of IPB, it looking all blue make it hard on the eyes.

 

I have no information on this however i think the design will highly possible change. The functions etc.. are highly possible tested with old style at the moment .

Link to comment
Share on other sites

I only have one fear with major upgrades... what happens to third party apps. It's fine for small tweaks but when your community is built on major apps if they become deprecated or incompatible, ouch. I'm looking at two right now, one for classifieds and the other for social groups and I'm getting nervous about diving in. I'm not asking for info, I know the drill, but I just wanted to voice my concerns in the hope that sooner, rather than later, we will know enough — I should say 3rd party developers will know enough — to let us know if their app will fly or die based on the new architecture. Of course, any development is good so I'm looking forward to 4.0 whenever it decides to sprout ;)

 

**edit**

 

A features list is what I'm hoping to see soon  :rofl:

Link to comment
Share on other sites

I only have one fear with major upgrades... what happens to third party apps. It's fine for small tweaks but when your community is built on major apps if they become deprecated or incompatible, ouch. I'm looking at two right now, one for classifieds and the other for social groups and I'm getting nervous about diving in.

I would recommend holding off doing upgrades to v4 until those are updated, possibly longer if you depend on them to be as error free as possible.  Early adopters will upgrade and then add in stuff as it becomes available.

 

Classifies, since it's a 3rd party product by an IPS employee, I wouldn't doubt if it happens to be one of the first 3rd party apps updated to work with v4.

 

Social Groups, since the author has a good reputation, I wouldn't doubt that it will be worked on soon after v4 has been released.

Link to comment
Share on other sites

No third party addons are going to work as they are written now on 4.0.  The entire codebase has been rewritten from the ground up.

 

That said, we intend to work closely with the developer and skinner community prior to release to get them a head start on building resources for 4.0 long before it goes "final".  We will also be publishing developer documentation prior to a final release to assist them in converting their resources and building new ones.

Link to comment
Share on other sites

We will also be publishing developer documentation prior to a final release to assist them in converting their resources and building new ones.

Could you also keep the older documentation available, but maybe in a category of "3.x"?  Not only make it easier note the changes but if needing to code for 3.x, will still have a reference.

Link to comment
Share on other sites




Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...