Posts in Category: Development

Mono 2.0!

Congrats to the Mono Team on shipping Mono 2.0!

Mono 2.0

I'm eager to try it myself and am interested to hear from people using mojoPortal on Mono. So if you try it with our latest release package for Mono, let us know how it works for you.

I generally test Mono with a virtual machine where I build Mono from svn to stay up with the latest changes and then I keep another VM for testing the releases. So I downloaded the new VMWare image with openSuse 11 and Mono 2.0, but apparently this vmware image isn't compatible with the older version of VMWare server I have running, so I've got some upgrading to do before I can try it. I have a physical machine running openSuse 10.3 with VMWare server and then I run the testing virtual machines inside it. I also got a new video card I need to install in this machine so I'm installing that first and then upgrading my vmware host machine to openSuse 11 and then I'll install the newer release of VMWare server, and then finally I will be ready to play with the new Mono release.

2.0 is a big milestone for the Mono project so I'm really looking forward to it. Hope you will try it too and share your experiences. If you are a developer and you have MonoDevelop, we include a MonoDevelop solution with the mojoPortal source code, so you can checkout mojoportal from our Subversion repository and compile it with MonoDevelop. So not ony can you run mojoPortal on Mono, you can also do mojoPortal development on Linux with MonoDevelop.

Gravatar Joe Audette is the founder of the mojoPortal project and was the primary developer until February 2017.

FormWizard Pro is almost ready

I've almost finished my second premium feature for mojoPortal. The feature will be called FormWizard Pro and you can try it now on the demo site.

Any feedback on the product is much appreciated. The Form Wizard Pro feature makes it easy to create arbitrary ad hoc forms for capturing input from your site visitors. You can create as many instances of forms as you like on as many pages as you like. It supports Text, Paragraph, Radio Button lists, Checkbox lists, Dropdown lists, Date, and Sliding Scale questions. You can re-arrange the questions using drag and drop, and you can export the submitted data as CSV (Comma Separated Values) which can be opened in Excel or other spreadsheet programs for analysis.

Here is a little snippet of the edit screen, but to see how it really works just try it out on the demo site.

form wizard pro screen shot

I hope to have it on sale very soon.

Gravatar Joe Audette is the founder of the mojoPortal project and was the primary developer until February 2017.

Should we move to Codeplex?

Big news today that Codeplex now supports svn bridge on the server. I'm thinking it would be very good for the mojoPortal project if we move our source code repository there, it would get us a lot more visibility among ASP.NET developers.

The Codeplex repository actually uses Team Foundation Server and in the past you could still connect with TortoiseSVN if you installed a client side svn bridge. The problem we faced with mojoPortal is that some developers work with mojoPortal on Linux using MonoDevelop and there wasn't an svn bridge for Linux, so it could not work for developers working on Linux. That pretty much made it not an option for us. Now, if I understand the announcement correctly, with the server side svn bridge, there is nothing to install on the client so it should work with the command line svn client. I will have to test it out before making a move, but I'm leaning very strongly that way. If anyone in the mojoPortal community has strong opinions about it, now is the time to sound off. Novell Forge, where we host our source code now has been good to us but I think being a part of the Codeplex community would be good for getting more exposure to a wider community of ASP.NET developers.

UPDATE 2008-09-22

I've been trying out the Codeplex svn bridge and its mostly working but not currently able to do merge. The Codeplex team has been very helpful and responsive and is looking into the merge issue. We should know more in a few days, but as long as we can get the merge working I see no reason not to move to Codeplex. Thanks for all the input, I'll post updates as things progress.

UPDATE 2008-09-27

The latest update from the Codeplex team is that its going to take about 4-8 weeks for them to implement support for svn merge. So we will have to wait a while and try it again after they implement this. To me this is good news. I was afraid the answer was going to be that they only support svn checkout and svn update. The fact that they are going to get it working (or at least try) is very good news even if we can't move to Codeplex right away, we will be able to move there when this feature is implemented. I was surpised that they think svn merge is a rarely used feature since I use it all the time merging changes from my sandbox into trunk. It makes me wonder if I use svn merge more than most svn users. I thought my use scenario was very common having trunk and branches, and sandboxes. I generally work in my sandbox and merge changes to trunk at the end of each day as long as my work is at a stable point. I'm curious what work flow other svn users have.

Gravatar Joe Audette is the founder of the mojoPortal project and was the primary developer until February 2017.

Coming Soon - The mojoPortal Store

Back in October of 2006 when I first launched my company, Source Tree Solutions to work full time on mojoPortal, I had kind of a fuzzy business plan with the main idea being that I would make revenue by offering consulting around the free mojoPortal product. I guess in my wide eyed optimism I thought that doing this kind of consutling would improve mojoPortal and in fact it did to some extent. A few customers actually sponsored development for things that improved mojoPortal for everyone. But most of the consutling was really for things that were not of any general benefit beyond the customer's needs, so in some cases I felt like taking on this work was actually slowing me down from progress on improving mojoPortal. Forming a business around consulting means you always have to be taking on more projects to keep the business going because you don't make any money unless you are doing billable work. Now I am in the process of shifting my strategy to sell some premium features on top of the free mojoPortal core product. I think that selling some products in order to generate revenue will be better because it will pay for the free time I need to keep improving the mojoPortal. Consulting will remain a part of my business model but my plan is to keep it very limited goig forward.

So with this changing strategy in mind I've been working feverishly to get my first product completed so that I can open up a Store here on mojoPortal.com in early July and begin selling it. The first feature for sale will be a more advanced Event Calendar that allows selling tickets to events. Following that I plan to build a Form Wizard that allows users to easily create forms to capture arbitrary data. I also plan a Fund Raiser feature and an add on package for Web Farm support. I have a lot of ideas for premium features, but my main goal is to just get enough revenue rolling in to allow me to keep improving the core. There are a lot of planned improvements for the core that I'm eager to complete, like built in support for tagging, comments, and content versioning so that they can easily be enabled for any feature with little effort. Eventually I'd like to open the store up so that other developers can also sell products there too, so that it can be a market place something like snowcovered.com which sells add ons for DNN.

One of the reasons I chose to implement a commerce enabled feature as my first product was so that I could figure out which pieces of the commerce architecture need to b re-usable. We already have a WebStore project that I will be using to sell my premium products and this WebStore is one of the free open source features of mojoPortal. So far the WebStore is very rudimentary, it can only sell download products and its really a bare bones implementation for the product catalog at the moment. The project was originally started under a sponsorship by BrainBeacon but was never completed fully because they went out of business before ever opening a store. Its hard to really polish up a complex feature like ecommerce unless you are actually using it for business or supporting a customer who is using it. So using it to sell my own products will lead to a lot of improvement in the WebStore feature. I've been doing a lot of re-factoring in the WebStore to get the re-usable pieces built into mojoPortal core so they can be used across features. For example, Country List, State List, Currency List, Language List and their administrative features were originally in the WebStore projects but I've moved them into the core of mojoPortal because they will be needed by other features. Support for Payment gateways like Google Checkout and PayPal are also being moved into the core so they can be re-used by any feature that wants to implement ecommerce. Since my first product will be an Event Calendar that allows selling tickets it will need to leverage a lot of the same ecommerce code that the WebStore does. Rather than re-implement it in every feature it has forced me to think about the best way to make most of it easily re-usable.

Implementing this more advanced Event Calendar has also led me to other improvements in the core of mojoPortal. For example one of the features in my new Event Calendar is support for recurring events. When you create a recurring event it actually creates event instances going out x number of years. Since  events are also searchable using the site search, you have to update the search index for each created event as well. What I found was that creating events in rapid succession due to recurrence could lead to some problems due to the way I was handling the indexing of items. The indexing was triggered by the saving of the event then code to update the index was spawned on a new thread so that it doesn't block the UI. Under some circumstances the writing to the index was not in the proper sequence and errors could occur. So I implemented a queue in the database so that items to be indexed could be queued and then processed in batch on a background thread while keeping the sequence correct because everything is processed in queue sequence.

Another thing that got improved in the core as I implemented this new Event Calendar is module settings, which is just a place to store feature specific settings for instances of a feature. In a number of the mojoPortal features we have support for google maps, but some of the settings needed for google maps were not well supported by module settings. For example the google maps api defines some constants for the Map Type like G_NORMAL_MAP, G_SATELLITE_MAP, G_HYBRID_MAP, etc. When I first enabled support for specifying the map type, it was done in module settngs by entering the constant in a textbox like this:

pretty yucky and not user friendly since its easy to put something incorrect there and nothing to tell the user what is acceptable. So as much as this bothered me I could not conceive of shipping a paid product with this kind of setting so I implemented ISettingControl as a way to introduce a possibility to use a custom UserControl for this setting and now for all features that use the google map the setting looks like this:

much better implemented as a dropdown list! Actually not shown in the screen shot is I also implemented a dropdown for the zoom level so that it is limited to the range of acceptable values.

So, in short, developing features to sell has made me think more deeply about what is needed in the core of mojoPortal to support 3rd party feature development more easily, because its made me think more like a third party.

I haven't blogged much this month because I've been so busy working to get this feature completed and to get the store opened, but thught I should go ahead and post this to let people know what I'm doing. Several people have asked recently what happened to the store demo site as it is currently off line. I will have that site back up soon. I just have a little more re-factoring of the WebStore code to do and I will setup the demo store again.

I'm very excited about the new store opening soon and will announce it here in the blog as soon as its open. There will also be anew release of mojoPortal soon with the improvements I've mentioned above as well as a few bug fixes and skin tweaks to better support Firefox 3.

Gravatar Joe Audette is the founder of the mojoPortal project and was the primary developer until February 2017.

A Few New Developer Docs

Just a quick post to point out some new documentation for mojoPortal developers.

Setting Up Your Projects - has notes about how to work with mojoPortal from our repository and your own code from your own repository.

Using The Installation System - talks about how to leverage the mojoPortal installation system to install your own features.

Using The Task System - discusses a little framework we have for managing long running tasks on a background thread. You can implement your own and plug them in. I built it for sending the news letter emails. It can chug through a long list effectively because it can resume even if the thread is killed by recycling the app pool. When the app starts again it picks up where it left off.

Gravatar Joe Audette is the founder of the mojoPortal project and was the primary developer until February 2017.