Есть ли бизнес-причина для стремления к чистому макету CSS?
Кажется, что каждый раз, когда я пытаюсь создать чистый макет CSS, мне требуется гораздо больше времени, чем если бы я использовал таблицу или две. Получение трех столбцов одинаковой длины с разными объемами данных, по-видимому, требует особых причудливых хаков, особенно при решении проблем кросс-браузера.
мой вопрос:
Кому могут навредить эти несколько столов?
Таблицы, кажется, работают особенно хорошо на табличных данных — почему они так оскорбляются в этот день и возраст? Google.com имеет таблицу в своем исходном коде, так же как и многие другие сайты (stackoverflow.com, кстати, не имеет).
Почему я не могу использовать блок try вокруг моего вызова super()?
Итак, в Java первая строка вашего конструктора HAS должна быть вызовом super... будь то неявный вызов super() или явный вызов другого конструктора. Вот что я хочу знать: почему я не могу поставить пробный блок вокруг этого?
Мой конкретный случай заключается в том, что у меня есть макет класса для теста. Конструктора по умолчанию нет, но я хочу, чтобы он упрощал чтение тестов. Я также хочу обернуть исключения, вызванные из конструктора, в RuntimeException.
Итак, то, что я хочу сделать, это эффективно:
public class MyClassMock extends MyClass {
public MyClassMock() {
try {
super(0);
} catch (Exception e) {
throw new RuntimeException(e);
}
}
// Mocked methods
}
Но Java жалуется, что супер-это не первое утверждение.
Мой обходной путь:
public class MyClassMock extends MyClass {
public static MyClassMock construct() {
try {
return new MyClassMock();
} catch (Exception e) {
throw new RuntimeException(e);
}
}
public MyClassMock() throws Exception {
super(0);
}
// Mocked methods
}
Является ли это лучшим обходным путем? Почему Java не позволяет мне сделать первое?
Моя лучшая догадка относительно "why" заключается в том, что Java не хочет, чтобы я имел сконструированный объект в потенциально противоречивом состоянии... однако, делая глумление, я не забочусь об этом. Кажется, я должен быть в состоянии сделать это выше... или, по крайней мере, я знаю, что вышесказанное безопасно для моего случая... или кажется, что так и должно быть в любом случае.
Я переопределяю все методы, которые я использую из тестируемого класса, поэтому нет никакого риска, что я использую неинициализированные переменные.
В чем разница между ошибкой и запросом на изменение в MSF для CMMI?
В настоящее время я оцениваю шаблон процесса MSF for CMMI под TFS для использования в моей команде разработчиков, и у меня возникли проблемы с пониманием необходимости отдельных типов рабочих элементов запроса на ошибку и изменение.
Я понимаю, что полезно уметь различать ошибки (errors) и запросы на изменение (changing requirements) при создании отчетов.
Однако в нашей текущей системе мы имеем только один тип запроса на изменение и просто используем поле, чтобы указать, является ли это ошибкой, изменением требований и т. д. (Это поле можно использовать для построения запросов отчетов).
Каковы преимущества наличия отдельного рабочего процесса для ошибок?
Меня также смущает тот факт, что разработчики могут отправлять работу против ошибки или запроса на изменение, я думал, что предназначенный рабочий процесс был для ошибок, чтобы генерировать запросы на изменение, на которые ссылается разработчик при внесении изменений.
Memcached предел куска
Почему существует жестко заданный предел куска (.5 Мег после сжатия) в memcached ? Кто-нибудь перекомпилировал их, чтобы поднять его? Я знаю, что не должен посылать большие куски, как это вокруг, но эти дополнительные тяжелые куски случаются для меня время от времени и сеют хаос.
Как вы используете переменную в xsl при попытке выбрать узел?
Я бы подумал, что это будет легко найти в Google, но я был неуспешен.
Я хочу назначить переменной значение из атрибута (легко до сих пор), а затем использовать эту переменную для выбора другого узла на основе значения этого атрибута.
Пример:
<xsl:variable name="myId" select="@id" />
<xsl value-of select="//Root/Some/Other/Path/Where[@id='{@myId}']/@Name />
Это не работает. Если я заменю {@myId} значением, которое находится в переменной, то она действительно найдет правильный узел,но не будет ничего делать таким образом. Я уверен, что что-то упускаю, или, возможно, есть другой способ сделать это.
Контекст заключается в том, что есть связанные данные под разными узлами верхнего уровня, которые используют одно и то же значение идентификатора, поэтому мне нужно получить связанные узлы в моем шаблоне.
Rational Purify не удается перейти к утечкам памяти
Поэтому моя компания использует восхитительно ошибочную программу Rational Purify (как плагин для Microsoft Visual Developer Studio) для управления утечками памяти. Программа соизволила позволить вам нажать на утечку памяти после того, как вы столкнулись с ней, а затем перейти к строке, на которой происходит утечка.
К сожалению, Purify неисправен, и Purify не будет прыгать в место, где произошла утечка, он только упоминает класс и метод, в котором происходит утечка. К сожалению, иногда это так же полезно, как нанять гида, чтобы помочь вам охотиться на медведей и заставить его указать на лес и сказать вам, что там есть медведи.
У кого-нибудь с опытом Purify есть идеи, как я могу исправить эту проблему или иметь хорошее руководство, чтобы посмотреть?
Числовой ввод данных в WPF
Как вы обрабатываете ввод числовых значений в WPF приложениях?
Без элемента управления NumericUpDown я использую TextBox и обрабатываю его событие PreviewKeyDown с помощью кода ниже, но это довольно уродливо.
Кто-нибудь нашел более изящный способ получить числовые данные от пользователя, не полагаясь на сторонний элемент управления?
private void NumericEditPreviewKeyDown(object sender, KeyEventArgs e)
{
bool isNumPadNumeric = (e.Key >= Key.NumPad0 && e.Key <= Key.NumPad9) || e.Key == Key.Decimal;
bool isNumeric = (e.Key >= Key.D0 && e.Key <= Key.D9) || e.Key == Key.OemPeriod;
if ((isNumeric || isNumPadNumeric) && Keyboard.Modifiers != ModifierKeys.None)
{
e.Handled = true;
return;
}
bool isControl = ((Keyboard.Modifiers != ModifierKeys.None && Keyboard.Modifiers != ModifierKeys.Shift)
|| e.Key == Key.Back || e.Key == Key.Delete || e.Key == Key.Insert
|| e.Key == Key.Down || e.Key == Key.Left || e.Key == Key.Right || e.Key == Key.Up
|| e.Key == Key.Tab
|| e.Key == Key.PageDown || e.Key == Key.PageUp
|| e.Key == Key.Enter || e.Key == Key.Return || e.Key == Key.Escape
|| e.Key == Key.Home || e.Key == Key.End);
e.Handled = !isControl && !isNumeric && !isNumPadNumeric;
}
Есть ли реальная польза от использования J#?
Я только что видел комментарий с предложением J#, и это заставило меня задуматься... существует ли реальное, полезное использование J# вместо Java? Итак, я чувствую, что единственная причина, по которой вы даже подумали бы использовать J#, заключается в том, что руководство постановило, что компания должна прыгнуть на подножку Java... и подножка .NET. Если вы используете J#,, вы фактически теряете самое большое преимущество выбора Java... богатая кросс-платформенная поддержка. Конечно, есть Mono, но это не так богато поддерживается или полнофункционально, верно? Я помню, что слуховые формы не полностью (возможно, вообще) поддерживаются.
Я не пытаюсь bash .NET здесь, я просто говорю, что если вы собираетесь идти по маршруту Microsoft, почему бы просто не использовать C#?, если вы собираетесь идти по маршруту Java, почему бы J# не войти в картину?
Я надеюсь найти здесь несколько реальных случаев, поэтому, пожалуйста, особенно отвечайте, если вы ACTUALLY использовали J# в проекте REAL и почему.
В ASP.NET MVC я сталкиваюсь с ошибкой неправильного типа при отображении пользовательского элемента управления с правильным типизированным объектом
Я сталкиваюсь с ошибкой формы: "элемент модели, переданный в словарь, имеет тип FooViewData, но этот словарь требует элемента модели типа bar", хотя я передаю объект правильного типа (bar) для типизированного пользовательского элемента управления.
Веб-службы на основе документов или RPC
Я нутром чувствую, что веб-сервисы на основе документов предпочтительнее на практике - это опыт других людей? Их легче поддерживать? (Я заметил, что SharePoint использует любой для "document type" в своем интерфейсе WSDL, я думаю, что это делает его документальным).
Кроме того-теперь люди предлагают услуги типа WSDL и Rest для одной и той же функциональности? WSDL популярен для генерации кода, но для таких интерфейсов, как PHP и Rails, они, похоже, предпочитают rest.
- «
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
- 91
- 92
- 93
- 94
- 95
- 96
- 97
- 98
- 99
- 100
- 101
- 102
- 103
- 104
- 105
- 106
- 107
- 108
- 109
- 110
- 111
- 112
- 113
- 114
- 115
- 116
- 117
- 118
- 119
- 120
- 121
- 122
- 123
- 124
- 125
- 126
- 127
- 128
- 129
- 130
- 131
- 132
- 133
- 134
- 135
- 136
- 137
- 138
- 139
- 140
- 141
- 142
- 143
- 144
- 145
- 146
- 147
- 148
- 149
- 150
- 151
- 152
- 153
- 154
- 155
- 156
- 157
- 158
- 159
- 160
- 161
- 162
- 163
- 164
- 165
- 166
- 167
- 168
- 169
- 170
- 171
- 172
- 173
- 174
- 175
- 176
- 177
- 178
- 179
- 180
- 181
- 182
- 183
- 184
- 185
- 186
- 187
- 188
- 189
- 190
- 191
- 192
- 193
- 194
- 195
- 196
- 197
- 198
- 199
- 200
- 201
- 202
- 203
- 204
- 205
- 206
- 207
- 208
- 209
- 210
- 211
- 212
- 213
- 214
- 215
- 216
- 217
- 218
- 219
- 220
- 221
- 222
- 223
- 224
- 225
- 226
- 227
- 228
- 229
- 230
- 231
- 232
- 233
- 234
- 235
- 236
- 237
- 238
- 239
- 240
- 241
- 242
- 243
- 244
- 245
- 246
- 247
- 248
- 249
- 250
- 251
- 252
- 253
- 254
- 255
- 256
- 257
- 258
- 259
- 260
- 261
- 262
- 263
- 264
- 265
- 266
- 267
- 268
- 269
- 270
- 271
- 272
- 273
- 274
- 275
- 276
- 277
- 278
- 279
- 280
- 281
- 282
- 283
- 284
- 285
- 286
- 287
- 288
- 289
- 290
- 291
- 292
- 293
- 294
- 295
- 296
- 297
- 298
- 299
- 300
- 301
- 302
- 303
- 304
- 305
- 306
- 307
- 308
- 309
- 310
- 311
- 312
- 313
- 314
- 315
- 316
- 317
- 318
- 319
- 320
- 321
- 322
- 323
- 324
- 325
- 326
- 327
- 328
- 329
- 330
- 331
- 332
- 333
- 334
- 335
- 336
- 337
- 338
- 339
- 340
- 341
- 342
- 343
- 344
- 345
- 346
- 347
- 348
- 349
- 350
- 351
- 352
- 353
- 354
- 355
- 356
- 357
- 358
- 359
- 360
- 361
- 362
- 363
- 364
- 365
- 366
- 367
- 368
- 369
- 370
- 371
- 372
- 373
- 374
- 375
- 376
- 377
- 378
- 379
- 380
- 381
- 382
- 383
- 384
- 385
- 386
- 387
- 388
- 389
- 390
- 391
- 392
- 393
- 394
- 395
- 396
- 397
- 398
- 399
- 400
- 401
- 402
- 403
- 404
- 405
- 406
- 407
- 408
- 409
- 410
- 411
- 412
- 413
- 414
- 415
- 416
- 417
- 418
- 419
- 420
- 421
- 422
- 423
- 424
- 425
- 426
- 427
- 428
- 429
- 430
- 431
- 432
- 433
- 434
- 435
- 436
- 437
- 438
- 439
- 440
- 441
- 442
- 443
- 444
- 445
- 446
- 447
- 448
- 449
- 450
- 451
- 452
- 453
- 454
- 455
- 456
- 457
- 458
- 459
- 460
- 461
- 462
- 463
- 464
- 465
- 466
- 467
- 468
- 469
- 470
- 471
- 472
- 473
- 474
- 475
- 476
- 477
- 478
- 479
- 480
- 481
- 482
- 483
- 484
- 485
- 486
- 487
- 488
- 489
- 490
- 491
- 492
- 493
- 494
- 495
- 496
- 497
- 498
- 499
- 500
- 501
- 502
- 503
- 504
- 505
- 506
- 507
- 508
- 509
- 510
- 511
- 512
- 513
- 514
- 515
- 516
- 517
- 518
- 519
- 520
- 521
- 522
- 523
- 524
- 525
- 526
- 527
- 528
- 529
- 530
- 531
- 532
- 533
- 534
- 535
- 536
- 537
- 538
- 539
- 540
- 541
- 542
- 543
- 544
- 545
- 546
- 547
- 548
- 549
- 550
- 551
- 552
- 553
- 554
- 555
- 556
- 557
- 558
- 559
- 560
- 561
- 562
- 563
- 564
- 565
- 566
- 567
- 568
- 569
- 570
- 571
- 572
- 573
- 574
- 575
- 576
- 577
- 578
- 579
- 580
- 581
- 582
- 583
- 584
- 585
- 586
- 587
- 588
- 589
- 590
- 591
- 592
- 593
- 594
- 595
- 596
- 597
- 598
- 599
- 600
- 601
- 602
- 603
- 604
- 605
- 606
- 607
- 608
- 609
- 610
- 611
- 612
- 613
- 614
- 615
- 616
- 617
- 618
- 619
- 620
- 621
- 622
- 623
- 624
- 625
- 626
- 627
- 628
- »