We have a large number of angularJS 1.5 directives (around 100) that we use throughout our applications. We also use slickgrid almost everywhere to display mass amounts of data. A project has recently come up where it would be ideal to be able to use our directives within slickgrid cells. So I've been trying to write a slickgrid editor to generate our directives when you go to edit one of the cells.
It seems as though angularJS doesn't pick up on the directive (because slickgrid doesnt operate within angular) and doesnt attach the element to its lifecycles. so basically the base element and its settings will appear in the HTML like this:
<div class="slick-cell l2 r2 active selected" title="">
<custom-directive></custom-directive>
</div>
but since angularJS doesn't process the directives there's no visible element in the view and none of the transcluded elements are created.
I've tried using $compile to sort of pre render the elements and then send them to slick grid, but that results in multilink errors which I'm not sure how to resolve.
I've also tried using a JS template with the hope that the template could be rendered and then used in a slickgrid editor later, but I haven't had success with that as of yet. I am still trying to make this approach work since I've seen other examples of using templates with slickgrid, but they aren't using angularJS so my situation doesn't quite fit to theirs.
To summarize I'm looking for suggestions on how I might approach this problem. I know slickgrid isn't technically supposed to be used in this fashion but there has to be a way to make this work. Reusing 100+ pieces of code to extend functionality here would be a very huge win.
We have a Angular 1.x app. Each screen/layout has multiple widgets. We have new requirement to inject a help icon into every widget. To make the setup less intrusive, we have come up with a controller which looks up for the widgets and then injects the icon dynamically.
I would like to ask the UI experts here regarding the appraoch to be used to select the widgets (and hence inject the icon into them). Is selecting by a CSS selector better than selecting by ID (say widget ID)? What are the pros and cons of both approaches?
Thanks,
Midhun
I believe the best way is to create attribute level directive instead.
it can be parameterized like help-article="create_category" or even using several attributes
it's safer to keep classes and id for styling while linking logic to custom attributes
more expected in angular world
Shorter question: how should toolbars be programatically created and dynamically changed in a D3.js app with a Python backend?
I'm trying to create Javascript/D3 visualizations for simulations written in Python and using Flask, as an alternative to using a Tkinter GUI. I want a particular model to be selected by a radio button. Changing the selection not only changes the plot, but also swaps to a toolbar of numerical inputs appropriate for that model. I want to create the toolbars programatically, so that as a new model is added to the code an appropriate toolbar is automatically generated.
My problem is that there are a lot of ways to manipulate the DOM, and it's not clear to me what the best approach would be:
Python/Flask could manipulate the DOM, but I think that requires a
page refresh.
If HTML imports were used, there would have to be a separate .html file for each toolbar.
A unique <div> could be created for each toolbar and hidden/unhidden as needed, but it feels wrong to create a dozen <div>s rather than swap the content of one <div>.
A toolbar <div> could be torn down/built up everytime a toolbar is needed, but it feels wrong to keep building the same toolbars from scratch.
innerHTML could be swapped, but this might be bad? cf. this SO question
There are multiple options for manipulating the DOM at the frontend: JS, D3, JQuery...
To illustrate, here is a screenshot of what I have so far. The radio buttons swap between two models. In lieu of a toolbar, I have a JSON dump of the model's toolbar info. The JSON dump would be replaced by its interpretation as a series of labels and numerical inputs.
I'm looking to put together a dynamic Web form where, when the customer selects options from a series of radio buttons, additional items will be added to the main image.
Think of it as if you had a Photoshop layer and all the other layers above could be hidden or revealed dependent on the customer's input on the form.
So, two questions...
I assume I should be using JavaScript for this form. Being a beginner with JavaScript, is there a way for me to tell it to change the image based on multiple inputs selected by the customer? The base image would be the same but I would be looking to hide/reveal multiple "overlays" on top of the base image.
Is this something that React can handle or should I be looking at something like Angular?
Thanks for your assistance with this question!
I can answer for number one by providing a live example: http://codepen.io/zvona/pen/mVQWvX
It consists of three components, FormControls, Blocks and App. Names are quite self-explanatory and so should be code itself. There may be some minor mistakes in code since it's quite quickly written on the fly, but it should give you insight on how this can be achieved with React.
I understand that content, presentation, and behavior are supposed to be separated by using HTML, CSS, and JS to implement them independently. Is there a best practice for binding these elements concretely while maintaining loose coupling in a dynamic web app? Is it even possible? Optimally without depending on jQuery?
To clarify what I'm talking about: HTML has no mechanism for the definition of new tags, so when your JavaScript model needs to generate content, the tags and structure for its presentation are necessarily defined in JS or somehow made accessible to it, tightly coupling behavior to content.
Before someone calls over-OOP, the reason I want to keep tags and CSS classes out of JS is that I don't even want to commit to HTML as a front end. There are at least five different representations of my underlying model that I'll eventually want, and tightly coupling the model to HTML rules out at least two of them.
Is there some way to late bind the model to the target representation without sacrificing dynamics or loose coupling? Like an XML document corresponding model elements to template HTML snippets?
UPDATE
Though it seems backward to provide concrete details of a question about factoring and OO best practice, I want to provide a much fresher example of the entanglement of form & function inherent to HTML. The entanglement of content & behavior between HTML and JS is the problem, though, not the example, and I want an answer that doesn't break when I change the details. It's from a very different project than the one I was working when I first asked this question, but the gist is the same:
I have some HTML for a UI widget. It is a view that represents a model object - a selection of palettes - to the user. Palettes themselves are part of the app's task, so they're not view, they're model.
I want to use this widget in at least 2 different dialogs (and any I might want in the future). In one, I need a changed selection to cause immediate action, the recoloring of a set of images in canvas elements that are part of the same dialog. In another, I just need to have two different sets to select from - one selection in each set.
I do not want to copy and paste this widget's HTML form or JS behavior because I want maintenance and revision to propagate from one base thing to all of its instances. Thus, only one instance of the widget, whatever its form may be, may exist in my source.
I do not want to have my JS rendering HTML tags directly because doing so will forfeit my IDE's error checking and content assistance on the HTML. Further, if there are problems with the HTML output, their source in my JS will be less clear because the process of generating the HTML doesn't look like HTML or necessarily reflect its structure. Finally, I want to test the effects of changes to the widget's CSS and HTML independently of my JS.
I do not want to involve additional dependencies e.g. separate templating & parameterization languages in my source because changes to various standards or evolving needs may break their compatibility, or they may themselves become unmaintained, in the future, leaving me with a massive quantity of useless source. Depending on jQuery is okay because it does more for normalizing between browsers (not to mention for convenience) than it is likely to ever break given its ubiquity, but other libraries will be regarded with extreme suspicion.
I want to specify the details of altering and retrieving the widget's state (what colors compose the palettes, how the user chooses among them) in JS that references only the widget and its component parts, since it's going to be a part of multiple dialogs that use its information in different ways.
Simultaneously, other JS code (the dialog's behavior) needs to be able to observe and initialize the widget's state - but without including any specific references to the widget's internal structure, which may some day change to accommodate new features, fix bugs, etc.
For simply making multiple copies of the widget's HTML, I can settle on calling jquery.clone on a template node that exists in an HTML file, and inserting the contents where I need them, from the function that sets up the dialog. HTML makes things difficult when any of the cloned elements have id or name attributes, but careful handling during cloning can make unique identifiers, point their corresponding label elements and href attributes at the new identifiers, and keep the old ones accessible in data attributes. So all is well and good for structure & content, and obviously the CSS presentation propagates to the clone just fine.
The rub comes when I try to implement the widget's interface with its dialog's controller. What is the most future-proof way to expose the widget's state's abstraction? I.e. I don't want to use widgetJquery.find('input:checked').val() to get the selected color from code that doesn't absolutely have to commit to a selection being based on a checked input element whose value attribute is a set of serialized colors.
I hope that makes it more clear what I'm looking for without muddling the question with details.
You can always have different XSLTs parse an XML.
But, it seems you try to abstract tooo much.
use the MVC, use different views to parse.
The methodology you write about is common in old systems, I worked with more than 10 years ago, there is probably a good reason evolution killed it.
Loose coupling is best achieved archtecturally using design patterns. A great example of how to achieve loose coupling is found in the Mediator Pattern. However, there are several patterns to use.
I suggest reading Addy Osmani's 'Essential JavaScript design Patterns' for comprehensive coverage of a range of patterns.
Enjoy!