검색결과 리스트
WEB STUDY에 해당되는 글 3건
글
Cross Browser DHTML Modal Dialogs For Web Apps
웹페이지를 만들 때 많이 쓰이면서도 지탄의 대상이 되는것이 있습니다. 바로 페이지를 접근 할 때 마다 뜨는 팝업창들이죠.
팝업창을 사이트에 꼭 필요한 부분에만 적절히 사용한다면 그것만큼 사이트의 주체가 방문자에게 무엇인가를 알릴 수 있는 좋은 방법은 없을 겁니다. 그런점을 악용해 광고나 이벤트성 팝업을 난발하는 사이트가 많아 진게 사실입니다.
오늘 소개할 내용은 Modal Dialogs 에 대한 내용입니다. 모달창은 팝업창과 비슷하지만 약간 다른 형태를 가지게 되죠. 창이 떠 있으면 부모창의 어떤 것도 제어가 안되는 그런 말이죠. 그런 모달 다이얼로그는 IE 브라우저에서 제공되는 기능중에 하나죠. 하지만 요즘처럼 IE 이외에 타 브라우저가 많아진 상태에서 기존 IE 호환 다이얼 로그로 작성된 페이지에서는 오동작을 하게 되니 문제가 생깁니다. ^^
그런 문제를 개선해서 만들어진게 subModal 이라고 불리는 것이구요. 서브모달의 개발자는 자신도 IE의 모달창을 좋아해서 쭉 써오다 크로스 브라우저 환경에서 동작을 하지 않아 subModal 을 만들게 됐다고 하네요 ^^;
(짧은 영어 실력이라 제대로 읽었는지 하하하~)
실제 사용법과 활용법은 원본글의 일부를 발췌 했습니다. 실제 써 보면 참 유용하게
많이 쓰일 수 있을것 같던군요. 물론 팝업창을 대체 하는것은 아니고 모달창이니
나름 쓰이는 용도가좀 다르겠지만. ^^;;
우선 한번 빠져~ 봅시다! ^^
How does it work?
The subModal works by placing a semi-transparent div over the browser, blocking access to the content below while still providing visibility. This maintains state and doesn’t make someone feel disoriented or lost by moving them completely to another page. Their frame of reference is kept while allowing them to perform a new task (usually closely associated with the content below).
Another div is layered and centered on top of the mask. This div contains an iframe which defaults to a “now loading” page. In my applications I usually place an animated gif inside of this page to make it appear the server is doing something while the user waits.
Finally the iframe’s source is swapped with the page you wish to display. When this page is loaded into the iframe it’s title is swapped with our fake title bar and displayed.
Note that this works best when used in concert with a scrollable div underneath. All of my apps make use of this layout technique. It’s rare that the browser window scrolls. This code supports scrolling the entire browser window, but I don’t recommend it.
Where does it work?
I’ve personally tested this technique with IE 6, FireFox 0.9+, and Opera 7. A good friend of mine tested it on Safari and also reports it works there. In theory it should work with IE 5.5, but I don’t have a 5.5 machine to test on currently.
UPDATE
Opera 7 works but with a hack. Since Opera’s css support doesn’t include opacity I’m using a 24 bit transparent PNG file for the demo. If you don’t care about Opera you can comment this out and it will still work in FireFox, IE, and Safari. I like that method better since you have full control over the mask color and opacity right from the CSS file.
How do I use it?
First you might want to download the code. After that it’s as easy as including references to a couple files and inserting some HTML into your page.
At the head of your file you’ll want to add the following references…
<head>
<link rel="stylesheet" type="text/css" href="subModal.css" />
<script type="text/javascript" src="common.js"></script>
<script type="text/javascript" src="subModal.js"></script>
</head>
The css contains sizing and display styles for the popup elements.
Common.js contains standard functions I find useful such as attaching event handlers and obtaining the browser’s dimensions.
subModal.js is where all the action happens. Inside event handlers are attached for the load and resize events of the browser. The load event initializes dhtml objects that are reused when showing, hiding, or resizing the window.
The following HTML also needs to be included in your file. I generally do it at the bottom of the page.
This code could be generated dynamically by the javascript, but for now I like it in HTML.
<div id="popupContainer">
<div id="popupInner">
<div id="popupTitleBar">
<div id="popupTitle"></div>
<div id="popupControls">
<img src="close.gif" onclick="hidePopWin(false);" />
</div>
</div>
<iframe src="loading.html"
style="width:100%;height:100%;background-color:transparent;"
scrolling="auto" frameborder="0"
allowtransparency="true" id="popupFrame"
name="popupFrame" width="100%" height="100%">
</iframe>
</div>
</div>
Now that everything’s in place all you have to do is add something that’s going to call the function to show the modal.
This is accomplished by doing the following
showPopWin('your_url_here.html', width, height, callback_function);
The first argument is the file to load, followed by width and height (integers). Any content that overflows these dimensions will scroll inside the modal, like a real window.
The fourth argument allows you to pass a javascript function that will be called when the window is closed – by calling hidePopWin(true). hidePopWin will not call the return function by default. This is useful for cancel button functions.
Conclusion
I’ve sort of glossed over the the DHTML, so if you have questions check out the code or ask me a question on the google group. In real-world implementations I usually wrap everything inside of a div that throws a shadow over the transparent mask, which adds to the floating effect.
I’m sure some of you are already thinking about how you can put this to use and modify it. Go right ahead! Please just drop me a line if you use it.
I hope it’s as useful to you as it is to me.
Bonus round, the callback function
Updated on 1/11/07
I’ve added a quick write-up about how to use the subModal callback function here.
출처 : http://sublog.subimage.com/articles/2006/01/01/subModal
설정
트랙백
댓글
글
Design Guidelines, Managed code and the .NET Framework By Brad Abrams
MS 내부에서 사용하는 .NET 코딩 가이드 라인이라고 하네요. ^^
평소에 깔끔한 스타일로 코딩을 즐겨 하시는 분들은 참고하세요 ~
Internal Coding Guidelines
Table of Contents
1. Introduction.......................................................................................................................................... 1
2. Style Guidelines.................................................................................................................................... 2
2.1 Tabs & Indenting................................................................................................................................ 2
2.2 Bracing............................................................................................................................................... 2
2.3 Commenting........................................................................................................................................ 2
2.3.1 Documentation Comments............................................................................................................. 2
2.3.2 Comment Style............................................................................................................................. 3
2.4 Spacing............................................................................................................................................... 3
2.5 Naming............................................................................................................................................... 4
2.6 Naming Conventions............................................................................................................................ 4
2.6.1 Interop Classes............................................................................................................................. 4
2.7 File Organization................................................................................................................................. 5
1. Introduction
First, read the .NET Framework Design Guidelines. Almost all naming conventions, casing rules, etc., are spelled out in this document. Unlike the Design Guidelines document, you should treat this document as a set of suggested guidelines. These generally do not effect the customer view so they are not required.
2. Style Guidelines
2.1 Tabs & Indenting
Tab characters (\0x09) should not be used in code. All indentation should be done with 4 space characters.
2.2 Bracing
Open braces should always be at the beginning of the line after the statement that begins the block. Contents of the brace should be indented by 4 spaces. For example:
if (someExpression)
{
DoSomething();
}
else
{
DoSomethingElse();
}
“case” statements should be indented from the switch statement like this:
switch (someExpression)
{
case 0:
DoSomething();
break;
case 1:
DoSomethingElse();
break;
case 2:
{
int n = 1;
DoAnotherThing(n);
}
break;
}
Braces should never be considered optional. Even for single statement blocks, you should always use braces. This increases code readability and maintainability.
for (int i=0; i<100; i++) { DoSomething(i); }
2.3 Single line statements
Single line statements can have braces that begin and end on the same line.
public class Foo
{
int bar;
public int Bar
{
get { return bar; }
set { bar = value; }
}
}
It is suggested that all control structures (if, while, for, etc.) use braces, but it is not required.
2.4 Commenting
Comments should be used to describe intention, algorithmic overview, and/or logical flow. It would be ideal, if from reading the comments alone, someone other than the author could understand a function’s intended behavior and general operation. While there are no minimum comment requirements and certainly some very small routines need no commenting at all, it is hoped that most routines will have comments reflecting the programmer’s intent and approach.
2.4.1 Copyright notice
Each file should start with a copyright notice. To avoid errors in doc comment builds, you don’t want to use triple-slash doc comments, but using XML makes the comments easy to replace in the future. Final text will vary by product (you should contact legal for the exact text), but should be similar to:
//-----------------------------------------------------------------------
// <copyright file="ContainerControl.cs" company="Microsoft">
// Copyright (c) Microsoft Corporation. All rights reserved.
// </copyright>
//-----------------------------------------------------------------------
2.4.2 Documentation Comments
All methods should use XML doc comments. For internal dev comments, the <devdoc> tag should be used.
public class Foo
{
/// <summary>Public stuff about the method</summary>
/// <param name=”bar”>What a neat parameter!</param>
/// <devdoc>Cool internal stuff!</devdoc>
///
public void MyMethod(int bar) { … }
}
However, it is common that you would want to move the XML documentation to an external file – for that, use the <include> tag.
public class Foo
{
/// <include file='doc\Foo.uex' path='docs/doc[@for="Foo.MyMethod"]/*' />
///
public void MyMethod(int bar) { … }
}
UNDONE§ there is a big doc with all the comment tags we should be using… where is that?
2.4.3 Comment Style
The // (two slashes) style of comment tags should be used in most situations. Where ever possible, place comments above the code instead of beside it. Here are some examples:
// This is required for WebClient to work through the proxy
GlobalProxySelection.Select = new WebProxy("http://itgproxy");
// Create object to access Internet resources
//
WebClient myClient = new WebClient();
Comments can be placed at the end of a line when space allows:
public class SomethingUseful
{
private int itemHash; // instance member
private static bool hasDoneSomething; // static member
}
2.5 Spacing
Spaces improve readability by decreasing code density. Here are some guidelines for the use of space characters within code:
- Do use a single space after a comma between function arguments.
Right: Console.In.Read(myChar, 0, 1);
Wrong: Console.In.Read(myChar,0,1); - Do not use a space after the parenthesis and function arguments
Right: CreateFoo(myChar, 0, 1)
Wrong: CreateFoo( myChar, 0, 1 ) - Do not use spaces between a function name and parenthesis.
Right: CreateFoo()
Wrong: CreateFoo () - Do not use spaces inside brackets.
Right: x = dataArray[index];
Wrong: x = dataArray[ index ]; - Do use a single space before flow control statements
Right: while (x == y)
Wrong: while(x==y) - Do use a single space before and after comparison operators
Right: if (x == y)
Wrong: if (x==y)
2.6 Naming
Follow all .NET Framework Design Guidelines for both internal and external members. Highlights of these include:
- Do not use Hungarian notation
- Do not use a prefix for member variables (_, m_, s_, etc.). If you want to distinguish between local and member variables you should use “this.” in C# and “
- Do use camelCasing for member variables
- Do use camelCasing for parameters
- Do use camelCasing for local variables
- Do use PascalCasing for function, property, event, and class names
- Do prefix interfaces names with “I”
- Do not prefix enums, classes, or delegates with any letter
The reasons to extend the public rules (no Hungarian, no prefix for member variables, etc.) is to produce a consistent source code appearance. In addition a goal is to have clean readable source. Code legibility should be a primary goal.
2.7 Naming Conventions
2.7.1 Interop Classes
Classes that are there for interop wrappers (DllImport statements) should follow the naming convention below:
- NativeMethods – No suppress unmanaged code attribute, these are methods that can be used anywhere because a stack walk will be performed.
- UnsafeNativeMethods – Has suppress unmanaged code attribute. These methods are potentially dangerous and any caller of these methods must do a full security review to ensure that the usage is safe and protected as no stack walk will be performed.
- SafeNativeMethods – Has suppress unmanaged code attribute. These methods are safe and can be used fairly safely and the caller isn’t needed to do full security reviews even though no stack walk will be performed.
class NativeMethods
{
private NativeMethods() {}
[DllImport(“user32”)]
internal static extern void FormatHardDrive(string driveName);
}
[SuppressUnmanagedCode]
class UnsafeNativeMethods
{
private UnsafeNativeMethods() {}
[DllImport(“user32”)]
internal static extern void CreateFile(string fileName);
}
[SuppressUnmanagedCode]
class SafeNativeMethods
{
private SafeNativeMethods() {}
[DllImport(“user32”)]
internal static extern void MessageBox(string text);
}
All interop classes must be private, and all methods must be internal. In addition a private constructor should be provided to prevent instantiation.
2.8 File Organization
- Source files should contain only one public type, although multiple internal classes are allowed
- Source files should be given the name of the public class in the file
- Directory names should follow the namespace for the class
For example, I would expect to find the public class “System.Windows.Forms.Control” in “System\Windows\Forms\Control.cs”…
- Classes member should be alphabetized, and grouped into sections (Fields, Constructors, Properties, Events, Methods, Private interface implementations, Nested types)
- Using statements should be inside the namespace declaration.
namespace MyNamespace
{
using System;
public class MyClass : IFoo
{
// fields
int foo;
// constructors
public MyClass() { … }
// properties
public int Foo { get { … } set { … } }
// events
public event EventHandler FooChanged { add { … } remove { … } }
// methods
void DoSomething() { … }
void FindSomethind() { … }
//private interface implementations
void IFoo.DoSomething() { DoSomething(); }
// nested types
class NestedType { … }
}
설정
트랙백
댓글
글
Ajax: A New Approach to Web Applications
by Jesse James Garrett
February 18, 2005
If anything about current interaction design can be called “glamorous,” it’s creating Web applications. After all, when was the last time you heard someone rave about the interaction design of a product that wasn’t on the Web? (Okay, besides the iPod.) All the cool, innovative new projects are online.
Despite this, Web interaction designers can’t help but feel a little envious of our colleagues who create desktop software. Desktop applications have a richness and responsiveness that has seemed out of reach on the Web. The same simplicity that enabled the Web’s rapid proliferation also creates a gap between the experiences we can provide and the experiences users can get from a desktop application.
That gap is closing. Take a look at Google Suggest. Watch the way the suggested terms update as you type, almost instantly. Now look at Google Maps. Zoom in. Use your cursor to grab the map and scroll around a bit. Again, everything happens almost instantly, with no waiting for pages to reload.
Google Suggest and Google Maps are two examples of a new approach to web applications that we at Adaptive Path have been calling Ajax. The name is shorthand for Asynchronous JavaScript + XML, and it represents a fundamental shift in what’s possible on the Web.
Defining Ajax
Ajax isn’t a technology. It’s really several technologies, each flourishing in its own right, coming together in powerful new ways. Ajax incorporates:
- standards-based presentation using XHTML and CSS;
- dynamic display and interaction using the Document Object Model;
- data interchange and manipulation using XML and XSLT;
- asynchronous data retrieval using XMLHttpRequest;
- and JavaScript binding everything together.
The classic web application model works like this: Most user actions in the interface trigger an HTTP request back to a web server. The server does some processing — retrieving data, crunching numbers, talking to various legacy systems — and then returns an HTML page to the client. It’s a model adapted from the Web’s original use as a hypertext medium, but as fans of The Elements of User Experience know, what makes the Web good for hypertext doesn’t necessarily make it good for software applications.
Figure 1: The traditional model for web applications (left) compared to the Ajax model (right).
This approach makes a lot of technical sense, but it doesn’t make for a great user experience. While the server is doing its thing, what’s the user doing? That’s right, waiting. And at every step in a task, the user waits some more.
Obviously, if we were designing the Web from scratch for applications, we wouldn’t make users wait around. Once an interface is loaded, why should the user interaction come to a halt every time the application needs something from the server? In fact, why should the user see the application go to the server at all?
How Ajax is Different
An Ajax application eliminates the start-stop-start-stop nature of interaction on the Web by introducing an intermediary — an Ajax engine — between the user and the server. It seems like adding a layer to the application would make it less responsive, but the opposite is true.
Instead of loading a webpage, at the start of the session, the browser loads an Ajax engine — written in JavaScript and usually tucked away in a hidden frame. This engine is responsible for both rendering the interface the user sees and communicating with the server on the user’s behalf. The Ajax engine allows the user’s interaction with the application to happen asynchronously — independent of communication with the server. So the user is never staring at a blank browser window and an hourglass icon, waiting around for the server to do something.
Figure 2: The synchronous interaction pattern of a traditional web application (top) compared with the asynchronous pattern of an Ajax application (bottom).
Every user action that normally would generate an HTTP request takes the form of a JavaScript call to the Ajax engine instead. Any response to a user action that doesn’t require a trip back to the server — such as simple data validation, editing data in memory, and even some navigation — the engine handles on its own. If the engine needs something from the server in order to respond — if it’s submitting data for processing, loading additional interface code, or retrieving new data — the engine makes those requests asynchronously, usually using XML, without stalling a user’s interaction with the application.
Who’s Using Ajax
Google is making a huge investment in developing the Ajax approach. All of the major products Google has introduced over the last year — Orkut, Gmail, the latest beta version of Google Groups, Google Suggest, and Google Maps — are Ajax applications. (For more on the technical nuts and bolts of these Ajax implementations, check out these excellent analyses of Gmail, Google Suggest, and Google Maps.) Others are following suit: many of the features that people love in Flickr depend on Ajax, and Amazon’s A9.com search engine applies similar techniques.
These projects demonstrate that Ajax is not only technically sound, but also practical for real-world applications. This isn’t another technology that only works in a laboratory. And Ajax applications can be any size, from the very simple, single-function Google Suggest to the very complex and sophisticated Google Maps.
At Adaptive Path, we’ve been doing our own work with Ajax over the last several months, and we’re realizing we’ve only scratched the surface of the rich interaction and responsiveness that Ajax applications can provide. Ajax is an important development for Web applications, and its importance is only going to grow. And because there are so many developers out there who already know how to use these technologies, we expect to see many more organizations following Google’s lead in reaping the competitive advantage Ajax provides.
Moving Forward
The biggest challenges in creating Ajax applications are not technical. The core Ajax technologies are mature, stable, and well understood. Instead, the challenges are for the designers of these applications: to forget what we think we know about the limitations of the Web, and begin to imagine a wider, richer range of possibilities.
It’s going to be fun.
Ajax Q&A
March 13, 2005: Since we first published Jesse’s essay, we’ve received an enormous amount of correspondence from readers with questions about Ajax. In this Q&A, Jesse responds to some of the most common queries.
Q. Did Adaptive Path invent Ajax? Did Google? Did Adaptive Path help build Google’s Ajax applications?
A. Neither Adaptive Path nor Google invented Ajax. Google’s recent products are simply the highest-profile examples of Ajax applications. Adaptive Path was not involved in the development of Google’s Ajax applications, but we have been doing Ajax work for some of our other clients.
Q. Is Adaptive Path selling Ajax components or trademarking the name? Where can I download it?
A. Ajax isn’t something you can download. It’s an approach — a way of thinking about the architecture of web applications using certain technologies. Neither the Ajax name nor the approach are proprietary to Adaptive Path.
Q. Is Ajax just another name for XMLHttpRequest?
A. No. XMLHttpRequest is only part of the Ajax equation. XMLHttpRequest is the technical component that makes the asynchronous server communication possible; Ajax is our name for the overall approach described in the article, which relies not only on XMLHttpRequest, but on CSS, DOM, and other technologies.
Q. Why did you feel the need to give this a name?
A. I needed something shorter than “Asynchronous JavaScript+CSS+DOM+XMLHttpRequest” to use when discussing this approach with clients.
Q. Techniques for asynchronous server communication have been around for years. What makes Ajax a “new” approach?
A. What’s new is the prominent use of these techniques in real-world applications to change the fundamental interaction model of the Web. Ajax is taking hold now because these technologies and the industry’s understanding of how to deploy them most effectively have taken time to develop.
Q. Is Ajax a technology platform or is it an architectural style?
A. It’s both. Ajax is a set of technologies being used together in a particular way.
Q. What kinds of applications is Ajax best suited for?
A. We don’t know yet. Because this is a relatively new approach, our understanding of where Ajax can best be applied is still in its infancy. Sometimes the traditional web application model is the most appropriate solution to a problem.
Q. Does this mean Adaptive Path is anti-Flash?
A. Not at all. Macromedia is an Adaptive Path client, and we’ve long been supporters of Flash technology. As Ajax matures, we expect that sometimes Ajax will be the better solution to a particular problem, and sometimes Flash will be the better solution. We’re also interested in exploring ways the technologies can be mixed (as in the case of Flickr, which uses both).
Q. Does Ajax have significant accessibility or browser compatibility limitations? Do Ajax applications break the back button? Is Ajax compatible with REST? Are there security considerations with Ajax development? Can Ajax applications be made to work for users who have JavaScript turned off?
A. The answer to all of these questions is “maybe”. Many developers are already working on ways to address these concerns. We think there’s more work to be done to determine all the limitations of Ajax, and we expect the Ajax development community to uncover more issues like these along the way.
Q. Some of the Google examples you cite don’t use XML at all. Do I have to use XML and/or XSLT in an Ajax application?
A. No. XML is the most fully-developed means of getting data in and out of an Ajax client, but there’s no reason you couldn’t accomplish the same effects using a technology like JavaScript Object Notation or any similar means of structuring data for interchange.
Q. Are Ajax applications easier to develop than traditional web applications?
A. Not necessarily. Ajax applications inevitably involve running complex JavaScript code on the client. Making that complex code efficient and bug-free is not a task to be taken lightly, and better development tools and frameworks will be needed to help us meet that challenge.
Q. Do Ajax applications always deliver a better experience than traditional web applications?
A. Not necessarily. Ajax gives interaction designers more flexibility. However, the more power we have, the more caution we must use in exercising it. We must be careful to use Ajax to enhance the user experience of our applications, not degrade it.
Jesse James Garrett is President and a founder of Adaptive Path. He is the author of the widely-referenced book The Elements of User Experience. Jesse’s other essays include The Nine Pillars of Successful Web Teams and Six Design Lessons From the Apple Store.
To get essays like this one delivered directly to your inbox, subscribe to our email newsletter. For more, check out our blog.
