I'm developing a library which targets browser and server ( node.js ), when trying to create an SVG on the server i ran into the error "document is not defined", because for some reason d3.js depends on the document object.
So i reached out for d3-node which depends on jsdom and probably will end up creating issues when building this library for the client.
One thing that is unknown to me is the fact I wish to generate same charts but when running on the browser i would like them to be interactive, which is something i can completely ignore when generating offline charts.
So i'm wondering if it's possible and worth to have a library that targets both environments and if possible have one simple build which runs on both environments?
Can't we use d3.js and generate the SVG string without depending on "document"? I believe the answer will be "NO" if i want to attach DOM events right? Therefore its likely i need to simply make a client build with all the features and design the library in a way it's possible to render the chart without adding DOM events.
Related
is it possible to have a dojo build that works fine with rhino and browser environments.
I'm in need making server side export of dojo charts and for the server side dojo charts I'm using rhino.
This question is not very specific. The dojo build can run in node.js and rhino environment. But I assume you need a browser to run a dojo application, no matter if it is built into a 'layer' or not.
Of course -- due to the extensible nature of the dojo build system, you could do some hacks like replacing certain patterns in your code to fix some specific issues.
Maybe you could be more specific about your scenario.
I have a question for professional Orchard developers?
Given that I can create new ContentTypes and ContentParts using the UI, when should you use the UI to create new Content Types/Parts versus creating a custom module and coding everything. What are the tradeoffs? Is there a time to combine the approaches and create some of your content types/parts in the UI and then extend them further using code?
What are the advantages of each method? (For example, it seems to me that deploying changes is easier using code...but still possible using the UI using the Import/Export module?
UI it seems you get things done pretty quickly, but is less flexible and portable than writing code?
What are the things you HAVE to do in code?
I tend to start by using the UI to test ideas and just adding templates to my theme to display these new parts. I also use the UI when I just want to add a new part to an existing type.
Where I find making a very simple module with my types specified in migrations useful is where I have a site in production that I know will need upgrading in the future. I have a dev version of the site that I play about with and then when ready to go live I create a migration that will upgrade the site.
This also means I can test the migration before going live and I don't need to have a list of manual changes required to make to the live site that is prone to mistakes.
I'm transferring huge chunks of data while my users work with their forms. Besides trying to optimize the code to ensure for the fastest connections, I'd like to display a spinning image in the middle of the form to notify the user that the software is sweating it's parts of to get the info as quickly as possible.
I'd like to point to following considerations.
Can I use an arbitrary animated image (e.g. abc.gif)?
Is it possible (suggested, even) to use the default spinner seen in the CRM?
Can such a solution be applicable even for older versions of CRM?
IS is possible (recommended, maybe) to use jQuery and it's cool effects?
Yes you can use any animated gif. Add as a web resource in CRM 2011.
You can take the default spinner and add as a web resource. I'd strongly recommend you don't try and address it directly.
Yes but the way you manage your scripts is less prescribed. No solutions or web resources to use in CRM4.
Absolutely. See below.
The jQuery plugin BlockUI is one of the most popular for potentially long running OData calls from which you need to prevent further UI interaction.
Since you'll need to attach directly to a DOM element it's use won't be supported. However, as long as you stick with attaching to the <body> element and avoid digging too far down into the DOM like for example onto the markup for specific form sections you'll be OK.
For CRM 2011 we use our own Web Resource to wrap BlockUI providing a very simple API enforcing consistent binding to the <body> element which also checks for the inclusion of jQuery and BlockUI scripts (Web Resources) on the form.
Same deal applies for CRM 4 but script management is much more down to how your team are currently managing customisations and dependencies.
The easier you can make it to use, the less likely other developers on the team are to go off and try and roll their own causing horrible inconsistencies in the final UX.
I'm planning to start a web project soon. Which should be done first? Is it better to do the client-side scripting (HTML, CSS, JS, Design, etc) first, or is it better to create a very simple draft with barely any CSS with the server-side scripting (Ruby, PHP, Python, etc) then build the design and client-side on top of that?
I would start with the database models. I guess you want to store some data. Organize your data first. Then, if you use django (python), create a models.py.
Of course you can start with the front end first, too. But I would do it with a pencil and paper.
This is what I follow.
1.Choose your tools first.
2.Create a solid architecture(which can endure specification changes).
3.Create dummy inputs(no fancy stuff,just simple input boxes and buttons to send your data to the server)
4.Start with your scripting(PHP,python,ruby).
5.Proceed with the entire Design process from scratch creating templates(HTML),Styling them(CSS) and making them interactive(JS).
6.Tightly integrate all aspects.
Is it possible to modify/supplement code generated by PhoneGap to modify/add functionality? And how does this effect the application's likelihood of being accepted into the apps market?
The reason I am asking is because there are certain components of the desired iPhone application that we would like to have that we can not achieve with our converted CakePHP web application. These desired items include QR code scanning and augmented reality.
Yes, you can do that.
https://github.com/phonegap/phonegap-plugins
You can look there for already written (and validated) plugins.
If I remember correctly, a qrscanner plugin already exists.
Augmented reality it not really possible with phonegap. (At least not as far as I know) As you can't manipulate the camera view with phonegap.
Maby if you would write a plugin for it. But that would mean writing almost the whole application in objective-C.