StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
20423840
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
0
CommunityOwnedDate
CreationDate
2013-12-06T12:23:01.080
FavoriteCount
0
LastActivityDate
2013-12-06T12:23:01.080
LastEditDate
2017-05-23T12:08:23.183
LastEditorUserId
-1
OwnerUserId
1609791
ParentId
5980194
PostTypeId
2
Score
0
ViewCount
0
LastEditorDisplayName
text
Body
I've been googling and landed here so, I have to post some ideas: first I agree with @Raynos. The most code out there that tries to build a jQuery plugin actually...is not a plugin! It's just an object stored in memory which is refered by the data property of a node/element. That's because jQuery should be seen and used as a tool side by side with a class library (to remedy js inconsistencies from OO architecture) to build better code and yes this is not bad at all! If you don't like classical OO behaviour stick to a prototypal library like <a href="http://clonejs.org/" rel="nofollow noreferrer">clone</a>. So what our options really? <ul> <li>use JQueryUI/Widget or a similar library that hides technicalities and provides abstraction</li> <li>don't use them because of complexities, learning curve and god knows future changes</li> <li>don't use them becuase you want to insist on modular design, build small-increase later</li> <li>don't use them because you might want porting/connecting your code with different libraries.</li> </ul> Suppose the issues addressed by the following scenario (see the complexities from this question: <a href="https://stackoverflow.com/questions/7127600/which-jquery-plugin-design-pattern-should-i-use">Which jQuery plugin design pattern should I use?</a>): <blockquote> we have nodes A, B and C that store an object reference into their <code>data</code> property <blockquote> some of them store info in public and private accessible internal objects, some classes of these objects are connected with inheritance, all of these nodes also need some private and public singletons to work best. </blockquote> </blockquote> What would we do? See the drawning: <pre><code>classes : | A B C ------------------case 1---------- members | | | | of | v v v an object | var a=new A, b=new B, c=new C at | B extends A node X : | a, b, c : private ------------------case 2--------- members | | | | of | v v v an object | var aa=new A, bb=new B, cc=new C at | BB extends AA node Y : | aa, bb, cc : public -------------------case 3-------- members | | | | of | v v v an object | var d= D.getInstance() (private), at | e= E.getInstance() (public) node Z : | D, E : Singletons </code></pre> as you can see every node refers to an object - a jQuery approach - but these objects change wildely; they contain object-properties with different data stored in or, even singletons that should be...single in memory like the prototype functions of the objects. We don't want every object's function belonging to <code>class A</code> to be repeatedly duplicated in memory in every node's object! Before my answer see a common approach I've seen in jQuery plugins - some of them very popular but I don't say names: <pre><code>(function($, window, document, undefined){ var x = '...', y = '...', z = '...', container, $container, options; var myPlugin = (function(){ //<----the game is lost! var defaults = { }; function init(elem, options) { container = elem; $container = $(elem); options = $.extend({}, defaults, options); } return { pluginName: 'superPlugin', init: function(elem, options) { init(elem, options); } }; })(); //extend jquery $.fn.superPlugin = function(options) { return this.each(function() { var obj = Object.create(myPlugin); //<---lose, lose, lose! obj.init(this, options); $(this).data(obj.pluginName, obj); }); }; }(jQuery, window, document)); </code></pre> I was watching some slides at: <a href="http://www.slideshare.net/benalman/jquery-plugin-creation" rel="nofollow noreferrer">http://www.slideshare.net/benalman/jquery-plugin-creation</a> from Ben Alman where he refers at slide 13 to object literals as singletons and that just knock me over: this is what the above plugin does, it creates one singleton with no chance whatsover to alter it's internal state!!! Furthermore, at the jQuery part it stores a common reference to every single node! My solution uses a factory to keep internal state and return an object plus it can be expanded with a class library and split in different files: <pre><code>;(function($, window, document, undefined){ var myPluginFactory = function(elem, options){ ........ var modelState = { options: null //collects data from user + default }; ........ function modeler(elem){ modelState.options.a = new $$.A(elem.href); modelState.options.b = $$.B.getInstance(); }; ........ return { pluginName: 'myPlugin', init: function(elem, options) { init(elem, options); }, get_a: function(){return modelState.options.a.href;}, get_b: function(){return modelState.options.b.toString();} }; }; //extend jquery $.fn.myPlugin = function(options) { return this.each(function() { var plugin = myPluginFactory(this, options); $(this).data(plugin.pluginName, plugin); }); }; }(jQuery, window, document)); </code></pre> My project: <a href="https://github.com/centurianii/jsplugin" rel="nofollow noreferrer">https://github.com/centurianii/jsplugin</a> See: <a href="http://jsfiddle.net/centurianii/s4J2H/1/" rel="nofollow noreferrer">http://jsfiddle.net/centurianii/s4J2H/1/</a>
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POjQuery plugin template - best practice, convention, performance and memory impact
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USCommunity
UserOwnerUserId
1. UScenturian
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. This table or related slice is empty.
CommentsPostId
1. This table or related slice is empty.

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.