- #524
- add tests of `DropDownList` and `ListBox` HTML helpers
- extend tests of `<select/>` tag helper
- add scenario to a functional test
New `HtmlHelperSelectTest` does not cover everything. In future (see #453):
- use non-`null` `optionLabel` and `htmlAttributes` arguments
- confirm value sources and their priorities
- mock an `IHtmlGenerator` and confirm how it is called
- mock an `IHtmlHelper` and confirm how extension methods call that
services
* Added WithControllersFromServiceProvider that replaces the default
controller activator with a service based one.
* Move activation to DefaultControllerFactory
* Modify [Activate] behavior so that it no longer activates services. Use
[FromService] attribute to hydrate services
Fixes#1707
Attribute route link generation will now have a slight preference for
entries that can use ambient values (vs ignoring an ambient value). This
means that areas will be more 'sticky' with regard to link generation
without the need to specify a better Order.
This change makes the attribute route capable of responding to updates in
the action descriptor collection.
The change moves the actual route implementation to InnerAttributeRoute.
AttributeRoute now wraps an InnerAttributeRoute - when processing a route,
AttributeRoute will now check with action descriptor collection if its
InnerAttributeRoute is still 'current' and rebuild it if necessary.
This is a major refactor of how IBinderMetadata interacts with model
binders and value providers. We're doing this to support better
extensibility for metadata in ApiExplorer.
You'll notice a bunch of deleted code in DefaultApiDescriptionProvider
that maps metadata marker interfaces to a fixed list of Api sources. This
is replaced now with IBindingSourceMetadata - which also replaces the
hierarchy of marker interfaces. Now user code can create an arbitrary
binding source and have a consistent API for model-binders,
value-providers and full-visibility in ApiExplorer as
well.
Additonally, there's some error checking in place that better enforces the
constraints we already have in the system. IE you can't create a 'greedy'
model binder that uses value-provider data.
Two additional enhancements are planned for followup PRs:
1. Add a BindingSource property to model-metadata. This will remove some
duplication, but I want to delay it because it would touch another 10 or
so files.
2. Add an extensibility interface for our 'special' model binders like the
file binder so these can show up in ApiExplorer as well.
1. Creates a filter called FormatFilter. This will look at the format parameter if present
in the route data or query data and sets the content type in ObjectResult
2. It adds new options called FormatterOptions, that contains the map of format to content tyepe
3. A method in MVC options to add the formatter mapping
- #439 (2 of 3)
- correct namespaces
- correct `Resources` class and member names; add new resources
- add `RequestServices` property to `ClientModelValidationContext`
- adjust to modern `IUrlHelper` API
- add `IClientModelValidator` support in `DataAnnotationsModelValidator`
- move previously-unused `StringSplit()` to `RemoteAttribute` and rename
- rewrite `RemoteAttributeTest`
- improve test method names
Reduce number of `[Remote]` constructor overloads
- remove `AreaReference` enum and related `[Remote]` constructor overload
- use `null` or empty `string` as explicit reference to the root area
- generally reduce parameter validation; match `UrlHelper`
Cleanup
- correct Engineering Guidelines violations
- especially: add doc comments
- correct spelling error in `_additonalFieldsSplit`
nits:
- minimize `null` checks in `AdditionalFields`
- make `GetClientValidationRules` `virtual`; some subclasses use `new` today
- add tests of `DataAnnotationsModelValidator.GetClientValidationRules()`
- remove `builder.ToString()` calls since it appears
https://roslyn.codeplex.com/workitem/246 has been resolved or Moq has
worked around that issue.
Changes here are all focused around MaxModelErrors on
ModelStateDictionary.
MaxAllowedErrors now defaults to 200 (same as options). This means that
constructing a new ModelStateDictionary with the default constructor will
use this default. There's a new constructor for creating a
MaxAllowedErrors with a non-default value.
The ControllerActionArgumentBinder is now responsible for setting the
value from options onto ActionContext.ModelState. This results in better
layering and guarantees the option is respected if someone uses
extensibility to call model binding.
ModelStateDictionary.CanAddErrors is renamed to MaxErrorsReached. We
wanted to change the behavior of this property, but realized that it's
very useful inside the model validation code, so opted to renamed.
There's also a bunch of doc cleanup inside ModelStateDictionary to
simplify things and improve clarity.
This change allows you to set global defaults for ApiExplorer on the
ApplicationModel. Additionally, we're more lenient about configuring
ApiExplorer = on with conventional routing. If you turn on ApiExplorer at
the application level, we'll just skip over all conventionally routed
controllers instead of throwing.
This is a cleanup PR to improve the common usage of
ModelMetadata.Properties.
We found placed in code where both .Count and the ability to index by
property name would be useful. I was able to cascade this and simplify the
ModelBindingContext as well.
- remove `explicitValue` variables from two `DefaultHtmlGenerator` methods
This follows up a [code review comment](https://github.com/aspnet/Mvc/pull/1834/files#r23120381)
related to `DefaultHtmlGenerator.GenerateCheckBox()`. Same issue appears in
`DefaultHtmlGenerator.GenerateRadioButton()`.
@pranavkm -
> Also a different variable name? There's a parameter isExplicitValue that
> follows which always has a false value. Reusing this name seems messy.
My response to that comment should not be repeated. @pranavkm was correct
that the only issue here is naming. `explicitValue` was too easily
confused with the `isExplicitValue` argument used a few lines later.
They had separate purposes: `explicitValue` related to the "checked"
attribute while `isExplicitValue` relates to the "value" attribute.
This change makes ApiDescription and ApiParameterDescription aware of all
of the new features we built into model binding for enhanced DTO support
(uber-binding).
The main change is that instead of sticking just to the declared
parameters on the action itself, we now traverse model metadata and break
the parameters down based on their logical data source.
This means that a model like the below will yield 3 parameters:
public class ProductChangeCommandDTO
{
public int Id { get; set; }
[FromBody]
public ProductDetails Changes { get; set; }
[FromQuery]
public string AdminComments { get; set; }
[FromServices]
public IProductRepository Repository { get; set; }
}
The 'Repository' will be hidden, as it's not related to user input.
Additionally, we treat different sources differently. In the
above example, 'Changes' is from the body and will be treated as a
leaf-node.
However if you use nested DTOs that are bound from the query string (using
[FromQuery]) or similar, we'll recursively explore to find as much
structure as possible.
This information is combined with data from the route template to give a
much more complete picture than we ever could in the past for parameters,
especially when DTO/Command pattern is used.
- add a couple more exclusions to .gitignore (recent VS additions)
- remove `<ProjectExtensions/>` elements
- update files that don't have the correct output directories
- remove dangling PrecompilationWebSite.kproj file
This change moves controller creation to the stage immediately before
model binding. The controller will be disposed/released before Resource
Filters run their 'OnResourceExecuted' method. Previously the controller's
lifetime surrounded all filter invocation.
Additionally, the Controller property is now gone from ActionContext, and
is moved to the 4 filter contexts that should have access to it
Action*Context and Result*Context.
This is a major change to how we handle the scenario where a controller is
a filter. We want to change the lifetime of the controller object, by
scoping it around action filters and result filters. This means that a
controller class can only implement action filters and result filters.
To implement #384 - we're creating a delegating filter class
'ControllerFilter' which will forward calls to the implementation of the
controller. This is discovered in the controller model and added to the
filter collection. This filter is removable as an opt-out of this feature.
The ControllerFilter only implements action filter and result filter, so
the new restriction about filter types on Controller is in place. A future
change will move the instantiation of the controller to after resource
filters.
This is a major change to how we handle the scenario where a controller is
a filter. We want to change the lifetime of the controller object, by
scoping it around action filters and result filters. This means that a
controller class can only implement action filters and result filters.
To implement #384 - we're creating a delegating filter class
'ControllerFilter' which will forward calls to the implementation of the
controller. This is discovered in the controller model and added to the
filter collection. This filter is removable as an opt-out of this feature.
The ControllerFilter only implements action filter and result filter, so
the new restriction about filter types on Controller is in place. A future
change will move the instantiation of the controller to after resource
filters.
This change adds support for our three-valued logic to the default value
handling part of the MutableObjectModelBinder.
The issue is that we want to look up a default value when a 'greedy' model
binder returns true but doesn't find a value.
We also don't want to call the property setter unless there is:
1). A value from model binding OR
2). A default value
In general all properties are get/set so filters can change them.
- some validate for not-null
- where we use services it's get/set also
Services are resolved in the Execute method if not provided.
A few more ActionResults that return a body have the ability to set a
status code now (optional).
- part II of #1253
- an expected case in template .cshtml files
- expression has name `""`; led to `ArgumentException` in `ModelExpression`
- test `@Model` and `@model.Property` in unit and functional tests
- update baselines to match
nits:
- remove a few unecessary `@`s in .cshtml files
- correct field names & ids in ProductList.cshtml (`foreach` confuses MVC)
- led to correct valiation attributes as well
The action invoker no longer needs access to model metadata or to the
input formatter selector. This change removes the same as constructor
parameters and cleans up tests which use the invoker.
This is a new filter stage that surrounds the existing model binding,
action, and result parts of the pipeline. Resource Filters run after
Authorization Filters.
The other major change is to support one of the primary scenarios for
Resource Filters. We want a filter to be able to modify the inputs the
model binding (formatters, model binders, value providers, etc) -- this
means that those changes need to be held on a context object and preserved
so that they can be used in the controller.
So, IActionBindingContextProvider is removed - the ActionBindingContext
will be created by the invoker. For now it will be part of the action
context.
- StyleCop working again (handles C# 6.0 additions) though only locally for me
- disable some new rules:
- ConstFieldNamesMustBeginWithUpperCaseLetter
- InstanceReadonlyElementsMustAppearBeforeInstanceNonReadonlyElements
- StaticReadonlyElementsMustAppearBeforeStaticNonReadonlyElements
- StaticReadonlyFieldsMustBeginWithUpperCaseLetter
- PrefixCallsCorrectly
- correct remaining violations
- lots of long lines for example
- use more `var`; some manual updates since StyleCop doesn't check seemingly-unused blocks
nit: remove new trailing whitespace (was paranoid about adding it w/ fixes)
The ParameterModel and ParameterDescriptor have had a notion of
optionality for a while now, even though all parameters are treated as
'optional' in MVC.
This change removes these settings. Optionality for overloading in webapi
compat shim is reimplemented via a new binder metadata.
This change adds an interface for the functionality provide by
RouteConstraintAttribute, and adds support for configuration constraints
on actions/action-model.
1. Updated ViewComponent to exposes similar properties to the existing ones in controller where
appropiate. We've left out Resolver for being a bad pattern (just inject the dependency on the constructor
or use Context.RequestServices to access it if needed) and Response as although available through the Context
property, it shouldn't be used/modified in a ViewComponent.
2. Updated ViewViewComponentResult to follow a similar pattern as ViewResult where the constructor is
parameterless and elements like ViewEngine are resolved during execution if the user does not set the
associated property on the object.
3. Updated ExecuteAsync in JsonViewComponentResult to remove the unnecessary pragma and async keyword from the
signature and to use Task.FromResult(true) instead.
4. Cleaned up ViewViewComponentResult tests.
- #EngineeringDay
- license present but incorrect in just a few files
- skip generated files such as Resources.Designer.cs and files under
test\Microsoft.AspNet.Mvc.Razor.Host.Test\TestFiles\Output
- #EngineeringDay
- VS does not yet format auto-properties nicely; reverted what it did
Also revert changes under
- test/Microsoft.AspNet.Mvc.Razor.Host.Test/TestFiles
- #EngineeringDay
- Total replaced: 660 Matching files: 270 in *.cs
- Total replaced: 250 Matching files: 32 in all other files
- Total replaced: 22 Matching files: 8 in a few stragglers
Did not change files under following directories
- test\Microsoft.AspNet.Mvc.Razor.Host.Test\TestFiles\Output
- test\Microsoft.AspNet.Mvc.FunctionalTests\compiler\resources
- test\WebSites\TagHelpersWebSite
(Razor generates trailing whitespace in a case or two)
For each of these TODOs:
- If there's an active bug tracking the work, and the TODO provides
something of value, I left it and standardized the formatting. I also
added comments to the bug.
- If the comment provided no value (implement feature X when we do feature
X), I deleted it with impunity.
- If the comment was stale (won't fix or just out of date), then we
removed it uncerimoniously.
There was a single TODO that was actually actionable, so I enabled that
test.
This change enables some compatibility scenarios with MVC 5 by expanding
the set of legal ways to configure attribute routing. Most promiently, the
following example is now legal:
[HttpPost]
[Route("Products")]
public void MyAction() { }
This will define a single action that accepts POST on route "Products".
See the comments in #1194 for a more detailed description of what changed
with more examples.
Rather than throwing here, this does what routing does. If request
services aren't set, we just create our own scope.
This will NOT create an extra scope if request services are already set.
- clean up "the the" in XML comments
- simplify refactoring VS did when I renamed `GetHtmlHelperForViewData()`
- fix existing issue in `HtmlHelperCheckboxTest.CheckBoxReplacesUnderscoresInHtmlAttributesWithDashes()`
(was using a `HtmlHelper<ViewDataDictionary<TestModel>>`)
This is the MVC companion to https://github.com/aspnet/Routing/pull/122
As routing flows, routes replace the route data and mutate a copy. This
allows users to make changes that dirty the data without affecting
undesired state changes.
We also add the 'next' router for diagnostic purposes.
- use new `ModelMetadata.HtmlEncode` property in HTML helpers
- specifically in default HTML display and editor object templates (e.g.
`@Html.DisplayFor()`) when value is non-`null` and the template is invoked
with template depth greater than 1
- similar to MVC 5.2 commit [2b12791aee4f](https://aspnetwebstack.codeplex.com/SourceControl/changeset/2b12791aee4ffc56c7928b623bb45ee425813021)
nits:
- remove dupe `null` check in `DefaultDisplayTemplates.ObjectTemplate()`
- move backing fields initialized with constants together in `ModelMetadata`
The change here is to always use the provided formatter, instead of using
it as a fallback. This is much less surprising for users.
There are some other subtle changes here and cleanup of the tests, as well
as documentation additions.
The primary change is that we still want to run 'select' on a formatter
even if it's the only one. This allows us to choose a content type based
on the accept header.
In the case of a user-provided formatter, we'll try to honor the best
possible combination of Accept and specified ContentTypes (specified
ContentTypes win if there's a conflict). If nothing works, we'll still run
the user-provided formatter and let it decide what to do.
In the case of the default (formatters from options) we do conneg, and if
there's a conflict, fall back to a global (from services)
JsonOutputFormatter - we let it decide what to do.
This should leave us with a defined and tested behavior for all cases.
- `null` checks can generally be removed but in one case needed to
special-case metadata for `object`
nit: remove duplicate empty `string` check in
`ExpressionMetadataProvider.FromStringExpression()`
- ensure correct `ViewData.ModelState` value in a `RazorPage` instance
- let view components inherit `ViewData.Model` from surrounding context
- do not create an isolated `ViewDataDictionary<TModel>` in one HTML helper
- allows previous `ViewDataDictionary<TModel>` constructor to be `internal`
- also add comments for that constructor
- change two `ViewDataDictionary` copy constructor calls to avoid uselessly
copying `Model` and related information from source
- `ViewDataDictionary<TModel>` constructors now pass `typeof(TModel)` to base
`protected` constructors
- move type compatibility checks into base `ViewDataDictionary`
- remove `ViewDataDictionary<TModel>.ModelMetadata` override
- don't retrieve `ModelMetadata` twice in a single constructor invocation
- remove newly-unused `protected` properties and use `private` fields in copy
constructors
Address longstanding problems found (see #1466)
- avoid reusing `ModelMetadata` after `Model` value changes
- reset `ModelMetadata` backing field in `Model` setter
- `Model` and `ModelMetadata.Model` could previously get out of sync
- carry `ModelMetadata` forward from an outer scope only if `Model` matches
- previously two scopes could have different `Model` values but share their
`ModelMetadata` (and `ModelMetadata.Model`)
- related to previous item but didn't require `Model` setting; switching
to a property of the same type as containing `Model` was enough
- avoid NRE if `ViewDataDictionary<int>.Model` is read before it's written
- problem affected all non-`Nullable` value types
- `ViewDataDictionary.ModelMetadata` setter should throw if value is `null`
nits:
- add and reword doc and code comments
- `ViewDataDictionary<TModel>` constructors should only inherit base's
parameter descriptions; have more information in the derived class
- make a few `ViewDataDictionary` properties get-only
- clean up `using` statements in `ViewDataDictionary<TModel>`
- make two constructors `internal`
This change adds the concept of a full-name to viewcomponents. View
components can be invoked using either the short name or long name. If the
provided string contains a '.' character, then it will be compared against
full names, otherwise it will be matched against short names only.
The short name is used for view lookups.
If the name is explicitly set via ViewComponent attribute, then the full
name is the name provided. The short name is the portion of the name after
the last '.'. If there are no dots, then the short name and full name are
the same.
If the name is not set explicitly, then it is inferred from the Type and
namespace name. The short name is the Type name, minus the 'ViewComponent'
suffix (if present). The full name is the namespace of the defining class,
plus the short name.
Taking the suggestion here to move these to a sub-object. This is future
proof in the event that we need to capture more data for ApiExplorer, and
reads better.
ViewComponents and Controllers now follow the same rules exactly for what
types of classes they can be.
Also corrected a bug in a test for controllers. Closed-generic types can
be controllers, the test was wrong.
never that for `object`
- `ViewDataDictionary<TModel>.ModelMetadata` was for `object` after base
copy constructor got value from `ViewDataDictionary<object>`
- problem led to #1426 symptoms
- with copy constructor leaving `base.ModelMetadata==null` more often,
`ViewDataDictionary<TModel>.ModelMetadata` usually tracks `TModel` if
`Model==null`
nit:
- fix existing comment in main `ViewDataDictionary` copy constructor
- This involved adding the StringComparer.OrdinalIgnoreCase comparer to the TagBuilder's Attributes dictionary.
- Added tests to validate that all methods that made use of TagBuilder.Attributes abide by the new ignore case mechanic.
- Added two sets of tests to validate the new functionality of Object => Dictionary HTML helper tests.
- Modified a functional test that utilizes HTML Helpers to provide same attribute-different case objects.
- Fixed existing HTML helper tests to account for new ordering of attrbutes (dictionary no longer adds key value pairs, it sets them).
#1328
This also comes with a rename of the namespace
Microsoft.AspNet.Mvc.ApplicationModel to
Microsoft.AspNet.Mvc.ApplicationModels.
Also tuned up some parameter and variable names for increased
understandability.
This change modifies the default parameter binding behavior for an
ApiController to use the WebAPI rules.
'simple types' default to use route data or query string
'complex types' default to use the body (formatters)
Adds ModelBindingAttribute to enabled model binding
- #704 part 2 of 2
- change `@Html.Id()` to sanitize return value; was identical to `@Html.Name()`
Copied `TagBuilder.CreateSanitizedId()` and `TagBuilder.Html401IdUtil` from MVC 5.2
- except this `CreateSanitizedId()` returns a valid identifier if first `char` is not a letter
- e.g. "[0].Name"
nits:
- expand variable names, use lots of `var`, put `public` members first
- add doc comments for `CreateSanitizedId()`
Note users will be able to apply different sanitization once we fix#1188.
- make a few more methods available as `internal static` in `DefaultHtmlGenerator`
- remove `IHtmlGenerator.GenerateOption()`; now `internal static`
nits:
- add `IHtmlGenerator.IdAttributeDotReplacement`
- move `DefaultHtmlGenerator.IdAttributeDotReplacement` after constructor
- move `HtmlHelper.ActionLink()` below static methods
- move newly-`internal` methods together in `DefaultHtmlGenerator`
- correct placement of `DefaultHtmlGenerator.GetValidationAttributes()` comment
- part of #1243 (kind-of)
- mostly copied from `HtmlHelper` but refactored to
- consistently take a `ViewContext` parameter and return a `TagBuilder`
- provide `GenerateActionLink()` and `GenerateRouteLink()`
- provide a separate `GenerateHiddenForCheckBox()`, allowing
`GenerateCheckBox()` to return a `TagBuilder`
- `GenerateForm()`'s `method` parameter is a `string`, not `FormMethod`
nits: format document, consistent line wrapping, variable name changes, ...
Fix: The MvcOptions takes in a list of ExcludeFromValidationDelegate (Func<Type,bool>). This func verifies if the type is excluded in validation or not.
- #965
- test call-throughs from `Html.Editor[For]()` to inner `IHtmlHelper`
- add another parameter to `DefaultTemplatesUtilities.GetHtmlHelper()`
nit: reorder dictionaries at the top of `TemplateRenderer` slightly
1) Expose the simplified relative path template by cleaning up constraints, optional and catch all tokens from the template.
2) Expose the parameters on the route template as API parameters.
3) Combine parameters from the route and the action descriptor when the parameter doesn't come from the body. #886 will refine this.
4) Expose optionality and constraints for path parameters. Open question: Should we explicitly expose IsCatchAll?
Html.PartialAsync
* Introducing StringCollectionTextWriter to buffer the contents of
PartialAsync
* Ensure DecorateWriter is called for partial views
Fixes#1266
- Sealed the ModelExpression.
- We use the stringified version of the ModelExpression type name to detect ModelExpression properties on TagHelpers. This is so the MvcRazorHost can work in tooling and in runtime.
- Created a GeneratedTagHelperAttributeContext to represent the specific stringified versions of the ModelExpression assets.
- Created an MvcTagHelperAttributeValueCodeRenderer to modify rendering of ModelExpression properties.
#1241
- includes new `RazorPage<TModel>.CreateModelExpression<TValue>()` method
- #1240
nit:
- regenerating the resources reordered Microsoft.AspNet.Mvc.Core's Resources.designer.cs
IActionConstraint follows a provider model similar to filters. The
attributes that go on actions/controllers can be simple metadata markers,
the 'real' constraint is provided by a set of configurable providers. In
general the simplest thing to do is to be both an
IActionConstraintMetadata and IActionConstraint, and then the default
provider will take care of you.
IActionConstraint now has stages based on the Order property. Each group
of constraints with the same Order will run together on the set of
actions. This process is repeated for each value of Order until we run out
of actions or run out of constraints.
The IActionConstraint interface is beefier than the equivalent in legacy
MVC. This is to support cooperative coding between sets of constraints
that know about each other. See the changes in the sample, which implement
webapi-style overloading.
1) Implemented FilePathResult to efficiently return files from disk.
2) Implemented FileStreamResult to return content from a stream.
3) Implemented FileContentResult to return content from a byte array.
This change removes WebAPI-style method parameter overloading and the
automatic mapping of 'unnamed' actions based on method names. For all
practicaly purposes, this change restores the MVC5 behavior for action
selection.
WebAPI-style overloading will be brought back in the future via a set of
opt-in constructs.
This adds support for attributes which interact with reflected model.
These conventions are applied after all of our built-in constructs so that
you can see and modify the results.
1. Support multiple [Http*] attributes on an action.
2. Support multiple [Route] attributes on a controller and on an action.
3. Support creating multiple attribute routes using [AcceptVerbs("...", Route = "...")]
4. Detect attribute routed actions during action discovery and return one action per [Http*],
[Route] or [AcceptVerbs] attribute found on the method when there is at least one valid attribute route.
5. Merge all the HTTP methods of [Http*] and [AcceptVerbs] attributes in a method during
action discovery when there are no valid attribute routes defined on the action.
6. Build one action descriptor per controller [Route] + action [Http*], [AcceptVerbs]
or [Route] combination in an action.
7. Disallow the use of attributes that do not implement IActionHttpMethodProvider and
IRouteTemplateProvider simultaneously in methods that define attribute routed
actions and throw an exception during startup.
8. Disallow mixing attribute routed and non attribute routed actions on the same method
and throw an exception during startup.
1. Changed attribute usage on RouteAttribute.
2. Added a test on action discovery to ensure that actions with [Route] get discovered as
attribute routed actions.
3. Added a test on reflected action descriptor provider to ensure that an action with [Route] on
the controller and [Route] on the action results in an action that allows any Http method.
1. Added tests that cover parameters in actions.
2. Added tests that cover building the reflected application model.
3. Added tests that cover attribute routed action constraints and default values.
4. Added tests that cover conventionally routed action constraints and default values.
5. Refactored and cleaned up ReflectedActionDescriptorProvider. All the refactors consist
of extracting blocks of code to separate methods to better display the flow when building
the action descriptors.
1. Added support for Name in attribute routing. Name can be defined using [RouteAttribute]
and the different Http*Attributes, for example [HttpGet].
2. Names defined on actions always override names defined on the controller.
3. Actions with a non empty template don't inherit the name from the controller. The name
is only inherited from the controller when the action template is null or empty.
4. Multiple attribute routes with different templates and the same name are not allowed.
Stephen Halter
Hao Kung
Ajay Bhargav Baaskaran
Pranav K
Praburaj
Doug Bunting
Ryan Nowak
sornaks
Yishai Galatzer
Kiran Challa
Anthony Sneed
Youngjune Hong
N. Taylor Mullen
Mugdha Kulkarni
Harsh Gupta
Kirthi Krishnamraju
Kiran Challa
Chris Ross
Bruce Bowyer-Smyth
SonjaKhan
Saar Cohen
ianhong
Mugdha Kulkarni
Victor Hurdugaci
kanchanm
jacalvar
David Fowler
Murat Girgin
Wei Wang