Средства управления по сравнению со стандартным HTML

Question

Средства управления по сравнению со стандартным HTML

Редактирование: как ни странно, после наших комментариев выше, я проверил, действительно ли это версия базового модуля babel, я использую это в своей скрипке:

https://cdnjs.cloudflare.com/ajax/libs/babel-core/5.8.24/browser.js

Второе, я перехожу к вашей версии выше, я получаю следующее:

Uncaught TypeError: Cannot read property 'keys' of undefined

Используйте React.createClass not ReactDOM.createClass и оберните несколько строк html в круглых скобках, например:

Working Пример: https://jsfiddle.net/69z2wepo/38998/

var Hello = React.createClass({
  render: function() {
    return (     
       
        Hello World
        This is some text
       
    )
  }
});

ReactDOM.render(
  ,
  document.getElementById('container')
);

11

controls asp.net c#

задан user1270384 11 September 2012 в 00:14

11 ответов

Я на самом деле вполне освобожден для наблюдения некоторых мнений, здесь согласившись с моим собственным: ASP.NET как шаблонный язык очень плох.

Я был бы точно так же, как для опровержения нескольких про точек, сделанных здесь (flamesuit на!):

Dave Ward упоминает идентификационные коллизии - это верно, но мой как плохо обработанный. Я предпочел бы видеть узлы, на которые ссылается xpath или глубокие селекторы CSS, чем путем создания идентификатора эффективно бесполезным кроме путем подчинения внутренностям ASP.NET как clientID - он просто делает запись CSS и JS это намного тяжелее бессмысленно.

Rob Cooper говорит о том, как средства управления являются заменой для HTML, таким образом, это - весь штраф (перефразирование, простите мне Rob) - хорошо это не прекрасно, потому что они взяли существующий и хорошо понятый язык и сказали "нет, необходимо сделать вещи наш путь теперь", и их путь очень плохо реализован. например, asp:panel представляет таблицу в одном браузере и отделение в другом! Без документации или выполнения, разметка для управления входом в систему (и многие другие) не предсказуема. Как Вы собираетесь заставить разработчика писать CSS против этого?

Espo пишет о том, как средства управления приносят Вам пользу абстракции, если платформа изменяет HTML - хорошо это является явно круговым (Он только изменяется, потому что платформа изменяется и не нуждалась бы к тому, если у меня просто был свой собственный HTML там вместо этого), и на самом деле создает проблему. Если управление собирается измениться с обновлениями снова, как мой CSS, как предполагается, справляется с этим?

Апологеты скажут "да, но можно изменить это в конфигурации" или говорить о переопределении средств управления и пользовательских элементов управления. Хорошо, почему я должен иметь к? CSS дружественный пакет средств управления означал решать некоторые из этих проблем, совсем не с, он - несемантическая разметка, и это не решает идентификационную проблему.

Невозможно реализовать MVC (абстрактное понятие, не 3,5 реализации) из поля с приложениями веб-формы becuase эти средства управления так плотно связывают представление и управление. Существует входная планка для традиционного веб-дизайнера теперь, потому что он должен связаться с серверным кодом для реализации то, что раньше было отдельными доменами CSS и JS. Я сочувствую этим людям.

Я действительно сильно соглашаюсь с точкой зрения новозеландца, которая средства управления допускают некоторую очень быструю разработку для приложений определенного профиля, и я признаю, что по любой причине некоторые программисты находят HTML неприятным, и далее что преимущества, которые другие части ASP.NET дают Вам, который требует этих средств управления, могут стоить цены.

Однако я снова послал потерю управления, я чувствую модель контакта с вещами как классы, стили и сценарии на codebehind заблуждающийся шаг назад, и я далее чувствую, что существуют лучшие модели для шаблонной обработки (реализация микроформатов и xslt для этой платформы), хотя замена средств управления с ними нетривиальна.

Я думаю, что ASP.NET мог узнать о много из связанной технологии в ЛАМПЕ и мире направляющих, до тех пор я надеюсь работать с 3.5 MVC, где я могу.

(извините, который был такой длинный </напыщенная речь>),

13