Migrating To IntraWeb 14 - Atozed Documentation Center

9/7/2020 Migrating to IntraWeb 14 – Atozed Documentation Center
Migrating to IntraWeb 14
Home » Migrating to IntraWeb 14 English > IntraWeb

14 > Migrating to
IntraWeb 14
Migrating to IntraWeb 14
Search …
In order to keep current with changes in browsers, web
servers, as well as Delphi/C++ changes and platforms some Search
code must be changed. This document details the changes to
IntraWeb 14 which may affect users upgrading from older Quick Links
IntraWeb versions.
Site Map
New ContentPath Directory ACORN

CrossTalk
First thing: Forget everything you know about the old /Files/
IntraWeb 14
directory! IntraWeb
Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To nd out more, including how to control cookies, see here: Cookie Policy Application Types
There is a new directory where you should put all your static Getting Started
les like images, JavaScript, style sheets (CSS), etc. This new Migrating
Close andtoaccept

IntraWeb 14
directory is named wwwroot (just like IIS) and resides below
https://doc.atozed.com/en/iw14/migratingto14/ 1/10
your application main binary le (your EXE or DLL IntraWeb Development
application le): Deployment

History
Misc
IntraWeb 15
IntraWeb 17
Many users prefer not to move their les to wwwroot folder

because they have been working with /Files/ folder for a long
time. If this is your case, OK, but have in mind that:
If you have an TIWImageFile control (for instance)

and its ImageFile.FileName property points to
/Files/SomeImage.png, you must have the
SomeImage.png le under wwwroot/Files/
directory. All relative paths are based on
wwwroot content path folder.
On the other hand, if you save your

SomeImage.png le under wwwroot folder, you
only should use the le name, so in this case you
will have:
“ IWImageFile1.ImageFile.FileName :=
‘SomeImage.png’; // no path is required in this case!
IntraWeb server WON’T ever serve a le outside

its ContentPath (wwwroot) folder, unless you use
WebApplication.SendFile() or SendStream()
methods.
You may also set a different ContentPath folder for your

IntraWeb application. This should be done in
ServerController.OnCon g event handler.
To nd out more, including how to control cookies, see here: Cookie Policy
Templates directory
Close and accept

When you are working with templates, they should be located

inside the Templates folder, located below your application
main executable. Please check the picture above.
TContentHandler replaces
TURLResponder
TURLResponder components were discontinued. They have
been replaced by the new TContentHandler (and descendant)
classes. Please note that these are not TComponent
descendants, so they are not visible from the Delphi’s
component pallete. They are lightweight classes and consume
less system resources. The most used content handler classes
are: TContentForm and TContentRedirect.
See also: URL & Content Handlers
TIWFileUploader replaces TIWFile

The new TIWFile control does not work in latest IntraWeb
versions anymore. It was replaced by the new
TIWFileUploader, a new and modern AJAX control. The new
IWFileUploader gives developers much more control of the
upload process (e.g. le extensions and le sizes) and a better
upload experience for the user, because it does not require a
full submit. Please note that IWFile is still present on the
component palette, and the associated dcu/pas le are still
there, but it does nothing. We let the control there so you can
safelly open your IW XI or XII application form and replace it
with the new control.
See also: TIWFileUploader
lization of ServerController
Initialization
All ServerController
Privacy setup/initialization
& Cookies: This site uses cookies. By continuing to(i.e. setting
use this website, you agree to their use.
ServerController properties at runtime) must be done inside
the ServerController.OnCon g event. Everything inside this Close and accept

OnCon g event is guaranteed to run only once during
application initialization, before any request is served by

IntraWeb application.
Dynamic Main Forms

Until IntraWeb XII you could use
ServerController.OnNewSession to dynamically set your
application main form (e.g. based on certain conditions or run
time parameters). The OnNewSession event signature
changed, and you should not set the main form there. Instead,
use the new ServerController.OnGetMainForm event. Please
note that you MUST create the form class, and pass it to
vMainForm event parameter. Not doing so will result in a
runtime exception when the rst application session starts,
unless you are calling IWForm’s SetAsMainForm() method
during initialization.
ServerController.OnNewSession
Signature Change
When opening an old ServerController unit having IntraWeb
XIV or XV installed you may receive an error message like this:
This is because ServerController.OnNewSession signature has

changed. To x that, just cut (Ctrl-X) the code within this
event, save the unit, re-create the same event with the new
signature and paste the old code there. Move any vMainForm
related code to OnGetMainForm event handler. Also note that
you may add ASession parameter to the
TIWUserSession.Create
Privacy call (this
& Cookies: This site uses cookies. is optional,
By continuing butwebsite,
to use this allows youyou
agreeto
to their use.
To nd out more, including how to control cookies, see
use UserSession.WebApplication property to access the here: Cookie Policy
WebApplication object). Close and accept


Old ServerController.OnNewSession:
procedure TIWServerController.IWServerController
New ServerController.OnNewSession:
Serving Static Content

In general, when serving static content (e.g. images, PDF les,
ZIP les, etc) IntraWeb server does NOT require session
validation and locking. This greatly improves the overall
IntraWeb application performance. In older IntraWeb versions,
if you had a reference to some le inside the /Files/ folder it
was served by IntraWeb automatically. Now the MIME type for
the le being served MUST be known by IntraWeb, i.e.
registered, otherwise IntraWeb server won’t know how to
provide the content-type response header eld. Most of
common le extensions like .js, .css, .pdf and image le
extensions are already registered during application
initialization. If you need to serve some unusual static le
extension, you must register it using TIWMimeTypes class, like
this (ServerController.OnCon g is also a good place to put this
code):
uses IWMimeTypes;
begin
TIWMimeTypes.RegisterType('.doc', 'application
end;
Close and accept


Absolute and Relative paths (Links,

JavaScript and CSS)
Absolute versus relative paths inside links, JavaScript and CSS
les is a controversial matter. Most JavaScript developers tend
to use relative paths, and use absolute paths only when
referencing a le in another domain. This is quite simple to
justify, because if you move your application to another
domain it won’t break all links. It is also easier to work of ine
with relative paths.
I will not go further explaining the differences, but I should

point that IntraWeb supports both of them, although relative
paths may be tricky when used with IntraWeb. You may
reference your links, JavaScript or CSS les this way:
a) http://mydomain.com/MyApplication.dll/JS/MyLib.js ->
Using an absolute path
or
b) /JS/MyLib.js -> Using a relative path
In example (a) we are using an absolute path for an ISAPI

application running under “mydomain.com” and having
“MyLib.js” inside “wwwroot/JS/” subfolder. Absolute paths also
include the protocol used (HTTP or HTTPS). In the example
(b), we are using a relative path. But here, inside the “relative
paths category” we also have two types of paths: document-
relative and site root-relative paths.
c) JS/MyLib.js -> document-relative path
and
d) /JS/MyLib.js -> root-relative path
The
To rstmore,
nd out type of relative
including path (c)
how to control is usefull
cookies, see here: when the relative
Cookie Policy
physical path of the current document and the linked
Close and accept
document remain the same even when you move les around 
your web server. When you reference something like
JS/MyLib.js you are asking IntraWeb to serve you the le

named “MyLib.js” under a folder named “JS”, below your
current document folder.
The second type of relative path (d) tells IW to serve you a le

named “MyLib.js” under a folder named “JS”, below the root
directory.
Remember that IntraWeb is a web application, not a bunch of

HTML les served by some web server. When using document-
relative paths like in (c), which is the current document
folder? When using root-relative paths, we can be sure that
some reference like (d) is pointing to a le named “MyLib.js”
under a folder named “JS” below our wwwroot (or
ContentPath) folder.
Unfortunately, the rst type of relative path (c) is the most

used within JavaScript and CSS les out there. It has never
been of cially supported by IntraWeb, but it used to work. In
IntraWeb XIV and XV you must use absolute or site root-
relative paths. To convert your document-relative paths to
root-relative paths, just add a slash in the front of the le
reference and you are done. For instance:
‘ a) If you have a le named MyStyle.css under the

folder wwwroot/css, you should use: /css/MyStyle.cssb)
If you have a le named MyLib.js under the folder
wwwroot, you should use: /MyLib.js
All les referenced using root-relative paths (and also

absolute paths) are served without session validation, unless
the MIME type of the le is not registered in IntraWeb server.
So, if you are reading only this line of this document: ALWAYS
PUT A SLASH in front of your le name references and you
should be safe!
Please
To nd outalso
more, check
includingthis good
how to document
control about
cookies, see here: absolute
Cookie Policy and
relative paths.
Close and accept

Cache Files
In older IntraWeb versions there was a method in
WebApplication called NewCacheFile(). Users used it to create
a new cache le (or better, create a new cache le NAME) and
then they could safely use that le name to save images,
reports, whatever. Cache management in IntraWeb XIV and XV
was re-created from scratch and works differently. The rst
rule of IntraWeb XIV and XV cache:
The cache le belongs to the IntraWeb

application!
This means: Once you add (or create) a cache le, it does not
belong to you anymore, so don’t touch it again. In older IW
versions, a cache le was a regular le (e.g a PNG image le)
saved under some special folder. Current cache les are more
than this. The cache le contains the original data (e.g. the
PNG image) but also some metadata used by IntraWeb core
when serving the le. So, once the le is added to the cache,
if you write something to it again, it will become useless and
it won’t be served correctly by IntraWeb.
There is a new utility class named TIWAppCache to help you

with creation of cache les. There are also many demos in our
CodePlex repository showing how to work with the new cache
system.
A simple example of how to create a new image le and add

it to the application cache:
procedure TForm1.SaveImageToCache;
var ImgFileName: string;
ImgUrl: string;
begin
// Get a new file name from the cache system
ImgFileName := TIWAppCache.NewTempFileName();
// Save a file there, in this case an gif imag
Close and accept
// Add the saved file to the cache system. It 
// Please note the type of cache file (ctSessi
// After this point, you must not touch this f

// The whole life-cycle of the file should be
ImgUrl := TIWAppCache.AddFileToCache(GGetWebAp
, ctSession);
// use the image URL in an IWImageFile control

IWImageFile1.ImageFile.URL := ImgUrl;
end;
Renamed Units
A few units were renamed. To update to IntraWeb XIV and XV
you should search the following units and replace with the
new name (GExperts may help you with that):
IWSystem.pas -> IW.Common.System.pas

IWStrings.pas -> IW.Common.Strings.pas
IW.HttpReply.pas -> IW.HTTP.Reply.pas
IW.HttpRequest.pas -> IW.HTTP.Request.pas
IWExtCtrls.pas -> IWCompExtCtrls.pas
New Default DOC TYPE

The default DOC TYPE of IntraWeb’s generated HTML is
<!DOCTYPE HTML>, meaning that we are now using Strict or
standard mode (HTML 5) by default and not Quirks mode
anymore. If you need IntraWeb to render your form using a
different doc type, you must set ServerController.DocType or
IWForm.DocType properties (Form property has precedence
over ServerController’s).
The recommended DocType value for HTML 4 is: <!DOCTYPE

HTML PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN”
“http://www.w3.org/TR/html4/loose.dtd”>
Browsers tend to render and behave differently when using

strict mode, compared to quirks mode. In some cases, a little
ajustment in visual control’s size and/or position maybe
required, but most forms – if not all – should render correctly. Close and accept

You should also add the same doc type to your template les,
when using templates.
Share this:
         
Proudly powered by WordPress | Theme: IWeb Unique by IWEBDM.com.
Close and accept



Migrating To IntraWeb 14 - Atozed Documentation Center

Uploaded by

Copyright:

Available Formats

Migrating To IntraWeb 14 - Atozed Documentation Center

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Migrating To IntraWeb 14 - Atozed Documentation Center

Uploaded by

Copyright:

Available Formats

9/7/2020 Migrating to IntraWeb 14 – Atozed Documentation Center

Home » Migrating to IntraWeb 14 English > IntraWeb

New ContentPath Directory ACORN

your application main binary le (your EXE or DLL IntraWeb Development

application le): Deployment

Many users prefer not to move their les to wwwroot folder

If you have an TIWImageFile control (for instance)

On the other hand, if you save your

IntraWeb server WON’T ever serve a le outside

You may also set a different ContentPath folder for your

When you are working with templates, they should be located

See also: URL & Content Handlers

TIWFileUploader replaces TIWFile

See also: TIWFileUploader

application initialization, before any request is served by

Dynamic Main Forms

This is because ServerController.OnNewSession signature has

WebApplication object). Close and accept

Serving Static Content

Close and accept

Absolute and Relative paths (Links,

I will not go further explaining the differences, but I should

b) /JS/MyLib.js -> Using a relative path

In example (a) we are using an absolute path for an ISAPI

c) JS/MyLib.js -> document-relative path

d) /JS/MyLib.js -> root-relative path

JS/MyLib.js you are asking IntraWeb to serve you the le

The second type of relative path (d) tells IW to serve you a le

Remember that IntraWeb is a web application, not a bunch of

Unfortunately, the rst type of relative path (c) is the most

‘ a) If you have a le named MyStyle.css under the

All les referenced using root-relative paths (and also

The cache le belongs to the IntraWeb

There is a new utility class named TIWAppCache to help you

A simple example of how to create a new image le and add

// After this point, you must not touch this f

// use the image URL in an IWImageFile control

IWSystem.pas -> IW.Common.System.pas

New Default DOC TYPE

The recommended DocType value for HTML 4 is: <!DOCTYPE

Browsers tend to render and behave differently when using

Proudly powered by WordPress | Theme: IWeb Unique by IWEBDM.com.

Close and accept

You might also like