Blend Workspaces

Visual Studio consente un export/import dei settings molto completo, Blend no.
Peccato, perché sarebbe molto comodo poter trasferire da una postazione all'altra almeno i Workspaces: ogni developer e/o designer (soprattutto ;-)) ha un proprio modo di organizzare palette e strumenti.
Nel mio caso la configurazione dell'ambiente di lavoro è una vera e propria mania!

E' possibile, però, trasferire manualmente la configurazione dei propri workspaces da filesystem...

Con Windows 7 e Blend 4 il path è questo:
%APPDATA%\Microsoft\Expression\Blend 4\Workspaces


Bisogna poi modificare il file %APPDATA%\Microsoft\Expression\Blend 4\user.config in questo modo:

<ConfigurationObject Name="WorkspaceService">
    <PrimitiveObject Name="ActiveWorkspace">[defaultworkspace]</PrimitiveObject>
    <PrimitiveObject Name="UserWorkspaces">[workspace1]|[workspace2]</PrimitiveObject>
 </ConfigurationObject>

Custom bindings rulez (again)

Continua l'implementazione di custom bindings per BS/KO (vd. Tre piccioni con un custom binding). Questa volta mi occorreva simulare il comportamento tipico del checkbox/toggle e di un gruppo di radiobuttons utilizzando però i button di BS.
Qui il binding:

/*****************************
** KnockOut Custom Binding for Bootstrap common property .active
** Author: lightwalker
** Usage:
** a)  VM property is a bool -> data-bind="bsActive: [vmpropertyname]" 
**     for example togglebutton (checkbox behavior)
** b)  two parameters -> data-bind="bsActive: {value: [viewvalue], property: [vmpropertyname]}"
**     for example buttons group (radiobuttons behavior)
** http://twitter.github.com/bootstrap/javascript.html#buttons
*******************************/

        ko.bindingHandlers.bsActive = {
            'init': function (element, valueAccessor, allBindingsAccessor) {
                var updateHandler = function () {
                    var valueToWrite = null;
                    var modelValue = null;
                    if (valueAccessor().value != undefined) {
                        modelValue = valueAccessor().property;
                        valueToWrite = ko.utils.unwrapObservable(valueAccessor().value);
                    }
                    else {
                        modelValue = valueAccessor();
                        valueToWrite = !ko.utils.unwrapObservable(modelValue);
                    }


                    if (ko.isWriteableObservable(modelValue) && modelValue !== valueToWrite) {
                        modelValue(valueToWrite);
                    }
                };
                ko.utils.registerEventHandler(element, "click", updateHandler);
            },
            'update': function (element, valueAccessor) {
                    var valueToCompare = null;
                    var modelValue = null;
                    var toToggle = true;
                    if (valueAccessor().value != undefined) {
                        modelValue = ko.utils.unwrapObservable(valueAccessor().property);
                        valueToCompare = ko.utils.unwrapObservable(valueAccessor().value);
                        toToggle = (modelValue.toString() == valueToCompare.toString());
                    }
                    else {
                        toToggle = ko.utils.unwrapObservable(valueAccessor());
                    }
                    $(element).toggleClass('active', toToggle);
                }
       }

E qui il frammento di view:

<!-- int value binding -->
<div class="btn-group">
  <button class="btn" data-bind="bsActive: {value: 0, property: intVMObservable}">Value 0</button>
  <button class="btn" data-bind="bsActive: {value: 1, property: intVMObservable}">Value 1</button>
  <button class="btn" data-bind="bsActive: {value: 2, property: intVMObservable}">Value 2</button>
</div>
<!-- bool value binding -->
<button class="btn" data-bind="bsActive:boolVMObservable">Yes/No</button>

Tre piccioni con un Custom Binding

Sulla falsariga dei Custom Bindings di Knockout per jQueryUI trovati qui e qui ne ho implementato uno per il PopOver di Bootstrap.

L'obiettivo principale era, ovviamente, rispettare il pattern MVVM anche nell'uso del framework di Twitter ed evitare che l'iniezione asincrona nel DOM di pezzi di UI rompesse l'applicazione del plugin al $(document).ready().
Mi si è aperta, però, un'altra possibilità...

I Popovers di BS non supportano nativamente l'opzione target, come invece fanno i Modals.
E questo è un peccato: definire direttamente nel markup il contenuto html è, di nuovo, perfettamente compliant al MVVM e offre una flessibilità impagabile.
Ho quindi delegato al binding la valorizzazione del content nei due casi:

• che sia valorizzata l'opzione content
• che sia valorizzata l'opzione target (non nativa) con il selettore di un oggetto definito nel DOM

Qui il binding:

/**
KnockOut Custom Binding for Bootstrap Popovers (http://twitter.github.com/bootstrap/javascript.html#popovers)
Author: lightwalker
**/

(function ($) {

    if (ko && ko.bindingHandlers) {

        ko.bindingHandlers.bsPopover = {
            init: function (element, valueAccessor) {
                var val = ko.utils.unwrapObservable(valueAccessor());
                var options = { title: val.title,
                    animation: val.animation,
                    placement: val.placement,
                    trigger: val.trigger,
                    delay: val.delay,
                    //can grab html content from a target option
                    content: ($(val.target).html() != null) ? $(val.target).html() : val.content
                };
                $(element).popover(options);
            }
        };

    };

})(jQuery);

E qui il frammento di view:

<!-- popover activator -->
<a href="#" class="btn btn-danger" rel="popover" data-bind="bsPopover:{title: vmObservable(), target:'#popover-content'}">Hover Me!</a>
<!-- popover html content -->
<div id="popover-content" class="hide"><b>Custom HTML Content</b></div>

E allora... Buon binding a tutti!

Edit: continua con: Custom bindings rulez (again)

Il kit del bravo Web Designer/Developer

L'azienda ha deciso recentemente (con generale e persistente rammarico di tutti) di abbandonare lo sviluppo di RIA su piattaforma ASP .NET e di migrare verso altri misteriosi e minacciosi net-lidi.
Hallelujah. ;-)
Cercando di scrollare di dosso la ruggine ho quindi rastrellato il web alla ricerca del miglior mix di tecnologie correnti per lo sviluppo di front-end web avendo in mente questi obiettivi:

• parallelizzazione design/development


• rapidità di implementazione


• scalabilità


• riuso


• flessibilità


• compatibilità cross-browser

E la mia salute mentale ha vacillato...
Troppi framework, troppi componenti, troppe librerie, TROPPO di tutto!
Ma alla fine (forse) ho trovato un approdo.
Grazie anche al pregevole tentativo di metter ordine da parte di BoilerPlate e Initializr.
Qualche appunto sul percorso fatto...

Pattern

Forti della solida e gratificante esperienza sul paradigma MVVM maturata con WPF/Silverlight, non potevamo rinunciare alle potenzialità di questo modello, soprattutto nella separazione delle professionalità... ma non solo.
E quindi abbiamo optato per l'incredibile framework KnockOut, dribblando il diffusissimo (e pur potente ed efficace) ASP.NET MVC.
Razor resta relegato, eventualmente, al semplice assemblaggio delle pagine nelle composite application e al modello di navigazione.
C'è un contro...

Il pattern MVVM mette in crisi l’applicazione di alcuni comportamenti di UI, soprattutto quando vengono iniettati in modo asincrono frammenti del DOM (per esempio con i template): quando accade cosa?

E quindi? Implementare un’instrumentazione nel “code-behind” delle view?
Funziona, ma non è una soluzione particolarmente performante e snella.
Pare molto più compliant al pattern ed efficace l’uso di custom bindings di KO, come quelli, per esempio, già disponibili in rete per jQueryUI (qui e qui).

Non affronto intenzionalmente il tema dell'accesso al datamodel: non è mia competenza.

UI Components

jQueryUI pare scelta obbligata.
Ma....
Trovo che soffra di una certa legnosità, che conti troppo sulla stesura di codice javascript per l'implementazione e troppo poco sul markup, che sia poco moderno nell'aspetto e ostico da customizzare, che sia ancora molto incompleto nella dotazione di serie.
Ok, ci sono zillioni di plugin, ma il rischio è di perdere in uniformità e di riempire l’applicazione di scripts).
L'alternativa: Twitter Bootstrap.
Pulito, versatile, leggero, veloce, completo, smart.
La maggior parte dei componenti viene istanziata nel markup con la semplice applicazione di classi CSS predefinite

CSS

Trovo molto interessanti Sass e LESS: entrambi estendono il CSS portandolo al livello di un vero e proprio linguaggio di programmazione dinamico e superando le sue rigide limitazioni (per esempio l'impossibilità di utilizzare variabili).
[Ci sono anche Stylus, CSSCrush, CleverCSS, HSS, XCSS e ilMioCSSèpiùBellodelTuo... e via così...]
Questo obbliga a compilare i sorgenti scritti con queste sintassi per ottenere un output compatibile con il vero CSS. E' possibile farlo in fase di deploy o al volo su web server.
Quale dei due preferire (qui, qui e qui a confronto)?
Sono molto simili, ma LESS offre in più:

• javascript DENTRO il css


• compilazione on-the-fly sul client via javascript (può essere utile in fase di sviluppo)


• è usato in Bootstrap

Sass ha dalla sua un compagno usatissimo: Compass, che agevola il mixin soprattutto per quanto riguarda il CSS3.
Però per LESS si trova una tonnellata di mixins già pronti come Less Elements o -lessins-.
Il contro di questi processori è che non si può fare (ancora) editing WYSIWYG dei CSS, ma credo che con un po’ di fatica in più si possa lavorare di cut&paste dall'ottimo Stylizer.
Per concludere, ecco il nostro kit:

• jQuery


• librerie di supporto (es. Modernizr)


• KnockOut + custom bindings


• Bootstrap


• LESS + mixins

Ah, poi si sono SproutCore, Wijmo, Kendo UI, ecc...
Ma bastaaaaa! ;-)