The work is now nearly finished, but there are still some task like opera supports requiring further work.

Where can i download the module. I can´t find it!!!!

afantin wrote:

Where can i download the module. I can´t find it!!!!

At the moment you can't download it. Sorry. But the new version should be finished shortly (I now, I have been promising that for a while now)...

Already done:

-> Server Side Code (now true OOP)
-> Client Side Code (also sort of OOP - as far as it's possible with javascript) except:
   -> It should be possible to block external content.
   -> Further compatibility checks should be done.
   -> JS-Code has to be integrated in my Web Component.

English

Description

I know it has been a long period since the last release, but time has been very rare, sorry. But now, the next release is finished and it is not only a bug-fix release, but a complete rewrite. This means, that especially the code is commented much better and even the clientside javascript code takes care of OOP (as far as it's possible - it's still a scripting language).

This module is primarily intended to be used for integrating existing webapplications into a DotNetNuke-Portal. This module offers three independent components, making the integration as seamless as possible: A autoresize-feature, trying to fit the iFrame to the content being displayed, takes care of the optical integration. Furthermore it is possible to let both, the existing webapp and epiFrame / DNN, interact in a very simple manner: Queryparams allow tweaking the module's settings by simply putting parameters, that can individually be activated, into the querystring. It is also possible to provide the shown page with some information about the portal. This can be done with URL-Placeholders.

The autoresize-feature is a main part of the module (also in the first version). It allows individual, but also combined, adjustment of the iFrame's height and width. EpiFrame does also recognize, when the browser-window's size has changed, which is another important step towards seamless integration. Due to current "Web2.0"-Movements, dynamical, clientsite extensions are getting even more important, which epiFrame will also take care of on most browsers (opera isn't supported). However, the module cannot be used to embed foreign content (actually it is possible, but autoresize won't work due to Cross-Domain-Scripting restrictions).

Queryparams allow changing of module-settings, by putting certain parameters into the querystring. Those params can be individually acitivated to prevent missuse.

Url-Placeholders can be used, for providing the page being displayed with further information about the portal / DNN: Placeholders can be put into the source-url and will be replaced with according values. It would be the best, if those values could be encrypted, but I'm missing knowledge being neccessary for implementing such a feature. In case you know how to do this, feel free to implement it.

The module is written entirely in C# and Javascript. At first it has been only intented for being used with .Net2 / DNN4, but converting it to .Net1.1 hasn't been that hard. However due to the lack of some .Net2 features, the DNN3-Version contains at least one part, where a ugly workaround has been used (doesn't change the way the module works, but the source-code isn't as nice as the newer version). You can also use this module (especially source) as basis for your own project, since it makes use of a permissive BSD-style licence.


Feature Overview

This is only intended as a short feature overview. A detailed description can be found either in the description-section or when clicking on the help-button in front of each option on the settings-dialog.

• all features of the iFrame HTML-Element
• Queryparams
• URL-Placeholders
• Autoresize (AutoHeight and/or AutoWidth)
• Detection of dynamic content changes
• Scrollposition is obtained while resizing the iFrame
• External content is opened in the entire Browserwindow or if this fails blocked (concerns only very view js-based redirections). This option is combined with the Autoresize feature, which means you will have to either turn on AutoHeight or AutoWidth to make use of this feature.
• Multiple module instances can be used on a single page
• Some more...

Browser Compatibilty

Some DOM-Objects being used by this module are being implemented differently by nearly every browser. Therefor browsercompatiblity is very tricky and requires a lot of testing. This is the main reason why the autoresize-feature should mainly be used in a well-known environment like a intranet or non-public pages.

For improving browsersupport, I need your feedback about browser not yet being tested. I already tryed Opera 8.52, Firefox 1.0.4, Firefox 1.5.0.1, IE6 and IE7 Beta2. Those browsers support most of epiFrames functionality, but not neccessarily all. Further details can be reviewed in the browser compatibility chart contained in the source-package (info/komp.xls).details about browser-specific issues can be reviewed in the Komp.xls Excel-Sheet from the Src-Package (folder info). A online version being valid for the newest module version can be viewed online: http://www.epifiles.de/daten/epiSource/DNN/epiFrame/komp.xls


Changelog

There's no changelog for this version, as it is a complete rewrite and has only very few parts not being changed since the last release. Anyhow, I want to highlight some features, that should encourage you to use the new version instead of the old one.

• Code-Injection: The queryparams of the 00.XX.XX versions allowed the injection of HTML- and JS-Code.
• Faster: The JS-Code is no longer dynamicly generated. Indeed this causes some overhead, but allows the JS-File to be stored in the browser-cache and speeds up site-generation
• No Flickering: The way size-changes where detected in the old version could cause ugly flickering
• Multiple Module Instances can be used on one page / tab
  
• A lot more...

Version Overview

At the moment, there are three versions trees. All of them offer exactly the same functionality, but run on different platforms. A higher version-number means "nicer" code and module structure, as new features not being avaible in earlier .Net / DNN  versions are used.

2.0.X

• Built using VS2005, .Net 2 and DNN4
• Requires DNN4 and .Net 2
  
• Requires the .resx buildprovider to be enabled, which means that
  the buildProviders section (web.config) should look as follows:
  
  <buildProviders>
      <!--<remove extension=".resx"/>-->
      <!--<remove extension=".resources"/>-->
   </buildProviders>
  
  Actually there's no need to reactiviate the .resources buildProvider, but it doesn't matter if doing so. See Issue-ID DNNP-2860

1.2.X

• Built using VS2005, .Net 2 and DNN4, but without making use of the Asp.Net 2 localization features
  
• Requires DNN4 and .Net 2
  
• Unlike the 2.0.X tree, there's no need to touch the default web.config. This is achieved by not using the new .Net2 localization features (the ones offered by DNN are used instead).

1.0.X

• Built using VS2005, MsBee, .Net 1 and DNN3
  
• Needs at least DNN3 and .Net 1.1, but also supports DNN4 and .Net 2

Download

All versions can be downloaded from this location: http://www.epifiles.de/daten/epiSource/DNN/epiFrame/

Deutsch

Beschreibung

Das letzte Release liegt nun bereits eine ganze Weile zurück, aber Zeit für dieses Projekt war mir leider nicht gerade viel beschert. Wie auch immer, nun ist die Arbeit an der nächsten version erledigt und es ist dabei nicht nur ein Bugfix-Release, sondern ein von Grund auf neu geschriebenes Modul entstanden. Insbesondere die code-Struktur hat dies positiv beinflusst, so berücksichtigt nun selbst der clientseitige Javascript-Code gewisse OOP-Prinzipien (soweit es eben mit Javascript möglich ist).

Gedacht ist dieses Modul insbesondere für das möglichst nahtlose einbinden bestehender Webanwendungen in das DotNetNuke Portal. Erleichtert wird dies durch drei Kernkomponenten, die sich auch unabhängig von einander nutzen lassen: Um die optische Eingliederung zu erleichtert versucht das Modul die Größe des darstellenden iFrame automatisch an dessen Inhalt anzupassen. Darüberhinaus soll auch das Zusammenspiel zwischen epiFrame / DNN  und der bestehenden Anwendung erleichtert werden. Dies geschieht durch Queryparameter, welche die äußere Einflussnahme auf das Modul erlauben und der Möglichkeit der dargestellten Seite Informationen über das Portal mitzuteilen (URL-Placeholder).

Ein zentraler Bestandteil - auch bereits der ersten Version - war die Autoresize-Funktion. Sie ermöglicht das getrennte (aber auch gemeinsame) Anpassen von Höhe und Breite. Auch reagiert epiFrame flexibel auf Größenveränderungen des Browserfenster, sodass der Inhalt fast vollständig integriert wird. In Folge der "Web2.0"-Entwicklungen, wird immer häufiger auf dynamische, clientseitige Erweiterungen zurückgegriffen, aber auch damit kommt das Modul weitestgehend zurecht (weitestgehend, da Opera nicht unterstützt wird). Für das einbinden fremder Inhalte lässt sich diese Funktion aufgrund eingeschränktem Cross-Site-Scripting (von nahezu jedem Browser werden Scriptfunktionen über Domaingrenzen hinweg aus Sicherheitsgründen blockiert) allerdings nicht nutzen, da dies in den meisten Fällen auch eine Urheberrechtsverletzung zur Folge hätte, kann man dies aber durchaus auch als gewollt bezeichnen - ändern lässt es sich so oder so nicht.

Die Queryparameter ermöglichen das Anpassen der Moduleinstellungen "von außen": Es können individuell freischaltbare Parameter wie z.B. epiHeight in den Querystring eingebaut werden. Auf diese Weise lassen sich alle Optionen flexibel steuern (in diesem Beispiel die Höhe des iFrame).

Url-Platzhalter ermöglichen das Übermitteln von Informationen an die im iFrame dargestellte Seite. An der gewünschten Stelle werden Informationen, die das DNN-Portal zur Verfügung stellt in den Seitenaufruf der darzustellenden Seite eingebaut. Ein verschlüsseln dieser Parameter ist jedoch leider noch nicht möglich und wird in Ermangelung des notwendigen Wissens von mir auch nicht implementiert - es steht jedoch jedem frei selber Hand anzulegen ;)

Geschrieben wurde das Modul in C# und Javascript. Ursprünglich war es nur für .Net2 (DNN4) gedacht, es hat sich aber herausgestellt, dass die Rückportierung ohne weiteres möglich ist. Einige neue Funktionen können bei der DNN3-Variante jedoch nicht verwendet werden, was bei dieser Variante an einer stelle etwas unschönen Code zur Folge hat (entsprechend im Quelltext kommentiert). Falls der Quellcode für eigene Zwecke verwendet werden soll, ist dies im Rahmen der sehr freizügigen BSD-Lizenz ebenfalls möglich.


Feature Übersicht

Eine genaue Beschreibung der einzelnen Features ist im Abschnitt Beschreibung zu finden. Weitergehende Informationen liefert insbesondere auch die Hilfefunktion des übersichtlichen Einstellungs-Dialogs (einfach auf das Fragezeichen vor der jeweiligen Option klicken).

• Alle Feature des iFrame HTML-Elements
  
• Queryparameter
• URL-Platzhalter
• Autoresize (AutoHeight und/oder AutoWidth)
• Erkennung dynamischer Veränderungen des Inhalts
• Scrollposition bleibt bei der Größenanpassung erhalten
• Externer Inhalt wird im gesamten Browserfenster dargestellt. Sollte dies fehlschlagen, wird die Seite geblockt (betrifft bloß sehr wenige javascript-basierte Weiterleitungen). Diese Funktion ist mit dem AutoResize-Feature gekoppelt.
• Mehrere Modulinstanzen auf einer Seite möglich
  
• Einige weitere...
  

Browserkompatibilität

Einige von diesem Modul verwendete DOM-Objekte werden von fast jedem Browser verschieden implementiert. Deshalb ist die Browserkompatibilität sehr trickreich und erfordert etliche Tests. Das ist der Hauptgrund, warum die Autoresize-Funktion hauptsächlich in bekannten Umgebungen wie Intranets oder nicht öffentlichen Seiten verwendet werden sollte.

Um die Browserkompatibilität zu verbessern, benötige ich Rückmeldungen bezüglich bisher noch nicht unterstützter Browser. Bisher habe ich Opera 8.52, Firefox 1.0.4, Firefox 1.5.0.1, IE6 und IE7 Beta 2 getestet. Diese Browser unterstützen den großteil der epiFrame-Funktionen, aber nicht grundsätzlich alle. Weitere Informationen bietet eine Übersichtstabelle, die in den Source-Paketen enthalten ist (Ordner info). Die für die jeweils aktuellste epiFrame-Version gültige Tabelle kann auch online unter folgender Addresse betrachtet werden: http://www.epifiles.de/daten/epiSource/DNN/epiFrame/komp.xls


Changelog

Für diese Version gibt es kein Changelog, da das Modul von Grund auf neugeschrieben wurde und fast nichts mehr mit den bisherigen Versionen zu tun hat. Dennoch möchte ich einige Veränderungen besonders hervorheben:

• Code-Injection: Die Queryparameter der 00.XX.XX Versionen erlauben das einschleußen von HTML- und Javascript code.
• Schneller: Der Javascript-Code wird nicht mehr dynamisch erzeugt.  Zwar sorgt das für einigen Overhead, allerdings ermöglicht es dem Browser die JS-Datei im Browsercache abzulegen und beschleunigt die Seitenerzeugung.
• Kein Flackern: Die Art und Weise, wie bisher Größenverändungen erkannt wurden neigte zum Flackern.
• Mehrere Modulinstanzen können auf einer Seite / einem Tab verwendet werden.
  
• Viele weitere...
  

Versionsübersicht

Im Moment existieren drei verschiedene Versionsreihen. Alle bieten exakt die selbe Funktionalität, unterstützen aber unterschiedliche Plattformen. Eine höhere Versionsnummer bedeutet i.d.R. "hübscheren" Code und ein besser strukturiertes Modul, da einige Funktionen verwendet werden, die in früheren .Net bzw. DNN Versionen noch nicht zur Verfügung standen.

2.0.X

• Erstellt mit VS2005, .Net2 und DNN4
• Benötigt DNN4 und .Net 2
  
• Der .resx-Buildprovider muss aktviert sein. Das bedeutet der buildProviders-Abschnitt der web.config sollte wie folgt angepasst werden:
  
  <buildProviders>
      <!--<remove extension=".resx"/>-->
      <!--<remove extension=".resources"/>-->
  </buildProviders>
  
  Eigentlich ist es nicht notwendig auch den .resource buildProvider zu reaktivieren, allerdings richtet man dadurch auch keinen Schaden an. Weitere Informationen sind unter der Issue-ID DNNP-2860 zu finden.
  

1.2.X

• Erstellt mit VS2005, .Net 2 und DNN4, aber ohne die Asp.Net 2 Localization-Funktionen
  
• Benötigt DNN4 und .Net 2
• Im Gegensatz zu den 2.0.X-Versionen, besteht kein Grund die standard web.config zu verändern. Dies ist möglich, indem auf die .Net 2 Localization Funktionen verzichtet wird (Die von DNN zur Verfügung gestellten Alternativen werden verwendet).

1.0.X

• Erstellt mit VS2005, MsBee, .Net 1 und DNN3
  
• Benötigt mindestens DNN3 und .Net 1.1. DNN4 und .Net 2 werden ebenfalls unterstützt

Download

Alle Versionen können hier heruntergeladen werden: http://www.epifiles.de/daten/epiSource/DNN/epiFrame/

Kabelsalat,

can you please explain your reasons for using ASP.Net 2 localization in you 2.0 module? AFAIK this is not supported by the DNN built in language editor, so translator will need extra tools to create installable lanugage packs. Thank you.

The answer is simple: I do like the Asp.Net localization features more and furthermore I didn't see any drawbacks at the beginning. Actually the only Contra-Aspect of the Asp.Net localization in combination with DotNetNuke I figured out till now, is that the default web.config disables the .resx BuildProvider which is neccessary to use Asp.Net localization. After reenabling it everything worked as desired and I wasn't able to notice any side-effects (see related bug-report mentioned in my previous post). Anyhow, requiring changes to the default web.config is always problematic for a module, therfor I made the 1.2.x-Version tree which only uses the localization features offered by DNN (additionally this made converting the module back to DNN3 somewhat easier).


PS: I never tested the integrated Language Editor, but I cannot imagine of any problems related to Asp.Net localization: Only the way the .resx files are accessed changes, not the files itself and what else does the Language Editor do than editing .resx files below the App_LocalResources folders?

IMHO, you should test translating your module with the language editor, if you want users to be able to use your module outside English tongued countries. Note that it is sensitive regarding location and names of the files, as well as their internal structure.

I'll definitely give the Language Editor a try...

Btw: The module is already translated into german. This was done using GlobalResource (http://www.everylittlething.net/GlobalResource/).

Even with version 2.0.0 (Asp.Net localization), the language editor is able to identify all resources correctly... works like a charm :)

Sorry for this tripple-post, but editing has been disabled a long time a go :(

-> Tested using DotNetNuke 4.0.3 + epiFrame 2.0.0

Kabelsalat,

being the most experienced DNN translator, maybe I should explain saome details of the localization concept of DotNetNuke:

The localization solution consists of components for implicit and explicit translation of strings used in the core and all modules. This part competes with ASP.Net 2.0 localization. Both use resx files to store the resource keys and values per language. AFAIK they have different naming conventions for files and maybe fallback mechanisms. The base language resource files are created in the developement environment.

For translators of the core or modules, there are the following tools: language editor, resource verifier, resource pack generator and resource pack installer.

The language editor is for creating and editing localized resource files. It adds missing keys and removes obsolete one and you can optionally highlight pending translations. you can also use the editor to create portal individual adoptions of the language files.

The resource verifier compares translated resource files with the original ones and reports missing or outdated files and missing or obsolete keys.

The resource pack generator creates a language pack for the complete installation, the core framework, one or multiple modules and providers. Each language pack is language specific.

The resource pack installer import a resource pack and places the files into existing folders. It reports files, tha cannot be installed e.g. because of not installed modules or providers.

As a conclusion, DNN comes with a full set of tools for efficient translation of DNN and its components into any language.

have you checked the output of the resource verifier as well and creating a new language. I know, there are areas, where the language editor can be bitchy.

Kabelsalat:

Sorry for this tripple-post, but editing has been disabled a long time a go :(

AFAIK editing is limited to unmoderated users only. You need a couple of posts to get unmoderated. Notice, that the DotNetNuke forums on ASP.Net will be closed in the future (no date fixed yet), please use the forums on DotNetNuke.com for announcements and discussions.

In some sub-forums (and as it seems also this one) I'm unmoderated, but editing still isn't possible. However, this doesn't concern the topic...

... Yepp, you're right with saying DNN and Asp.Net localization features are competing, but this does not mean they would not work together. Actually both do exactly the same, only the code-base is different. Both use the same naming-convention, fallback-mechanisms are the same (per default) and the .resx files use the same format. This is the reason why I do not see any problems with using both, Asp.Net and DNN localization together. When looking at Library/Components/Localization/Localization.vb you'll notice that DNN is implementing localization mostly the same way as the new .Net 2 features do.


PS: I'm using the Asp.Net forums, since I started this thread here and because of the "real" DotNetNuke forums loading slower and being harder to read (the design isn't that clear). However, it seems like I'll be forced to move to the new forums...

I forgot to mention one DNN localization function, that was implemented to support the developer and is also annonced to be used in planned module certification: the "show missing keys" switch in web.config. I f turned on, it will indicate by a special prefix, which texts don't have a localization (this is also improved in upcoming DNN 3.3/4.1)