Basic Feature development questions...

This forum is only for questions or discussions about working with the mojoPortal source code in Visual Studio, obtaining the source code from the repository, developing custom features, etc. If your question is not along these lines this is not the right forum. Please try to post your question in the appropriate forum.

Please do not post questions about design, CSS, or skinning here. Use the Help With Skins Forum for those questions.

This forum is for discussing mojoPortal development

This forum is only for questions or discussions about working with the mojoPortal source code in Visual Studio, obtaining the source code from the repository, developing custom features, etc. If your question is not along these lines this is not the right forum. Please try to post your question in the appropriate forum.

You can monitor commits to the repository from this page. We also recommend developers to subscribe to email notifications in the developer forum as occasionally important things are announced.

Before posting questions here you might want to review the developer documentation.

Do not post questions about design, CSS, or skinning here. Use the Help With Skins Forum for those questions.
This thread is closed to new posts. You must sign in to post in the forums.
10/14/2014 10:49:52 AM
Gravatar
Total Posts 28

Basic Feature development questions...

Hello all.

I am working on developing features for Mojo to prepare my company to migrate our web services to this new CMS from a much older one. And I am looking for some answers to questions I can't seem to find clear answers for. Thanks for your help. :)

1. Every individual feature seems to need a GUID to work properly. This is not a problem, but my question is *where* is the authoritative location for a specified GUID for a feature? In existing features I see a GUID specified in the business library, but also in the feature configuration (module settings) file. And on top of that my test feature - which has no specified GUID in code - seems to have generated its own GUID when it installed on my local Mojo copy. Which one takes precedence, and should I be setting a new GUID from the beginning?

2. Does the module settings file add new module settings after a feature is installed (i.e. an upgrade)?

3. I have absolutely no use for multiple language support, and for the limited number of clients that desire a language or two added I plan on using Google Translate's add-on. I want to void the hassle of using Resource files altogether. How supported is this? And can I skip the Resource specifications in the feature configuration (module settings) file?

4. I have run into an interesting issue with a reference version conflict. Newtonsoft.Json specifically. I need to use 6.0 and I see that there are references to both 5.4 and 4.5 in the Mojo solution. Is it safe to upgrade these references? I did turn off specific versioning in the Web.UI and Feature.UI libraries and force copied 6.0 from my own feature and it seems to work fine.

That's all for now, but I hope to have more questions soon. Thanks!

10/14/2014 11:31:42 AM
Gravatar
Total Posts 1188
Proud member of the mojoPortal team

Help support mojoPortal!
Add-on modules

Re: Basic Feature development questions...

For each feature, there is a feature definition config file (located in /Setup/applications/[appname]/FeatureDefinitions. This file contains the GUID that will be used to identify that feature. If you create a custom feature without a GUID in the feature definition file, mojoPortal will likely generate a random GUID to identify it during installation. I'd definitely recommend using a known GUID, so supporting parts of your feature can reference it as needed.

New settings in the config file should be created at upgrade, but you *might* need a corresponding SQL upgrade script to trigger setup to look for them. I'm not sure about that but it should be easy for you to test.

You don't have to use a resource file, but I've done third party development work, and a custom resource file is actually a handy way for clients to be able to change descriptions, etc. for a module after it's deployed, without having to go into code, change static strings, and recompile/redeploy.

For #4, check the solution for references to that library, and see where it's being used in the mojoPortal core. Chances are it won't hurt to use a more recent version, and Joe may deploy the latest version when he upgrades mojoPortal again.

Jamie

10/14/2014 2:13:49 PM
Gravatar
Total Posts 18444

Re: Basic Feature development questions...

In addition to what Jamie said

if you start without a feature definition file a feature guid will be generated. If you later decide to implement a feature definition then you should copy the previously generated guid into the feature definition file so that the feature guid does not change, otherwise adding a feature definition file for an existing feature with a new guid would create a duplicate of the feature with a different guid than the original and this would cause conflicts.

I usually also put the same feature guid in the business class or somewhere as a static property that I can use in code. For features with supporting pages for example you will usually need to know the feature guid to enforce security. ie your supporting page would take advantage of methods in mojoBasePage as in this code snippet from the blog edit page:

LoadParams();

            if (!UserCanEditModule(moduleId, Blog.FeatureGuid))
            {
                SiteUtils.RedirectToAccessDeniedPage(this);
                return;
            }

UserCanEditModule is a method in the mojoBasePage class, it sees the page id in the url and the passed in module id and feature guid are needed to determine if the user can edit or not. The user can edit if he has edit permission on the page or edit permission on the module and the module exists on the page. The feature guid is needed otherwise a user could manipulate the url passing in a different module id or page id that he has permission on, it is checked against the feature guid of the module instance to make sure it matches.

The feature definition file can add new module settings after the feature is already installed (ie on upgrades), it is processed every time the setup page is visited to make sure that all the module settings in the file exist in the mp_ModuleDefinitionSettings table. You can also update the default value for an existing setting by changing it in the feature definition and visiting setup but that default is only what is used when new instances of the feature are created, it does not update settings on existing instances and existing instances only get the new settings the next time you save the module settings on the instance. Removing a module settings from the file also will not delete it from the database, that would have to be done from an upgrade script.

In your own features you are free to use or not use resx files as you see fit, our features do use them and do need them.

Just before we are ready to make the next release I plan to go through and change as many of our existing dependencies to use NuGet and will update to the latest versions of libraries like NewtonSoft.Json. Our add on products need to be updated at the same time since they often depend on the same libraries so I have to be careful about the timing of such changes. If I updated the mojoportal repository today with those changes it would break things for anyone working with the latest code that also uses our add on features since they would still expect the older versions. So I need to have updated packages of all the products ready at the same time as the next release to do this.

10/28/2014 9:11:39 PM
Gravatar
Total Posts 28

Re: Basic Feature development questions...

That answers most of my questions - except one. You state that using Resource files isn't required for my own features - does that mean there are featureDefinition and featureSetting attributes to name settings in the config file instead of pointing to a key in the resource file?

10/29/2014 12:14:11 PM
Gravatar
Total Posts 18444

Re: Basic Feature development questions...

I believe if you don't specify a resource file (ie use resourceFile=""), then the raw value of the resourcekey will be used as a label, so you can just hard code the label in the feature definition file without using a resx file

Hope that helps,

Joe

10/29/2014 1:31:45 PM
Gravatar
Total Posts 28

Re: Basic Feature development questions...

Joe,

Thanks for the answer - I thought as much myself, but the resourcekey is also used to reference the setting in code. That leads me to suspect there's rules against using spaces and such. Can you confirm this? I'm trying to develop a simple and straightforward process for module/feature development in Mojo for my company and fellow devs, and trying to eliminate the excess stuff that I know won't be needed for our needs. 

Thanks for your help!

Mike

10/29/2014 1:36:58 PM
Gravatar
Total Posts 18444

Re: Basic Feature development questions...

you can't use any spaces in a resource key is the only reason not to, a setting can have spaces but since they usually correspond to resource keys they usually do not.

the main thing I would try to avoid is changing the name of a setting because doing that would not remove the previous setting, it would just create a new one with the new name. this can happen for example if you later decide to use a resx file then you have to change the name to remove any spaces

the only way to remove a setting is from a database query or upgrade script to remove it from both mp_ModuleDefinitionSettings and mp_ModuleSettings

3/27/2015 4:26:31 PM
Gravatar
Total Posts 28

Re: Basic Feature development questions...

Hello again! Thanks for answering my questions thus far. I promised I would have more. :)

Here's the next questions...

1. Is there a mojo function/constant that returns the full application root virtual path? Like Request.ServerVariables.Get("HTTP_HOST") or similar?

2. I was curious, in doing some housekeeping if it is possible to have all the front end files for features in a single folder as opposed to all over the root folder? Something like MojoFeatures or something? Would that break anything on the core end?

3. I have a development scenario where I need two tiers of admin settings for a module/feature. Would this mean I need to create a second feature for the second level admin settings if I don't want the first level to have access to them since the security settings apply to the entire feature as a whole?

Thanks!

3/28/2015 2:58:03 PM
Gravatar
Total Posts 503
feet planted firmly on the ground

Re: Basic Feature development questions...

Hi Mike

#1 I maybe misunderstanding your q, but I don't think you need mojoPortal methods for this... can't you just use httprequest properties e.g. see https://msdn.microsoft.com/en-us/library/system.web.httprequest(v=vs.140).aspx ?

#2 Mostly; we always put user controls into a specific sub-folder in the site, though if you have dlls they need to go in \bin, and there are various other considerations for cosmetic and js resources etc. You certainly don't need to drop anything in the root of the site unless you want to.

#3 Do you mean you want members of one role to be able to change only certain properties of a feature instance, while members of another role can edit these plus more properties? I don't believe that's possible on a single feature, but I could be wrong. Or perhaps building these controllers into your custom feature for users in certain roles, or building another interface for admins to control behaviours - hard to say more without knowing the requirements.  I recall that when we started developing with mojoPortal we were under the impression that all custom content needed to be developed as CMS features, whereas in fact you need to focus on designing the entry points that will be CMS features, then everything else can be on pages where you can do whatever you like (while inheriting site skin etc).

3/28/2015 6:48:01 PM
Gravatar
Total Posts 28

Re: Basic Feature development questions...

Hi Crispin :)

#1 - I was already aware of the httprequest server variables, but in order to create a typesafe application root url you have to use a few lines of code (one for host, and one for determining security, maybe one for port). In most CMS applications there's a pre-wrapped function built into the core, usually left there by the developer that can be used by those working on the CMS. I was hoping for the same case.

#2 - I'm not sure i am being clear enough on this question. Currently each features front-end files is in its own folder in the root (like ContactForm, EventCalendar, Forums, etc). I was wondering if it's possible to easily put these files - or at least my own features/modules front end files - into their own subfolder like MyFeatures or something. Example: /MyFeatures/MyEventCalendar. What setting does the core system look for in locating these files? The config file?

#3 - You have the idea for the most part. Here's the scenario: We have our own admin access, and our clients have a lower level of admin access. Client admins can edit HTML, blogs, read contact forms, and perform other low level admin tasks. Our admins on the other hand have access to higher level functions like configuring features/modules and adding/editing pages. On our modules they can vary as well. I got around this problem the older way by creating another "submodule" containing the separate functions within the module and assigning separate security permissions to it. This was easy to do because in our older system the module was loaded by ASCX file (the GUID was built into the file itself). Thus, you could have multiple "features" in one web project that share the same files. That doesn't seem to be the case in Mojo - as it seems the project itself (or maybe the project.config file?) is the feature and you can't have more than one in a project. This would mean that in order to do the same thing I would need to create separate projects for the second level admin functions AND create a separate project for the data layer if I don't want to create duplicate code. It's a bit more work, and not the style I am accustomed to.

I guess my question is - how does the core Mojo CMS recognize new features? By their feature.config file or the front-end folder?

3/28/2015 7:01:46 PM
Gravatar
Total Posts 28

Re: Basic Feature development questions...

I can clarify #3 a bit more now that I have woken up some. :)

Can a Feature project have more than one UserControl (SiteModuleControl) in a project? Yes, I realize that each control would be treated as a separate module - that's the intention. And could I specify feature.config files for each that contain module settings?

You must sign in to post in the forums. This thread is closed to new posts.