Website Forms - C# -vs- Classic ASP

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/1/2007 6:11:54 PM
Gravatar
Total Posts 43
Partner

Website Forms - C# -vs- Classic ASP

In our business I have two types of employees creating websites; a designer and a developer. The designer creates the look and feel of the site and populates most of the website content. I bring in our developer if we need databases elements not offered in the base mojoPortal package. The problem is I would like for our designer to be able to create website forms and not the developer.

I discovered one way to do this but I consider it a hack.

The approach is to add an “HTML Content” section to the page. Create the form in that HTML Content. The submit on the form calls a classic ASP script that send an email to the user and then redirects them back to a “message sent” mojoPortal page (that is not listed in the menu). This method allows the designer to change fields and not depend on the developer. I should also mention this email is customized for each form; it is not a multipurpose scripts that simply loops all for the form fields.

This method does require another hack however. The beginning of the HTML Content must begin with a </form> tag since the whole page is wrapped in a <form>.

I am relatively new to the mojoPortal scene and may be missing something obvious. Is there an easier way for me to accomplish this?

Thanks,
-Todd

10/2/2007 8:50:15 AM
Gravatar
Total Posts 46

Re: Website Forms - C# -vs- Classic ASP

Hi Todd,
I’m in the process of building a survey module. This will allow administrators to create surveys, which if only one page would be no different from a standard data entry form. Below is some of the basic functionality I will be implementing for the first version.


Ability to add the following question types:
Textbox
Dropdown
Checkbox list
Radio button list
Date Entry

Validation:
Answer Required
Minimum X checkboxes answered

Separation of question by pages:
Add/delete pages
Order pages
Enable/disable page

Answers
Export of CSV of all answers
Survey
Anonymous surveys
Member only surveys
I’ve created most of the basic admin functionality and am hoping to start working on the rendering of the surveys in the next couple of weeks. When I have a working version I’ll be posting a message on here. If you have any suggestions for functionality then please let me know and I’ll definitely consider them. If you have any more questions please let me know.

Cheers

Rob

10/2/2007 11:39:47 AM
Gravatar
Total Posts 18439

Re: Website Forms - C# -vs- Classic ASP

Hi Todd,

Sounds like what Rob is suggesting is his survey feature could potentially be used as a way to create custom forms.

I think the core of what you've hit on is that we lost a little something in the transition from Classic ASP which is an interpreted scripting language to .NET which is a strongly typed compiled language. The scripting model has an advantage in that a designer can learn just enough and be able to develop forms. To me the designer is kind of being a junior programmer in this task and the barrier has gotten a little higher in .NET. I think in this case the designer is going to have to learn some new tricks. Its further complicated/made difficult by the fact that mojoPortal uses the pre-compiled code behind model of the ASP.NET Web Application where all the server side code is precompiled into the bin folders as dlls. There is another model with the ASP.NET Web Site Project which does allow deployment of source code which is then compiled as needed autmatically. This model is perhaps a little more conducive to a designer/junior developer being able to edit files right on the server without having to compile.

I have some ideas about trying to bridge this and make it possible to add pages with mojoportal that contain raw source code but I need to experiment with it to see if it works. I'll try to do that soon and report back.

The other thing you've hit upon is that only 1 form can be on a page in ASP.NET. This is not a mojoPortal specific limitation this is limitation of ASP.NET that not everyone thinks was a great design choice on the part of MS but is nevertheless the way it is, some call it a feature, others deride it as a design flaw.

So I think there are several possible strategies to adapt the workflow.

1. If we implement some kind of form wizard type feature in mojoPortal a la Rob's Survey feature

2. The untried idea (that I will try soon and report back on) that would at least make it easier to deploy pages with code written by the designer. Even if this works its going to take the designer learning some C#

Best Regards,

Joe

 

10/2/2007 6:42:34 PM
Gravatar
Total Posts 43
Partner

Re: Website Forms - C# -vs- Classic ASP

Our organization has developed entry level webparts for the Plumtree Portal. It is a mixed environment at the moment, classic ASP and .NET. Up to this point we have created most of our routines in Visual Web Developer Express and copy the source code to the server; the Express version does not allow you to compile DLLs.

Joe, is this the concept you are talking about for the mojoPortal? For instance, would it be possible to drop a datagrid into an .aspx page, copy that page to the portal and then perform record manipulation through that datagrid? If so, this would be huge for our organization. We are writing our first project, a payroll management system, in the mojoPortal environment and compiling it to a DLL. For simpler needs the source code idea would most likely be a better fit.

-Todd

10/5/2007 3:48:02 PM
Gravatar
Total Posts 18439

Re: Website Forms - C# -vs- Classic ASP

The concept I was thinking of turned out to work. Basically the idea is to create an aspx page with inline code instead of codebehind and then make it inherit from mojoBasePage. This technique wwould allow your designer to write the form handling code right in the page albeit in C# not VBScript as in Classic ASP.

mojoPortal uses the Web Application project type which uses code behind files that are ultimately pre-compiled into mojoPortal.Web.dll in the bin folder. If you try to add a WebForm to the project in VS it will automatically stub out the code behind files. However if you create an aspx page that uses inline code instead of code behind using a text editor you can drop this file into your web folder and you can still edit it in VS, just don't add the file to the project. By default files that are not in the project are not shown in Solution Explorer but if you click the web project name in Solution Explorer then mouse over the icons at the top of Solution Explorer you will see one for "Show All Files". Click that and it will now show all files including those not in the project, they will be kind of whited out but you can see them and double click to open.

I will paste into this post below a skeleton hello world example that inherits from mojoBasePage and thus makes the page fit in visually. Handling the form post is really just code in the button click event. Using this model your designer can tiptoe into this and learn just enough C# to do what is needed. Not sure if this will come out right when I paste the code in here but we'll see.

<%@ Page Language="C#"
ClassName="ExampleInlineCodePage"
Inherits="mojoPortal.Web.mojoBasePage"
MasterPageFile="~/App_MasterPages/layout.Master" %>

<%@ Import Namespace="mojoPortal.Business" %>
<%@ Import Namespace="mojoPortal.Business.WebHelpers" %>
<%@ Import Namespace="mojoPortal.Web.Framework" %>
<%@ Import Namespace="mojoPortal.Web.Controls" %>
<%@ Import Namespace="mojoPortal.Web.Editor" %>
<%@ Import Namespace="mojoPortal.Net" %>

<script runat="server">

protected override void OnPreInit(EventArgs e)
{
this.allowSkinOverride = true;
base.OnPreInit(e);
}

protected override void OnInit(EventArgs e)
{
base.OnInit(e);
this.SuppressPageMenu();
}

protected void Page_Load(object sender, EventArgs e)
{
TextBox1.Text = "Click the button";

}

protected void Button1_Click(object sender, EventArgs e)
{
TextBox1.Text = "Hello Web";
}

</script>

<asp:Content ContentPlaceHolderID="leftContent" ID="MPLeftPane" runat="server" />
<asp:Content ContentPlaceHolderID="mainContent" ID="MPContent" runat="server">
Your custom form goes here.
<asp:TextBox ID="TextBox1" runat="server"></asp:TextBox>
<asp:Button ID="Button1" runat="server" OnClick="Button1_Click" Text="Button" /></div>

</asp:Content>
<asp:Content ContentPlaceHolderID="rightContent" ID="MPRightPane" runat="server" />
<asp:Content ContentPlaceHolderID="pageEditContent" ID="MPPageEdit" runat="server" />

Hope it helps,

Joe

ps I will also be creating a Codesmith template so pages like this can be easily stubbed out with Codesmith.

9/29/2008 10:19:26 AM
Gravatar
Total Posts 18439

Re: Website Forms - C# -vs- Classic ASP

Form Wizard Pro is on sale now and makes it easy to add custom forms to mojoPortal.

Best,

Joe

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