Ward Bell
My feedback
8 results found
-
182 votes
An error occurred while saving the comment -
341 votes
An error occurred while saving the comment Ward Bell
commented
Sorry. Just have not got to it. There is a work around (not great) and we're working higher priorities. This is an open source project. We'd welcome your attempt at it and a PR.
-
25 votes
An error occurred while saving the comment Ward Bell
commented
FWIW, I have long felt we made a fundamental error in making entityAspect a property. It should have been a getter method. Too late now though.
An error occurred while saving the comment Ward Bell
commented
Thanks for the deets. I'll take a look at the code you linked
I hasten to add that there is an easy and performant way to detect changes ... listen for property changed, either on the entity itself or on the `EntityManager`.
That's where I'd go and then to see how to drive ng-firmly from that ... if that's possible.
Events always beat watches. The problem with events is setting them up. Breeze does that for free.
I will look at your links soon.
Thanks for the dialog.
-
6 votesWard Bell
supported this idea
·
An error occurred while saving the comment Ward Bell
commented
UPDATE: I'm a TypeScript idiot. You can get the prototype from a TS class quite easily. I'll bet it's the same in ES6.
Here is some TS that you can try in the playground (http://www.typescriptlang.org/Playground) that proves it:
```
class Foo {
private _baz = 'original _baz';
get bar() { return true;}
get baz() { return 'first baz';} // type-safety placeholder; will be redefined
}// You CAN get the prototype from the class!
var x = Foo.prototype;
console.log(x);// baz has no setter at this point
let foo = new Foo();
console.log("foo.baz1:" + foo.baz); // "first baz"
foo.baz = "new value";
console.log("foo.baz2:" + foo.baz); // still "first baz"/* redefinition has a setter and is no longer configurable */
Object.defineProperty(Foo.prototype, "baz", {
get: function () { return this._baz; },
set: function(value) {this._baz = value;},
enumerable: true,
configurable: false
});// redefine `foo` with new version
foo = new Foo();
console.log("foo.baz3:" + foo.baz); // "original _baz"
foo.baz = "new _baz";
console.log("foo.baz4:" + foo.baz); // "new _baz"```
An error occurred while saving the comment Ward Bell
commented
Your comment counts.
You can add methods and properties to the ctors today. You don't have to add them to the initializer ... and I don't know why you would.
There is only a potential problem if the property has a **setter** and you do NOT want breeze to track it as an "unmapped property". Even then you can add such a property to the ctor AFTER registering with breeze client `MetadataStore`.
BTW, adding properties to a class later is kind of tricky in TS/ES6. The class constructor is not exposed by default so you can't grab it to add to the prototype.
Fear not, grasshopper! You can add a static method (in TS anyway) that exposes the ctor ... and mess with it anytime. I have no idea if the same game is viable in ES6.
I'm thinking out loud here. Given that Breeze has to rewrite the ctor anyway (in order to inject its goodness), I'm not quite sure how we're going to do this with TS or ES6 classes. We need that prototype.
Personally, when it gets funky like this, I'd chuck the class. This nonsense is one (among many reasons ... mix-ins being another) why I don't like classes and wish they had never been introduced. I was doing just fine with prototypes and I don't get the value of classes ... whereas the harm I see. Apparently I have company in Douglas Crockford.
-
35 votes
An error occurred while saving the comment Ward Bell
commented
Not to my knowledge. The execution of the LINQ query occurs outside the controller method. There is no way to inspect the results.
The only way I know to intercept the results is to execute the query yourself after applying the client's query specification ... which is no easy task.
.. or to write a custom Web API filter (for example, modify the JSON serialization filter with a custom Json.Net serialization interceptor) ... which seem like the wrong abstractions to me and would be no easy task either.
I've been thinking about an option on the BreezeEnableQuery attribute for calling back into some method in your controller that could post-process the results before sending them out of the controller, toward the client (that is, onward to the filters). I have gotten no further than speculation.
An error occurred while saving the comment Ward Bell
commented
You can get the query string from the URL programmatically with code like this:
var allUrlKeyValues = ControllerContext.Request.GetQueryNameValuePairs();
string filter = allUrlKeyValues.SingleOrDefault(x => x.Key == "$filter").Value;What you do with it is another matter.
-
932 votes
To accelerate the development of this particular feature we are seeking user support through crowdfunding.
Want to learn more? Send us an email at breezeadmin@ideablade.com and we’ll send you details on how you can participate.
Thanks for helping us make BreezeJS the best open source project on the planet!
An error occurred while saving the comment Ward Bell
commented
@aaron - why is this a requirement? It's a really iff idea to begin with. You do realize that if you ever have to add even a single field to the junction table ... a timestamp ... anything ... then the whole m-to-m collapses and you're right back to a 3-part entity implementation: left - junction - right. It's an extremely brittle EntityFramework technique that I have always avoided.
An error occurred while saving the comment Ward Bell
commented
I can assure you that we at IdeaBlade deeply appreciate the financial votes for a feature in amounts of any size. The act of opening your wallet sends a signal more powerful than a vote button. Thank you all.
An error occurred while saving the comment Ward Bell
commented
@Brian - I have to leap to the bait about JayData. "Feature Matrix". Don't make me laugh.
They don't have m-2-m "figured out". They don't have relationships of any kind ... not in the Breeze sense.
They don't have entity caching or identity map. They don't have to maintain the creation and dissolution of relationships over time. JayData has nothing comparable to the ability to fetch the Orders now, fetch the OrderDetails later, and have something wire them together automatically.
The 'm-2-m' problem is quite trivial if you don't have to do anything but return an object with an embedded related-entity array handed to you by the server. Anybody can do that. That's not what your asking for.
You want Breeze to maintain a User/Roles relationship (linked by a hidden UserRole mapping table on the server) in the same way as Breeze today maintains 1-M relationships such as Order/OrderDetails.
Maintaining relationships among entities in cache is hard ... and there is nothing in JayData to reverse engineer.
There is something we can use as a guide: our own DevForce .NET product.
An error occurred while saving the comment Ward Bell
commented
@Brian LOL! I know I'm fighting a losing battle and have lost it in fact. We have it on our backlog to do. I wish I could say when it will be done. This is REALLY hard to get right. We know that because we've done it before. Looks like we'll be doing it again.
The offer of $$ is intriguing. Nothing like money to motivate. We might just pass the hat to get this done sooner. Cheers, W
-
5 votesWard Bell
shared this idea
·
-
16 votes
An error occurred while saving the comment Ward Bell
commented
We hate to disappoint. We just don't know what to do about it. We don't understand the scenarios in which this feature would be beneficial.
For example, what do you do in a form when the user "pages" away while the async validation is in-progress? Should the user be allowed to leave or not? How would the user return if there were a problem?
How should saveChanges work? At least saveChanges is already async so we could plumb async validation through it. But do you process the save before the async validation returns? I think not. It's not acting as a validation then and if the server rejects it, you now have two competing validations for the same rule. But maybe you'd expect something different?
My point is that the problem is not as simple as firing off a validation. You have to work through the consequences. I don't know what the right thing to do is in all scenarios for all apps. I don't know where to put the hooks so that we can offer a facility that everyone can use appropriately.
We're not talking about a "fix" here. This needs real thought. We wouldn't know what to implement until we had good answers.
On the other hand, it isn't difficult for you to write application-specific async validation logic that does exactly what you want. Post your scenarios to StackOverflow and we can all work through this together. Maybe the proper implementation of a feature will become apparent when we've worked through some real use cases.
We actually have it! We should publish it.