jaydata and globals

[RainerAtSpirit]

If you compare the pages below you see that there a quite a few new globals.

$data, ARRAYACCESS, C$, DECISION …

Is there a way to avoid leaking those into the global namespace?

Rainer

jquery: http://www.spirit.de/demos/metro/ZurbV3/index.html jquery and jaydata-standalone.min: http://www.spirit.de/demos/metro/ZurbV3/jaydata.html

[robesz]

Hello Rainer,

These globals are used by the library and intended to help jaydata-based developments. We collect feedback how would developers user the library in a comfortable manner. Currently there is no way of using jaydata, where you can avoid these globals. Which are the globals you don't use in your project?

Thank you for your feedback! Bye, Robert

[RainerAtSpirit]

First I've uploaded V1.1.1 http://www.spirit.de/demos/metro/ZurbV3/jaydata1.1.1.html and most of the globals are gone, good!

In 1.1 constants like ARRAYACCESS, DECISION etc. were leaked. In an ideal world jaydata and the provider/modules would be AMD compatible and wouldn't expose any globals. That would leave it up to the developer if they want to expose it globally our not.

[PeterAronZentai]

I am not quite sure how could we get rid of $data as it is the root namespace and everything is exposed through it. Service classes generated with JaySvcUtil heavily depend on $data. Does $data leak to your expreience?

The $C and Container are a different animal, they will be moved under $data so that to not contaminate global.

[RainerAtSpirit]

Picking one global would be ok, but the name needs to be chosen wisely or at least offer a noconflict option. $data is a internal in knockout and would be a reserved $xxx in angularjs. Not saying that you can't pick it anyways for background compatible reason. Everything else like $etc. clearly shouldn't be exposed. Same is true for JaySvcUtilthat takes the OData service namespace by default. You can certainly imagine that I was suprised seeing a Microsoft global after converting a SharePoint listdata.svc :).

[PeterAronZentai]

This is a tough question. $data was picked after the relative success of $ for jQuery (jQuery has jQuery as a fallback however which we don't at this point but should have). But yes, knockout has a special meaning for $data. I could not quite get you regarding angularjs: are you telling accessing anything (global) with a $ in its name is not viable with it?

Regarding servicenamespaces: the default behavior so that it generates Namespaces in par with the .NET classes was an intentional decision (this you can however override with JaySvcUtil settings). This we decided as a means to provide a more familiar client environment to C# (where you get those global namespaces after a service import). It is prone however to collide with existing objects with the same names.

What do you think a proper way to resolve this could be?

[RainerAtSpirit]

re angularjs: I can't find the specific place in their docs at the moment, but they encourage you not to use $ as starting char as this is reserved for all internal services like e.g. $resource, $injector` etc. http://docs.angularjs.org/api/. re servicenamespaces: This is probably more a documentation issue than anything else. Just point out that the auto-generated namespace might/should be updated to match the project's requirements.

[Micha4711]

I located a related defect, so I'm posting it in addition to this ticket.

jaydata.js uses Function.prototype to extend (any) function objects with methods like before(), after(), chain(), etc. This has major side effects to any external JavaScript Code, which uses identifiers like that on their local functions.

The result is, that JayData 1.1.1 is no longer compatible to the dojo framework, cause dojo uses before() and after() functions for it's dojo/aspect module. So, I had to patch JayData by myself to use it any longer.

Please get rid of any Function.prototype extensions and any other namespace issues, cause I really like to use JayData in my projects. ;)

I would really appreciate to see JayData AMD compliant: https://github.com/amdjs/amdjs-api/wiki/AMD

[PeterAronZentai]

Consider this sorted out. :) There will not be Function.prototype extends in 1.2 (coming in Sept).

Is any extension to a prototype "forbidden" even those created with defineProperty, marked as enumerable: false?

[Micha4711]

Thanks Peter! I'm looking forward to the next version. :)

I think extending or modifying a "global" prototype is always dangerous, because you might change the behaviour of all objects, which are derived from this prototype. In my opinion it's regardless whether the prototype is modified directly or via defineProperty().

I would recommend to use a "namespace" (encapsulating object) as only exported global, like RainerAtSpirit did (or even better, to be AMD compliant).

[RainerAtSpirit]

@Micha4711: I've added an AMD feature request to http://jaydata.org/backlogs. @PeterAronZentai: Here's a good discussion about cons/pros http://perfectionkills.com/extending-built-in-native-objects-evil-or-not/