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



Indeed, the interface is extremely subject to change.  These are mainly intended to be screenshots showing the functionality, not the final polished interface.

 

Bingo! Thus why feedback is important, even at this stage.

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.

 

Okay for the coders and skinners. How about the users? There a thread about it in IP.Content.

Link to comment
Share on other sites

 

Okay for the coders and skinners. How about the users? There a thread about it in IP.Content.

 

I'm not really sure what you are asking.  If you mean, will we be working closely with the users, that's a somewhat odd question and I'm not sure what it really means.  Our clients will have access to public betas before the product goes final, and it's probable we will do a test installation of 4.0 long before we reach those stages like we did with 3.0.  Nothing is set in stone yet, however.

 

I would caution against getting ahead of ourselves here.  I know everyone will be excited to see the new version as soon as it is possible, but we're a ways off from betas and showing off the product at this point.

Link to comment
Share on other sites

 

 

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

 

Certain people in this very section throw temper tantrums when someone "does" choose to do something manually. Clearly they have issues where they have to have everyone else doing things the way they do. They need some help. Definitely understandable that someone wonders why someone would do things various ways, but some third party developers here whine and want everyone who makes apps which don't involve them at all to do things their way.

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...