Yahoo! Blog User Interface (YUIBlog)

YUIConf 2011 Registo Early Bird já está aberto

30 de setembro de 2011 às 09:31 por Jenny Donnelly | Em Desenvolvimento e Eventos YUI | 4 Comentários

Early-bird de inscrição para YUIConf 2011 está agora aberto em Eventbrite! O evento deste ano será realizada em novembro 2-4 na Yahoo! 's campus Great America. Estamos entusiasmados por trazer-lhe um dia cheio de hands-on workshops de formação (qua), seguido por dois dias inteiros de palestras técnicas sobre YUI (qui / sex). As inscrições para a conferência custa 75 dólares este ano, com uma taxa de cedo-pássaro de US $ 50. As inscrições para as oficinas será separada da conferência e os detalhes estão chegando em breve.

Estamos forro ocupado até grandes temas, incluindo:

• Mergulhos profundos de componentes YUI, incluindo Dial e calendário
• YUI em ambientes móveis
• Testando com YUI
• Do mundo real, histórias de migração
• e muito, muito mais!

Como sempre, as sessões da conferência será gravada em vídeo e está disponível em YUI Theater e nosso canal no YouTube para que todos possam desfrutar.

Espero ver você lá!

(Yahoos IMPORTANTE! internos registre para um bilhete de Empregado Yahoo! e fornecer seu endereço de e-mail de trabalho.)

Encontrar conversas: bloglines | technorati

Compartilhar e ampliar: Bookmark com del.icio.us | digg it! | reddit!

YUI 3.4.1 está agora a viver

27 de setembro de 2011 às 02:37 por Allen Rabinovich | Em Desenvolvimento | 8 Comentários

O YUI 3.4.1 liberação de ciclo curto já está disponível no CDN e para baixar , mais de uma semana mais cedo! Aqui estão alguns destaques desta edição:

• Mais de 150 correções de bugs para controlador , Painel , DataTable , Calendário , e uma série de outros módulos.
• Bug corrige a Y.substitute () por YUI contribuinte Satyam .
• Suporte ao idioma japonês para o Calendário e Console , cortesia do YUI contribuinte Ryuichi Okumura .
• Diversos ajustes para a documentação e exemplos.

Você pode também pode rever o resumo de todas as mudanças observadas nos arquivos do componente histórico para YUI 3.4.1 , bem como a lista completa dos bilhetes abordados durante YUI desenvolvimento 3.4.1 . Como sempre, gostaríamos que você apresentar quaisquer sugestões que você pode ter ou defeitos você pode descobrir na nossa base de dados do bilhete. Feedback para YUI 3.4.1 podem ser inseridos em banco de dados bilhete YUI 3 .

Gostaríamos também de anunciar que na próxima versão do YUI, DataType.Date, DataType.Number e DataType.XML será preterido em favor de Y.Date, Y.Number e Y.XML, respectivamente. Compatibilidade com versões anteriores serão mantidos para uma versão, para dar a todos a chance de passar.

Ah, e mais uma coisa: estamos bem em nosso caminho na migração do conteúdo para o YouTube Theater YUI . Para começar, confira palestra Douglas Crockford série "Crockford em JavaScript" - com legendas!

Encontrar conversas: bloglines | technorati

Compartilhar e ampliar: Bookmark com del.icio.us | digg it! | reddit!

Vote em YUI nos Prêmios Finals Open Source

26 de setembro de 2011 às 9:21 pm por Jenny Donnelly | Em Miscelânea | 1 Comentário

Obrigado a todos que YUI nomeado para os Prémios Packt Publishing Open Source. Vote agora para YUI como sua biblioteca JavaScript favorito!

Encontrar conversas: bloglines | technorati

Compartilhar e ampliar: Bookmark com del.icio.us | digg it! | reddit!

YUI 3.4.1 PR1 agora disponível no CDN

22 de setembro de 2011 às 1:35 pm por Jenny Donnelly | Em Desenvolvimento | 1 Comentário

YUI 3.4.1 PR1 já está disponível para testes na comunidade e feedback. Ele está disponível no CDN Yahoo! em http://yui.yahooapis.com/3.4.1pr1/build/yui/yui-min.js , e você pode ver as mudanças acontecendo em 3.4.1 da lista de bilhetes marcados em para o lançamento .

A versão 3.4.1 será uma menor liberação de correção de bugs, com um ciclo de desenvolvimento reduzido, programada para o go-live de 05 de outubro. Por favor, erros de arquivos e regressões em banco de dados de bilhete em YUILibrary.com pela manhã de segunda - feira, 26 de setembro, para que possamos certificar-se de quaisquer questões críticas são dirigidas antes da liberação geral. Se há problemas urgentes são relatados, iremos liberar 3.4.1 tão cedo quanto 27 de setembro.

Encontrar conversas: bloglines | technorati

Compartilhar e ampliar: Bookmark com del.icio.us | digg it! | reddit!

YUI: Open Horas qui 15 de setembro

Setembro 12, 2011 at 9:58 pm por Lucas Soares | Em Desenvolvimento e Horas Abertas | 2 Comentários

Extensão da Satyam MakeNode

Se você não sabe Satyam , você deve ser novo para YUI. Ele tem sido um pilar da comunidade YUI desde os primeiros dias de YUI 2. Seus artigos sobre YUIBlog são alguns dos mais lidos e encaminhados às fontes de "como realmente usar a biblioteca" de conteúdo estilo. Se você ver que Satyam escreveu, vale a pena a leitura, e muito provavelmente, uma re-leitura e um marcador.

Em julho, ele postou um ótimo artigo sobre um MakeNode extensão Widget que visa simplificar alguns dos padrões comuns usados ​​na construção de Widgets, e torná-lo mais fácil evitar erros comuns. O módulo já foi adicionada à Galeria e só hoje cedo, ele postou uma atualização de seu artigo original.

Isso é o que nós vamos estar falando. As características, a história, e os raciocínios. Se você estiver usando a infra-estrutura componente e, em particular, Y.Widget , você já deve ter encontrado pelo menos alguns dos obstáculos Satyam estabelecidos para tratar com MakeNode . Este vai ser o melhor um festival de práticas, para trazer o seu bloco de notas, e suas próprias experiências para compartilhar.

Time & Detalhes

Nós vamos estar online na quinta-feira 10:00-11:00 PDT.

Junte-se à Reunião

Gravação

A gravação é disponível no YouTube YUILibrary canal .

Encontrar conversas: bloglines | technorati

Compartilhar e ampliar: Bookmark com del.icio.us | digg it! | reddit!

Enviar uma conversa por YUIConf 2011

Setembro 12, 2011 at 15:48 por Jenny Donnelly | Em Desenvolvimento e Eventos YUI | No Comments

Mostre o código que você está trabalhando sobre ou compartilhar algo que você aprendeu ao trabalhar com YUI! Apresente sua proposta para yui-eventos (at) yahoo-inc.com por sexta-feira, 23 de setembro, 2011. Certifique-se de incluir:

• Título
• Descrição
• Público-alvo
• Seu nome
• Uma breve biografia

YUIConf 2011 será realizado 03 de novembro e 4 de Santa Clara Yahoo! 's, CA campus. Sua apresentação deve durar cerca de 45 minutos. Vamos ter até 15 minutos após a sua apresentação para o Q & A. Mensagem dúvidas nos comentários ou e-mail diretamente para yui-eventos (at) yahoo-inc.com.

Encontrar conversas: bloglines | technorati

Compartilhar e ampliar: Bookmark com del.icio.us | digg it! | reddit!

Atualizado: O "MakeNode" Extensão Widget

Setembro 12, 2011 at 15:18 por Satyam | Em Desenvolvimento e YUI 3 Galeria | 8 Comentários

Nota do Editor: Este artigo foi publicado originalmente no início deste ano . Desde então, o módulo MakeNode foi publicado na Galeria YUI e recebeu algumas melhorias. O artigo de hoje reflete todas as alterações mais recentes MakeNode.

Em meu artigo anterior, uma receita para um 3 YUI Aplicação , mostrei uma maneira de usar Y.substitute como um processador de modelo muito básico. A idéia tomou a vida de lá, com sugestões dos povos da yui # canal de IRC, e eu fiz-lhe uma extensão Widget que está disponível na Galeria YUI, chamado MakeNode . MakeNode não é um processador de modelo genérico e não se entende como um. Por outro lado, ele é totalmente integrado com o YUI Widget classe base, incluindo o nome de classe e eventos ajudantes e internacionalização. Neste artigo, levará o Spinner exemplo e modificá-lo a seguir as orientações do meu artigo anterior e para usar MakeNode. MakeNode está disponível como um componente galeria, bem como a modificação Spinner componente e do exemplo que será usada neste artigo .

Estendendo a sua componente

Para carregar MakeNode você precisa incluir o módulo em seu YUI().use() declaração usando o nome de 'gallery-makenode' ou, se a definição de um módulo via YUI.add() , listá-lo como o requires matriz. Então, para estender o seu widget, você listá-lo no terceiro argumento para Y.Base.create() , como este:

  Y.Spinner = Y.Base.create (
      'Spinner',
      Y.Widget,
      [Y.MakeNode],
      {
         / / Instância membros ...
      },
      {
          / / Membros estáticos
      }
 ); 

Você pode adicionar MakeNode ao longo de qualquer número de extensões adequadas para widget, como WidgetParent, WidgetChild, WidgetStdMode, etc MakeNode adiciona dois métodos protegidos para serem usadas pelo desenvolvedor, _makeNode e _locateNodes, e ele irá ler a partir de várias propriedades estáticas, se encontrado .

Todos os membros desta extensão são ou protegido ou privado, uma vez que se destinam a ser usadas pelo desenvolvedor do componente e não pelo implementador usando esses componentes, que não deve ser incomodado com elas. Lembre-se de verificar o "Show Protegido" opção ao ver a documentação da API .

Definir o modelo de

A primeira coisa que normalmente você vai fazer é definir o modelo para seu componente. Para a Spinner, o nosso modelo será:

  _Template: [
     "<input Type="text" title="{s input}" class="{c input}"> ',
     "<button Type="button" title="{s up}" class="{c up}"> botão </> ',
     "<button Type="button" title="{s down}" class="{c down}"> botão </> '
 ]. Join ('\ n'), 

O modelo padrão será normalmente chamado _TEMPLATE e declarou ao longo das outras propriedades estáticas da classe, como ATTRS . MakeNode vai usar este modelo, se nenhuma outra estiver expressamente prevista. O modelo é feito de HTML simples, mais uma série de marcadores de posição entre colchetes chaves, cada uma formada por um único personagem (o código de processamento) e seguido por um ou mais argumentos. Os espaços reservados eo que eles produzem são:

• {@ attributeName} valor de atributo de configuração

• {p propertyName} valor propriedade de instância

• {m methodName arg1 arg2 ….} valor de retorno de um método. O código de processamento é seguido pelo nome do método e qualquer número de argumentos separados por espaço em branco.

• {c classNameKey} className CSS gerado a partir do _CLASS_NAMES propriedade estática (ver A propriedade _CLASS_NAMES seção abaixo)

• {s key} cadeia a partir da strings atributo, utilizando key como o atributo de sub-.

• {? condition valueIfTrue valueIfFalse } muito parecido com o ?: operador de JavaScript, avalia a valueIfTrue se a condição for truish, valueIfFalse contrário.

• {1 condition valueIfOne valueIfMore } usado para produzir singular / plural palavras com base no valor da condição.

• {} qualquer outro valor será tratado como Y.substitute faz.

Por exemplo, {@ value} se traduzirá em this.get('value') , enquanto {p value} se traduz em this['value'] .

Quando espaços reservados ter argumentos, como {m} , {?} e {1} , cordas devem ser colocados entre aspas duplas. Números, booleanos e null (todos sem aspas) será analisado para seus próprios tipos de dados. Espaços reservados podem ser aninhados. O {?} e {1} espaços reservados normalmente irá conter um espaço reservado nested para a condição e possivelmente para os seus valores, por exemplo:

  {P qty} {1} {p qty "unidade" "unidades"} 

Se a propriedade qty é 1, ele irá avaliar a "1 unit" , para 2 ou mais ele vai voltar "2 units" e assim por diante. Uma versão mais elaborada lidar com zero seria:

  {?  {P qty} "{p qty} {1} {p qty" unidade "" Units "}" "none"} 

Observe que o resultado do processamento dos espaços reservados interiores, se uma string, deve ser colocado em seu próprio conjunto de aspas.

Para incluir uma aspas duplas dentro de uma string, utilize \\" , a barra invertida dupla sendo necessária, porque o JavaScript irá interpretar um único e descarta-lo antes que ele chegue ao MakeNode Apenas aspas são permitidos;. MakeNode não usa eval() para o analisador é limitada, mas seguro. Qualquer coisa, mas números, null , booleanos e strings de aspas duplas serão ignoradas.

O {?} espaço reservado também é útil para usar com caixas de seleção e botões de rádio. Ele pode ser usado para produzir a cadeia "checked" , dependendo do valor de verdade da código de instrução de processamento que se segue. Assim, <input type="checkbox" {? {m getLength} "checked" ""}/> <input type="checkbox" {? {m getLength} "checked" ""}/> irá produzir uma caixa de seleção marcada se o getLength método retorna nada, mas zero.

Para o {c} espaço reservado, nós precisamos ter um _CLASS_NAMES propriedade definida.

Espaços reservados adicionais podem ser adicionados a MakeNode adicionando-los para o _templateHandlers hash.

A propriedade _CLASS_NAMES

Junto com o ATTRS e _TEMPLATE propriedades estáticas, podemos definir uma _CLASS_NAMES propriedade estática que aponta para uma matriz de strings. Cada uma dessas cadeias irá ser utilizado para gerar um className. Assim _CLASS_NAMES: ['input'] irá produzir o className "yui3-spinner-input" . Esses nomes de classes são armazenados em uma propriedade de instância this._classNames . A {c input} espaço reservado no modelo acima será substituído por "yui3-spinner-input" . Eu chamo as cordas listados na _CLASS_NAMES , como 'input' , as "chaves classname", uma vez que pode ser usado como uma chave para se referir ao className real ou os elementos que contenham essas classnames, como veremos mais tarde.

Você pode usar o _CLASS_NAMES propriedade para gerar qualquer número de nomes de classes, se você usá-los no modelo ou não. Você ainda pode chegar a esses nomes de classes extras de dentro this._classNames . O className é gerada utilizando o yui3 prefixo seguido pelo valor do NAME propriedade estática transformou em letras minúsculas, e então a string dada em _CLASS_NAMES (este último não será transformado em minúsculas), todos separados por hífens. O _classNames hash irá conter também os nomes de classes para o boundingBox eo contentBox , o primeiro sob a "boundingBox" chave ea segunda sob o "content" da chave. Widget atribui ao boundingBox de classnames derivados a partir dos valores da NAME propriedade de cada uma das classes na cadeia de herança, começando com yui3-widget . Lojas MakeNode em this._classNames apenas o topo className-mais para o boundingBox .

Se o módulo é carregado WidgetStdMod, MakeNode também irá gerar entradas para sua HEADER , BODY e FOOTER seções com as mesmas chaves, que são também as constantes definidas nesse mesmo módulo.

Se um componente é vários níveis de distância de Widget, como SuperSpecialSpinner Herança de SuperSpinner que herda de Spinner que herda de Widget, e se algum ou todos eles têm _CLASS_NAMES propriedades definidas, MakeNode produzirá classnames para todos eles e armazená-los no this._classNames . Você não precisa incluir em cada nível os nomes já declarados nos níveis anteriores. Na verdade, é melhor que você não já que os nomes de classes produzidas em cada nível vai usar o valor do NAME propriedade desse nível. Assim, em SuperSpecialSpinner , {c input} ainda resultará em "yui3-spinner-input" e não "yui3-superspecialspinner-input" e por isso vai manter o seu arquivo CSS ainda válido.

O espaço reservado {s}

Widget tem uma strings atributo de configuração definida, embora não seja inicializada com qualquer valor. Este atributo é utilizado para armazenar seqüências que são visíveis (ou, através de leitores de tela, leia a) o usuário. É importante que você nunca incluem cordas visíveis diretamente no modelo. Esta não é uma exigência de MakeNode - nunca foi uma boa idéia de todo. Todas as seqüências que devem ser vistos por ler ou para o usuário sempre deve ser colocado no strings atributo. O strings atributo contém um hash onde cada texto individual fica por sua chave. O componente Spinner tem o seguinte texto, que você pode ver utilizadas no modelo acima.

  cordas: {
     valor: {
         entrada: "Pressione a seta para cima / para baixo teclas para incrementos menores, Page Up / Down para incrementos importantes.",
         se: "Increment",
         para baixo: "Decremento"
     }
 }, 

A melhor parte de fazer isso é que o componente pode ser localizada para outros idiomas com muita facilidade por desenvolvedores que utilizam o componente. Ao criar uma instância de Spinner, você pode fazer:

  var mySpinner = new Spinner ({strings: Y.Intl.get ('giratório')}); 

Definindo o atributo de configuração strings desta forma substitui o padrão strings com os valores do arquivo de recurso língua usando a linguagem previamente definida. O {s} espaço reservado acessa as seqüências armazenadas no strings atributo, tanto os de defeito ou os mais traduzidos, se definido. O {s xxxx} espaço reservado é quase como usar {@ strings.xxxx} exceto que as seqüências de substituição localizadas podem ter espaços reservados que serão tratados posteriormente. Isso é importante para traduções desde que a ordem sintática varia de língua para língua e isso permite reformular o texto, incluindo os seus espaços reservados para atender qualquer língua. Strings podem também ser acessados ​​usando {@ strings.xxxx.yyyy.zzzz} , que permitirá o acesso a cordas aninhados em profundidade e vai impedir que outras substituições. Chaves podem ser incluídos em um texto usando {LBRACE} e {RBRACE} como espaços reservados.

Usando _makeNode em renderUI

Nós usamos o modelo para criar a marcação para o nosso componente. Para isso, podemos chamar de MakeNode _makeNode método, como este:

  renderUI: function () {
     . this.get ('Contentbox') append (this._makeNode ());
 }, 

Isto irá preencher o contentBox de nosso widget com a marcação a partir do processamento do modelo. O _makeNode método retorna uma instância de Y.Node que pode ser acrescentado ou inserido em qualquer lugar ou apenas mantidos para uso posterior. Ela não retorna uma string, ele produz um Node de instância. (Se você precisa de uma seqüência e não um nó, você pode usar o _substitute método, que exige que você passe em um modelo.)

O _makeNode método leva dois argumentos opcionais: uma referência a um modelo e um objeto para preencher espaços reservados, como Y.substitute faz. No nosso exemplo Spinner simples há um modelo único para o widget todo, mas outros widgets pode exigir pedaços feitos de vários modelos. Nesse caso, você normalmente chamar _makeNode sem argumentos para a parte principal e chamá-lo mais uma vez com modelos diferentes para preencher as peças extras. O exemplo contém este renderUI método:

  renderUI: function () {
     var fieldset = this._makeNode ();
     this.each função ((item) {
         fieldset.appendChild (this._makeNode (MultipleTemplates.RADIO_TEMPLATE, item));
     }, This);
     this.get ('Contentbox') append (fieldset).;
 } 

A primeira chamada para _makeNode retorna um Node instância armazenada na variável fieldset . O componente da amostra é também estendido com Y.ArrayList assim o RADIO_TEMPLATE será preenchido com valores retirados os itens armazenados na lista de matriz e os nós resultantes anexados ao fieldset antes de ser finalmente anexado ao contentBox . Os espaços reservados especiais, como {@} ou {p} ainda se referem a atributos ou propriedades do objeto principal. Os itens aninhados serão processados ​​tal como Y.substitute faria.

O método _locateNodes

MakeNode proporciona ainda um _locateNodes método que irá tentar localizar todos os elementos com os nomes de classes declaradas no _CLASS_NAMES . Para localizar elementos específicos que você pode passar qualquer número de chaves classname, caso contrário, _locateNodes tenta todos eles. Para cada elemento encontrado de cada className, _locateNodes produzirá uma propriedade de instância privada usando o prefixo sublinhado seguido do nome da chave e do "Node" sufixo. Assim, em nosso exemplo Spinner, _locateNodes irá gerar a propriedades _inputNode , _upNode e _downNode . Se vários elementos têm o mesmo className, _locateNodes retornará uma referência para o primeiro deles. Se um elemento não for encontrado, nenhuma variável será criado.

Na componente Spinner usamos _locateNodes depois de criar a marcação:

  renderUI: function () {
     . this.get (CBX) append (this._makeNode ());
     this._locateNodes ();
 }, 

A propriedade estática _EVENTS

Uma outra propriedade pode ser definida ao longo das linhas de _TEMPLATE e _CLASS_NAMES e que é _EVENTS . _EVENTS irá conter um hash composto de chaves de classe de nomes, cada um contendo um hash de tipos de eventos e métodos para lidar com eles. É melhor explicado com um exemplo:

  _EVENTS: {
     entrada: 'change', / / ​​this._afterInputChange chamadas
     BoundingBox: [
         {
             tipo: "chave",
             fn: '_onDirectionKey', / / ​​chamadas this._onDirectionKey
             args: ((Y.UA.opera) "para baixo":? "imprensa:") + "38, 40, 33, 34"
         },
         "Mousedown '/ / chamadas this._afterBoundingBoxMousedown
     ],
     documento: "mouseup ', / / ​​this._afterDocumentMouseup chamadas,
     Y: 'broadcastingObject: SomeEvent' / / chamadas this ["_afterYBroadcastingObject: SomeEvent"]
 }, 

_EVENTS é um objeto (um hash), com qualquer número de entradas. Os nomes das propriedades, ou seja, as chaves do hash, identificar os nós cujos eventos que irão ouvir. Eles são as chaves classname mesmos definidos na _CLASS_NAMES . Existem várias teclas extra especiais:

• "boundingBox" referem-se ao caixa delimitadora em si.

• "document" refere-se ao documento que contém este widget.

• "THIS" refere-se ao próprio widget

• "Y" refere-se ao Y exemplo.

Se o Widget foi estendida com WidgetStdMod bem, as teclas HEADER , BODY e FOOTER irá se referir a essas seções, uma vez que estará disponível no _classNames hash. JavaScript não precisa de chaves para ser citados, se são identificadores válidos para nenhuma das opções acima precisam ser citado.

O _EVENTS propriedade é processado após as renderUI , bindUI e syncUI métodos têm sido chamados assim o widget deverá já estar inserido dentro do corpo do documento, caso contrário o "document" identificador irá falhar.

Para cada um desses elementos não é um identificador de evento ou um conjunto de identificadores de eventos. Um evento pode ser identificada pelo tipo de evento para ouvir ou um objecto com mais detalhes. Por padrão, MakeNode usará como um ouvinte um método chamado usando o "_after" prefixo seguido pelo identificador do elemento com o seu primeiro caractere em maiúsculo seguido pelo tipo de evento com o seu primeiro caractere em maiúsculo. O bloco de código acima mostra os métodos chamados para cada evento.

Um identificador de evento também pode ser um objeto com propriedades type , fn e args . O type é obrigatória e indica o tipo de evento que está sendo escutado. O fn propriedade dá o nome do método que ouvir o evento evitando assim a nomeação automática. Desde _EVENTS é uma propriedade estática, ela não tem acesso a this para que ele não pode ter uma referência real a um método, apenas o seu nome. O args argumento pode ser usado para transmitir outros argumentos para o chamador, tais como com a key acontecimento que exige uma especificação chaves.

MakeNode usará Node.delegate para ouvir a eventos sobre os elementos de dentro da boundingBox , enquanto ele usará Node.after para ouvir a eventos do boundingBox e do corpo do documento. Ele usará this.after para ouvir eventos sob a THIS chave e Y.after para os ouvintes listadas sob o Y chave. Todos os eventos são ouvidas usando após ouvintes de eventos, uma vez que se destinam a tornar o widget responder a eventos, não para filtrar o comportamento do objeto que aciona-los assim, em nenhum caso desses eventos pode ser evitada ou interrompida. (Nota: ouvir a key evento em qualquer elemento aninhado funciona apenas com 3.4.0pr1 versão e acima, uma vez que a delegação da key caso não estava disponível antes de todas as características de outros trabalham com as versões anteriores também.).

Os _EVENTS declarações são cumulativos quando os componentes herdar um do outro. Cada classe na cadeia de herança terá a sua própria _EVENTS declaração processada separadamente.

A propriedade estática _ATTRS_2_UI

Eventos em ambos os sentidos, a partir da interface do usuário para o componente e do componente de interface do usuário. O primeiro são tratados pelo _EVENTS propriedade. Depois, há os eventos disparados por mudanças de atributos de valor que precisam ser refletidas na interface do usuário. Como eu mencionei no artigo anterior, quando houver efeitos secundários de mudar um atributo de configuração, eles devem ser manuseados por ouvintes de eventos de alteração, e não pelo opcional setter método do atributo, que só deve lidar com normalização do valor a ser definido. A interface do usuário deve refletir o estado dos atributos de configuração, primeiro em syncUI , ao ser inicializado e, em seguida, em cada evento de alteração de atributo. Para este último, precisamos anexar um ouvinte de evento, que normalmente faria em bindUI . Widget já fornece um mecanismo para fazer com que simples, que eu descrevi nos comentários ao artigo anterior.

Widget usa a instância de propriedade _UI_ATTRS que contém um objeto com duas propriedades adicionais, SYNC e BIND . Cada um destes é uma matriz que lista os nomes dos atributos de configuração para ser inicialmente sincronizado e, em seguida, ouvido, a fim de manter a UI reflectindo os valores actuais. Widget espera que cada uma dessas entradas de ter um método associado, nomeado após o nome do atributo prefixado por _uiSet com o primeiro caractere do nome do atributo convertido para maiúsculas para ter o nome do método no caso de camelo adequada. Assim, se "value" foi listado em nenhum dos _UI_ATTRS matrizes (tanto no SYNC ou BIND ), Widget esperaria encontrar uma _uiSetValue método. Este método irá receber dois argumentos, o value a ser definido eo src da mudança. Este é o código para o nosso Spinner _uiSetValue método:

  _uiSetValue: function (valor, src) {
     if (src === UI) {
         voltar;
     }
     this._inputNode.set (VALOR, this.get (Formatter) (valor));
 }, 

Todos os identificadores de maiúsculas que você vê neste pedaço de código correspondem aos constantes da cadeia declarado em outro lugar, para permitir que o compressor YUI para fazer seu trabalho melhor. O método, basicamente, define o value do atributo HTML no <input> caixa para o conjunto novo valor, depois de ser formatado. A referência à caixa de texto foi fornecido por _locateNodes . O src argumento é inicialmente marcada para ver se definido para o valor de seqüência 'ui' . Se isto é assim, nenhuma ação será tomada. Isso é para evitar loops infinitos. Se o usuário digita algo na caixa de entrada, o seu valor iria para o value atributo de configuração que então iria disparar um valueChange evento, que iria ficar _uiSetValue chamado, que, se não for controlada, então vá e altere o valor da caixa de entrada, que desencadearia todo o processo novamente. Assim, em _uiSetValue , se sabemos que a mudança vem a partir da interface do usuário, não fazemos nada e assim quebrar o loop. No entanto, isto requer uma outra parte de código em outro lugar. No ouvinte para o evento DOM, quando vamos definir o atributo de configuração, usamos o terceiro argumento opcional para definir, como este:

  _afterValueChange: function (ev) {
     this.set (VALOR, ev.newVal, {src: UI});
 } 

Cabe a nós garantir que as mudanças provenientes da interface do usuário são marcados assim e depois verificar que a bandeira do mesmo para evitar loops. Não usar o identificador src quando definir o valor do atributo não, source que não será reconhecido.

Com tudo isso dito, eu ainda não falou sobre a propriedade estática _ATTRS_2_UI mencionado no título desta seção. Como os comentários em meus shows artigo anterior (através dos erros que fiz neles), certificando-se que todos os atributos que afetam a interface do usuário estão devidamente listados é um pouco confuso. Você nunca deve inicializar _UI_ATTRS a partir do zero desde Widget já enumera uma série de atributos e aqueles seriam perdidos. Você tem que concatenar nomes de atributos novos ao longo dos já existentes, o que é um pouco difícil de lembrar de como fazer isso direito. Para tornar mais simples, MakeNode vai ler a propriedade estática _ATTRS_2_UI e fazer isso de concatenação para você. Ele irá concatenar todas as listas de cada classe na cadeia de herança assim em cada nível de cada classe pode lidar com seus próprios atributos. Em Spinner, temos:

  _ATTRS_2_UI: {
     BIND: VALOR,
     SYNC: VALOR
 }, 

MakeNode irá aceitar tanto um array de nomes ou um nome de atributo único, como neste caso.

A pergunta surge naturalmente, por duas listas, uma para ligar o outro para sincronizar? SYNC é usada na primeira vez, após as renderUI e bindUI métodos, se existirem, são chamadas e antes syncUI enquanto os enumerados no BIND será obrigado a os atributos correspondentes para alterações posteriores. Muitas vezes o SYNC matriz tem entradas menos do que o BIND lista e isto é porque o modelo para o componente pode já ter o valor padrão muito mesmo que o atributo de configuração e não há necessidade de fazer uma sincronização inicial. Assim, se o valor padrão para o value atributo de configuração é uma string vazia ea <input> elemento no modelo não tem value atributo, então não há necessidade de sincronizá-los na inicialização.

Atributos listados na BIND terão seus _uiSet Xxxx métodos chamados em qualquer ordem, como os atributos podem ser definidas em qualquer ordem. Atributos listados na SYNC será chamado uma vez na ordem em que são listados com aqueles de ancestrais antes seus herdeiros, portanto, se um é dependente de outro (o que não deve), a ordem pode ser importante.

MakeNode irá verificar se há entradas duplicadas em qualquer uma dessas matrizes. Se aparecer qualquer, isso significa que uma classe de componente herda de nosso já lida com esse atributo e qualquer nova declaração faria ultrapassar mais provável que o _uiSet Xxxx manipulador para ele. Aliás, MakeNode também verifica as entradas duplicadas em _CLASS_NAMES , que também podem causar conflitos em alguns, embora não todos, circunstâncias. MakeNode vai escrever uma mensagem para o log por qualquer erro desse tipo.

A propriedade _PUBLISH

Finalmente, o _PUBLISH propriedade estática irá listar os eventos que têm de ser publicado. Ele contém um hash usando o nome do evento como suas chaves e um objeto literal de atributos de configuração como os seus valores. Ele irá publicar todos os eventos listados em qualquer propriedade em toda a cadeia de herança. O nome do evento mesmo pode ser publicado em uma classe e em qualquer classe herdando a partir dele, o que fará com que os atributos de configuração de outros mais tarde substituir aqueles em que os mais velhos. Por exemplo, você pode querer fazer uma transmissão de evento existente no mundo. Assim como com a _EVENTS propriedade, uma vez que _PUBLISH é uma propriedade estática sem acesso a this , quando especificar funções, é o nome do método, como uma cadeia de caracteres, que necessita de ser determinado.

Conclusão

MakeNode fornece um processador de modelo muito simples, com funcionalidade que é altamente integrada com a classe base Widget. Ele também fornece métodos auxiliares para criar classnames para ser usado no modelo e usar estes nomes para localizar e referem-se aos nodos criados. Ele também fornece os meios para ligar para os eventos gerados tanto pela interface do usuário e do próprio componente e associar cada um com um método. Ele faz todas essas coisas, tendo o cuidado de respeitar a cadeia de herança em linha reta até Widget e qualquer nível de classes que você pode definir.

Ele não prevê absolutamente todas as possibilidades, mas abrange uma boa variedade deles. No entanto, isso não impede você de adicionar funcionalidade extra. Você raramente pode ter que escrever uma bindUI ou syncUI método se você usar a cola fornecida pelo MakeNode, mas poderá fazê-lo, uma vez que MakeNode não usá-los.

Como um bônus para aqueles que tiveram a paciência de ler este conjunto agora, eu também modificou Anthony Pipkin do botão de componentes galeria e fez um acordeão e componentes TimeSpinner, todos disponíveis na Galeria .

Sobre o autor: Daniel Barreiro (nome de tela Satyam) tem sido em torno de algum tempo. O ENIAC foi desativado no dia antes de ele nascer, por isso ele perdeu isso, mas ele não perdeu muito desde então. Ele teve a chance de cartões perfurados, o programa de 6502 fichas (lembre-se o Apple II?), Do próprio. TRS-80 e veja algumas peças fantásticas de equipamentos operacionais em sua Argentina natal que pode ter sido em outro lugar em museus Quando a globalização abriu as portas para o mundo, o seu Inglês, em seguida, pouco utilizável (mais um formado em Engenharia Elétrica) colocou no plano de carreira que terminou em um trabalho de 5 anos na área da baía de volta nos dias de NCSA Mosaic. Totally intrigued by the funny squiggles a friend of his wrote in his plain text editor, full of <'s and >'s, he ended up learning quite a lot about the world of frontend engineering. It's been a long journey since COBOL and Fortran. Now he lives quite happily semi-retired in the Mediterranean coast close to Barcelona, Spain.

Encontrar conversas: bloglines | technorati

Compartilhar e ampliar: Bookmark com del.icio.us | digg it! | reddit!