12
votes

Modèles d'interface utilisateur en JavaScript

Quels motifs UI utilisez-vous habituellement dans JavaScript?

Par motifs d'interface utilisateur, je veux dire les meilleures pratiques à utiliser pour construire et organiser l'interface utilisateur, générée / gérée à partir de JavaScript (en dehors des bibliothèques comme JQuery ou Yui).

Par exemple, si vous venez de .NET World, vous connaissez la famille MVC (Model-View-Controller). Dans le monde de Winforms et ASP.NET, vous rencontrerez une présentatrice de vue modèle. Dans WPF, vous trouverez probablement une approche MVVM (Model-View-ViewModel).

Et qu'en est-il de JavaScript?


1 commentaires

Theres aucune raison pour laquelle MV [C | P] devrait s'appliquer - sa jolie langue indépendante.


6 Réponses :


1
votes

Comme je sais qu'il n'y a pas encore de motifs spécifiques pour JavaScript. Mais je pense qu'il y a un potentiel de quelque chose comme une approche de widgets (composante). Depuis principalement, nous utilisons JavaScript pour responsabiliser notre code HTML. Il est logiquement que nous devrions connecter notre objet JavaScript à la balise HTML. Nous avons donc quelque chose comme modèle (JSOBJECT) + vue (HTMLrePresentation). Pour obtenir MVC, nous avons besoin de contrôleurs et nous avons des événements pour cela. Dans ce cas, nous aurons une composante facilement extensibel.

Par exemple: P>

// this is a part of some FormValid.js
<script>
function FormValid(){

}
Components.extendCore(FormValid);

FormValid.prototype.validate=function(){...}
</script>

FormValid.prototype.templates={
   main:'<form class="form1"...onsubmit="this.jsObject.validate();">...</form>'
}

//this is our HTML
<div id="form1"></div>
<script>
Components.Attach("FormValid").to("form1");
</script>


3 commentaires

Les widgets / composants sont déjà couverts par Yui, JQuery, Extjs, Dojo, etc. et la question de savoir sur les approches "en dehors de" ces bibliothèques.


Je vois ton point djko! Pour certaines raisons, je ne me sens pas confiant dans cette technique. Cela me rappelle du code désordonné ASPX + derrière, mais dans ce cas, c'est comme le code-derrière-derrière est écrit directement dans la page ASPX (Eh bien, disons que j'ai oublié ). L'UI agit comme une vue et un contrôleur en même temps. Et le modèle devrait connaître beaucoup pour faire des changements dynamiques dans l'interface utilisateur (par exemple, changer sa classe) ... Peut-être que vous pourriez peut-être donner de bons exemples du monde réel avec une démonstration de cette idée?


Je comprends vos préoccupations, mais pour le développement du client, la fonction JavaScript est de travailler avec UI. Cela devrait donc en savoir beaucoup et interagir profondément avec elle. D'autre part, je peux vous montrer l'exemple où il est possible de séparer la vue et le modèle. Voir la réponse mise à jour.



8
votes

Les motifs sont généralement agencés-agnostiques. Si un motif a une valeur, à l'aide de certains cas de bord, il aura de la valeur quel que soit la langue ou la technologie que vous utilisez. Prendre mvc. Le concept de séparation du modèle de la vue du contrôleur a une valeur, que le modèle soit implémenté avec une SGBBR ou une autre technologie, que la vue soit HTML ou Swing ou X.

où vous voyez certains modèles appliqués plus dans une technologie qu'un autre, cela signifie généralement que les développeurs de la technologie avaient une approche particulière qu'ils ont soutenu plus complètement que d'autres.

JavaScript lui-même n'impose aucun modèle particulier sur vous. Certains cadres javascript, tels que Yui ou Dojo ou Glow auront tendance à vous amener une direction plus qu'une autre.

À la fin de la journée, examinez le problème que vous résolvez, les ressources et l'expérience que vous avez et suivez les modèles qui ont un sens.


1 commentaires

Merci pour la réponse, t.j! Je ne l'ai pas marqué comme une réponse avant, parce que j'étais sans doute. Je pensais qu'il devrait y avoir quelque chose de plus populaire que le reste. Mais on dirait dans le monde JavaScript que vous utilisez des bibliothèques ou adoptez quelque chose d'autres plates-formes (MVX), ce qui convient à votre problème.



4
votes

J'aimerais recommander Ross Harges & Dustin Diaz's Wook's's Wook, Modèles de design JavaScript PRO , définitivement la meilleure ressource sur ce sujet et valant la peine de lire.

Il y a aussi un article très intéressant sur JavaScript MVC dans le dernier numéro de une liste d'une liste .


1 commentaires

+1 en 2009, mais probablement pas vrai. Ce livre est à partir de 2007, sans aucun doute mal ayant besoin d'une mise à jour. Pourrait vouloir mettre à jour cette réponse. J'ai lu et apprécié JavaScript maintable , qui est excellent mais assez court.



1
votes

Une bonne approche pour la construction de l'application GUI est celle du navigateur:

  1. Utilisation du marquage pour la mise en page UI
  2. Utilisation de la logique UI JavaScript
  3. Utilisation de CSS pour le style UI

    La plupart des cadres d'interface graphique moderne (extjs, dojo, etc.) offrent des API qui aident grandement à construire une interface graphique à JavaScript uniquement. Mais il y a un autre cadre d'interface graphique Ample SDK qui apporte la séparation des préoccupations précédemment mentionnée. Il permet d'utiliser des langues xml (XHTML, XUL, SVG) pour la mise en page, CSS pour style et API DOM pour l'UI logique.

    à orchestrer une application GUI côté client Vous pouvez utiliser MVC ou un peu plus avancé PAC, comme pour l'ancien - il y a un PUREMVC Mise en œuvre disponible

    Vérifiez que le snippet suivant (ne concerne que la logique UI, pas la logique de l'application, pour être construite avec MVC / PAC): < /p>





    xxx

    index.css xxx < /PRE >P > xxx


1 commentaires

Ça semble intéressant. J'en entends la première fois. Savez-vous à quel point cette approche est populaire dans JS World? Je pensais que XUL est une langue utilisée par les applications de Mozilla (uniquement).



0
votes

Consultez un site appelé Quince . Je ne sais pas combien de motifs ici sont des modèles d'interface utilisateur JavaScript. Mais c'est une assez bonne ressource pour les modèles d'interface utilisateur


1 commentaires

Merci pour cette référence, Sandeep. Autant que je sache, le coing est sur les meilleurs modèles de convivialité. Et ma question était liée à l'approche architecturale, utilisée par la communauté JavaScript pour organiser leur couche de présentation. En tout cas, merci encore une fois de mentionner ceci :).



0
votes

Les motifs ne sont pas toujours un langage agnostique. Beaucoup de modèles de design classiques sont inutiles dans JavaScript, car nous n'avons pas besoin de beaucoup de solution de contournement qu'ils résolvent dans des paradigmes plus strictes de languges.

La raison pour laquelle MVC n'est pas un ajustement tellement chaud pour le développement Web côté client, mais est plus situationnel.

Tout d'abord, je pense que le temps et la douleur ont prouvé que des applications Web typiques sont mieux traitées comme deux applications distinctes. Celui qui se produit sur le navigateur et celui qui se produit sur le serveur. Les moins de dépendances que vous établissez entre les deux, les applications Web plus flexibles, maintenables et plus faciles ont été de modifier dans mon expérience. La m est la logique commerciale (quelles personnes ont tendance à se confond avec "la couche de base de données" imo).

Le problème avec MVC dans ce scénario est que nous ne voulons pas exposer la logique commerciale sur le côté client et tenter de mener à MUNGE Toute l'application dans une construction hideuse http-Divide-cache-cache-cachette a été douloureuse comme je l'ai mentionné. < / p>

Des schémas très similaires dans lesquels vous séparez des données ou des préoccupations de "modèle" peut fonctionner assez bien, cependant.


0 commentaires