we are working on a one page website project which wad already build in jquery and javascript at client side and cake php at service side but one for grid we want to use DGRID of dojo framework and for that when we try to integrate dgrid with our project we are getting this error
defineAlreadyDefined
In case we try to open another module because the content coming from AJAX and updated in same page.
We had included dojo.js in main page which loads only once and module included with require in each individual file.
Any help will be appreciated.
Well, this happens when we use two or more different libraries which expose same define method to create new widgets.
solution:
in our project we modified the name of exposed value like instead of define we replaced the customDefine in other widget so if we need define of first library we use define (as it was earlier) and if we need define of second library basically we used customDefine.
Note:- Before making above changed just verify that you are not adding same or similar libraries more than once in your project. In our project we were using dojo and d3 libraries.
This is how we resolved in our project.
Problem with almost similar solution - Trouble adding search widget to ArcGIS Shortlist Story App
hoping this will help you:)
Related
We have a React application created/deployed using CreateReactApp.
This application is able to display some widgets. We've predefined types of widgets deployed with our own application. We'd like the end-users of our application to be able to develop their own type of widgets - using a dev tool like Webstorm/VisualStudio - and deploy them into our application.
Our application needs to provide a public API and a plugin dev library
We want the plugins to be able to use the libraries our application is using (e.g. React, material-ui…)
We need a way to "load" end-user code that is registering new widget types using our public API.
Can we do that using CreateReactApp or do we need to eject?
What are the best practices for doing this?
I have more a suggestion than an answer, a best practice for that can depend on the structure of your current project, so I don't think there's a right answer. I wrote a small proof-of-concept, feel free to fork and use that, if it helps: https://github.com/anderick/react-dynamic-components.
Our application needs to provide a public API and a plugin dev library
To solve this you can create a folder structure to let users upload their component projects.
You need a name or id to link this new uploaded project so you can load it later.
We want the plugins to be able to use the libraries our application is using (e.g. React, material-ui…)
If the use is only allowed to use the libraries you already have, you don't need to worry about their package.json.
In case you want to allow users to use their own libs, it adds some complexity on how to process this during runtime.
We need a way to "load" end-user code that is registering new widget types using our public API.
You can use create-react-app in this approach, but you may need a good definition of an entry point (in my example project, I'm using Index.js as the file I'll use as the main component of the project), or some kind of descriptor(maybe extending package.json) so you can read from your application to understand how to load the component. I'd go with the first approach, convention over configuration is more simple, and you can expand from that with a descriptor later.
by ejecting you can customize anything you want but you've to configure and maintain it by yourself, I think going through CreateReactApp also a good idea based on your criteria. I hope this article may help you out.
Thank You!
MSS-
I'm looking for a way to implement "Plugins" for my Electron tool.
Below is a pseudo example of how I'm thinking it would work
Supply .js/.zip/plugin file
File would contain name of plugin, and it's category (Global, Team centric, Misc)
File would contain HTML for the GUI, which get's placed in a div designated for tool space. This name would be added as an option to the necessary Select, as well as logic added to pull in the HTML to the same div
In the tool, select the plugin file:
page will load the JavaScript script, and add option to select along with logic to switch to the plugin
The hope is to automate my current process.
Currently I'm manually updating the index page to reference the new JavaScript script, and to add the option on the select
The JavaScript Script has logic in it looking at the Select, and looking to see if the option was selected
which then pulls in it's own HTML via a function within
Is there anything I can reference/utilize to make this work?
After 4+ months of working on this, I've managed to get this to work. I will try to outline my approach.
Each "plugin" or "tool" will need it's own .js file
the js file should contain an exports.html function that will return the html for the tool
the js file should contain an exports.Events function that adds all relevant event listeners
create a json file cataloging each tool, along with information needed i.e. a description, image path, .js file path, etc.
require the .js file when selected, load the html and the events
parse the json to figure out which tool to load along with needed info
all i need to do is update the json file and upload the .js file to add a new plugin.
I developed an electron app using vue as the front-end.
My idea was to develop plugins as vue plugins and publish via npm.
I used live-plugin-manager to install and uninstall plugins.
The dependencies were automatically removed by making use of a counter
The only problem I faced was how to load these installed plugins into my main app.
The workaround I found was posted as answer to my own question at How to use electron to load the vue plugins installed dynamically into a plugins folder
Hope it helps
I know I'm a little late to the party but I encountered the same problem. To solve it I have built a plugin framework for Electron called Pluggable Electron and it is available on npm.
The framework handles the lifecycle of plugins, provides as npm packages, like installation, activation, removal, etc. The plugins can then be called on at any time to exend the core app functionality.
The framework is still under development but you can find a 1st version here: pluggable-electron.
I expect it is too late for Marker but still answering here for anyone else that might have this question.
I am adding logic to a custom module in its RecordView.
Now I want to be able to use the same code in my CreateActionsView.
How can one achieve this in an upgrade-safe approach in SugarCRM 7.2.x without having to copy and paste the same logic to the other view?
I should be able to do this by injecting my code to the stock record.js and then calling my functions from my inherited views but this would not be upgrade-safe.
You can package your common JS code as a separate script library and have it included into the page via the JSGroupings extension. If you extend one of the existing JSGroupings (such as sidecar.min.js) then that will ensure that your JavaScript is pulled into the page.
http://support.sugarcrm.com/02_Documentation/04_Sugar_Developer/Sugar_Developer_Guide_7.5/50_Extension_Framework/Extensions/JSGroupings/
By using an Extension, your addition of the JS code would be upgrade safe.
We are developing a javascript component to be used in a JSF app and we're using Dojo.
The thing is we only need specific parts of the library and we'd like to only insert into our webapp the files/folders we use to accomplish our goal.
We could do this 'by hand' but in the future we might need to add other functionality from Dojo and then we will not know what resources we need -> I guess by this moment you realised we are no Dojo/js gurus.
Basically we are looking for a way to automate this process. We were thinking of getting a list of the dependencies and then create a small script to 'filter' the files.
Is this possible ? Have anyone tried this before ?
Thanks.
I may be misinterpreting your request, but I think dojo does what you want out of the box. Since the latest versions of dojo follow the Asynchronous Module Definition (AMD) format, you use a global require function to describe what dependencies a specific block of code have, and only those modules are loaded. An example from the sitepen dojo intro:
require(["dojo/dom", "dojo/domReady!"], function(dom){
var greeting = dom.byId("greeting");
greeting.innerHTML += " from Dojo!";
});
If you only want to have to to load a single <script/> tag, you'll want to look into the dojo builder. Using the online build tool You can select what packages you want included into the dojo.js layer and it will bundle everything up into a zip file that includes dojo.js/dojo.js.uncompressed.js which contains dojo core in addition to the modules you selected.
Ok, we did this by doing the following (just in case anyone will need this):
* declare a JSF filter and map it to /js/* (all dojo resources are under /js folder, this may need to be modified to fit your folder structure); this way, all requests for a dojo resource will be filtered.
* in the filter class, get all the requested files: (HttpServletRequest) request).getRequestURI() and write it line by line in a file: now you have all the needed resources.
* parse that file with a script, line by line, and copy the files to another location -> build the folder structure.
* use the created files in your WebContent folder (or wherever you need it), you have a clean library -> you only deploy what you use.
The web is littered with full-blown JavaScript libraries who say they will save your day and make your web development life much easier. You get encouraged to include these “mere 80 kb” libraries that is supposed to be the solution to all your needs, and practically make the web site work by itself. Needless to say, I’m not a big follower of JavaScript libraries,, especially since they almost always include lots of superfluous code, so I thought I’d put together a tiny library with only essential JavaScript functions.
The result of that is EJ – Essential JavaScript.
EJ consists of functions that I use all the time and they make writing JavaScript go faster and the result is being able to do work more efficiently. It is also about having the things you would write again and again for every web site you produce in one neat and tiny file instead, to be able to focus on the new things you need to address
I'm creating a single page web application.
I created a basic design for the app structure. This answer about this video was very helpful.
The application contains one html page. The JS code will change it's content.
The Usher will supply a module according to the URL (domain.com/#list#item1 will return an item module).
The module will use the sandbox to retrieve data from the server (that will use the Application Core for that).
The module will set the page style by passing the sandbox an key-value list and will set the page HTML in this way too.
What do you think about it. Does it decoupled enough?
Short answer: Kind of. It depends on how complex your modules are.
Long answer:
I'm working on one application that respects the Core -> Sandbox Instances -> Modules pattern like you described.
The only unanswered question about my application is this:
"What happens when Module A and Module B have a small UI component that is the same, or almost the same?".
In your case, this might be an accordion on 3 modules out of 5. This accordion might be application specific, so simply adding a jquery plugin in core, and exposing it to the modules via Sandbox will just not cut it.
I ended up with two possible solutions:
1) Use the common functionality as a special type of module that can be requested via the sandbox by other modules. This is the case when just one instance of the UI will be visible at a given time - which might be your case -
2) Use a simple prototype instantiation for my reused object and add it as a dependency for all modules that use it.