Code Behind in FrontPage?

[Todd]

Does anyone know of an example where FrontPage was used to create an ASPX
page in a SharePoint 2003 database that runs server side script. I
understand that the ISAPI filter that SharePoint uses doesn't support the
use of inline server side script but there are references to using a code
behind page (like we use in VS.NET).

How can I do this in FrontPage 2003?

<Todd />

 

[MD Websunlimited]

Hi Todd,

AFAIK, FP3 does not support code behind.

 

[Todd]

How can we run server-side script?

<Todd />

Hi Todd,

AFAIK, FP3 does not support code behind.

 

[John Jansen \(MSFT\)]

Hi Todd,

SharePoint has blocked the running of arbitrary ASPX code on your sites, so
you can't really do this using FrontPage 2003. However, there are two
options you have as I see it:

1. Create a custom web part
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/spptsdk/html/CreateABasicWP.asp)
using VS.net which you can then edit in FrontPage
2. Use the Data View Web Part and code the XSLT yourself
(http://msdn.microsoft.com/library/d...n-us/odc_fp2003_ta/html/odc_fpbldgxmlwebs.asp)

check out microsoft.public.sharepoint.windowsservices for a newsgroup you
can might find helpful as well.

 

[Jim Buyens]

Can't. You have to:

1. Create a Web Part in Visual Studio .NET.
2. Register the Web Part on the SharePoint server.
3. Add the Web Part to a Web Part page.

To get started, browse:

http://msdn.microsoft.com/library/en-
us/spptsdk/html/createabasicwp.asp

Jim Buyens
Microsoft FrontPage MVP
http://www.interlacken.com
Author of:
*----------------------------------------------------
|\---------------------------------------------------
|| Microsoft Office FrontPage 2003 Inside Out
||---------------------------------------------------
|| Web Database Development Step by Step .NET Edition
|| Microsoft FrontPage Version 2002 Inside Out
|| Faster Smarter Beginning Programming
|| (All from Microsoft Press)
|/---------------------------------------------------
*----------------------------------------------------

 

[Todd]

Thanks for the feedback. I am familiar with creating Web Parts and the Data
View Web Part. Both of these tools are great for _displaying_ disparate
data.

However, I need to perform things like server side validation of data
entered when someone is creating (updating) a list item OR provision a new
WSS site when someone creates a new list item and populate some of its lists
with default data that is dependant on the new list item.

How does a Web Part facilitate doing these kind of things on Form Post?

<Todd />

 

[Todd]

This PowerPoint presentation on the FrontPageDevKit site:
http://www.frontpagedevkit.com/demo... for SharePoint Products and Technologies.ppt

eludes to the ability to do code behind. See the 17th page on Deployment and
Security slide. It clearly says that "Inline script in the page will not
execute [but] code behind in pages can be made to work".

<Todd />

 

[Jim Buyens]

This PowerPoint presentation on the FrontPageDevKit site:
http://www.frontpagedevkit.com/demo... for SharePoint Products and Technologies.ppt

eludes to the ability to do code behind. See the 17th page on Deployment and
Security slide. It clearly says that "Inline script in the page will not
execute [but] code behind in pages can be made to work".

I'm not a definitive expert on SharePoint, but I did some research a
while ago and creating a Web Part is the solution I found.

This doesn't mean creating a Web part through FrontPage or through the
SharePoint Web interface; it means creating a special kind of custom
control in Visual Studio, compiling it, digitally signing it, and then
registering it to the SharePoint server.

The way you'd do form field validation is to design the form and write
the code in Visual Studio, just as you'd do for a native ASP.NET
application, except that you'd be creating a Web Part rather than a
Web Form.

The "Code Behind" approach,in case you don't know, means that:
o The HTML resides in an .aspx file and the program code resides in a
separate .vb or .cs file (.vb for Visual basic, .cs for C#).
o When Visual Studio compiles the project (which is roughly
analogous to a FrontPage Web), it compiles all the .vb or .cs
files into one .dll.
o When you publish the site, you only publish the .aspx and .dll
files. (The .vb and .cs files server no purpose at run time,
so why put them on your public site where intruders might
steal them?)
o When a visitor requests a page, the .aspx file inherits
properties, methods, and events from an object in the compiled
.dll file. This is how the HTML and the code behind it come
together.
o For security and reliability reasons, SharePoint won't run
code from just any DLL. It only accepts code that's been
digitally signed and registered.
o FrontPage can't compile .vb and .cs files into a DLL. I think
there are command-line tools that can do such compilations,
but who needs that? For $100 or so you can get Visual Basic
.NET Standard or C# Standard and get a much better toolset.

For mode detail, and a more reliable answer, you should probably take
this question onto one of the SharePoint newsgroups.

Jim Buyens
Microsoft FrontPage MVP
http://www.interlacken.com
Author of:
*----------------------------------------------------
|\---------------------------------------------------
|| Microsoft Office FrontPage 2003 Inside Out
||---------------------------------------------------
|| Web Database Development Step by Step .NET Edition
|| Microsoft FrontPage Version 2002 Inside Out
|| Faster Smarter Beginning Programming
|| (All from Microsoft Press)
|/---------------------------------------------------
*----------------------------------------------------

 

[Todd]

Thanks again for your help Jim.

A good example of what I am trying to do is provision a SharePoint Site (or
any API call really) when a list item is created. Does anyone have any idea
how to accomplish that kind of task?

Since FrontPage is the recommended tool (really the only tool) for working
with the SharePoint ASPX pages I'm somewhat stuck. FrontPage/SharePoint
doesn't seem to support inline server-side (or code-behind) and Web Part
code doesn't appear to run on post back. It only seems to run when the form
is initially requested.

I actually DO know how to create custom Web Parts in VS.NET, sign them with
a key, deploy them, and import them into a FrontPage SharePoint Site/Area.
However, I can't get Web Part code to run when the page is _posted_. It only
runs when the page is initially loaded.

What I'm chasing is the hope of executing server-side code in any fashion as
the second bullet in this MSDN article seems to indicate is possible:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/spptsdk/html/tsovNETSupport.asp
It says: "Inline script is not executed in a default page, such as for
working with lists or managing a site, although you can implement
code-behind pages in which script will run." Is this MSDN article wrong?

If I switch to a full blown ASP.NET application I loose the SharePoint Web
Part architecture which is the reason for basing our application on the WSS
platform.

<Todd />

"Todd" <[email protected]> wrote in message

This PowerPoint presentation on the FrontPageDevKit site:
http://www.frontpagedevkit.com/demo... for SharePoint Products and Technologies.ppt

eludes to the ability to do code behind. See the 17th page on Deployment and
Security slide. It clearly says that "Inline script in the page will not
execute [but] code behind in pages can be made to work".

I'm not a definitive expert on SharePoint, but I did some research a
while ago and creating a Web Part is the solution I found.

This doesn't mean creating a Web part through FrontPage or through the
SharePoint Web interface; it means creating a special kind of custom
control in Visual Studio, compiling it, digitally signing it, and then
registering it to the SharePoint server.

The way you'd do form field validation is to design the form and write
the code in Visual Studio, just as you'd do for a native ASP.NET
application, except that you'd be creating a Web Part rather than a
Web Form.

The "Code Behind" approach,in case you don't know, means that:
o The HTML resides in an .aspx file and the program code resides in a
separate .vb or .cs file (.vb for Visual basic, .cs for C#).
o When Visual Studio compiles the project (which is roughly
analogous to a FrontPage Web), it compiles all the .vb or .cs
files into one .dll.
o When you publish the site, you only publish the .aspx and .dll
files. (The .vb and .cs files server no purpose at run time,
so why put them on your public site where intruders might
steal them?)
o When a visitor requests a page, the .aspx file inherits
properties, methods, and events from an object in the compiled
.dll file. This is how the HTML and the code behind it come
together.
o For security and reliability reasons, SharePoint won't run
code from just any DLL. It only accepts code that's been
digitally signed and registered.
o FrontPage can't compile .vb and .cs files into a DLL. I think
there are command-line tools that can do such compilations,
but who needs that? For $100 or so you can get Visual Basic
.NET Standard or C# Standard and get a much better toolset.

For mode detail, and a more reliable answer, you should probably take
this question onto one of the SharePoint newsgroups.

Jim Buyens
Microsoft FrontPage MVP
http://www.interlacken.com
Author of:
*----------------------------------------------------
|\---------------------------------------------------
|| Microsoft Office FrontPage 2003 Inside Out
||---------------------------------------------------
|| Web Database Development Step by Step .NET Edition
|| Microsoft FrontPage Version 2002 Inside Out
|| Faster Smarter Beginning Programming
|| (All from Microsoft Press)
|/---------------------------------------------------
*----------------------------------------------------

 

[Jim Buyens]

For some information on how Web Parts created in VS.NET can respond to
events other than Pgae Load, brwose:

http://msdn.microsoft.com/library/en-us/odc_sp2003_ta/html/sharepoint_northwindwebparts.asp

Jim Buyens
Microsoft FrontPage MVP
http://www.interlacken.com
Author of:
*----------------------------------------------------
|\---------------------------------------------------
|| Microsoft Office FrontPage 2003 Inside Out
||---------------------------------------------------
|| Web Database Development Step by Step .NET Edition
|| Microsoft FrontPage Version 2002 Inside Out
|| Faster Smarter Beginning Programming
|| (All from Microsoft Press)
|/---------------------------------------------------
*----------------------------------------------------

Thanks again for your help Jim.

A good example of what I am trying to do is provision a SharePoint Site (or
any API call really) when a list item is created. Does anyone have any idea
how to accomplish that kind of task?

Since FrontPage is the recommended tool (really the only tool) for working
with the SharePoint ASPX pages I'm somewhat stuck. FrontPage/SharePoint
doesn't seem to support inline server-side (or code-behind) and Web Part
code doesn't appear to run on post back. It only seems to run when the form
is initially requested.

I actually DO know how to create custom Web Parts in VS.NET, sign them with
a key, deploy them, and import them into a FrontPage SharePoint Site/Area.
However, I can't get Web Part code to run when the page is _posted_. It only
runs when the page is initially loaded.

What I'm chasing is the hope of executing server-side code in any fashion as
the second bullet in this MSDN article seems to indicate is possible:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/spptsdk/html/tsovNETSupport.asp
It says: "Inline script is not executed in a default page, such as for
working with lists or managing a site, although you can implement
code-behind pages in which script will run." Is this MSDN article wrong?

If I switch to a full blown ASP.NET application I loose the SharePoint Web
Part architecture which is the reason for basing our application on the WSS
platform.

<Todd />

"Todd" <[email protected]> wrote in message

This PowerPoint presentation on the FrontPageDevKit site:
http://www.frontpagedevkit.com/demo... for SharePoint Products and Technologies.ppt

eludes to the ability to do code behind. See the 17th page on Deployment and
Security slide. It clearly says that "Inline script in the page will not
execute [but] code behind in pages can be made to work".

I'm not a definitive expert on SharePoint, but I did some research a
while ago and creating a Web Part is the solution I found.

This doesn't mean creating a Web part through FrontPage or through the
SharePoint Web interface; it means creating a special kind of custom
control in Visual Studio, compiling it, digitally signing it, and then
registering it to the SharePoint server.

The way you'd do form field validation is to design the form and write
the code in Visual Studio, just as you'd do for a native ASP.NET
application, except that you'd be creating a Web Part rather than a
Web Form.

The "Code Behind" approach,in case you don't know, means that:
o The HTML resides in an .aspx file and the program code resides in a
separate .vb or .cs file (.vb for Visual basic, .cs for C#).
o When Visual Studio compiles the project (which is roughly
analogous to a FrontPage Web), it compiles all the .vb or .cs
files into one .dll.
o When you publish the site, you only publish the .aspx and .dll
files. (The .vb and .cs files server no purpose at run time,
so why put them on your public site where intruders might
steal them?)
o When a visitor requests a page, the .aspx file inherits
properties, methods, and events from an object in the compiled
.dll file. This is how the HTML and the code behind it come
together.
o For security and reliability reasons, SharePoint won't run
code from just any DLL. It only accepts code that's been
digitally signed and registered.
o FrontPage can't compile .vb and .cs files into a DLL. I think
there are command-line tools that can do such compilations,
but who needs that? For $100 or so you can get Visual Basic
.NET Standard or C# Standard and get a much better toolset.

For mode detail, and a more reliable answer, you should probably take
this question onto one of the SharePoint newsgroups.

Jim Buyens
Microsoft FrontPage MVP
http://www.interlacken.com
Author of:
*----------------------------------------------------
|\---------------------------------------------------
|| Microsoft Office FrontPage 2003 Inside Out
||---------------------------------------------------
|| Web Database Development Step by Step .NET Edition
|| Microsoft FrontPage Version 2002 Inside Out
|| Faster Smarter Beginning Programming
|| (All from Microsoft Press)
|/---------------------------------------------------
*----------------------------------------------------

 

[Todd]

Thanks! I'll post here once I have a solution.

<Todd />

For some information on how Web Parts created in VS.NET can respond to
events other than Pgae Load, brwose:

http://msdn.microsoft.com/library/en-us/odc_sp2003_ta/html/sharepoint_northwindwebparts.asp

Jim Buyens
Microsoft FrontPage MVP
http://www.interlacken.com
Author of:
*----------------------------------------------------
|\---------------------------------------------------
|| Microsoft Office FrontPage 2003 Inside Out
||---------------------------------------------------
|| Web Database Development Step by Step .NET Edition
|| Microsoft FrontPage Version 2002 Inside Out
|| Faster Smarter Beginning Programming
|| (All from Microsoft Press)
|/---------------------------------------------------
*----------------------------------------------------



"Todd" <[email protected]> wrote in message

Thanks again for your help Jim.

A good example of what I am trying to do is provision a SharePoint Site (or
any API call really) when a list item is created. Does anyone have any idea
how to accomplish that kind of task?

Since FrontPage is the recommended tool (really the only tool) for working
with the SharePoint ASPX pages I'm somewhat stuck. FrontPage/SharePoint
doesn't seem to support inline server-side (or code-behind) and Web Part
code doesn't appear to run on post back. It only seems to run when the form
is initially requested.

I actually DO know how to create custom Web Parts in VS.NET, sign them with
a key, deploy them, and import them into a FrontPage SharePoint Site/Area.
However, I can't get Web Part code to run when the page is _posted_. It only
runs when the page is initially loaded.

What I'm chasing is the hope of executing server-side code in any fashion as
the second bullet in this MSDN article seems to indicate is possible:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/spptsdk/html/tsovNETSupport.asp
It says: "Inline script is not executed in a default page, such as for
working with lists or managing a site, although you can implement
code-behind pages in which script will run." Is this MSDN article wrong?

If I switch to a full blown ASP.NET application I loose the SharePoint Web
Part architecture which is the reason for basing our application on the WSS
platform.

<Todd />

"Todd" <[email protected]> wrote in message

This PowerPoint presentation on the FrontPageDevKit site:

http://www.frontpagedevkit.com/demo... for SharePoint Products and Technologies.ppt

eludes to the ability to do code behind. See the 17th page on

Deployment
and

Security slide. It clearly says that "Inline script in the page will not
execute [but] code behind in pages can be made to work".

I'm not a definitive expert on SharePoint, but I did some research a
while ago and creating a Web Part is the solution I found.

This doesn't mean creating a Web part through FrontPage or through the
SharePoint Web interface; it means creating a special kind of custom
control in Visual Studio, compiling it, digitally signing it, and then
registering it to the SharePoint server.

The way you'd do form field validation is to design the form and write
the code in Visual Studio, just as you'd do for a native ASP.NET
application, except that you'd be creating a Web Part rather than a
Web Form.

The "Code Behind" approach,in case you don't know, means that:
o The HTML resides in an .aspx file and the program code resides in a
separate .vb or .cs file (.vb for Visual basic, .cs for C#).
o When Visual Studio compiles the project (which is roughly
analogous to a FrontPage Web), it compiles all the .vb or .cs
files into one .dll.
o When you publish the site, you only publish the .aspx and .dll
files. (The .vb and .cs files server no purpose at run time,
so why put them on your public site where intruders might
steal them?)
o When a visitor requests a page, the .aspx file inherits
properties, methods, and events from an object in the compiled
.dll file. This is how the HTML and the code behind it come
together.
o For security and reliability reasons, SharePoint won't run
code from just any DLL. It only accepts code that's been
digitally signed and registered.
o FrontPage can't compile .vb and .cs files into a DLL. I think
there are command-line tools that can do such compilations,
but who needs that? For $100 or so you can get Visual Basic
.NET Standard or C# Standard and get a much better toolset.

For mode detail, and a more reliable answer, you should probably take
this question onto one of the SharePoint newsgroups.

Jim Buyens
Microsoft FrontPage MVP
http://www.interlacken.com
Author of:
*----------------------------------------------------
|\---------------------------------------------------
|| Microsoft Office FrontPage 2003 Inside Out
||---------------------------------------------------
|| Web Database Development Step by Step .NET Edition
|| Microsoft FrontPage Version 2002 Inside Out
|| Faster Smarter Beginning Programming
|| (All from Microsoft Press)
|/---------------------------------------------------
*----------------------------------------------------