Atualizado: O "MakeNode" Extensão Widget
Setembro 12, 2011 at 15:18 por Satyam | Em Desenvolvimento e YUI 3 Galeria | 8 Comentários 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_NAMESpropriedade estática (ver A propriedade _CLASS_NAMES seção abaixo){s key}cadeia a partir dastringsatributo, utilizandokeycomo o atributo de sub-.{? conditionvalueIfTrue valueIfFalse }muito parecido com o?:operador de JavaScript, avalia avalueIfTruese a condição for truish,valueIfFalsecontrário.{1 condition valueIfOne valueIfMore }usado para produzir singular / plural palavras com base no valor da condição.{}qualquer outro valor será tratado comoY.substitutefaz.
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 aoYexemplo.
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 .
Compartilhar e ampliar: Bookmark com del.icio.us | digg it! | reddit!
8 Comments »
RSS feed dos comentários deste post. URI TrackBack
Deixe um comentário

Copyright © 2006-2012 Yahoo! Inc. Todos os direitos reservados. Política de Privacidade - Termos de Serviço
Alimentado por WordPress em Yahoo! Web Hosting .

Hum, wow. Finalmente fez-lo através deste artigo e eu estou ansioso para experimentar o módulo de galeria. Parece que * a * monte de andaimes que eu não tenho certeza que é ótimo para novos desenvolvedores para YUI sem estar nas primeiras trincheiras, mas posso certamente ver como ele pode encurtar um código muito repetitivo, especialmente para aqueles de nós que têm já colocou o nosso tempo em :-).
Estou curioso sobre a seguinte declaração: "A propriedade _EVENTS é processado após a renderUI, métodos e bindUI syncUI foram chamados para o widget deverá já estar inserido dentro do corpo do documento, caso contrário o" documento "identificador irá falhar." Em geral, um widget que está sendo processado não significa necessariamente que ele está no DOM, muitas vezes tornar um widget a um nó contendo que ainda não foi inserido, que funciona bem desde que eu não tente chegar no DOM .
Então, é a questão na declaração de apenas um problema quando se quer usar o "documento" identificador ou vai causar transformação em geral a falhar? Gostaria de saber se a funcionalidade _LOCATE_NODES primeiro deve ser verificado, para voltar a DOM verifica quando necessário?
Obrigado por dois grandes (se não muito) e artigos do módulo galeria.
B
Comentário por Brian J. Miller - 12 de setembro de 2011 #
Brian
Se você usar o "documento" identificador no _EVENTS eo componente não está anexado ao documento, ele será ignorado. Além disso, "documento" irá se referir ao documento o componente está em, se o principal ou o único em um iframe.
_locateNodes vai funcionar se o componente está anexado ao documento ou não, porque ele procura dentro do BoundingBox, caso contrário ele pode escolher elementos com os mesmos nomes de classes em outras instâncias do componente.
Comentário por Satyam - 13 de setembro de 2011 #
Obrigado Satyam. Grande economia de tempo para melhorias escrita Widget.
Eu fiz passar por um pouco de dificuldade para descobrir as dependências do módulo. E a versão de agosto não parecem ter o disparo _EVENTS. Mas, uma vez que foi descoberto e usando uma versão mais recente galeria, ele funciona muito bem.
Eu fiz montar um exemplo mais simples, apenas para mostrar o widget mais básico usando MakeNode com bruxa requisitos nu poderão ser úteis:
https://github.com/JohnICello/yui-samples
Comentário por John Iannicello - 16 de setembro de 2011 #
Você já pensou em dividir o processador modelo fantástico em um módulo separado galeria?
Comentário por John Lindal - 22 de setembro de 2011 #
John ,
É engraçado que a questão vem à tona, porque todo o projeto começou apenas com o modelo de coisa. É por isso que é chamado MakeNode, após o que era seu método, só então pública, makeNode por isso é como pedir para voltar ao palco. Mas pode fazer sentido, vamos ver os números:
A versão de depuração atual é 23.7K, com a versão minified 4.68k, um quinto (eu coloquei muitos comentários para a documentação da API). Até 3.4.1 sai, esta versão tem um Y.substitute patched incluído. Uma vez que está fora, o minified desce para 3.87k, por outras palavras, o adesivo tem de 17%.
Se eu tirar tudo não relacionado à modelagem, (e eu também significar _locateNodes caindo) desce para 2.13k. Isso significa que o modelo já leva 55% do módulo. Eu me pergunto se vale a pena é dividir.
Eu teria pensado comigo mesmo que a parte de modelagem foi talvez um terço do pacote para que ele teria feito sentido para soltar o resto. Será que faz sentido fazê-lo com este número?
Incluir _locateNodes, que é tão útil, uma vez que você usou _makeNode, e todo o resto acaba sendo não muito depois de tudo.
Comentário por Satyam - 22 de setembro de 2011 #
Eu não parecem ser capazes de manter este módulo silencioso.
Eu adicionei dois novos recursos:
Se a classe usando MakeNode nem nenhum daqueles que herda tem um método renderUI, ele irá automaticamente criar um para você que acrescenta o resultado do processamento do _Template ao Contentbox e depois faz um _locateNodes.
Tenho também acrescentou o espaço reservado {n}, que terá uma seqüência de códigos de processamento e argumentos e assumir o valor do primeiro é um objeto que ele usará para processar o segundo.
Dessa forma,
{np objRef @ attr}será lido da propriedadeobjRef, suponha que o valor é um objeto e ler atributoattrdele. Ele só funciona com os códigos de processamento que levam identificadores simples como argumentos (não com {m}).Comentário por Satyam - 29 de setembro de 2011 #
Nova adição:
O descritor _EVENTS tem uma nova opção em seu manipulador. Além do 'tipo', 'fn' e 'args' propriedades que têm agora 'quando'.
Se não for especificado, o padrão é 'depois'. Também pode ser 'antes' e 'delegado'. Ele determina qual o método que ele usa para anexar o evento, seja Y.after (o padrão), Y.on (por 'antes') ou Y.delegate (para 'delegado').
O padrão de nomenclatura para os métodos de evento ouvinte mudanças desde agora não é apenas um '_after' prefixo, os métodos podem agora começar com '_before' ou '_delegate'.
Comentário por Satyam - 21 de outubro, 2011 #
Oi,
Treeble fonte de dados é great.However não é capaz de analisar dados json sem colchetes Por exemplo:
{"TreeNode":
[{"Legenda": "ModelDate", "Model1": null, "Model2": null},
{"TreeNode": {"legenda": "Taxa de Crescimento", "Model1": 14, "Model2": 20},
"Rótulo": "Modelo Preço", "Model1": "15", "Model2": "16"},
{"TreeNode":
{"TreeNode":
{"TreeNode":
[{"Legenda": "grant1", "Model1": 1000 ", Model2": 1000},
{"Rótulo": "grant2", "Model1": 1000 ", Model2": 800},
{"Rótulo": "grant3", "Model1": 1000 ", Model2": 900}],
"Rótulo": "investido", "Model1": 3000 ", Model2": 5700},
"Rótulo": "Opções", "Model1": 3000 ", Model2": 5700},
"Rótulo": "Valor Líquido", "Model1": 3500 ", Model2": 5000}]} não está funcionando
No entanto, se eu colocar manualmente colchetes parece funcionar.
Você pode responder. É urgente
Comentário por Nanditha - 16 janeiro de 2012 #