RockResolve

My feedback

  1. 278 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    10 comments  ·  1. BreezeJS Feature Suggestions  ·  Flag idea as inappropriate…  ·  Admin →

    A quick update for this request:

    We’re probably 50% there today, but hope to get to 80% soon. This is certain to get done, but we’re just not there yet.

    RockResolve commented  · 

    Added my own answer refinement. Default displayName on client converting "PascalCaseFieldName" or "camelCaseFieldName" to "Upper Case Field Name".

    This means a lot less EF annotation of DisplayName (used by validation messages)

    RockResolve commented  · 

    I got this working (DisplayNameAttribute) using the solutions on stackoverflow
    http://stackoverflow.com/questions/16733251/breezejs-overriding-displayname.

  2. 16 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    under review  ·  6 comments  ·  1. BreezeJS Feature Suggestions  ·  Flag idea as inappropriate…  ·  Admin →
    RockResolve commented  · 

    For other readers benefit ...
    My use case was to validate my entity's foreign key against an entity that may not have been fetched from the server. I had thought the lack of async validation meant this was not practical.

    But the solution is simple:
    Create a "Fetching ..." error while the fetch is pending. Add it as a keyed validationError.
    Once the fetch completes, either update the keyed validationError if the fetch fails, or remove the keyed validationError if the fetch succeeds.

    This means the entity can't be saved until the fetch is resolved (which is what I want for my use case), and so my entity's foreign key is always validated.

  3. 385 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    under review  ·  21 comments  ·  1. BreezeJS Feature Suggestions  ·  Flag idea as inappropriate…  ·  Admin →
    RockResolve supported this idea  · 
    RockResolve commented  · 

    I have partially implemented this in my client's project.

    My project has two modes of notifying updates. In addition to the usual individual updates processed by breeze (saveChanges webApi) I also have some webApi methods that perform bulk updates. I've got this working well to let every client know of the changes, and update their viewed data.

    I have the individual saveChanges working for edits, and will shortly start on Insertions & Deletions.

    I went with Ward's approach only notifying clients of changes. This was absolutely the correct way to go as a client may never have used the record, or it may be used on a view that is not currently displayed (so I tell the VM its data is stale, so it refreshes its data when next fetched)

    I used Jeffery's code as a starting point (I am the below anonymous!). But I had to add some client VM processing code.

    RockResolve commented  · 

    I found someone who seems to have solved this with SignalR using Ward's notification only technique.

    http://www.jefferyscottswensen.com/broadcasting-breezejs-entity-changes-with-signalr/

Feedback and Knowledge Base