WEB SKIN : CRÉEZ UNE INTERFACE ASPNET POUR VOTRE CLIENT LOURD DOTNET SANS IIS. H
godvicien
Messages postés
36
Date d'inscription
dimanche 23 janvier 2005
Statut
Membre
Dernière intervention
6 avril 2014
-
7 mai 2008 à 11:50
cs_Warny Messages postés 473 Date d'inscription mercredi 7 août 2002 Statut Membre Dernière intervention 10 juin 2015 - 2 déc. 2008 à 22:27
cs_Warny Messages postés 473 Date d'inscription mercredi 7 août 2002 Statut Membre Dernière intervention 10 juin 2015 - 2 déc. 2008 à 22:27
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/46581-web-skin-creez-une-interface-aspnet-pour-votre-client-lourd-dotnet-sans-iis-hebergement-interne-de-webapp
https://codes-sources.commentcamarche.net/source/46581-web-skin-creez-une-interface-aspnet-pour-votre-client-lourd-dotnet-sans-iis-hebergement-interne-de-webapp
2 déc. 2008 à 22:27
2 déc. 2008 à 19:12
//disable stop
this.btnStopServer.Enabled = false;
//close page
_ServerASPNET.CloseBrowserOnWebApp();
//stop the server
_ServerASPNET.StopThread_ServerASPNET();
//enable start
this.btnStartServer.Enabled = true;
17 mai 2008 à 18:28
a mettre dans le code-behind de la page :
/// <summary>
/// Override: nothing.
/// </summary>
///
public override void VerifyRenderingInServerForm(Control control)
{
//nothing
}
/// <summary>
/// Override: call Render_WithAutoPostBack().
/// </summary>
///
protected override void Render(HtmlTextWriter htmlWriterResponse)
{
this.Render_WithAutoPostBack(htmlWriterResponse);
}
/// <summary>
/// Render the html of the page with AutoPostBack events.
/// </summary>
///
protected void Render_WithAutoPostBack(HtmlTextWriter htmlWriterResponse)
{
//TODO: update the list of YOUR controls that have the AutoPostBack properties
Control[] controlsWithAutoPostBack =
new Control[] { this.ddlSemanticLangs };
//make a new htmlTextWriter on a stringWriter
StringWriter stringWriter = new StringWriter();
HtmlTextWriter htmlTextWriter = new HtmlTextWriter(stringWriter);
//render the page
base.Render(htmlTextWriter);
htmlTextWriter.Flush();
string html = stringWriter.ToString();
//add inputs hidden for AutoPostBack function
html = html.Replace("\n" +
"\n" +
//"\n" +
"<script type="text/javascript">\n" +
" var theForm = document.forms['aspnetForm'];\n" +
" if (!theForm) {\n" +
" theForm = document.aspnetForm;\n" +
" }\n" +
"function __doPostBack(eventTarget, eventArgument) {\n" +
" if (!theForm.onsubmit || (theForm.onsubmit() != false)) {\n" +
" theForm.__EVENTTARGET.value = eventTarget;\n" +
" theForm.__EVENTARGUMENT.value = eventArgument;\n" +
" theForm.submit();\n" +
" }\n" +
"}\n" +
"</script>\n" +
"<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE");
//loop to treat each control with AutoPostBack
foreach (Control control in controlsWithAutoPostBack)
{
//get render of the control
StringWriter strWriter = new StringWriter();
HtmlTextWriter htmlWriter = new HtmlTextWriter(strWriter);
control.RenderControl(htmlWriter);
htmlWriter.Flush();
string htmlControl = strWriter.ToString();
//get id of the control
XmlDocument xmlControl = new XmlDocument();
xmlControl.LoadXml(htmlControl);
string idControl = "id="" + xmlControl.DocumentElement.Attributes["id"].Value + """;
//build onchange function
string onchange = "onchange="javascript:setTimeout('" + this.GetPostBackEventReference(control).Replace("'", "\\'") + "', 0)"";
//affect in html
html = html.Replace(idControl, idControl + " " + onchange);
}//next control
//write html in the response
htmlWriterResponse.WriteLine(html);
}
Comme vous pouvez le voir il suffit de mettre a jour la liste des controls qui utilisent le AutoPostBack au d?but de la fonction Render_WithAutoPostBack().
17 mai 2008 à 13:29
Pourquoi ? Myst?re ...
16 mai 2008 à 08:08
J'ai ajouté quelques fonctionnalités indispensables :
- Gestion des sous-repertoires de la WebApp (dont App_GlobalRessources)
- Gestion des fichiers Non-ASP (images, css, html)
A part ca j'ai découvert que l'on pouvait débuguer la WebApp avec ce server comme pour une WebApp sous IIS.
C'est magique, il suffit d'inserer un point d'arret dans une page web.
12 mai 2008 à 14:44
J'ai fais le teste à l'instant, ca fonctionne en réseau local (pas essayé par internet). Il suffit d'indiquer l'ip de la machine sur le formulaire de la V3. Le serveur écoute alors tout les requêtes du réseau. Reste qu'il me semble que les box-internet modernes masquent l'ip de la machine sur internet. Faut donc faire quelques testes.
J'ai donc mis à jour la source pour vous donner la version finale qui intègre une dll (ServerASPNET.dll) qu'il faut simplement placer dans le répertoire /bin/ de votre WebApp. Et d'instancier ensuite la classe 'ServerASPNET' dans votre client lourd.
Vous pouvez maintenant mettre une note à mon code...
9 mai 2008 à 09:51
Le débat est fort intéressant et pourrait durer un bon moment: peut-on mélanger client lourd/client léger ?
Pour ma part, je pense que non pour les même raisons que Sebmafate. Un client lourd a ses avantages fortement appréciables. Néanmoins, il est vrai que les entreprises (du moins, basé sur mon expérience) ont tendance à faire route vers des clients légers (comme disait Seb: plus appréciable pour leur côté maintenance).
Mais je ne pense vraiment pas que ce soit le côté graphique et interface qui rebutent les gens à utiliser les logiciels client lourd.
Enfin tout ça pour dire que l'intérêt de ce code n'est pas moindre. Il m'intéresse beaucoup et, faute à moi de ne pas télécharger tous les codes du site, il fera partie de la rare liste de code que j'aurais téléchargé sur code source afin de le dépouiller. Il m'apprendra certainement beaucoup de choses dans ma courte expérience du .Net.
Et pour cela (ne pas avoir laisser dormir le code sur ton ordi sans jamais le poster), je t'en remercie GodVicien
Bonne journée,
Billou_13
PS: Et n'oubliez pas, avant de s'occuper de supprimer les clients lourds, faudrait surement penser à s'occuper de la communauté JAVA d'abord ^^
8 mai 2008 à 21:13
En effet, si tu programme un service, par définition sans interface, il peut être interessant, voire très pertinent, d'exposer une interface web pour le piloter.
Et puis n'oublions pas qu'une célebre application de p2p (eMule) peut exposer du web pour être contrôlée à distance.
Il existe même un antivirus d'entreprise (officescan) dans laquelle les clients exposent un service web pour être contactés par le serveur pour être notifiés des mises à jour importantes.
Même dans une application de gestion, on pourrait imaginer une interface qui permette à l'administrateur de vérifier le bon fonctionnement du programme client, de vérifier l'état de la machine, d'installer ou de désinstaller des programmes ou des modules à distance...
Tout ça pour dire que la technique qui est présentée ici est interressante, ce qui compte ensuite, c'est de lui trouver une application, ce qui, et je le conçois parfaitement, n'entre pas dans le périmètre de la majorité des applications.
8 mai 2008 à 13:03
Mais, j'ai aussi une très bonne culture du WinForms.
Maintenant, chacun ses choix. Mais pour moi, quitte à avoir une application à déployer sur _chaque_ poste, autant que ce soit du Windows Forms : pour la puissance, la souplesse et la robustesse.
8 mai 2008 à 10:50
Je crois que pour dire ca tu n'as pas de clients à satisfaire, ou alors tu es un pro des WinForms. Car, pour mon application, la skin de base est une WinForm, et à chaque fois c'est la même remballe : C'est condensé, riche, complexe, bref peu-lisible pour quelqu'un qui n'a pas été spécialement formé à l'interface.
La philosophie d'un client lourd ou client riche, à base de WinForms, est d'être très puissant en offrant un maximum de fonctionnalités sur chaque formulaire. Mon formulaire principale cumule les fonctions de :
- champs de recherches
- listings de résultats
- consultation de fiches
- création de fiches
Tout ca sur le même formulaire, alors qu'en WebApp il y aurait une page par fonctionnalité. Pour être franc les WinForms ont vite tendance à devenir de véritables usines à gaz qui concentrent trop de fonctionnalités. Les utilisateurs de base ne sont pas habitués à autant de fonctionnalités, ils préfèrent une navigation claire par page dans un navigateur Web. Je n'ai pas l'intention de former tous mes utilisateurs donc je décide de me lancer dans l'aventure...
Au fait je précise que malgrès l'utilisation des Visual Express 2008 le projet est compilé pour le Framework .Net 2.0, donc il est possible d'ouvrir les fichiers solution du projet avec Visual Studio 2005 en changeant simplement la version de ces fichiers .sln (textes).
Si vous recompilez le tout n'oubliez pas de mettre une copie de ServerLocalASPNET.exe (ou .dll) dans le dossier /bin/ de l'application, car c'est la que cherchera la fonction de création du Host Server. Il doit y trouver la classe 'ServerLocalASPNET'.
7 mai 2008 à 14:37
Quand tu dois mettre à jour un site intranet, tu interviens sur 1 serveur IIS (voire plus si c'est une ferme)... Dans ton cas, tu perds complètement cet avantage.
Quant aux applications Windows Forms... il est de plus en plus rare de voir une base Access (quand bien même ce soit une tare), on trouve du SqlServer Express, du MSDE2000 (oui encore) voire du SqlServer Compact.
En tout cas, je ne suis pas prêt de changer une application Windows Forms par une pseudo application Web locale. (Surtout que maintenant ClickOnce gomme la contrainte du déploiement)
7 mai 2008 à 12:12
7 mai 2008 à 11:50
Si quelqu'un trouve la solution pour faire marcher cet exemple sous Vista, je pourrai être très gratifiant (je serais même prêt à payer, c'est vous dire).
De même si quelqu'un trouve la solution pour faire fonctionner cet exemple avec Firefox...