Author Archives: admin

10 Razones por las que fallan los proyectos web

[Fuente: http://speckyboy.com/2012/08/24/10-reasons-why-website-projects-fail/]

A menudo me pregunto porqué hay tantos clientes que vienen a nosotros después de que sus proyectos Web hayan fallado. Alrededor del 75% de nuestro negocio viene de proyectos donde alguien no ha podido terminar su trabajo. La situación más común es lo que yo llamo el “Money Pit”. Ahí es donde el programador sigue diciendo al cliente que está casi hecho pero nunca lo acaba.

Hoy todos los proyectos utilizan algún tipo de Gestor de Contenidos. En vez de pintar un lienzo como en los viejos tiempos del HTML, estamos haciendo aplicaciones que necesitan seguir aproximaciones al desarrollo más tradicionales. Si el proyecto es codificado de forma impropia, entonces muy a menudo tienes que tirarlo todo a la basura y empezar de nuevo. El coste de arreglar todos estos problemas puede ser significativo.

Pienso que debería compartir las razones más comunes que hemos visto alrededor de todos estos años que hacen que los proyectos fallen.

1. El “Sindrome Freelance”: programadores no cualificados; utilizando tu marca , amigo / vecino , contratando en tu nombre o yendo más alla de lo que deberían.

Quieres hacer un web increible que automatizará las gestiones de tu negocio y se beneficiará de las maravillosas oportunidades que Internet proporciona. Todos te dicen que pueden hacerlo para ti y todos te suenan a lo mismo. El problema es que la mayoría de la gente con la que estás hablando no están cualificados para realizar el trabajo. La mayoría de las agencias de marketing son increibles a la hora de construir tu marca, pero tienen gente en su empresa apropiada para desarrollar tu aplicación web?

Asegurate que ellos no están subcontratando tu proyecto a freelances o incluso peor, lo están encargando a grupos de trabajo en paises lejanos. Visita o habla con la gente que está desarrollando tu website y mira su trabajo. Habla para pedirles referencias. Mira que no te den gato por liebre. Han hecho ellos proyectos de complejidad similar? Hacer negocios con amigos / vecinos no tiene sentido. Contratar programadores para tu empresa  puede convertirte en aprendiz de todo maestro de nada. Hace falta varios perfiles con diferentes especializaciones para construir los websites de hoy. Los recursos de la casa se ajustan mejor a una fase del proyecto en la que el proyecto ya ha sido comenzado. Es en ese momento en el que el programador de tu empresa puede servir de soporte de recursos según sean necesarios a los programadores de tu website ahorrandote dinero.

2. Saltarse lo fundamental: Carencia de una clara definición del ámbito y los requerimientos

Todo el mundo está siempre ansioso para empezar y estamos seguros de conocer lo que tienen que hacer. Pero no pensamos  sobre cómo va a funcionar y qué sucede bajo distintos escenarios. Estos es especialment cierto cuando una compañia pone su negocio online. Cómo afectará este nuevo proceso a su negocio? La mayor parte de los clientes creen que saben lo que ellos quieren, pero el diablo está en los detalles. No puedo decirte cuántos clientes conocemos que cuando les presionamos a detallar su funcionalidad, ellos habian pasado por alto algunas ramificaciones. Asegurate que pasas por un ejercicio de planificación detallado antes de empezar a programar. asegurate de programar algo que tus clientes quieren y necesitan, no solo lo que ellos quieren. Saca input de tus clientes.

3. Perdida de liderato. Falta de interés en comprar y falta de participación

La gestión quiere una nueva web para alcanzar objetivos corporativos e incrementar el ROI. La gestión no tiene tiempo de estar en la toma de las decisiones estratégicas que deben ser hechas. Aparecen grandes problemas cuando la gestión prueba la versión Beta y encuentra que no es lo que originalmente ellos querian. Algunos de los mejores proyectos en los que hemos trabajado son aquellos en los cuales la gestión ejecutiva estuvo más activamente involucrada desde el comienzo. Los cambios pueden ser muy caros en tiempo y dinero si tienen que hacerse al final del proyecto en vez de al comienzo.

4. El “Sindrome Facebook” abarca más de lo que puede abarcar

Hay que ser cuidados de no querer abarcar más de lo que se puede. Roma no fue construida en un día. Si tienes entre manos un proyecto realmente complejo, hazlo en fases. No tienes que sacarlo todo en la primera versión de una vez. No hay nada malo con reemplzar la web antigua después de que se hayan completado tres o cuatro fases.

5. Anteponiendo el diseño como lo primero: Diseñar sin proposito ni función

Hemos visto diseños muy bonitos para nuevos proyectos que directamente no pueden ser programados o son muy caros de construir. Es mejor diseñar toda la funcionalidad teniendo en cuenta la plataforma donde el diseño va a ser integrado. Entonces debes hacer trabajar a tu equipo de programadores junto con el diseñador, asi juntos deben llegar a algo que es bonito y funcional a la vez. De otra forma llegarás a tener un Frankestein que no hay por donde cojerlo.

6. Código descontrolado: No utilizar un Control de Versiones

Hoy en día es insondable programar una web sin algún tipo de sistema de control de versiones de código. Nosotros utilizamos GITSVN. Cuando los programadores crean , soportan y actualizan archivos de código fuente para una aplicación grande, la coordinación puede ser compleja. Los sistemas de control de código fuente graban todos los cambios de los archivos, con comentarios , en un proyecto. Necesitas tener la posibilidad de poder recuperar la funcionalidad, fundir distintas ramas de desarrollo y trabajar off line. Un apropiado control de versiones es vital para cualquier proyecto.

 

7. Programadores descontrolados: Carencia de buena gestión del Proyecto

The Project Manager (PM) is the Quarterback of your football team. The PM is responsible for the successful planning, execution, monitoring, control and closure of a project. The PM needs to understand the client’s needs and provide communication to and from the developers. Without a proficient PM, the project will get off track and become a run away train that ends up in disaster. A good PM will publish weekly progress reports keeping everything on track.

8. Intentar reinventar la rueda: hackeando el core o el código fuente

Hacking is changing the source code structure. We always believe in K.I.S.S, Keep it short and simple. When an unqualified developer doesn’t know how to do something, they tend to hack the code to make it do it. This causes a number of problems and greatly affects quality. If your developer fixes one problem and another arises, it may be the result of a lot of hacks.

Doing so will make it near impossible for site updates due to Security and bug fixes. It also makes it difficult for those that come in after to maintain the site and could possibly leave your site vulnerable to exploits. We have a tool we run that uncovers all of the Hacks for our customers who come to us in trouble. Then we show them the results and why their website doesn’t work.

9. Getting Off Track: Scope Creep

Esto sucede mucho. La tarea principal de un buen PM es mantener las cosas en el buen camino. Es natural según avanzas en el proyecto de desarrollo, que se te ocurran nuevas ideas y cosas que quieres. Pero necesitas darte cuenta que cada vez que haces un cambio, esto suma tiempo y coste en tu proyecto.

This happens a lot. A good PM’s main job is to keep things on track. It’s natural as you go through the development, to come up with new ideas and things you want. You need to realize that every time you make a change, it adds to the time and cost of your project. Changes late within the process have large affects. If a website is built and tested, you will have to retest after the change. Some changes are beneficial, especially if they make the website better for your users. But lots of indecision and changing can derail a project. Scope Creep happens when decision makers aren’t involved early on or the project didn’t go through proper planning.

10. Inexistencia de Testing de funcionalidad: carencia de pruebas de Calidad sólidas

Es importante hacer pruebas unitarias de cada pieza de funcionalidad y entonces hacer test de regresiones en el producto final. Todos los proyectos tienen bugs (fallos), asi que es mejor hacer que los programadores encuentren los problemas a los usuarios. Nosotros generalmente reservamos de un 20 a un 25% del tiempo de desarrollo a tareas de QA

It’s important to unit test each piece of functionality and then do regression testing on the final product. All projects have bugs, so it’s better to have the developers find the problems instead of your users. We usually set aside 20% to 25% of the development time to perform proper QA. Make sure there is a comprehensive QA Plan, otherwise you could get a website that has a lot of issues. Developers need to be thinking about quality from day one and be responsible to fix their problems. Otherwise it could get very sloppy.

Conclusion

Building a successful website requires all ten of these areas to be properly addressed. Failure to perform any of these tasks could derail a project which ends up being completely wasted money in the budget. When you select a developer make sure they can address all of these before you start. Properly done projects can be a tremendous asset to the wellbeing of your company.

Hacia una web para Retina

[Fuente: http://coding.smashingmagazine.com/2012/08/20/towards-retina-web/]

Con el reciente anuncio y versión del Retina Macbook Pro, Apple ha introducido las pantallas de doble densidad a todas las categorias de productos en sus lineas de ventas, allanando el camino a la nueva generación de estandares de pantalla. Mientras el iPhone de cuarta generación nos ofreció lo que era Web en modo “no-Retina” en 2010, hemos tenido que esperar a la tercera generación de iPad para darnos cuenta de lo anticuados que están nuestros gráficos e imágenes de contenido.

En los confines del jardin de Apple, las apps nativas son actualizadas con los gráficos Retina de una forma eficaz, con la ayuda de un sólido SDK y de un proceso de transición bien documentado. Por contraste, la Web al tener una naturaleza tan abierta hace que la transición a displays de alta densidad sea lento y doloroso. En la ausencia de estandares ampliamente aceptados por la industria para hacer eficaz este proceso, cada diseñador/programador Web se le deja la responsabilidad de que sus usuarios tengan la mejor experiencia de usuario, independientemente del tipo de pantalla que estén utilizando.

Antes de entrar en materia, veamos brevemente algunas nociones básicas que son claves para entender los retos y restricciones de diseñar para múltiples densidades de pantalla.

Los píxeles de los dispositivos

Device Pixels

Un pixel de dispositivo (o pixel físico) es la unidad más pequeña en una pantalla. Cada pixel configura su propio color y brillo como le va diciendo el sistema operativo. La impreceptible distancia entre puntos minusculos hace el efecto optico de percibir la imagen de forma completa y contínua.

La densidad de la pantalla se refiere al número de píxeles de dispositivo en un superficie física. Es a menudo medido en pixeles por pulgada (PPI). Apple ha acuñado el término “Retina” para sus pantallas de doble densidad, haciendo que el ojo humano no pueda ni de lejos distinguir píxeles individuales en la pantalla desde una distancia de visionado “normal”.

Los píxeles CSS

CSS Pixels

Un pixel CSS es un unidad abstracta utilizada por los navegadores para dibujar contenido de forma precisa y consistente en las páginas Web. Genericamente, los píxeles CSS se refieren a píxeles independientes del dispositivo (DIPs). En pantallas de densidad estandar, 1 pixel CSS se corresponde con el pixel de dispositivo.

<div height="200" width="300"></div>

Esto utilizaría una caja de 200×300 de píxeles de dispositivo para ser dibujado en la pantalla. En la pantalla Retina, el mismo div utiliza 400×600 para que salga del mismo tamaño, resultando en cuatro veces más píxeles, como mostramos en la siguiente figura:

Device Pixels In Retina Displays

En un pantalla Retina , para cubrir la misma superficie física se utiliza 4 veces más de píxeles de dispositivo

La proporción entre los pixeles de dispositivo y los pixeles de CSS puede obtenerse utilizando el siguiente media query y sus equivalentes especificos del vendedor:

	 device-pixel-ratio,
	 -o-device-pixel-ratio,
	 -moz-device-pixel-ratio,
	-Webkit-device-pixel-ratio {
	…
	}

O puedes utilizar sus primos hermanos que vendrán en un futuro:

device-pixel-ratio,
	 -o-min-device-pixel-ratio,
	 min--moz-device-pixel-ratio,
	-Webkit-min-device-pixel-ratio {
	…
}

En Javascript ,  window.devicePixelRatio puede ser utilizado para obtener el mismo ratio, aunque no todos los navegadores lo soportan. Ambas técnicas serán discutidas en más profundidad en este artículo.

Así por ejemplo podemos decirle a una pagina web que utilice una hoja de estilos diferente en caso de pantallas de alta densidad:

<!-- High pixel density displays -->
<link rel='stylesheet' href='highRes.css' media='only screen and (min--moz-device-pixel-ratio: 2), only screen and (-o-min-device-pixel-ratio: 2/1), only screen and (-webkit-min-device-pixel-ratio: 2), only screen and (min-device-pixel-ratio: 2)' />

o dentro de una hoja de estilos:

/* iPhone 4 ----------- */
@media
only screen and (-webkit-min-device-pixel-ratio : 1.5),
only screen and (min-device-pixel-ratio : 1.5) {
/* Styles */
}

 

Los pixeles Bitmap

Bitmap Pixels

Un pixel de bitmap es la unidad más pequeña de datos de una imagen raster (PNG. GIF, JPG, etc). Cada pixel contien información sobre cómo debe ser mostrado, incluyendo su posición en el sistema de coordenadas de la imagen y su color. Algunos formatos de imágenes pueden almacenar datos adicionales por pixel, tales como la opacidad (lo que se llama el canal alpha).

Además de la resolución raster, una imagen de la web tiene un tamaño abstracto,  definido en pixeles CSS. El browser ensancha o estrecha la imagen basándose en el height y el width CSS mientras está dibujando la imagen.

Cuando una imagen raster se muestra a tamaño completo en una pantalla de densidad estandar, 1 pixel de bitmap se correspondecon 1 pixel de dispositivo, resultando en una representación completamente fiel. Como el pixel de un bitmap no puede ser dividido, es multiplicado por 4 en las pantallas Retina para preservar el mismo tamaño físico de la imagen, perdiendo detalle en el camino.

Bitmap Pixels On Retina Displays

Each bitmap pixel gets multiplied by four to fill the same physical surface on a Retina display.

La herramienta Pecho (Tool Chest)

Incluso aunque estamos en el camino de un cambio, hay varias aproximaciones para optimizar los gráficos para pantallas Retina , y más que estarán saliendo en el mismo momento que se lee esto. Cada método hace algún grado de compromiso entre al rendimiento, facilidad de implementación y soporte multinavegador (corss-browser). Por tanto , elegir la herramienta debe ser analizado caso por caso, teniendo en cuenta tanto los factores cuantitativos como los cualitativos.

 

El tamaño en HTML y CSS

La forma más directa de servir gráficos web preparados para Retina es reducir a la mitad el tamaño de tus imagenes raster utilizando CSS o HTML,  o manualmente o programaticamente. Por ejemplo. para servir una imagen de 200×300 pixeles (recuerda pixeles CSS), deberiamos subir una imagen con una resolución de bitmap de 400×600 al servidor, entonces reducirla al 50% utilizando CSS o atributos HTML. En una pantalla estandar , el resultado seria una imagen renderizada con cuatro veces menos pixeles que el tamño completo del bitmap – un proceso que es conocido como “downsampling

How downsampling works

A CSS-sized image gets its dimensions halved during the rendering process.

Debido a que la misma imagen en una pantalla Retina utiliza 4 veces más pixeles , cada pixel físico termina coincidiendo exactamente con un pixel del bitmap , permitiendo que la imagen se dibuje completamente fiel.

How HTML sizing works

CSS-sized images regain their full-detail glory on Retina displays.

Hay varias formas de conseguir esto:

USING HTML

The easiest way to apply CSS sizing would be by using the width and height attributes of the img tag:

1 <img src="example@2x.png" width="200" height="300" />

Please note that, even though specifying height is optional, it allows the browser to reserve the space required for the image before loading it. This prevents the page layout from changing as the image loads.

What to use it for? Single-page websites with few content images.

USING JAVASCRIPT

The same result can also be obtained using Javascript by targeting all Retina-ready content images in the document and halving their sizes. With the help of jQuery, this would look like this:

1 $(window).load(function() {
2 var images = $('img');
3 images.each(function(i) {
4 $(this).width($(this).width() / 2);
5 });
6 });

What to use it for? Websites with few content images.

USING CSS (SCSS)

If you want to keep all of the presentation code in your CSS files, then the most common technique involves setting the image as the background of another HTML element, usually a div, then specifying its background-size property. You could either set explicit width and height values for the background image or use the contain value if the dimensions of the HTML element are already specified. It is worth noting that the background-size property is not supported in IE 7 or 8.

1 .image {
2 background-image: url(example@2x.png);
3 background-size: 200px 300px;
4 /* Alternatively background-size: contain; */
5 height: 300px;
6 width: 200px;
7 }

You could also target a :before or :after pseudo-element instead:

1 .image-container:before {
2 background-image: url(example@2x.png);
3 background-size: 200px 300px;
4 content:'';
5 display: block;
6 height: 300px;
7 width: 200px;
8 }

This technique works just as well with CSS sprites, as long as the background-position is specified relatively to the CSS size (200 × 300 pixels in this case):

01 .icon {
02 background-image: url(example@2x.png);
03 background-size: 200px 300px;
04 height: 25px;
05 width: 25px;
06
07 &.trash {
08 background-position: 25px 0;
09 }
10
11 &.edit {
12 background-position: 25px 25px;
13 }
14 }

When using image sprites, consider any OS-specific limitations.

What to use it for? Websites that make limited use of the background-image property, such as those that rely on a single-image sprite.

HTML AND CSS SIZING: PROS

  • Easy to implement
  • Cross-browser compatible

HTML AND CSS SIZING: CONS

  • Non-Retina devices have to download larger assets.
  • Downsampled images might lose some of their sharpness on standard-density screens, depending on the algorithm used.
  • The background-size property is not supported in IE 7 or 8.

Querying Pixel Density

Querying Pixel Density

Perhaps the most popular way to serve Retina-ready graphics on the Web is by querying the device for its pixel density and then serving assets accordingly. This can be done using either CSS or JavaScript.

USING CSS MEDIA QUERIES

As of this writing, almost every major browser vendor has implemented a prefixed variant of device-pixel-ratio and its two siblings, min-device-pixel-ratio and max-device-pixel-ratio. These media queries can be used in conjunction with the background-imageproperty to serve Retina-ready assets to high-density devices:

01 .icon {
02 background-image: url(example.png);
03 background-size: 200px 300px;
04 height: 300px;
05 width: 200px;
06 }
07
08 @media only screen and (-Webkit-min-device-pixel-ratio: 1.5),
09 only screen and (-moz-min-device-pixel-ratio: 1.5),
10 only screen and (-o-min-device-pixel-ratio: 3/2),
11 only screen and (min-device-pixel-ratio: 1.5) {
12 .icon {
13 background-image: url(example@2x.png);
14 }
15 }

By using a ratio of 1.5 instead of 2, you can target other non-Apple devices with the same query.

What to use it for? Any website or app that uses the background-image property for graphic assets. Not suitable for content images.

CSS QUERYING: PROS

  • Devices download only those assets that target them.
  • Cross-browser compatible
  • Pixel-precise control

CSS QUERYING: CONS

  • Tedious to implement, especially on large websites.
  • Displaying content images as backgrounds of other HTML elements is semantically incorrect.

USING JAVASCRIPT

The pixel density of the screen can be queried in Javascript usingwindow.devicePixelRatio, which reports the same value as its CSS counterpart. Once a higher-density screen is identified, you can replace every inline image with its Retina counterpart:

01 $(document).ready(function(){
02 if (window.devicePixelRatio > 1) {
03 var lowresImages = $('img');
04
05 images.each(function(i) {
06 var lowres = $(this).attr('src');
07 var highres = lowres.replace(".", "@2x.");
08 $(this).attr('src', highres);
09 });
10 }
11 });

Retina.js is a Javascript plugin that implements roughly the same technique as described above, with some additional features, such as skipping external images and skipping internal images with no @2x counterparts.

Lastly, it is worth noting that devicePixelRatio is not entirely cross-browser compatible.

What to use it for? Any website with content images, such as landing pages and blogs.

JAVASCRIPT QUERYING: PROS

  • Easy to implement
  • Non-Retina devices do not download large assets.
  • Pixel-precise control

JAVASCRIPT QUERYING: CONS

  • Retina devices have to download both standard- and high-resolution images.
  • The image-swapping effect is visible on Retina devices.
  • Does not work on some popular browsers (such as IE and Firefox).

Scalable Vector Graphics

Scalable Vector Graphics

Regardless of the method used, raster images remain inherently constrained by their bitmap resolution; they were never meant to be infinitely scalable. This is where vector graphics have the advantage, being a future-proof way to “Retinize” your Web graphics.

As of this writing, the vector XML-based SVG format has cross-browser support of more than 70% and can be used in several ways on the Web. SVG images can be easily created in and exported from a number of vector-graphic editors, such as Adobe Illustrator and free alternatives such as Inkscape.

As far as Web design goes, the most straightforward way to use SVG assets is with the HTML img tag or with the CSS background-image and content:url() properties.

1 <img src="example.svg" width="200" height="300" />

In the example above, a single SVG image can be used as a universal asset, scaling infinitely up or down as required. This not only saves precious bandwidth (most SVG files tend to be smaller in size than standard-resolution PNGs), but also makes your graphic assets much easier to maintain. The same would apply if used in CSS:

01 /* Using background-image */
02
03 .image {
04 background-image: url(example.svg);
05 background-size: 200px 300px;
06 height: 200px;
07 width: 300px;
08 }
09
10 /* Using content:url() */
11
12 .image-container:before {
13 content: url(example.svg);
14 /* width and height do not work with content:url() */
15 }

If you have to support IE 7 or 8 or Android 2.x, then you will need a fallback solution that swaps SVG images with their PNG counterparts. This can be easily done with Modernizr:

01 .image {
02 background-image: url(example.png);
03 background-size: 200px 300px;
04 }
05
06 .svg {
07 .image {
08 background-image: url(example.svg);
09 }
10 }

For best cross-browser results and to avoid some rasterization headaches in Firefox and Opera, make each SVG image at least the size of its parent HTML element.

In HTML, you can implement a similar fallback solution by adding a custom data attribute to your img tag:

1 <img src="example.svg" data-png-fallback="example.png" />

Then, handle the rest with jQuery and Modernizr:

1 $(document).ready(function(){
2 if(!Modernizr.svg) {
3 var images = $('img[data-png-fallback]');
4 images.each(function(i) {
5 $(this).attr('src', $(this).data('png-fallback'));
6 });
7 }
8 });

This HTML and JavaScript route, however, would not prevent browsers with no SVG support from downloading the SVG assets.

What to use it for? Any website or app. Suitable for icons, logos and simple vector illustrations.

SVG: PROS

  • One universal asset for all devices
  • Easy to maintain
  • Future-proof: infinitely scalable vector graphics

SVG: CONS

  • No pixel precision due to anti-aliasing
  • Unsuitable for complex graphics due to large file sizes
  • No native support in IE 7 and 8 or early Android versions

Icon Fonts

Icon Fonts

Popularized by Twitter’s Bootstrap, the technique of using @font-face with icon-based fonts has garnered a following of its own as a resolution-independent alternative to bitmap icons. The technique consists of using a custom Web font that replaces the alphabet with monochrome glyphs, which can be styled using CSS, just like any other text on the website.

There is no shortage of comprehensive, good-quality icon fonts that would cover most of your needs. That being said, importing a large font in half a dozen formats only to use a small subset of the icons is a bad idea. Consider building your own custom font with free tools such as FontelloFont Builder or even Inkscape.

The most common way to use icon fonts on websites is by assigning an .icon or .glyphclass to a particular HTML element — most often a <span> or an <i> — and then using the letter corresponding to the desired icon as its content:

1 <span class="icon">a</span>

After having imported your custom font using @font-face, you would declare it:

1 .icon {
2 font-family: 'My Icon Font';
3 }

Another technique consists of using the :before pseudo-element and the contentproperty, with a unique class for each icon:

1 <span class="glyph-heart"></span>
1 [class^="glyph-"]:before {
2 font-family: 'My Icon Font';
3 }
4
5 .glyph-heart:before {
6 content: 'h';
7 }

What to use it for? Websites or apps with a high number of icons, and for rapid prototyping.

ICON FONTS: PROS

  • Future-proof: infinitely scalable glyphs
  • Cross-browser compatible
  • More flexible than graphic assets: can be used in placeholder text and other form elements, etc.

ICON FONTS: CONS

  • No pixel precision due to subpixel anti-aliasing
  • Hard to maintain: changing a single icon requires regenerating the whole font.
  • Relies on semantically incorrect markup (unless used with :before or :afterpseudo-elements).

Favicons

Favicons are getting their fair share of attention, being increasingly used outside of browser chrome as an iconic representation of our websites and apps. To make your favicons Retina-ready, export an .ico file in both 16- and 32-pixel versions. If you are using a Mac, you can create your own .ico files with Apple’s Icon Composer (included in theGraphic Tools in Xcode) or with Icon Slate, a paid third-party application.

A Glimpse Of The Future

Besides the techniques covered above, several other efforts are being made independently by organizations and individuals alike, not the least of which is Apple’s own-Webkit-image-setintroduced last spring. This proposal allows for multiple variants of the same image to be provided in one CSS declaration:

1 .image {
2 background-image: -Webkit-image-set(url(example.png) 1x, url(example@2x.png) 2x);
3 background-size: 200px 300px;
4 }

This technique does not, however, cover images inside img tags, and it is Webkit-only as of this writing.

Another notable effort is Scott Jehl’s Picturefill, an HTML and Javascript solution that makes heavy use of data attributes and media queries to serve different images in different media contexts.

1 <div data-picture>
2 <div data-src="example.png"></div>
3 <div data-src="example@2x.png" data-media="(min-device-pixel-ratio: 1.5)"></div>
4
5 <!-- Fallback content for non-JS browsers -->
6 <noscript>
7 <img src="example.png" >
8 </noscript>
9 </div>

Even if the markup puts you off, it is a good cross-browser solution to consider if you are dealing with few content images.

Last but not least, the ambitious picture element proposal aims to bring responsive images to the Web using a markup-only approach for multiple image sources, coupled with media queries that route each device to the right asset.

CLOSING WORDS

Like other major shifts the Web is currently undergoing, attaining resolution independence will be a long journey. As Web designers and developers, either we can sit down and wait passively for a convention to be standardized, or we can immediately start offering a pleasurable viewing experience to our users. Let’s get to work.

(al)

CSS: 10 sencillos pasos para aprender posicionamiento CSS

[Fuente: http://www.nosolocodigo.com/10-sencillos-pasos-para-aprender-posicionamiento-css]

El posicionamiento CSS es la técnica utilizada para maquetar diseños usando únicamente XHTML y las propiedades CSS. Es el estándar hoy en día y todo sitio web bien maquetado debería usar esta técnica. Las ventajas son muchas, pero entre ellas destaca una mejor separación entre la apariencia y la estructura de la página, un código más semántico y entendible por buscadores, es decir, mejor para SEO, y un tamaño de página resultante inferior, por lo tanto mayor velocidad de carga de la página.

El otro día, vía Twitter me os hablé de un pequeño tutorial donde se enseñaban las bases del posicionamiento CSS en 10 lecciones prácticas. El tutorial me pareció muy bueno y creo que es básico para cualquier persona que quiera aprender a maquetar sitios web con CSS.  Los pasos son realmente sencillos de seguir.
Para todo el tutorial se va a utilizar siempre la misma estructura XHTML, que se muestra a continuación.

	<div id="example">

		<div id="div-before">
			<p>id = div-before</p>
		</div>

		<div id="div-1">
			<div id="div-1-padding">

				<p>id = div-1</p>

			        <div id="div-1a">
				        <p>id = div-1a</p>
				        <p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Integer pretium dui sit amet felis. Integer sit amet diam. Phasellus ultrices viverra velit.</p>
			        </div>

			        <div id="div-1b">
				        <p>id = div-1b</p>
				        <p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Integer pretium dui sit amet felis. Integer sit amet diam. Phasellus ultrices viverra velit. Nam mattis, arcu ut bibendum commodo, magna nisi tincidunt tortor, quis accumsan augue ipsum id lorem.</p>
			        </div>

			        <div id="div-1c">
				        <p>id = div-1c</p>
			        </div>

			</div>
		</div>

		<div id="div-after">
			<p>id = div-after</p>
		</div>

	</div>

POSITION STATIC

El posicionamiento normal de todos los elementos es static, que significa que cada elemento se posiciona donde le corresponde según el flujo normal de la página. Si no se indica nada, este es el valor que toman todos los elementos.

#div-1 {
    position:static;
}

El resultado que se muestra es el mismo que si no se hubiese aplicado ninguna regla CSS.

Posicionamiento CSS estático. Propiedad static.

POSITION RELATIVE

Si se especifica la posición relativa para un elemento, puedes posicionar este elemento usando las propiedades top, bottom, left y right, y el elemento se posicionará a la distancia indicada respecto de donde debería estar según el flujo normal de la página.

#div-1 {
    position:relative;
    top:20px;
    left:-40px;
}

Posicionamiento relativo en CSS.

POSITION ABSOLUTE

Si se especifica position absolute, el elemento se muestra exactamente donde se indica en las propiedades top, bottom, left o right.

#div-1a {
    position:absolute;
    top:0;
    right:0;
    width:200px;
}

Posicionamiento CSS absoluto

POSITION RELATIVE + POSITION ABSOLUTE

Si especificas la posición de div-1 de forma relativa, todos los elementos contenidos dentro de div-1 se posicionaran relativamente a div-1, por lo tanto si le establecemos la posición absoluta a div-1a, este se posicionará en la esquina superior derecha del contendor div-1.

#div-1 {
     position:relative;
}
#div-1a {
     position:absolute;
     top:0;
     right:0;
     width:200px;
}

Posicionamiento CSS relativo + absoluto

2 COLUMNAS POSICIONADAS DE FORMA ABSOLUTA

Utilizando posicionamiento relativo en el contenedor y absoluto para las columnas se pueden posicionar las columnas, una en cada lado.
Una ventaja de usar este posicionamiento es que se puede colocar el HTML de las columnas en cualquier orden, ya que el posicionamiento se realiza de forma absoluta.

#div-1 {
      position:relative;
}
#div-1a {
      position:absolute;
      top:0;
      right:0;
      width:200px;
}
#div-1b {
     position:absolute;
     top:0;
     left:0;
     width:200px;
}

Posicionamiento CSS de columnas de forma absoluta
Si te fijas, los demás elementos han sido tapados por las dos columnas que están posicionadas de forma absoluta. Vamos a ver cómo solucionar esto.

COLUMNAS POSICIONADAS DE FORMA ABSOLUTA CON ALTO DEFINIDO

Para poder visualizar el contenido tapado por las dos columnas, habría que darle un alto definido al elemento contenedor, de esta forma ya se visualizarían.

#div-1 {
    position:relative;
    height:250px;
}
#div-1a {
    position:absolute;
    top:0;
    right:0;
    width:200px;
}
#div-1b {
    position:absolute;
    top:0;
    left:0;
    width:200px;
}

posicionamiento CSS de columnas con alto fijo
Pero esta no es una solución válida para la mayoría de los diseños, porque lo normal es que no se sepa cual va a ser la longitud del texto introducido en las columnas. ¿Cómo se puede solucionar esto? Sigue leyendo…

POSICIONAMIENTO FLOTANTE

Para columnas de altura variable, el posicionamiento absoluto no sirve, en este caso hay que utilizar el posicionamiento flotante. Con la propiedad float se puede posicionar un elemento lo más a la derecha posible o lo más a la izquierda posible, dejando que el resto de elementos fluya alrededor suyo. El div div-1a está flotado a la izquierda, y el texto del resto de divs fluye alrededor el div-1a, pero el resto de divs (div-1b y div-1c) siguen ocupando la misma posición que antes, es decir todo el contendor, porque son elementos de bloque. Esto significa que el texto no se solapará con div-1, pero si le asignas una imagen de fondo con CSS, esta imagen sí que se solapará con div-1.

#div-1a {
    float:left;
    width:200px;
}

Posicionamiento CSS flotante

COLUMNAS FLOTANTES

Para que no se solapen unos elementos con otros hay que flotar todas las columnas. Para que se muestren una al lado de otra, entre todas las columnas han de sumar un ancho no superior al ancho del contenedor. Si te fijas, tanto div-after, como div-1 (que hace de contenedor) se solapan con las columnas creadas, vamos a ver como solucionar esto.

#div-1a {
    float:left;
    width:150px;
}
#div-1b {
    float:left;
    width:150px;
}

Posicionamiento CSS con columnas flotantes

COLUMNAS FLOTANTES CON CLEAR

Luego, en el último div (div-1c), en este caso el que hace de pie, se le puede añadir la propiedad clear, para que deje de tener efecto el flotado de las columnas de arriba y el resto del contenido se posicione debajo.

#div-1a {
    float:left;
    width:190px;
}
#div-1b {
    float:left;
    width:190px;
}
#div-1c {
     clear:both;
}

paso9

FIN

Con estos pasos se ha aprendido lo básico del posicionamiento CSS. Se han dejado bastantes cosas por ver, como la compatibilidad entre navegadores, etc… Pero creo que es una buena introducción para aprender a colocar cada elemento de la página donde le corresponde sin usar tablas o técnicas desaconsejadas.

¿Qué es Google Apps Engine?

Google App Engine te permite ejecutar aplicaciones web en la infraestructura de Google. Las aplicaciones del App Engine son fáciles de programar , fáciles de mantener, y fáciles de escalar a tu tráfico y el almacenamiento que se necesite. Con App Engine, no hay servidores que mantener: tu solamente subes tu app, y está lista para ser servida a tus usuarios.

Puedes servir tu app desde tu propio dominio (como por ejemplo http://www.example.com) utilizando Google Apps. O, pùedes servir tu app utilizando el nombre que quieras en el dominio appspot.com . Puedes compartir tu app con el mundo, o limitar el acceso a los miembros de tu organización.

Google App Engine soporta apps escritas en diferentes lenguajes de programación. Con el entorno Java del App Engine , puedes desarrollar tu app utilizando la tecnologia Java estandar, incluyendo la JVM, Java Servlets, y el lenguage de programación Java – o cualquier otro lenguaje utilizando una JVM o compilador , como puede ser Javascript o Ruby. App Engine además te ofrece dos entornos de ejecución dedicados de Python, cada uno de los cuales incluye el intérprete de Python y la librería estandar de Python. Finalmente, App Engine proporciona un Go runtime environment que se ejecuta nativamente en código Go. Estos entornos de ejecución son construidos para asegurar que tu aplicación se ejecuta rápidamente, de forma segura, y sin interferencia de otras apps del sistema.

Con App Engine, tú solo pagas por lo que tú usas. No hay costes de configuración y no hay cuotas recurrentes a pagar. Los recursos que tu aplicación utiliza, tales como almacenamiento y ancho de banda, son medidos por los gigabytes utilizados y facturados en tarifas competitivas. Tu controlas la máxima cantidad de recursos que tu app puede consumir, asi siempre estás dentro del presupuesto.

El App Engine no cuesta nada para empezar con él. Todas las aplicaciones pueden utilizar hasta 1GB de almacenamiento y suficiente CPU y ancho de banda para soportar un servicio de app de alrededor de 5 millones de páginas vistas al mes, absolutamente gratis. Cuando activas que se facture por tu app, entonces se te cobrará por lo que te pases de esos límites.

 

El entorno de Aplicación

Google App Engine te hace fácil construir una aplicación que se ejecuta de forma fiable, incluso bajo condiciones de estres y con grandes volumenes de datos. App Engine incluye las siguientes características:

  • Servicio de páginas web dinámicas, con soporte completo para utilizar las tecnologías web más comunes.
  • Almacenamiento persistente con queries, ordenación y transacciones.
  • Escalado automático y balance de carga
  • APIs para autenticar usuarios y enviar email utilizando Google Accounts
  • Un entorno de desarrollo local completo que simula el Google App Engine en tu ordenador.
  • Colas de tareas para realizar trabajo del ámbito de la petición web.
  • Tareas planificadas para ser disparadas por eventos en momentos concretos o a frecuencias determinadas.

Tu aplicación puede ejecutar en uno de los tres siguientes entornos de ejecución:

  • El entorno Go
  • El entorno Java
  • El entorno Python (a elegir entre Python 2.5 o Python 2.7)ç

Cada uno de estos entornos de programación proporciona protocolos y tecnologías estandars para desarrollo de aplicaciones web.

 

El cajón de arena (Sandbox)

Applications run in a secure environment that provides limited access to the underlying operating system. These limitations allow App Engine to distribute web requests for the application across multiple servers, and start and stop servers to meet traffic demands. The sandbox isolates your application in its own secure, reliable environment that is independent of the hardware, operating system and physical location of the web server.

Examples of the limitations of the secure sandbox environment include:

  • An application can only access other computers on the Internet through the provided URL fetch and email services. Other computers can only connect to the application by making HTTP (or HTTPS) requests on the standard ports.
  • Applications cannot write to the file system in any of the runtime environments. An application can read files, but only files uploaded with the application code. The app must use the App Engine datastore, memcache or other services for all data that persists between requests. The Python 2.7 environment allows bytecode to be read, written, and modified.
  • Application code only runs in response to a web request, a queued task, or a scheduled task, and must return response data within 60 seconds in any case. A request handler cannot spawn a sub-process or execute code after the response has been sent.

The Go Runtime Environment

App Engine’s Go runtime environment provides a convenient way to implement and deploy web applications written in the Go Programming Language.

The Go runtime environment uses Go release r60.3. The SDK includes the Go compiler and standard library, so it has no additional dependencies. As with the Java and Python environments, not all the standard library’s functionality is available inside the sandbox. For example, attempts to open a socket or write to a file will return an os.EINVAL error.

The SDK includes an automated build service to compile your app, so you’ll never need to invoke the compiler yourself. And—as with the Python SDK—your app will be automatically re-built whenever you change the source. This keeps you productive by making the edit-compile-run cycle refreshingly short.

The Go environment provides idiomatic Go APIs for most of the App Engine services.

You can upload other third-party libraries with your application, as long as they are implmented in pure Go.

For more information about the Go runtime environment, see The Go Runtime Environment.

The Java Runtime Environment

You can develop your application for the Java runtime environment using common Java web development tools and API standards. Your app interacts with the environment using the Java Servlet standard, and can use common web application technologies such as JavaServer Pages (JSPs).

The Java runtime environment uses Java 6. The App Engine Java SDK supports developing apps using either Java 5 or 6.

The environment includes the Java SE Runtime Environment (JRE) 6 platform and libraries. The restrictions of the sandbox environment are implemented in the JVM. An app can use any JVM bytecode or library feature, as long as it does not exceed the sandbox restrictions. For instance, bytecode that attempts to open a socket or write to a file will throw a runtime exception.

Your app accesses most App Engine services using Java standard APIs. For the App Engine datastore, the Java SDK includes implementations of the Java Data Objects (JDO) andJava Persistence API (JPA) interfaces. Your app can use the JavaMail API to send email messages with the App Engine Mail service. The java.net HTTP APIs access the App Engine URL fetch service. App Engine also includes low-level APIs for its services to implement additional adapters, or to use directly from the application. See the documentation for the datastorememcacheURL fetchmailimages and Google Accounts APIs.

Typically, Java developers use the Java programming language and APIs to implement web applications for the JVM. With the use of JVM-compatible compilers or interpreters, you can also use other languages to develop web applications, such as JavaScript, Ruby, or Scala.

For more information about the Java runtime environment, see The Java Runtime Environment.

The Python Runtime Environment

With App Engine’s Python runtime environment, you can implement your app using the Python programming language, and run it on an optimized Python interpreter. App Engine includes rich APIs and tools for Python web application development, including a feature rich data modeling API, an easy-to-use web application framework, and tools for managing and accessing your app’s data. You can also take advantage of a wide variety of mature libraries and frameworks for Python web application development, such as Django.

The Python runtime environment uses Python version 2.5.2 by default. You can also choose the Python 2.7.2 runtime.

The Python environment includes the Python standard library. Of course, not all of the library’s features can run in the sandbox environment. For instance, a call to a method that attempts to open a socket or write to a file will raise an exception. For convenience, several modules in the standard library whose core features are not supported by the runtime environment have been disabled, and code that imports them will raise an error.

Application code written for the Python environment must be written exclusively in Python. Extensions written in the C language are not supported.

The Python environment provides rich Python APIs for the datastoreGoogle AccountsURL fetch, and email services. App Engine also provides a simple Python web application framework called webapp to make it easy to start building applications.

You can upload other third-party libraries with your application, as long as they are implemented in pure Python and do not require any unsupported standard library modules.

For more information about the Python runtime environment, see The Python Runtime Environment.

Storing Your Data

The App Engine environment provides a range of options for storing your data:

  • App Engine Datastore provides a NoSQL schemaless object datastore, with a query engine and atomic transactions.
  • Google Cloud SQL provides a relational SQL database service for your App Engine application, based on the familiar MySQL RDBMS.
  • Google Cloud Storage provides a storage service for objects and files up to terabytes in size, accessible from Python and Java applications.

The Datastore

App Engine provides a distributed NoSQL data storage service that features a query engine and transactions. Just as the distributed web server grows with your traffic, the distributed datastore grows with your data. You have the choice between two different data storage options differentiated by their availability and consistency guarantees.

The App Engine datastore is not like a traditional relational database. Data objects, or “entities,” have a kind and a set of properties. Queries can retrieve entities of a given kind filtered and sorted by the values of the properties. Property values can be of any of the supported property value types.

Datastore entities are “schemaless.” The structure of data entities is provided by and enforced by your application code. The Java JDO/JPA interfaces and the Python datastore interface include features for applying and enforcing structure within your app. Your app can also access the datastore directly to apply as much or as little structure as it needs.

The datastore provides ACID transactions using optimistic concurrency control. An update of a entity occurs in a transaction that is retried a fixed number of times if other processes are trying to update the same entity simultaneously. Your application can execute multiple datastore operations in a single transaction which either all succeed or all fail, ensuring the integrity of your data.

The datastore implements transactions across its distributed network using “entity groups.” A transaction manipulates entities within a single group. Entities of the same group are stored together for efficient execution of transactions. Your application can assign entities to groups when the entities are created.

Google Accounts

App Engine supports integrating an app with Google Accounts for user authentication. Your application can allow a user to sign in with a Google account, and access the email address and displayable name associated with the account. Using Google Accounts lets the user start using your application faster, because the user may not need to create a new account. It also saves you the effort of implementing a user account system just for your application.

If your application is running under Google Apps, it can use the same features with members of your organization and Google Apps accounts.

The Users API can also tell the application whether the current user is a registered administrator for the application. This makes it easy to implement admin-only areas of your site.

For more information about integrating with Google Accounts, see the Users API reference.

App Engine Services

App Engine provides a variety of services that enable you to perform common operations when managing your application. The following APIs are provided to access these services:

URL Fetch

Applications can access resources on the Internet, such as web services or other data, using App Engine’s URL fetch service. The URL fetch service retrieves web resources using the same high-speed Google infrastructure that retrieves web pages for many other Google products.

Mail

Applications can send email messages using App Engine’s mail service. The mail service uses Google infrastructure to send email messages.

Memcache

The Memcache service provides your application with a high performance in-memory key-value cache that is accessible by multiple instances of your application. Memcache is useful for data that does not need the persistence and transactional features of the datastore, such as temporary data or data copied from the datastore to the cache for high speed access.

Image Manipulation

The Image service lets your application manipulate images. With this API, you can resize, crop, rotate and flip images in JPEG and PNG formats.

Scheduled Tasks and Task Queues

An application can perform tasks outside of responding to web requests. Your application can perform these tasks on a schedule that you configure, such as on a daily or hourly basis. Or, the application can perform tasks added to a queue by the application itself, such as a background task created while handling a request.

Scheduled tasks are also known as “cron jobs,” handled by the Cron service. For more information on using the Cron service, see the Python or Java cron documentation.

Task queues keep track of tasks to handle in the background. The Python, Java, and Go runtime environments can use task queues. For information about the task queue service, see the Python API documentationthe Java API documentation or the the Go API documentation.

Development Workflow

The App Engine software development kits (SDKs) for Java, Python, and Go each include a web server application that emulates all of the App Engine services on your local computer. Each SDK includes all of the APIs and libraries available on App Engine. The web server also simulates the secure sandbox environment, including checks for attempts to access system resources disallowed in the App Engine runtime environment.

Each SDK also includes a tool to upload your application to App Engine. Once you have created your application’s code, static files and configuration files, you run the tool to upload the data. The tool prompts you for your Google account email address and password.

When you build a new major release of an application that is already running on App Engine, you can upload the new release as a new version. The old version will continue to serve users until you switch to the new version. You can test the new version on App Engine while the old version is still running.

The Java SDK runs on any platform with Java 5 or Java 6. The SDK is available as a Zip file. If you use the Eclipse development environment, you can use the Google Plugin for Eclipse to create, test and upload App Engine applications. The SDK also includes command-line tools for running the development server and uploading your app.

The Python SDK is implemented in pure Python, and runs on any platform with Python 2.5, including Windows, Mac OS X and Linux. The SDK is available as a Zip file, and installers are available for Windows and Mac OS X.

The Go SDK features an idiomatic, native Go API for using the App Engine services, and uses the same tools as the Python SDK (with some additional machinery for automatically compiling your Go apps). The Go SDK is stand-alone—you do not need to install Go separately—and is available as a Zip file for both Mac OS X and Linux (a Windows version will be available soon).

The Administration Console is the web-based interface for managing your applications running on App Engine. You can use it to create new applications, configure domain names, change which version of your application is live, examine access and error logs, and browse an application’s datastore.

Quotas and Limits

Not only is creating an App Engine application easy, it’s free! You can create an account and publish an application that people can use right away at no charge, and with no obligation. An application on a free account can use up to 1 GB of storage and up to 5 million page views a month. When you are ready for more, you can enable billing, set a maximum daily budget, and allocate your budget for each resource according to your needs.

You can register up to 10 applications per developer account.

Each app is allocated resources within limits, or “quotas.” A quota determines how much of a given resource an app can use during a calendar day. In the near future, you will be able to adjust some of these quotas by purchasing additional resources.

Some features impose limits unrelated to quotas to protect the stability of the system. For example, when an application is called to serve a web request, it must issue a response within 60 seconds. If the application takes too long, the process is terminated and the server returns an error code to the user. The request timeout is dynamic, and may be shortened if a request handler reaches its timeout frequently to conserve resources.

Attempts to subvert or abuse quotas, such as by operating applications on multiple accounts that work in tandem, are a violation of the Terms of Service, and could result in apps being disabled or accounts being closed.

For a list of quotas and an explanation of the quota system, including which quotas can be increased by enabling billing, see Quotas.

For More Information…

For more information about Google App Engine:

jQuery Mobile: Toolbars

[Fuente: http://jquerymobile.com/test/docs/toolbars/docs-bars.html]

Tipos de Toolbar

En jQuery Mobile, hay dos tipos de standars de toolbars: Cabeceras (Headers) y Pies (Footers).

  • La Header bar sirve como el título de la página, es generalemente el primer elemento dentro de cada página de una web de movilidad, y tipicamente contiene el título de la página y hasta dos botones.
  • El Footer bar es generalmente el ultimo elemento dentro de cada pagina de una web de movilidad, y tiende a estar más abierta en términos de contenidos y funcionalidad, pero tipicamente contiene una combinación de textos y botones.

Es muy común tener una barra de navegación horizontal o tab bar dentro del header o del footer; jQuery Mobile inclute el navbar widget que convierte un lista no-ordenada de links en una botonera horizontal, que funcione bien en estos casos.

Ver el  data- attribute reference para ver todas los posibles atributos que se pueden poner con las toolbars.

Opciones de posicionamiento de las Toolbar

Las headerss y los footers pueden ser posicionados en las páginas de varias formas distintas. Por defecto, las toolbars utilizan el modo de posicionamiento “inline”. En este modo, las headers y el footer se colocan en el flujo de documento natural (el comportamiento HTML por defecto), lo cual te asegura que van a ser visibles en todos los dispositivos, independientemente del código Js o CSS de posicionamiento que tenga.

El modo de posicionamiento “fixed” positioning mode fija las toolbars arriba o al fondo del viewport de los navegadores que soportan CSS fixed positioning (la mayoria de los browsers los incluyen). Las browsers que no lo soportan , las toolbars tendrán la posición static e inline de la página.

Cuando el tap-toggling esta activo, tapping la pantalla cambiará la visibilidad de las toolbars fixed. Tapping the page cuando las toolbars no están visibles las muestra de nuevo. Tapping otra vez las esconde. Esto le da a los usuarios la opción de esconder las toolbars hasta que las necesiten y maximizar los contenidos centrales de la pagina. Un inconveniente de las fixed toolbars es que nunca realmente se esconden, porque cambian entre modo de posicionamiento fixed y static. Esto quiere decir que si estas arriba de la pagina, no puedes esconder el header toolbar haciendo tap-toogle, porque lo que hace en su vez es cambiar a su punto en el documento en el top de la página. Lo mismo pasa con los fixed footers si estamos al fondo de la página.

Para obtener este comportamiento del header y el footer , añade el atributo  data-position="fixed" al elemento header o footer.

Un modo de posicionamiento “fullscreen” “fullscreen” position mode funciona como el modo fixed excepto que las toolbars solapan el contenido de la página, más que ocupar un espacio en el documento cuando no están en modo fixed. Esto es útil para apps de inmersión como son visores de fotos o videos donde quieres que el contenido rellene toda la pantalla y la toolbars puedan ser escondidas o invocadas a aparecer haciendo un toque (tapping) de la pantalla. Recuerda que las toolbars en este modo se pondrán sobre el contenido de la página asi que es mejor que sea utilizada en situaciones especificas.

Opencart: cómo esta estructurado, cómo añadir contenido al site

Introducción

OpenCart utiliza una arquitectura pseudo MVC. Puedes aprender más sobre MVC en Google, pero en OpenCart esta montado de la forma siguiente:

Hay dos “caras” del sistema OpenCart: “admin” & “catalog”. Está muy claro lo que hace cada una. Pero lo mejor sobr eesto, es que ambas tienen la misma estructura y funcionalidad. Hay también un conjunto de ficheros comunes que llamamos “library”. Los ficheros dentro del library son utilizados para crear las estructuras y variables globales necesarias para el resto del carrito de la compra, asi como funcionalidades básicas.

Para simplificar, en el siguiente ejemplo, trabajaremos del lado “catalog”.

Componentes MVC

Hay 3 partes principales en cada pantalla que se muestra:

1. Controlador

Este es el fichero core donde tienen lugar todos los calculos, queries de DB y magia diversa. Aqui es también son configuradas las variables para valores e idiomas que son pasadas a la variables de vista para que se muestren. Los ficheros del Controller están localizados en el directorio “controller” tanto en catalog como en admin, dependiendo de qué estes modificando.

2. Idioma

Aqui es donde los idiomas son configurados. Los ficheros de idioma utilizan una configuración del tipo ‘constant=value’. El nombre de la constante se utiliza en el código, y nunca cambia. Solo cambia el valor según el idioma. Por ejemplo:

ENGLISH: $_['text_review'] = 'Product Review';
SPANISH: $_['text_review'] = 'De Revisión de Producto';
GERMAN:  $_['text_review'] = 'Produkt Bewertung';

Observese que el lado izquierdo (constante) no cambia.

Los ficheros de idioma están alojados en el directorio “language”

3. Vista

Esto se refiere al template o ficheros tpl. Todas las variables que son pasadas desde el controlador a la vista pueden ser utilizadas para mostrar la salida de los cálculos o funcionalidad. Por ejemplo, si quieres mostrar el total del carrito de la compra, primero necesitas definirlo en el controlador y pasarlo como variable de vista. Algunos ejemplos:

$view = $this->locator->create('template');
set('entry_page', $language->get('entry_page'));
set('text_review_by', $language->get('text_review_by')); 

/* Sets a variable called "text_review_by" to the value pulled
from the language file for the constant matching that variable name */

Los fichero de vista están localizados en el directorio “template”.

Poniéndolo todo junto

La mayoría de los controladores tienen un nombre intuitivo para explicar lo que ellos representan:

product.php = the product page
cart.php = the cart page
home.php = the home page

Ellos también tienen nombres similares para sus ficheros de vista e idiomas correspondientes.

Ejemplo

Digamos que queremos añadir un nuevo mensaje a la página principal que diga “Jander CLander”

1.- Editamos el fichero controller:

EDIT: catalog/controller/home.php

Localizasmos una variable existente para utilizar la como guía (no inventemos la rueda).

FIND:

$view->set('text_latest', $language->get('text_latest'));

AFTER, ADD:

$view->set('text_jander', $language->get('text_jander'));

2.-Ahora insertamos el nuevo valor a nuestro fichero de idioma:

EDIT: catalog/language/english/controller/home.php

Nos servimos de guia de una existente:

$_['text_latest']   = 'Latest Products';

Añadimos

$_['text_jander']   = 'Happy Holidays to your family from www.MySite.com!';

3.- Finalmente , lo insertamos en el fichero de template:

EDIT: catalog/template/default/content/home.tpl

FIND:

<?php echo $text_greeting; ?>

AFTER, ADD:

<?php echo $text_jander; ?>

DONE!

Ya debes poder ver el nuevo mensaje en la home

Monedas sociales.Cooperativas integrales

Cooperativas Integrales

Propuesta de transición para construir un modelo de sociedad basado en la autogestión en todos los ámbitos de vida como forma de cubrir las necesidades básicas materiales e inmateriales de todas las personas.

Qué es la Cooperativa Integral

  • Es un espacio que nos permite construir un entramado de relaciones económicas autogestionadas fomentando las relaciones sociales solidarias, las ideas de colectividad y de autogestión
  • Es Integral porque junta todos los elementos básicos de una economía como son la producción, el consumo, la financiación y la moneda propia y, al mismo tiempo, porque quiere integrar todos los sectores de la actividad necesarios para vivir
  • Proyectos productivos autónomos y servicios públicos de interés común (espacios comunes, centrales de compras, etc.) manteniendo una relación de reciprocidad y solidaria.

Qué objetivos tiene

  • Crear un entramado de relaciones económicas cooperativas y solidarias entre personas y organizaciones sociales que salga de las reglas del mercado y que no sea controlado por el estado.
  • Desarrollar productos ecológicos y locales, servicios necesarios para nuestro día a día y nuevos proyectos vinculados a las necesidades reales.

Rechazamos el Euro como medio de intercambio

  • Es parcial y escaso: lo crean instituciones financieras privadas con fines lucrativos.
  • Se fundamenta sobre la deuda: se crea cuando los bancos otorgan créditos
  • Promueve la falta de honestidad y la corrupción
  • Se esfuma hacia los centros financieros y de poder
  • Destruye las economías locales y la comunidad, provocando una degeneración social y cultural
  • Fomenta la competitividad debido a su insuficiencia
  • La usura: el dinero para pagar los intereses del dinero deuda nunca se crea

Sistema económico integral

La economía como herramienta para generar redes de autosuficiencia

  • Desarrollar herramientas que faciliten las interrelaciones económicas.
  • Claves para construir un sistema económico integral de transición.

Economía financiera (euro)

  • Entendido como parte de este modelo en transición, utilizamos el euro para interactuar con el sistema económico capitalista
  • En los proyectos en transición necesitaremos inyecciones de euros para ponerlos en marcha.
  • Con estos objetivos surge dentro de la red de Cooperativa integral, una cooperativa de autofinanciamiento social en red (CASX), 1º estructura bancaria en forma de cooperativa de servicios financieros en España

Euros virtuales

El euro virtual trading es una aplicación del C.E.S para poder mover euros entre cuentas del C.E.S, este sistema permite mover % en euros sin tener que hacerse transacciones entre cuentas corrientes reales, con sus comisiones y con su funcionamiento privativo.

Moneda social (Trueque multirecíproco)

  • Las monedas libres, sociales o locales, sirven para asignar un valor a los bienes y servicios.
  • Restan hegemonía al capitalismo y podría sustituir progresivamente al euro
  • Comparten unos criterios éticos, ecológicos y sociales que permiten que todas las personas puedan interaccionar
  • Se entiende como una herramienta de transición, que inevitablemente convive con la economía capitalista
  • La moneda social en las cooperativas integrales suelen ser virtuales a través del C.E.S o en papel.

El trueque

  • Acción no-monetaria de intercambio de bienes, servicios y conocimientos.
  • Un acuerdo verbal directo entre ofertante y demandante que satisface las pretensiones de ambas partes en relación a la equidad del intercambio

Economía comunitaria (compartir y donaciones)

Puesta en común de los recursos para el disfrute colectivo de personas que interaccionan, funcionando bajo relaciones de afinidad y apoyo mutuo.

Conclusión

  • Es necesario asumir la relación con la economía capitalista como una relación en transición
  • Forma parte de un camino a recorrer para llegar a generar a largo plazo otra economía fuera de lo establecido
  • La profundización en la economía comunitaria, el trueque, las monedas sociales y movimiento de euros hacia proyectos autogestionados, tienen que entenderse como ejes complementarios de una misma estrategia de transición.

Presentación Cooperativa Integral

OBJETIVOS: ¿QUÉ QUEREMOS?

  • Crear una red comunitaria que, bajo los principios de la ayuda mutua y la solidaridad, resuelva los problemas concretos de nuestra vida cotidiana.
  • Facilitar el intercambio de conocimientos, servicios y productos entre personas que viven en un mismo entorno local.
  • Potenciar economías locales basadas en la cercanía y el conocimiento mutuo.
  • Impulsar la participación en la construcción de un modelo de economía solidaria y social.

¿CÓMO NOS ORGANIZAMOS?

  • Para la gestión del mecanismo de Moneda Complementaria se propone convertir la Comisión de BdT en un “Concejo de Mora” integrado por los miembros representantes de las asambleas locales que impulsen en su localidad la Moneda, y por cualquier otra persona que voluntariamente quiera participar.
  • Periódicamente se realizarán Ferias itinerantes en que se presentaran los servicios, se expondrán y venderán los productos de los usuarios y se premiaran las historia de trueque y la cadena de cambio más diversificadas, más rápidas y más creadoras de riqueza. Las historias de trueque recogidas en los billetes nos permitirán visualizar la historia de los flujos y el proceso de reconstrucción de la inteligencia colectiva que significa el uso de la Moneda Complementaria.

¿CÓMO NOS ORGANIZAMOS?

Funciones de la administración:

  • Gestión de las solicitudes pendientes (comprobar datos, contactar, aprobar.)
  • Revisar las transacciones e informar delos posibles errores.
  • Dinamizar el CES (boletines, información de nuevos mercadillos y presentaciones, bienvenida a las nuevas altas…)•Hacer una copia de seguridad mensual de la basede datos.
  • Cobrar la oxidación, cada dos meses.
  • Participar en las jornadas de presentación del Sistema de Intercambio en los municipios, si procede.
  • Acompañar durante dos meses a las nuevas personas que asumen la administración
  • Comunicación con otros coordinadores/as localesa través de: bdt.sierra@gmail.com•Comunicación con la administración general del CES.

TÉRMINOS Y CONDICIONES (en constante revisión para mejorar)

  • Una MORA tendrá una equivalencia a 1 €, pero no será canjeable en euros.
  • Los servicios tendrán todos el valor de 10 MORAS/Hora, salvo para personas desempleadas y proyectos de autoempleo.
  • Se recomienda que los servicios sean 100% en MORAS (para servicios hora) pero pueden complementarse con euros hasta un máximo del 50% del valor (para productos y para personas desempleadas o en dificultades laborales).
  • Iniciaremos el sistema de intercambio con un límite de crédito de 100 Moras por cada persona inscrita.
  • Los tiempos de desplazamiento entre pueblos correrán a cargo del demandante del servicio en el caso de 100%MORAS, pero podrán ir incluidos en el precio en el caso de pago parcial en euros.
  • Oxidación moneda: la moneda que no se use perderá un 10% de su valor cada 3 meses y un 20% cada 6 meses

Banco de tiempos: crear una comunidad

Crear una nueva comunidad de intercambio o registrate en una existente

¿No tienes una comunidad de intercambio en tu área?

Si no hay una CES de intercambio en tu área porque no creas una? Si sientes que hay suficiente gente en tu comunidad que puede estar interesada en comercio sin usar la moneda establecida en el pais, o gente que está metida en serios problemas creados por un sistema basado en el crédito, entonces registra una nueva comunidad de intercambio. Nos pondremos en contacto contigo después de que nos llegue tu registro y empezaremos el proceso de configurarlo.

Register a new or existing exchange with the CES

« Back

Your details…
Details of Exchange Group
Full title of exchange: (e.g. New Town Community Exchange)
Short name for exchange: (e.g. New Town) – this gets used in menus
Four letter code for exchange: (e.g. NTCE) – exchange ID; account number prefix
Location (City/Town/Place): (where this exchange is located)
County/Province/State etc: (where this exchange is located)
Country:
Currency name: (e.g. Green Dollar, Talent)
Currency symbol: (e.g. G$, T)
Web site of exchange: (if any)
Language: (default language for new members)
Other language: (if not listed above)
Motivation:
If this is a new exchange please tell us about your vision for it; if it is an existing exchange tell us something about its history and your vision for the future.
Administrator’s Details
First name: Tel (home):
Surname: Tel (work):
Address: Fax:
Address (cont.): Mobile:
City/Town/Place: Email:
County/Province/State etc:
Postcode/Zip:
Country:
Additional detail can be provided after your new exchange has been set up. You will be able to submit your logo and modify default text to customise your site.

Unete a un grupo existente de la red CES

Su ya eres miembro de un grupo de intercambio que tiene algún tipo de moneda social, como por ejemplo el grupo LETS o un banco de tiempos, porque no registrar tu grupo en la red CES y te conviertes en parte de la red CES que permite intercambios a nivel global. Enganchando tu grupo al CES puedes beneficiarte de un avanzado sistema y avanzadas herramientas de gestión.

Intercambio de crédito mútuo o banco de tiempos?

La red CES puede acoger grupos de intercambio mútuo de crédito, donde la unidad de valor estaá basada en la moneda nacional o cualquier otro standard ; y los bancos de tiempo, donde la unidad de valor está basada en el tiempo.

Ningun coste en moneda convencional

No hay coste en moneda convencional para formar parte de la red CES. Estamos haciendo todo lo posible para eliminar nuestra necesidad del dinero convencional y crear un sistema de intercambio que es soportado por su propia energia.

Herramientas de gestión

Para gestionar las transacciones en el intercambio, hay tres interfaces de gestion que te ofrece la red CES

  • un interfaz administrativo sofisticado Administrative Interface desde donde el administrador o equipo administrador gestiona el intercambio y guarda registro de lo que está sucediendo. Para ver las funciones que están contenidas en el interfaz de usuario, miralo aqui click here.
  • un interfaz de Coordinacion de miembros Membership Co-Ordinator’s Interface para menejar asuntos de registro de los miembros. Puedes verlo aqui click here.
  • Un interfaz de coordinador para miembros apuntados que realicen acciones departe de otros (por ejemplo para aquellos que no tienen ordenador ni internet). Para ver qué funciones están contenidas en este interface , mira  click here.

Si necesitas más información escribe a  

Nota importante:

Registrar una comunidad de intercambio significa que tu o tu organización se convierte en el Administrador del intercambio. Lo que CES proporciona es solo la herramienta que gestiona ese intercambio, pero no es el intercambio en sí mismo. Una comunidad de intercambio es un entidad real establecida con el proposito de facilitar el comercio en tu comunidad sin el uso de la moneda convencional. Para conocer más sobre lo que significa ser administrador , podemos leer lo siguiente read here.

Qué significa ser Administrador?

Cuando se envia una solicitud de registro de grupo de intercambio automáticamente te conviertes en el Administrator  del grupo. La web del CES es sólo una herramienta para la gestión del intercambio, pero no es el intercambio en si mismo.

Mucha gente se ha registrado como comunidad de intercambio esperando que los intercambios se crearán por si mismos cuando la gente se registre y empiece a hacer transacciones. En la práctica no sucede asi. Un intercambio es un entidad de la vida real. Tiene que comenzar desde abajo, y no en el ciberespacio. Debe ser promocionado en la comunidad y constantemente debe realizar actividades que motiven a la gente a hacer actividades juntos, tales como mercados de intercambio, reuniones y otros eventos. Tiene que haber uno o más gente apsionada con la idea cuando el intercambio empieza a funcionar.

Ser Administrador viene con ciertas responsabilidades y obligacines. El Administrator tiene acceso a un interfaz de administracion, que tiene un conjunto de herramientas de intercambio. Las obligaciones del Administrator incluyen lo siguiente:

  • Aprobar nuevas suscripciones al grupo
  • Dar soporte a los dudas de los usuarios
  • Mantener a los usuarios informados. Esto incluye, entre otras cosas:
    • Enviar un estado de cuentas mensual
    • Enviar una lista de las ofertas regularmente
    • Enviar una lista de las demandas regularmente
    • Enviar noticias sobre el grupo
  • Mantenimiento (bloqueo de cuentas , transferencia de usuario, borrar anuncios caducados, etc)
  • Monitorear estadisticas y datos de transacciones para ver que los intercambios se realizan bien y que ciertos usuarios no están abusando del sistema.
  • Meter transaciones, anuncios y otra información de parte de otros usuarios
  • Ser árbitro de las disputas

Apart from the above the Administrator needs to promote the exchange in the community to ensure its growth to a position of critical mass, when the exchange tends to take on a life of its own.

Often the Administration consists of a committee and the tasks of administration are shared. Every exchange is different.

Please consider the above before sending in your application for a new exchange. Administration is a rewarding position but for an exchange to be a success it does require some effort!


Dojo: custom builds

En este tuto explicaremos como hacer un sistema dojo reducido para que el rendimiento de nuestra app mejore (menos peso de librerias). Esta guia brevemente nos enseña los usos más comunes y parámetros. Para información detallada ver full build documentation.

Introducción

Un custom build de dojo mejora el rendimiento por medio de lo siguiente:

Se trata de diseñar los módulos de cada capa con un “profile” , que es algo similar a un script de Ant o un Makefile. Pero esto no es dificil si conoces tu app bien.

La entrada al build system es el árbol de codigo fuente del dojo, más cualquier fuente para asuntos personalizados que quieras incluir… más el profile. La salida es una distribución de Dojo que puedes poner en tu web server.

Prerequisitos

Necesitas lo siguiente instalado en tu ordenador para ejecutar el Dojo’s build system:

  • Java 1.4.2 or later (Java 1.5 recommended).
  • El código fuent de Dojo, que puedes obtener de http://download.dojotoolkit.org/. Los builds de código fuente tienen el sufijo “-src”. Si quieres descargarte la última versión del repositorio Subversion , puedes hacerlo en Using Subversion .

Parámetros de perfiles y de linea de comando

El build system es manejado por el script build.sh (o build.bat para Windows), que acepta varios parámetros en la línea de conados, uno de los cuales debe indicar qué build profile se debe utilizar para hacer el build. Los parámetros especificados en la línea de comando y el profile son combinados para hacer el build.

Nota: In Dojo versions 1.X CHECK FACT and later, if parameter values from the profile override parameters of the same name on the command line. Prior to version 1.X CHECK FACT, parameters on the command line override parameters of the same name from the profile.

Donde de ponen los profiles?

Cuando especificamos el nombre del profile por el parámetro profile , el directorio por defecto para los profiles es :

util/buildscripts/profiles.

Podemos poner los profiles fuera de la estructura de directorios de Dojo (lo cual no es mala idea de forma que podamos utilizarlo en subsecuentes versiones de Dojo), puedes utilizar el parámetro profileFile para que apunte a tu profile en cualquier sitio del disco.

Nomenclatura de los profiles

Tus profiles deben seguir siempre la siguiente nomenclatura  name.profile.js. El parámetro  profile automaticamente añade  profile.js a la string que sea especificada para determinar el nombre del fichero.

Ejemplo: Crear un Custom Profile

En el siguiente ejemplo, que está dentro del directorio  util/buildscripts/profiles , crearemos un fichero profile build llamado foo.profile.js que contendrá lo siguiente:

dependencies ={

  layers:  [
      {
      name: "mydojo.js",
      dependencies: [
          "dijit.Button",
          "dojox.wire.Wire",
          "dojox.wire.XmlWire",
          "explosive.space.Modulator"
      ]
      }
  ],

  prefixes: [
      [ "dijit", "../dijit" ],
      [ "dojox", "../dojox" ],
      [ "explosive", "../../explosive" ]
  ]

};

La sección dependencies dentro de layer lista todos los módulos que puedes invocar “directamente”. Cualquier módulo referenciado también será incluido, asi que no tienes que preocuparte de las dependencias. También, los módulos base de Dojo están implicitos, asi que no necesitas listar cosas como “dojo.query”. (Los módulos core , sin embargo , sí necesitan ser listados)

Los módulos encontrados en layer son reunidos para hace el fichero “layer”, en nuestro ejemplo: “mydojo.js”. Entonces ya solo tienes que cargar este js en tus páginas en la script tag para empezar a funcionar con dojo. Fácil!

 

 

The prefixes section list any modules that need inclusion. Note our “explosive” module, which is located away from the Dojo tree. You need to list these if you use them, even if you don’t want any modules from it in your layer file.

For the 1.0+: If you choose to optimize the JS files in a prefix directory (via the optimize= build parameter), you can choose to have a custom copyright text prepended to the optimized file. To do this, specify the path to a file tha contains the copyright info as the third array item in the prefixes array. For instance:

prefixes: [
    [ "explosive", "../../explosive", "../../explosive/copyright.txt"]
]

If no copyright is specified in this optimize case, then by default, the dojo copyright will be used.

Running The Build

After specifying a profile file as shown above that statically specifies the resources you want to include, and saving it as /buildscripts/profiles/foo.profile.js, you run the Rhino interpreter on it and specify the profile name as a parameter. For example, from the buildscripts directory:

$ cd util/buildscripts
$ build.sh profile=foo action=release

On Windows PC’s, substitute build.bat for build.sh. For both platforms, you may also specify additional build options. Run build.sh with no options to see a list of all supported options. Here is a sample of the supported options:

profile
The name of the profile to use for the build. It must be the first part of the profile file name in the profiles/ directory. For instance, to use base.profile.js, specify profile=base. Default: base
profileFile
A file path to the profile file. Use this if your profile is outside of the profiles directory. Do not specify the “profile” build option if you use “profileFile” Default: “”
action
The build action(s) to run. Can be a comma-separated list, like action=clean,release. The possible build actions are: clean, release Default: “help”.Note: the ”release” action automatically implies the ”clean” action, except when you have used the advanced parameter ”buildLayers” in your profile.

version
The build will be stamped with this version string Default: “0.0.0.dev”
localeList
The set of locales to use when flattening i18n bundles Default: “en-gb,en-us,de-de,es-es,fr-fr,it-it,pt-br,ko-kr,zh-tw,zh-cn,ja-jp”
releaseName
The name of the release. A directory inside ‘releaseDir’ will be created with this name Default: “dojo”
releaseDir
The top level release directory where builds end up. The ‘releaseName’ directories will be placed inside this directory Default: “../../release/”
loader
The type of dojo loader to use. “default” or “xdomain” are acceptable values.” defaultValue: “default”
internStrings
Turn on or off widget template/dojo.uri.cache() file interning Default: true
optimize
Specifies how to optimize module files. If “comments” is specified, then code comments are stripped. If “shrinksafe” is specified, then the Dojo compressor will be used on the files, and line returns will be removed. If “shrinksafe.keepLines” is specified, then the Dojo compressor will be used on the files, and line returns will be preserved. If “packer” is specified, Then Dean Edwards’ Packer will be used Default: “”Note: using the ”packer” option is discouraged in most environments. In environments where the http server supports gzip compression automatically, ”shrinksafe” will provide better performance. ”packer” also does more transformations to the underlying source code.

layerOptimize
Specifies how to optimize the layer files. If “comments” is specified, then code comments are stripped. If “shrinksafe” is specified, then the Dojo compressor will be used on the files, and line returns will be removed. If “shrinksafe.keepLines” is specified, then the Dojo compressor will be used on the layer files, and line returns will be preserved. If “packer” is specified, Then Dean Edwards’ Packer will be used Default: “shrinksafe”
copyTests
Turn on or off copying of test files Default: true
log
Sets the logging verbosity. See jslib/logger.js for possible integer values Default: logger.TRACE
xdDojoPath
If the loader=xdomain build option is used, then the value of this option will be used for the path to Dojo modules. The dijit and dojox paths will be assumed to be sibilings of this path. The xdDojoPath should end in ‘/dojo’ Default: “”

Cross Domain (XDomain) Builds

Doing an xdomain build allows you to load Dojo and your custom modules from another domain.

Benefits

  • You get more connections in MSIE, since you can load from another domain. Faster loading.
  • You get increased cacheability/startup if many of your applications use the same installation.
  • Resource loading does not block the rest of the page from filling in as with Dojo’s normal, synchronous loading.
  • With a local install, your ISP may charge you for all of those Dojo bits that you are serving.

Implications/Limitations

  • Not all external resources can be xdomain loaded, in particular some support files that need to be loaded from the same domain as the HTML page. See module-specific notes below.
  • Requires a “xdomain” build of Dojo (see below for more info on how to make a xdomain build).
  • Asynchronous loading. You MUST use dojo.ready() to register a callback function to get notification of package loading. This can be used even after the initial page load. Just do the dojo.require()s that you need, and then call dojo.ready() with a callback function, and once those new packages are loaded (or if they are already loaded), then the callback will be called. This technique works even for the normal Dojo loader, so this is a good practice to use even when not using an xdomain build.
  • Avoid using document.write(): Since module can load asynchronously, after the page is loaded, document.write can cause problems.

Module-specific Notes

dojo.io.iframe.create(), dijit.Editor, dijit._editor.RichText: You need to save dojo/resources/blank.html to the same domain as your HTML page and set dojoConfig.dojoBlankHtmlUrl to the path on that domain.Note: The dijit.Editor/dijit._editor.RichText has a bug in release 1.1.0 where it was not using this dojoConfig parameter. It is fixed in Dojo 1.1.1 and later.

dojo.back: You need to save dojo/resources/blank.html to the same domain as your HTML page and set dojoConfig.dojoIframeHistoryUrl to the path on that domain.

dojox.flash.Info(): It uses document.write() which will cause problems if dojox.flash is loaded via dojo.require().

Doing xdomain builds

Sample xdomain build command:

$ cd util/buildscripts
$ build.sh profile=foo loader=xdomain xdDojoPath=http://my.server.com/path/to/buildoutputdir action=release

xdDojoPath is optional. It just burns in the location of dojo, dijit and dojox into the built dojo.js. If you do not specify that option, then you will need to use dojoConfig.modulePaths/dojo.registerModulePath() in your HTML page to set the xdomain locations for dojo, dijit and dojox. For your own custom modules, you will have to set dojoConfig.modulePaths/dojo.registerModulePath() even if you use the xdDojoPath build option.

For Dojo 0.9 through 1.1.x: there is a bug about loading dojox.gfx with an xdomain build. This is fixed in Dojo 1.2. If you want to use dojox.gfx with an xdomain build of Dojo 0.9-1.1.x, there are some workarounds until the bug gets fixed:

How to use xdomain builds in web pages

  • In dojoConfig, add useXDomain = true.
  • In dojoConfig, add a modulePaths object that maps where to find your modules.
  • Only use dojo.require() to load xdomain layers. Do not reference the .xd.js file for the layer file. The one exception is dojo.xd.js. If your layer does not map to a real module name, then specify a resourceName: property for that layer in your build profile. The other option is to load the built .js file (not .xd.js file) in a script tag.
  • Register a callback function to get notification of when the packages are loaded by using dojo.ready().
  • Optional: set a wait time in milliseconds (dojoConfig.xdWaitSeconds) that specifies how long the resource loader should wait for a resource to load until returning an error. Since script elements do not give information about failed or long-running requests, this timeout is used to prevent infinite waiting in the browser. An exception will be thrown to indicate a load error. The default xdWaitSeconds is 15.

XDomain Example

Here is an example showing how to load local modules along with an xdomain-loaded dojo and dijit. You can download this example.

TODOC: everything. outline here:

  • summary
  • requirements / setup
  • creating a profile
  • command line arguments
  • special builds: * layers * css
  • file structure

link to full docs to cover:

  • excludeStart/Stop
  • restoreRequire
  • layerDependencies
  • discard
  • .uncompressed.js
  • customBase
  • more..