Databases
StackOverflow2013
Postsdbo
POOOPs concepts into Javascript widget
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POOOPs concepts into Javascript widget
    primarykey
    data
    text
    <p>A simple javascript widget design question. I have started working in javascript fairly recently. And as part of my work, I intend to create a lot of reusable code; so for me javascript widgets seems like the best way to go. However I am faced with a design dilemma, and I am not able to find the right answer.</p> <p>I have a simple javascript widget, which alters the string in a html component. So my widget is somewhat like this:</p> <pre><code>(function() { var convertString = function() { $(".classForHtmlComponentsIWantToHandle").each(function(index, element) { //js_fu stuff done with string fetched from "element" }); }; var _somePrivateHelperMethod() { //some work that would have been impossible without this helper method }; GloballyDefinedNamespace.StringUtils = {convert : convertString}; }()); </code></pre> <p>this allows me to call later</p> <pre><code>GloballyDefinedNamespace.StringUtils.convert(); </code></pre> <p>Now if you would notice in my widget-ish function above, I extract all the HTML components from the DOM, that I want to alter string for. Interesting bit is that HTML will have span and divs with same css class and also textbox components with css class.</p> <p>Both have a different way of extracting their value and setting new value back. Based on my experience, if this is a widget to alter string then all it should care about is incoming object that "hold" string in a uniform manner and then based on a object expectations, my widget should be able to operate blindly. </p> <p>"if it sounds like a duck, walks like a duck, then it's a duck". Kind of thing.</p> <p>So effectively I would like to be able to NOT worry about distinguishing "element" object being a textbox or span in my widget. Instead wrap it into a generic wrapper. </p> <p>However people have advised me that in javascript widgets the usual convention is to take care of component specific stuff within widgets. I am not convinced, as I firmly believe in programming to interfaces and not specifics. So I am at conflict.</p> <p>In my example above, I don't think so the highlighted dilemma does justice to this problem, but on a larger scale this pops up as a question for me often.</p> <p>I would like to hear opinion from guys, as to how to build that component independence within my widget for an HTML DOM? Is a solution to create javascript wrapper objects with same interface and then css-select them separately and then make method call as following?</p> <pre><code>(function() { var locateAllComponents = function() { $(".generic-class").each(function(index, element) { //wrap element into suitable wrapper that has common interface for getter //setter. GloballyDefinedNamespace.StringUtils.convert(wrappedElement); }); }; }()) </code></pre> <p>Any insights and answers would be highly appreciated. </p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PTQuestion
    1. This table or related slice is empty.
    1. USPriyank
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POOOPs concepts into Javascript widget
      1. UShappytime harry
      1. VTFavorite
    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.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload